3D Secure (3DS) can move fraud liability off the merchant and onto the issuer, but only in specific cases. This article explains when liability shift applies in the US, when it does not, and what evidence your team should include when a dispute lands.
What ‘Liability Shift’ actually means
With successful 3DS authentication, certain card-not-present fraud disputes shift from the merchant to the issuer. The exact conditions depend on the network program (Visa Secure, Mastercard Identity Check) and how the transaction was authenticated.
When does Liability Shift usually apply
-
Fraud-coded CNP disputes after successful authentication: For Visa and Mastercard, fully authenticated 3DS transactions are generally protected from fraud chargebacks (e.g., Visa 10.4 ‘Other Fraud – Card-Absent’). Your auth payload should include the authentication value (CAVV/AAV) and the appropriate ECI to signal authentication level.
-
ECI indicators: Networks use ECI to denote authentication level and related liability. Typical patterns: Visa ECI 05 (authenticated) and ECI 06 (attempted) vs ECI 07 (no 3DS). Mastercard uses a different scale (e.g., ECI 02 authenticated). Always confirm with your acquirer’s matrix.
Note: Program matrices evolve; rely on your acquirer’s latest guidance and network documentation for edge cases.
What Liability Shift does not cover
-
Non-fraud disputes: 3DS does not shield you from consumer or processing disputes like product not received, not as described, cancelled service, credit not processed, or authorisation/processing errors. Visa
-
Data-Only 3DS: ‘Data-Only’ shares 3DS data with issuers but is not a full authentication flow; it improves decisioning but doesn’t grant liability shift. Visa Acceptance Trust Payments
-
Some recurring/MIT scenarios: Subsequent merchant-initiated or recurring charges may be ineligible for liability shift, depending on the network and setup, even if the first payment was authenticated. Treat initial 3DS as context, not blanket coverage.
Friendly Fraud and 3DS
‘Friendly fraud’ is often coded as fraud by issuers. If the transaction was properly authenticated, liability typically sits with the issuer, but issuers can still initiate disputes. Your job is to represent with complete 3DS evidence (ECI + CAVV/AAV + server/ACS transaction IDs) and purchase context.
Covered vs Not covered
| Scenario | Liability shift likely? | Why |
|---|---|---|
| Fraud CNP with successful 3DS auth (correct ECI/CAVV) | Yes | Network programs provide protection for fraud disputes when auth is valid. (U.S. Payments Forum) |
| Fraud CNP with Data-Only | No | Data-Only isn’t full authentication; no shift. (Visa Acceptance) |
| Non-fraud consumer disputes (e.g., goods not received) | No | Outside fraud category. (Visa) |
| Subsequent recurring / MIT | Varies | Often ineligible; check acquirer/network rules. (ChargeBlast) |
Your disputes playbook: How to win when you should
-
Pass complete data at checkout: Clean addresses, email, phone, device/browser data; run the 3DS Method or use the SDK so device context is available. Better signals reduce step-ups and strengthen cases later.
-
Store the 3DS artifacts: Keep ECI, CAVV/AAV, XID/transaction IDs, DS/ACS references, AVS/CVV results, timestamps, IP/device info. You will need these for representment.
-
Respond with ‘compelling evidence’: Visa outlines acceptable evidence for fraud conditions (10.x), including technical logs and proof of cardholder participation. Organise templates so your ops team can respond quickly.
-
Segment your liability: Tag transactions by route (ECI value, wallet tokenisation, Data-Only, SDK vs browser) so finance can attribute chargebacks to the right controls and see where coverage applies.
At a Glance
3D Secure 2 can shift liability for card-not-present fraud to the issuer when authentication succeeds (correct ECI plus valid authentication values). It does not cover non-fraud disputes, and Data Only does not provide liability shift. Some recurring or merchant-initiated transactions may be ineligible, so check your acquirer and network matrix. Maximise your win rate by sending complete data, running the 3DS Method or SDK, and retaining ECI, CAVV/AAV, and transaction IDs for representment.
FAQs
Does liability shift apply to all chargebacks if 3DS was used?
No. It typically applies to fraud disputes only, not consumer or processing disputes. Visa
Does ‘Data-Only’ 3DS provide liability shift?
No. It improves issuer decisioning but does not grant liability protection. Visa Acceptance
What should I include in a 10.4 response?
Provide the 3DS evidence set (ECI + CAVV/AAV + transaction IDs), plus order details and device/behaviour signals. Follow your acquirer’s checklist.