3D Secure 2.0: How Authentication Affects Chargeback Liability and Evidence

3D Secure 2.0 is an authentication protocol that lets card issuers verify a cardholder's identity during checkout and, when that verification succeeds, shifts liability for a fraud-related chargeback from the merchant to the issuer. It does not shift liability for non-fraud disputes, and it does not eliminate the need for dispute evidence.

Most guides stop at "it reduces fraud." That is not the merchant question. The real questions are: which disputes actually move off your books when authentication succeeds, which ones stay yours regardless, how much conversion friction you take on to get there, and what data you need to pull from the authentication record when you fight the disputes that remain. This guide answers all four.

Understanding 3D Secure

3D Secure is a security protocol built by the major card networks to add a second layer of identity verification to online card transactions, on top of the card number, expiry, and CVV. It is designed to reduce fraud-driven disputes by confirming that the person entering the card details is the person the issuer expects.

The name comes from the three domains involved in every authentication call: the issuer domain (the cardholder's bank), the acquirer domain (the merchant's payment processor), and the interoperability domain (the network infrastructure connecting the two). Merchants only need to understand the outcome each domain returns, covered below.

Definition of 3D Secure

3D Secure is an online authentication protocol first introduced by Visa in 2001 and later adopted, under different brand names, by every major network: Mastercard, American Express, Discover, and JCB. Visa's implementation is now marketed as Verified by Visa, Mastercard runs Identity Check (formerly SecureCode), and American Express runs SafeKey. All current implementations run on the EMV 3-D Secure specification, published by EMVCo in October 2016 and updated through versions 2.1, 2.2, and 2.3.

Differences Between 3D Secure 1.0 and 2.0

3D Secure 1.0 relied on a static password the cardholder set up in advance, which was rarely used correctly, easy to phish, and heavily blamed for high checkout abandonment. 3D Secure 2.0 replaces the static password with risk-based, data-driven authentication that can approve low-risk transactions without any customer action at all.

How the Authentication Flow Works and What It Can Return

Every 3D Secure 2.0 call runs through the same sequence, but it can end in four different states, and only one of them gives you the liability shift.

1. Cardholder initiates payment: the cardholder enters their payment details on the merchant's website.
2. Merchant sends the authentication request: the payment gateway passes an authentication request, along with order and device data, to the card issuer's Access Control Server (ACS).
3. The issuer scores the risk: the ACS evaluates the data against the issuer's risk models and decides whether the transaction can pass frictionlessly or needs a challenge.
4. Challenge, if required: the cardholder completes a one-time code, biometric prompt, or banking-app approval on their device.
5. The issuer returns an authentication result: the ACS sends back an Electronic Commerce Indicator (ECI) and, on Visa and Mastercard, a Cardholder Authentication Verification Value (CAVV) or equivalent cryptogram.
6. The payment is authorized or declined: the acquirer processes the authorization using the authentication result attached to the transaction.

The result of step 5 lands in one of four buckets: fully authenticated (the issuer verified the cardholder and returns a valid cryptogram), attempted (the issuer or network attempted authentication but the cardholder's bank could not complete it, which still carries a partial protection value on some networks), not authenticated (the issuer explicitly declined to authenticate, and the merchant proceeds at full fraud risk if they still choose to authorize), and rejected (the issuer blocks the transaction outright). Only the fully authenticated result reliably carries the liability shift discussed next.

Where Liability Actually Shifts, and Where It Doesn't

When authentication succeeds and the transaction carries a valid ECI and cryptogram, liability for a fraud chargeback (unauthorized use of the card) moves from the merchant to the card issuer. On card issuer networks, this is enforced at the reason-code level: a properly authenticated Visa transaction disputed under a fraud reason code, or a Mastercard transaction disputed as fraud, is the issuer's problem to prove, not yours.

That protection has real limits merchants routinely misunderstand:

• Data-only 3DS (a risk-scoring pass with no ECI/cryptogram returned) improves the issuer's approval decision but does not carry the fraud liability shift on its own.
• Recurring and merchant-initiated transactions after the first authenticated charge in a series are not automatically covered by that first authentication.
• The liability shift only applies to fraud-coded disputes. It has no effect on the non-fraud dispute categories covered in the next section.
• Issuers can still request the underlying authentication data during a dispute, and a merchant who cannot produce it can lose a case that should have been protected.

Disputes 3D Secure 2.0 Cannot Stop

This is the gap most 3D Secure explainers skip. Even with a fully authenticated, liability-shifted transaction, the following dispute types stay merchant-liable because they are not fraud disputes; they are service and delivery disputes governed by different chargeback reason codes:

• Product not received: the cardholder was who they say they were; the complaint is about fulfillment, not identity.
• Not as described / defective merchandise: authentication confirms the payer, not the product condition.
• Credit not processed: a refund promised but not issued, unrelated to how the original card was authenticated.
• Duplicate processing or incorrect amount: a billing error, not an identity dispute.
• Subscription or recurring-billing complaints: cancellation and renewal disputes routinely fall outside the authentication event entirely.
• Friendly fraud: a cardholder who authenticated the purchase themselves, then disputes it anyway. See friendly fraud for how this differs from true third-party fraud and why authentication alone cannot resolve it.

In practice, most merchants who lean on 3D Secure 2.0 as a chargeback strategy are only protected against a minority of the disputes actually hitting their card-not-present fraud queue. The rest still have to be fought on the merits, with evidence.

The Authentication Evidence You Need to Keep for Every Transaction

Whether a dispute is covered by the liability shift or not, the authentication record itself is valuable evidence, and issuers can ask for it. Retain the following for every transaction, not just the ones you expect to dispute:

• Electronic Commerce Indicator (ECI): the code that tells you and the issuer what authentication level actually applied.
• CAVV / AAV cryptogram: the cryptographic proof the issuer generated at authentication time.
• 3DS Server Transaction ID and ACS Transaction ID: the unique identifiers that tie the authentication call to the specific payment.
• Authentication timestamp: when the challenge or frictionless check occurred, relative to the order timestamp.
• Device and session data submitted with the auth request: IP address, device fingerprint, and browser data used in the risk score.
• Challenge outcome: whether the cardholder completed a challenge (and how) or the transaction cleared frictionlessly.

This is the same category of proof required for compelling evidence submissions on non-fraud disputes: issuers and networks want a documented, timestamped trail, not a narrative.

Friction vs Recovery: When to Require Step-Up Authentication

3D Secure 2.0's risk-based design means you are not choosing "on or off," you are choosing thresholds. Forcing a challenge on every transaction maximizes your liability protection and tanks conversion. Relying entirely on frictionless, data-only passes protects conversion but leaves more transactions in the "attempted" or "not authenticated" bucket, where you carry full fraud risk.

The practical approach: route step-up challenges to the transaction profiles that actually drive your fraud losses (new device, mismatched billing and shipping, high order value, first purchase from an account), and let low-risk, repeat-customer transactions pass frictionlessly. Track the outcome by dispute type, not just approval rate, so you can see whether the friction you are adding actually reduces the fraud-coded disputes it is meant to stop, versus just adding checkout drop-off with no dispute benefit. A payment service provider that supports granular exemption and challenge rules gives you more control over this trade-off than an all-or-nothing integration.

Authentication Alone Is Not a Dispute Strategy

3D Secure 2.0 is a real, measurable liability tool for one category of dispute: card-not-present fraud where the issuer can be shown a valid authentication result. It does nothing for the non-fraud disputes that make up the rest of most merchants' chargeback volume, and even covered disputes can be lost if the authentication data is not retained and produced correctly. Treat authentication as one input into a broader evidence and recovery workflow, not a replacement for one, and route the fraud-coded volume it does not stop into automated prevention and dispute automation instead of manual triage.

Frequently Asked Questions

Does 3D Secure 2.0 stop chargebacks?

No. It reduces fraud-coded chargebacks by shifting liability to the issuer when authentication succeeds, but it has no effect on non-fraud disputes like product not received, not as described, or credit not processed, which make up a large share of most merchants' dispute volume.

What is the 3D Secure liability shift?

The liability shift is the rule that moves responsibility for a fraud chargeback from the merchant to the card issuer when a transaction was fully authenticated with a valid ECI and cryptogram (CAVV/AAV). It applies only to fraud-coded disputes, not to service, delivery, or billing disputes.

Is 3D Secure 2.0 mandatory in the United States?

No. Strong Customer Authentication under PSD2 is an EU/EEA regulatory requirement, in force since 2019. In the US, 3D Secure 2.0 adoption is optional and driven by each merchant's or processor's own fraud-liability calculation, not by law.

What is the difference between frictionless and challenge flow in 3D Secure 2.0?

Frictionless flow authenticates the cardholder using background risk data with no visible action required. Challenge flow requires the cardholder to actively complete a step, such as a one-time code or biometric prompt, when the issuer's risk model cannot clear the transaction automatically.

Does 3D Secure protect against friendly fraud?

No. Friendly fraud happens when the cardholder who legitimately authenticated the purchase later disputes it anyway. Since the authentication event confirms identity, not intent, 3D Secure has no mechanism to prevent this category of dispute.

Ready to stop guessing which disputes your authentication setup actually covers? See how Chargeflow Prevent turns authentication and evidence data into automated dispute recovery.