3-D Secure and Liability Shift: Who Pays When the Chargeback Lands

October 29, 2026 - RiskRampart

Most fraud controls argue about probability. 3-D Secure argues about responsibility. When a cardholder completes the authentication challenge, the liability for fraud related chargebacks on that transaction generally moves from the merchant to the card issuer. That single legal fact makes 3DS different from every scoring tool in the stack, and it is why the argument about it should start with liability, not with friction.

What actually shifts, and what stays

The shift covers chargebacks where the claim is that the cardholder did not authorise the transaction, the classic stolen card fraud case, on transactions where authentication completed successfully under the scheme rules. It does not cover friendly fraud, where the real cardholder claims a genuine purchase was not theirs in the chargeback reason codes that fall outside the shift, and it does not cover goods not received, not as described, or cancelled subscription disputes. A merchant who enables 3DS and cancels their other controls has misunderstood the product completely. 3DS answers one question, was this the cardholder, and stays silent on every other reason money comes back.

The details vary by card scheme and region, and exemptions matter: low value transactions, certain recurring payments, and in some markets transactions where the issuer chose not to challenge can carry different liability treatment. The processor's documentation for your exact setup, not a blog summary, is the authority, and the fraud team should be able to quote its own configuration's rules without looking them up during a dispute.

Frictionless versus challenge flows

Modern 3-D Secure, the second generation, lets issuers authenticate many transactions silently using data passed with the payment: device, account history, address, transaction patterns. Those frictionless authentications usually carry the liability shift with no customer interruption at all. When the issuer wants more, the customer gets a challenge, typically a bank app approval or a one time code, and that is where conversion meets its cost.

Challenge completion is where merchants lose sales they never see itemised. A code sent to an old phone number, a banking app the customer never installed, a challenge screen that looks like a phishing page because, to a careful customer, it does. Track challenge initiation, completion, and abandonment as a funnel of its own. The liability shift on completed challenges can look wonderful while the abandoned challenges quietly eat more margin than the fraud did.

Where to require it, where to let it ride

In markets where strong customer authentication is mandated for most electronic payments, the decision is largely made, and the work is optimisation: maximise frictionless outcomes with clean data, and make challenges as survivable as possible. Where it is optional, the rational pattern is risk based: require 3DS where the liability shift is worth the friction, high value, risky categories, signals that worry the scoring system, and let clean, low value, repeat customer transactions run without it.

That selectivity is itself a signal to maintain. Issuers see which merchants challenge everything and which challenge intelligently, and frictionless rates respond to the data quality and behaviour of the merchant's whole flow. Treating 3DS as a switch you flip once, rather than a relationship with issuer models you feed with good data, leaves the best outcomes unclaimed.

Build the reporting around the shift

Report three numbers monthly: the share of volume authenticated, the fraud chargeback rate on authenticated versus unauthenticated transactions, and the challenge abandonment cost in lost orders. With those three, the 3DS conversation becomes arithmetic: liability avoided, minus conversion lost, equals the programme's value, per segment, so it can be widened or narrowed where the numbers say.

Without the third number, the programme will always expand, because its benefits arrive as chargebacks that visibly did not happen and its costs leave as customers who silently did not buy. Costs that leave silently always win budget arguments they should lose.

Keep reading

Frequently asked questions

What is liability shift in 3-D Secure?

When a transaction completes 3-D Secure authentication successfully, liability for fraud related chargebacks, where the cardholder denies authorising the payment, generally moves from the merchant to the card issuer under the scheme rules.

Does 3-D Secure protect against all chargebacks?

No. It addresses unauthorised use claims. Chargebacks for goods not received, items not as described, cancelled subscriptions, and much friendly fraud sit outside the shift, so other controls and good records are still necessary.

Why do customers abandon 3-D Secure challenges?

Usually mundane reasons: a one time code sent to an outdated number, a banking app they do not have, or a challenge screen they cannot distinguish from phishing. Challenge initiation, completion, and abandonment should be tracked as their own funnel.

Should every transaction use 3-D Secure?

Where it is not mandated, risk based use is usually best: apply it to high value and higher risk transactions where the liability shift is worth the friction, and let clean low value repeat purchases run without a challenge. Measure both the fraud saved and the sales lost.