3D Secure Liability Shift: What It Covers and What It Doesn't

Turn on 3D Secure and fraud chargebacks shift to the card issuer. That is the pitch, and it is true as far as it goes. The liability shift covers one family of disputes, excludes several high-risk merchant categories entirely, and does nothing for your Visa monitoring ratio.

This guide sets out what the 3D Secure liability shift covers under the card network rules, what it does not, and how to decide where to use it. The Visa material comes from the Visa Core Rules and Visa Product and Service Rules dated 18 April 2026, and the Mastercard material from the Mastercard Chargeback Guide, Merchant Edition, dated 19 May 2026.

What the 3DS liability shift means

When a cardholder disputes an online charge as fraud, the loss normally lands on the merchant. A liability shift moves that loss to the card issuer instead. With 3D Secure, the logic is straightforward: the issuer verified the shopper before the payment was authorized, so the issuer carries the fraud risk if that verification turns out to be wrong.

The 3DS liability shift applies to fraud disputes only. A cardholder who admits making the purchase but says something went wrong with it can still dispute, and for many high-risk merchants those claims are most of the dispute volume.

How 3D Secure works

3D Secure, or 3DS, is the protocol that lets the card issuer check that the person paying online is the cardholder before the payment is authorized. A 3DS payment is simply a payment the issuer verified this way. Each network brands its own version: Visa Secure (formerly Verified by Visa) and Mastercard Identity Check (formerly SecureCode). The current version, EMV 3DS, sends the issuer information about the device and the order. The issuer can approve the shopper silently, called a frictionless flow, or challenge them with a one-time passcode or a banking-app approval.

The result travels with the authorization. On Visa, a successful authentication produces a cryptogram called the Cardholder Authentication Verification Value (CAVV) and an Electronic Commerce Indicator (ECI) of 5. When the issuer or the cardholder is not participating in Visa Secure, the issuer or Visa can return what Visa calls an attempt response, and the transaction carries ECI 6. A transaction with no authentication carries ECI 7. The dispute rules look at those values, which is why a 3DS integration that drops them from the authorization request gets none of the protection described below.

What the Visa liability shift covers

Visa's fraud dispute for online and phone orders is dispute condition 10.4, Other Fraud – Card-Absent Environment. It applies when the cardholder denies authorizing or taking part in the transaction. Visa's rules list the transactions on which a 10.4 dispute is invalid, and two of them are the liability shift:

• A transaction processed with ECI 5, where the issuer responded to the authentication request with an authentication confirmation using Visa Secure with EMV 3DS, and the CAVV was included in the authorization request.
• A transaction processed using EMV 3DS with ECI 6, where the issuer, or Visa on the issuer's behalf, responded with an attempt response and a CAVV, and the CAVV was included in the authorization request. This does not apply to non-reloadable prepaid cards.

Two details matter. First, the protection turns on the issuer's response and the CAVV, not on whether the shopper saw a challenge screen, so a frictionless approval counts. Second, the attempt case means you can be protected even when the issuer or cardholder is not enrolled in Visa Secure, provided the attempt response and CAVV came back and were sent with the authorization. The exception is a non-reloadable prepaid card, where an attempt does not shift liability.

The Visa merchant categories the shift does not protect

This is the part most 3DS sales pitches leave out, and it falls squarely on high-risk businesses. For US domestic transactions, Visa's rules say a 10.4 fraud dispute applies regardless of the ECI value when the merchant is classified under any of these merchant category codes (MCCs):

• 4829, wire transfer and money orders
• 5967, direct marketing – inbound teleservices merchants
• 6051, non-financial institutions selling foreign currency, money orders, travelers cheques and debt repayment
• 6540, stored value card purchase and load
• 7801, government-licensed online casinos
• 7802, government-licensed horse and dog racing
• 7995, betting, including lottery tickets, casino gaming chips and off-track betting

Visa also requires US acquirers to tell merchants in these categories that their authenticated transactions are not eligible for protection from 10.4 disputes. If your account is coded under one of these MCCs, authenticated fraud disputes still land on you. Confirm your MCC with your processor before you count on the shift. 3DS can still be worth running, because an issuer that authenticates the shopper is less likely to approve a stolen card in the first place, but the liability shift itself does not apply.

What the Mastercard liability shift covers

Mastercard's equivalent fraud chargeback is message reason code 4837, No Cardholder Authorization. The Chargeback Guide lists among the transactions ineligible for it any transaction properly authenticated in authorization with a Security Level Indicator (SLI) of 211, 212, 217 or 242, naming Identity Check and Digital Secure Remote Payment as examples. In Mastercard's coding, 212 is a fully authenticated Identity Check transaction and 211 carries an attempt, so as on Visa an attempt can protect you. Our guide to Mastercard's chargeback reason codes covers the full set of 4837 conditions.

Mastercard extends the protection beyond the first charge. The same rule covers any subsequent transaction related to the original authenticated one, such as a partial shipment or a recurring payment. For a merchant-initiated transaction that relates to a prior authenticated cardholder-initiated transaction (SLI 212 or 242), the Chargeback Guide says the issuer should not use 4837 and should consider a different reason code, such as a cardholder dispute of a recurring transaction. The issuer can still use 4837 if neither it nor the cardholder can link the charge to the authenticated one after reasonable effort, and the acquirer can answer with evidence of that link. That is a reason to authenticate the first payment of a subscription and to keep the record of it.

Does 3DS2 change the liability shift?

EMV 3DS, often called 3DS2, is the current version of the protocol, and the Visa and Mastercard rules quoted above are written for it. The mechanics of the shift are the same as they have always been: the issuer's authentication response, carried in the ECI and CAVV on Visa and the SLI and authentication value on Mastercard, is what the dispute rules check.

What 3DS2 changes is how often shoppers are approved without a challenge. Because the issuer receives device and order data with the authentication request, more transactions clear through the frictionless flow, and a frictionless approval shifts liability exactly as a challenged one does. If your integration still references the old redirect-based flow, confirm with your gateway that you are on EMV 3DS, since that is what the current rules describe.

"Successful liability shift for enrolled card is required": what the error means

Some gateways can be configured to block any payment that would settle without the liability shift. When that rule is on and a card enrolled in 3D Secure fails to produce a successful authentication, the payment is declined with a message along the lines of "successful liability shift for enrolled card is required." The card was enrolled, authentication did not complete successfully, and the gateway refused to let the transaction proceed unprotected.

The usual causes, and what to do about each:

• The shopper abandoned or failed the challenge. They closed the passcode screen or entered the wrong code. Invite them to retry, and check that your challenge window renders properly on mobile, where most abandonment happens.
• The issuer's authentication system returned an error. Issuer-side outages happen. A retry minutes later often succeeds; a pattern of failures from one issuer is worth raising with your gateway.
• The authentication result never reached the authorization. If your integration does not pass the ECI and CAVV through exactly as received, the gateway sees no successful shift even when the shopper authenticated. This is an integration fix, and it is worth making regardless of the error, because it is also what the dispute protection depends on.

If the rule is blocking more good orders than it saves in fraud, most gateways let you relax it for specific order types rather than switching it off entirely.

The chargebacks 3D Secure does not stop

The liability shift moves fraud liability. It does nothing for the disputes where the cardholder admits making the purchase. On Visa, those sit under different dispute conditions, and the fraud exclusions above do not apply to them:

• 13.1, merchandise or services not received
• 13.2, cancelled recurring transaction
• 13.3, not as described or defective merchandise
• 13.5, misrepresentation
• 13.6 and 13.7, credit not processed and cancelled merchandise or services
• The processing error disputes in group 12, such as duplicate processing or an incorrect amount

For a subscription business, a supplement seller or a coaching program, those are often the bulk of the dispute volume. A customer who forgot to cancel files 13.2 whether or not the first charge was authenticated. A customer unhappy with results files 13.3. Fixing those means clear descriptors, cancellation flows, delivery evidence and a refund policy that follows the refund-policy rules the card networks set — not authentication. A shopper who authenticated and then says the goods never came is making a 13.1 claim, and you answer it with delivery proof like any other.

Authenticated fraud still counts toward your VAMP ratio

Since June 2025, Visa's Acquirer Monitoring Program (VAMP) measures card-not-present merchants with one ratio: the count of fraud reports (TC40) plus disputes (TC15), divided by the count of settled transactions (TC05). Visa's VAMP fact sheet lists two exclusions: disputes resolved through pre-dispute solutions, and TC40 fraud reports that qualify under Compelling Evidence 3.0. Authenticated transactions are not on that list.

Visa's rules require an issuer to report the fraud to Visa before it can file a 10.4 dispute, and that fraud report is a separate record from the dispute. So when a stolen card gets through 3DS and the issuer cannot charge it back, the TC40 can still be counted against you. The liability shift protects the money on that transaction, not your monitoring ratio. Where 3DS helps the ratio is upstream: an issuer that challenges a suspicious shopper declines more stolen cards before they settle, so fewer fraud reports are filed at all.

The thresholds have tightened. Visa's fact sheet puts the excessive merchant threshold at 150 basis points, or 1.5%, in the US, Canada, the EU and Asia-Pacific from 1 April 2026, with a minimum of 1,500 fraud and dispute counts a month. Our guide to how the Visa VAMP program measures merchants covers the enforcement in detail.

Is 3D Secure mandatory in the US?

No. There is no US regulation or card network rule that requires 3D Secure on most transactions. That is different from Europe, where the PSD2 strong customer authentication requirement makes authentication the default for most online card payments. In the US, running 3DS is a commercial decision: you weigh the fraud disputes it removes against the checkout friction it adds, with the MCC exclusions above as part of the math.

Why 3D Secure payments get rejected, and how to fix authentication failures

A payment that fails at the 3DS step was stopped before authorization, so there is no decline code from the issuer to read. The common causes mirror the error section above: the shopper failed or abandoned the challenge, the issuer's authentication service errored, or the authentication data never made it into the authorization request.

From the merchant's side, the fixes are practical. Make the challenge easy to complete, especially on mobile. Retry transient issuer failures rather than treating them as final. And audit your integration so the ECI, CAVV, SLI and authentication values pass through to authorization exactly as received — a sale that authenticated but lost its cryptogram in transit is unprotected and may be blocked outright.

When to use 3D Secure, and when not to

A challenge adds a step, and some shoppers abandon the checkout rather than complete it. The case for running 3DS depends on what is costing you money:

• If fraud disputes under 10.4 or 4837 are a large share of your chargebacks, and your MCC is not on Visa's excluded list, authenticating card-not-present orders is likely to pay for itself.
• If most of your disputes are not-received, not-as-described or cancelled-recurring claims, 3DS will not change them. Spend the effort on the causes of those disputes first.
• If you sell subscriptions, authenticating the first payment protects the Mastercard recurring series that follows and gives you evidence of who signed up.
• If you are in an excluded Visa MCC, run 3DS for its effect on fraud approvals and issuer trust, not for dispute protection, and price your risk accordingly.

Many gateways let you apply 3DS selectively, for example to first-time customers, high-value orders or orders a fraud tool flags. Check which rules your gateway supports and whether it passes the authentication data through to authorization exactly as received, since that is what the protection depends on. Measure checkout drop-off after you turn 3DS on, and adjust which orders you send to a challenge.

A checklist before you rely on the liability shift

1. Confirm your MCC with your processor and check it against Visa's excluded list.
2. Check that your gateway sends the CAVV and ECI from Visa Secure, and the SLI and authentication value from Identity Check, in every authorization request.
3. Pull a sample of recent authenticated transactions and confirm they cleared with ECI 5 or 6 on Visa and SLI 211 or 212 on Mastercard.
4. Break your disputes down by reason code. For online orders, the liability shift reaches only the card-absent fraud codes: 10.4 on Visa and 4837 on Mastercard.
5. Keep authentication records with your order data so you can prove the link between a recurring charge and the authenticated first payment.
6. Track your TC40 fraud reports alongside your chargebacks. Authenticated fraud still counts toward VAMP.
7. Run the numbers on checkout drop-off after you turn it on, and adjust which orders you send to a challenge.

3D Secure is one of the few tools that moves fraud losses off a merchant's books entirely, and for most card-not-present businesses it is worth having. It is not a chargeback program on its own. We place high-risk merchants with acquiring banks and gateways that support 3D Secure for high-risk merchants, and our team can help you review whether your category is protected and which of your disputes it is likely to stop.