Portreeve
explainer · 7 Sept 202611 min read

A chargeback for fraud usually isn't: what Visa 10.4 means

A chargeback for fraud means the cardholder tapped 'I didn't authorize this.' What Visa 10.4 lets you argue, and the logging that decides it months ahead.

You open the dashboard and there is a chargeback for fraud against a customer who has been paying you since March. Same email as the card's billing contact. Forty logins from the same laptop. A support ticket in July asking how to widen a CSV export. Stripe's reason field on the dispute says fraudulent.

Nobody investigated that customer. The cardholder opened their banking app, tapped the line item, and picked an option from a short list. One option is always some version of "I didn't authorize this." On a card-absent sale, that answer routes the case to Visa dispute condition 10.4 or Mastercard 4837, and those codes are where the merchant has the least room to argue.

The code describes what the cardholder claimed. It also decides what you are allowed to say back.

The fraudulent chargeback reason code is a dropdown selection

Stripe's documentation is unusually direct about this category. The Fraudulent reason "is the most common reason for a dispute and happens when a cardholder claims that they didn't authorize the payment," and "this is a difficult dispute type to win because in many cases the reason for the dispute is correct," per Stripe's dispute categories reference. Both halves hold at once. It is the most common code, and it is often accurate, and neither fact tells you which one you are looking at.

Stripe's Fraudulent bucket holds Visa 10.1 through 10.5 alongside Mastercard 4837 and 4863, mapped together because the general claim and the required evidence are the same shape. For a software business selling online, nearly everything that lands in it is 10.4 or 4837.

The issuer's incentive explains the rest. Refunding the cardholder provisionally and passing the case to the acquirer costs the issuer almost nothing. Refusing the cardholder costs them a phone call and a relationship. So the claim gets coded and forwarded, and the burden of proof lands on you.

Reason code 10.4 and Mastercard 4837 permit different arguments

Visa 10.4 is "Other Fraud - Card Absent Environment." Stripe describes it as the cardholder claiming they did not authorize a transaction that took place online, over the phone, or through a mobile app, and lists the evidence that speaks to it: AVS and CVV match results, "device and IP address data" showing the transaction came from a known device or a location consistent with previous activity, and the pattern of prior legitimate purchases, per Stripe's reason code reference.

Mastercard 4837 is "No Cardholder Authorization." Same claim, and for the card-not-present case Stripe lists the same evidence: 3D Secure proof, AVS and CVV, IP and device data, support conversations.

The asymmetry is in the remedy. Visa 10.4 has a structured path with a defined pass condition, Compelling Evidence 3.0, and Stripe implements it as a first-class object on the dispute. The enhanced_eligibility_types array carries visa_compelling_evidence_3 when the charge qualifies, and there is a matching enhanced_evidence object you fill in, per Stripe's CE 3.0 documentation. Nothing equivalent exists for 4837. On Mastercard you are writing a narrative and hoping an analyst reads it carefully. On Visa you can meet a checklist.

One aside on the neighbouring code. Visa 10.5 disputes "are extremely rare and have no recourse to remedy the dispute," and Visa accepts no evidence for them at all. Accept it and move on.

Real fraud arrives in a burst, friendly fraud arrives alone

Work out which of the two happened before you decide anything, because the fixes have nothing to do with each other.

A stolen card that actually got used on your product looks like a cluster. The card was bought as one of a batch, tested somewhere, and spent quickly across several merchants before the real cardholder noticed. You usually see the neighbours: several attempts in a short window, distinct cards from one device, small amounts first. That is a card testing problem at the front door, and the dispute is a symptom arriving weeks later.

A single fraud-coded dispute at month three, against an account that verified an email, logged in forty times from one device, and filed a support ticket, is a different animal. Thieves do not maintain accounts. They do not use the product in August and dispute the March charge in September.

Two more tells. Compare the age of the charge to the age of the account, because someone whose card was genuinely used without permission usually finds out by reading a statement, and statements arrive monthly. And check whether the issuer flagged the card on its own: Stripe surfaces issuer fraud reports as early fraud warnings sourced from Visa's TC40 reporting, and they arrive separately from disputes. An unauthorized transaction chargeback with no prior fraud report on the card is a cardholder's assertion and nothing more.

If it is your customer, the code still says fraud and the network still counts it. What changes is that you now have something to prove.

What Compelling Evidence 3.0 requires

CE 3.0 is the rule that made 10.4 winnable for card-absent merchants. Before it, "proof of authorization" for an online sale meant a signature that does not exist. You can now win by showing history instead.

Stripe documents the qualifying criteria as: at least two previous transactions on the same payment method, paid, undisputed, and not validation charges; each of them within 120 to 364 days of the disputed transaction; product descriptions supplied for all three; the disputed transaction categorized as merchandise or services; and a data match across all three transactions, per Stripe's CE 3.0 documentation.

The data match is the part people get wrong. It is not "any one matching field."

ElementClass
Customer purchase IPMain
Customer device fingerprint, or customer device IDMain
Shipping addressSecondary
Customer email addressSecondary
Customer account IDSecondary

You need two main elements, or one main plus one secondary. Device fingerprint and device ID together is explicitly not a valid pair, which means every qualifying combination contains either the purchase IP or a device identifier. Email address and account ID, the two things a SaaS logs by default, are both secondary, and two secondaries do not qualify.

So the dispute you are looking at today was decided in March, by whether your checkout recorded an IP and a device identifier next to the user id on every successful charge. Not the disputed one. The earlier ones.

IP is the cheap half. It is already on the request, and it fills customer_purchase_ip on all three transactions if you stored it against the charge. The device identifier is the half people skip, because it needs a script that was already running a year ago and a token that survives a browser update rather than a user agent string that does not. If you are starting from nothing today, that is the thing to add today, and the shape of it is covered in the device fingerprinting docs. The evidence pack for a friendly fraud dispute is the rest of the work; CE 3.0 is the part with a defined answer.

Stripe autofills what it has and flags eligibility for you. It can only match on data it received.

How to fight a fraud chargeback, and when not to

"Fight every chargeback" is bad advice for a small team, and the fee schedule is why.

For disputes received after 17 June 2025 in the US, Stripe charges a $15 fee when the dispute arrives and another $15 when you counter it, and the counter fee comes back only if you win; a partial win returns nothing, per Stripe's dispute pricing update. In the UK it is £20 and £20, in the EU €20 and €20. A $29 subscription charge you fight and lose costs $59. The same charge accepted costs $44.

So the triage is short:

  1. Look at enhanced_eligibility_types on the dispute. If it contains visa_compelling_evidence_3, counter. Stripe has done most of the assembly, and required_actions tells you what is still missing.
  2. If it is not CE 3.0 eligible, ask one question: do you have login or usage activity from the same device after the disputed charge? If yes, and the amount beats the counter fee plus twenty minutes of your time, counter with that log as the first page.
  3. If the answer is no, accept it. A rebuttal that says "the account existed" does not address the claim, which is "I am not the person who made it."

Accepting is cheaper, not free. The dispute counts against you whether you win, lose, or never respond.

A merchant on Hacker News, chasebank, described where a decade of this ends up: "Now we don't even fight chargebacks, we just hook into the visa RDR network or Ethoca's dispute mgmt tool, autorefund and move on." That is a rational endpoint for any single dispute and a bad one for the ratio.

3-D Secure moves the liability and takes conversions with it

The standard second piece of advice is to turn on 3-D Secure. The liability shift is real: Stripe lists successful 3D Secure authentication as one of the ways to overturn a fraudulent dispute, and supplies the ECI for you.

Two problems with the blanket version.

3DS solves the case you probably do not have. Someone committing first-party fraud passes the challenge on their own phone, because it is their phone, and disputes anyway. You have added a step that fails for some share of every legitimate checkout in order to stop a behaviour that does not happen at checkout.

And the shield is conditional. Under the Visa Secure Excessive Fraud Program, a US business that meets or exceeds both $75,000 in monthly fraud volume on 3DS-authenticated payments and a 0.9% fraud rate on them loses "liability shift on domestic 3DS transactions" until it fully exits the program, per Stripe's monitoring programs page. Authentication does not make fraud someone else's problem forever.

Selective step-up is the honest version. Request 3DS on the slice that looks risky: a new card on a new account, a mismatch between card country and IP country, a first charge well above your normal ticket. Leave the returning customer on the same device alone.

One counter-consideration if you are already in trouble. Mastercard's Excessive Fraud Merchant program applies only to accounts meeting all four of its conditions, and one of them is that 3DS payments are 10% or less of Mastercard payment count in non-regulated countries. If your 4837 rate is already high, raising 3DS coverage is one of the levers that keeps you out of that program.

The ratio is what ends the account

The transaction is the small number. Visa's Acquirer Monitoring Program counts disputes and fraud together: all payment disputes from TC15 reporting, plus early fraud warnings from TC40, measured against the total count of your captured payments. Non-compliant is a count of 5 and a ratio of 0.5%. Excessive is 1,500 and 1.5% outside CEMEA. A transaction that appears in both the TC40 and TC15 reports is counted twice, all per Stripe's monitoring programs page. Mastercard's Excessive Fraud Merchant program counts fraud chargebacks under 4837 and 4863 specifically.

Visa excludes a TC40 fraud report from the VAMP count if it qualified for Compelling Evidence 3.0. The same logging that wins you the $29 also removes the mark from the ratio that can cost you card acceptance. That is the actual return on writing an IP and a device token next to a user id.

CE 3.0 only ever covers the customer you already have history with. It does nothing about the account that will dispute its first charge, and nothing about that person coming back next month with a new email. Those have to be stopped at the front, because after the fact they are counted regardless of outcome.

That is the tool I built. Portreeve takes one call at checkout_attempt and returns allow, review, or block with reason codes in under 100 ms, and its identity graph links accounts across hashed email, device fingerprint, and card fingerprint, so reporting the dispute in front of you marks the whole linked cluster rather than one account: portreeve.feedback({ kind: "external_user_id", value: userId }, "chargeback", "stripe dispute du_..."). The feedback docs cover the three outcomes. A review never blocks anyone, so the suspicious repeat buyer completes checkout while the event lands in a queue for you, which is what each verdict means in practice.

Whatever you use, the property that matters is that the memory outlives the email address, because the email is the one identifier the person on the other side can replace for free.

Portreeve's free tier screens 1,000 events a month with no card: sign up and wire one call.

← Back to all posts