There is a category of chargeback you cannot win, no matter how good your evidence is. And there is a version of that exact same chargeback that you cannot lose, no matter how thin your file. The difference between the two is not the customer, not the product, not the rebuttal letter you spent an hour writing at midnight. It's a single authentication step that happened — or didn't happen — before the money ever moved.

Most merchants never learn this. They learn the other thing instead: the slow accumulation of fraud disputes they respond to diligently, professionally, with screenshots and timestamps and delivery confirmations, and lose anyway. They start to believe the system is rigged against them. It isn't rigged. It's just that they showed up to a fight that was already decided in a room they didn't know existed.

What the liability shift actually is

When a cardholder disputes a transaction as fraud — I did not authorize this — somebody has to absorb the loss. The card networks decided long ago that the party who absorbs it should be the party who had the chance to verify the cardholder and declined to take it.

That's the whole logic. If you, the merchant, accept a card number without asking the issuing bank to authenticate the person typing it, you have accepted the fraud risk. If you do ask, and the bank authenticates them — approves them, vouches for them — the bank has now made a claim about that person's identity. When the real cardholder later says that wasn't me, the bank's own vouching is the thing that failed. The loss lands on the issuer.

The mechanism is 3D Secure, and its modern version is EMV 3DS (what you'll see as 3DS2). Visa and Mastercard both encode this in their dispute rules: a fraud chargeback filed against a transaction that carried a successful 3DS authentication is, in most cases, not a chargeback the merchant is allowed to be charged for. The issuer can't file it, or if it's filed, it's invalid on its face.

This is the closest thing to a guarantee in the entire chargeback system. Everything else you do — compelling evidence, AVS matches, delivery proof — is an argument. The liability shift is a rule.

The part everyone gets wrong

Here is where merchants lose money by believing they're protected.

The liability shift covers fraud. Only fraud. It covers the dispute where the cardholder says this transaction was not made by me. In Visa's taxonomy, that's the fraud dispute category — Card Absent Fraud. In Mastercard's, it's the no-cardholder-authorization reason code.

It does not cover product not received. It does not cover not as described. It does not cover cancelled recurring transaction, credit not processed, or duplicate processing. Those are consumer-dispute chargebacks, and 3D Secure has nothing to say about them. The customer authenticated. Nobody disputes they authenticated. They're disputing what happened after.

So a merchant enables 3DS, sees their fraud chargebacks drop to nothing, and then gets blindsided when disputes keep arriving under a different code. The protection didn't fail. It was never pointed at that problem.

And there's a second, sharper edge: friendly fraud. A customer who genuinely bought your product, used it, and then decided they'd rather have the money back has a strong incentive to file as fraud — it's the fastest path, and it requires them to explain nothing. If that transaction was 3DS-authenticated, the issuer should reject the fraud claim outright. What happens instead, often, is that the issuer re-files it under a consumer-dispute reason code. Now you're in a fight again, but on different ground. The liability shift didn't lose. It just moved the argument.

Why you're not already using it everywhere

If 3DS is this powerful, the obvious question is why any merchant would let a single transaction through without it.

Because authentication is friction, and friction is expensive. Every 3DS challenge is a moment where your customer is bounced to a bank screen, asked for a code, and given a clean opportunity to reconsider the purchase entirely. Some of them fail the challenge because they've changed phones. Some abandon out of confusion. Some never come back. The behavioral economics here are unforgiving: a checkout interruption doesn't just cost you the seconds it takes: it re-opens a decision the customer had already closed. Anything that reintroduces deliberation into a purchase re-exposes it to hesitation.

This is why 3DS2 was built the way it was. It sends the issuer a rich bundle of data about the transaction — device, history, behavior — and lets the issuer decide whether a challenge is warranted. Most of the time it isn't, and the authentication happens invisibly, frictionlessly. The customer sees nothing. You still get the liability shift.

That frictionless path is the whole game. The naive framing — "3DS costs conversions, so I'll skip it" — is a decision made against the old, clunky version of the technology.

In Europe, incidentally, the choice was made for you. Under PSD2's Strong Customer Authentication requirements, most online transactions must be authenticated, with a defined set of exemptions — low-value payments, transaction risk analysis, merchant-initiated transactions, and cardholder-trusted-beneficiary listings among them. And there's a trap inside the exemptions: when you claim an exemption, you're generally the one taking the fraud liability back. The exemption buys you frictionlessness by selling back the protection. That is sometimes the right trade. It should never be an accidental one.

Your next moves

  • Open your last twenty fraud disputes and check, one by one, whether 3DS authentication was present. In Stripe, the payment intent's charge object records the authentication outcome under the card's three_d_secure details. If a dispute is coded as fraud and the charge shows a successful authentication, you are not arguing — you are pointing at a rule. Say so explicitly in your response and name the authentication result.
  • Build a Radar rule that requests 3DS conditionally instead of never or always. Start with the transactions where fraud actually hurts: high ticket value, first-time customer, billing country mismatched to IP country, card issued outside your normal market. Let everything else through frictionlessly. This is a fifteen-minute change in the Radar rules editor.
  • Re-code the last quarter of your chargebacks by dispute category, not by dollar amount. Split fraud from consumer-dispute. If your losses are mostly consumer-dispute, 3DS is not your lever and no amount of authentication will help — go fix your billing descriptor, your delivery proof, or your cancellation flow instead.
  • If you sell into the EU or UK, audit which SCA exemptions your integration is silently claiming. Every exemption you request is a fraud liability you're taking back onto your own balance sheet. Decide that deliberately, per exemption, and write down why.
  • Turn on 3DS for every subscription's initial transaction, even if you leave later renewals unauthenticated. The first charge is where the cardholder relationship is established, and merchant-initiated renewals inherit from it. Authenticating the setup is cheap; authenticating every renewal is a conversion tax you don't need to pay.

The disputes that are left

Do all of that and something clarifying happens. The fraud chargebacks — the ones that were never winnable on evidence, the ones that made you feel like the system was arbitrary — mostly stop arriving. What remains is the honest fight: the customer who forgot the subscription, the buyer who says the file never downloaded, the person who genuinely believes they were wronged. Those are disputes with a real answer buried somewhere in your Stripe logs and your support inbox. They're winnable. They just require someone to go find the answer and write it down inside the seven-day window, on a day when there's already too much else happening.

That's the part Argeback handles. It watches your Stripe account, pulls the dispute the moment it lands, assembles the evidence that actually maps to the reason code — the authentication result, the delivery record, the support thread where the customer said thank you — and drafts a response you approve from your phone before the deadline closes. You brought the fraud losses down by fixing the front door. Let something else make sure the back door gets answered. See how it works →