Does 3DS2 Shift Chargeback Liability? Which Disputes It Covers and Which It Doesn’t

Yes, but only for a specific slice of chargebacks. And the gap between what merchants expect and what actually happens is where the money gets lost.

When a card-not-present transaction is authenticated through 3DS 2.0, liability for certain fraudulent chargebacks shifts from the merchant to the issuing bank. That is the deal the card networks struck when they built the protocol. But “certain fraudulent chargebacks” is doing a lot of work in that sentence. Most merchants hear “liability shift” and assume they are covered across the board. They are not. The protection is narrower than the marketing around it suggests, and the disputes it leaves uncovered are exactly the ones that tend to escalate.

What the liability shift actually protects

The shift kicks in on one category of dispute: unauthorized transaction claims. A cardholder says “I didn’t buy that,” the issuer files a chargeback under a fraud reason code, and because the transaction was authenticated via 3DS 2.0, the issuer absorbs the loss instead of the merchant.

This applies whether the authentication was challenge-based (the cardholder completed an OTP or biometric step) or frictionless (the issuer approved the transaction silently based on risk signals). Both paths count. The liability shift also holds in a scenario merchants often overlook: when the merchant requests 3DS 2.0 authentication but the issuer’s system doesn’t support it or fails to respond. Under Visa and Mastercard rules, an attempted authentication where the issuer couldn’t participate still transfers liability. The merchant tried. The issuer’s infrastructure didn’t show up. That distinction has saved merchants real money in arbitration cases, particularly in markets where issuer-side 3DS adoption still lags behind acquirer readiness.

Where the protection stops

Here is where merchants get burned. The liability shift covers fraud disputes. It does not cover anything else. And “anything else” turns out to be a large and growing portion of the chargebacks hitting most merchants.

Product and service disputes sit entirely outside the shift. If a customer says the item arrived damaged, wasn’t as described, or never showed up at all, that chargeback lands on the merchant regardless of whether 3DS 2.0 authentication happened. The card networks treat these as fulfillment failures, not fraud, and authentication has nothing to say about whether you shipped the right product.

Processing errors are another blind spot. Duplicate charges, incorrect amounts, wrong currency conversions. These are merchant-side mistakes, and no authentication protocol is going to absorb the cost of your billing system misfiring.

Recurring payments create a particularly tricky gap. The initial transaction might be fully authenticated through 3DS 2.0, but subsequent subscription charges typically run as merchant-initiated transactions without cardholder authentication. Those later charges carry no liability protection. A customer who signed up six months ago and now disputes charge number five is filing against an unauthenticated transaction, and the merchant owns that loss entirely.

That last row matters more than most payment teams realize. Friendly fraud, where the actual cardholder made the purchase but disputes it anyway, often gets filed under non-fraud reason codes. The cardholder claims “not as described” instead of “I didn’t do this.” When that happens, the liability shift doesn’t apply, even though the underlying behavior is fraudulent. The reason code on the chargeback determines protection, not the reality of what happened. And issuers have little incentive to reclassify these, because the current coding keeps the loss on the merchant’s side.

The exemption trap

3DS 2.0 introduced transaction risk analysis (TRA) exemptions, letting merchants skip authentication on low-risk payments to reduce friction at checkout. The catch: if you request a TRA exemption and the transaction turns out to be fraudulent, the liability stays with you. You asked to skip the authentication. The network honored that request. Now you own the outcome.

Low-value exemptions work similarly. Transactions under €30 in Europe (under PSD2 rules) can bypass Strong Customer Authentication. But the liability shift doesn’t follow. The calculus here is straightforward but easy to get wrong. If your average fraud loss on sub-€30 transactions exceeds the conversion lift from skipping authentication, the exemption is costing you money. Smart payment teams track exemption usage against fraud rates on a rolling basis and pull back when the numbers turn.

Secure corporate payment exemptions and trusted beneficiary listings carry the same trade-off. Every exemption pathway under 3DS 2.0 trades liability protection for checkout speed. That’s a valid trade in many cases, but only when someone is actually watching the fraud data.

What this means for payment architecture

The liability shift is a risk management tool, not a chargeback elimination tool. The merchants who get this right treat 3DS 2.0 as one layer in a stack that includes pre-authorization fraud screening, post-purchase dispute management, and real-time transaction monitoring.

Consistency across your payment routing matters here. When you’re sending transactions across multiple processors and geographies, keeping authentication logic uniform gets complicated fast. A transaction routed through one processor might trigger 3DS, while the same card through another processor might not, and the liability implications are completely different. Payment orchestration platforms exist to solve exactly this problem, enforcing authentication policies from a single control plane regardless of which PSP handles the settlement.

Conclusion

The real risk isn’t that 3DS 2.0 doesn’t work. It does what it was designed to do. The risk is building your chargeback strategy around a protection that covers maybe 30 to 40 percent of your actual dispute volume and assuming it handles the rest. Knowing precisely where that line falls, dispute type by dispute type, reason code by reason code, is what separates a payment team that budgets accurately from one that keeps getting surprised by the quarterly bill.