3-D Secure (EMV 3DS) is the authentication protocol for card-not-present payments: the merchant requests authentication, the issuer's ACS assesses risk, and the cardholder is authenticated frictionlessly or via a challenge before authorization.

What is the difference between frictionless and challenge flow?

In the frictionless flow the issuer authenticates from the risk data in the AReq with no cardholder interaction. A challenge flow steps the cardholder up to an OTP, app push, or biometric when risk or regulation requires it.

The Cardholder Authentication Verification Value is the cryptographic proof that authentication happened; it travels in the authorization message so the issuer can verify the transaction was 3DS-authenticated.

Does 3DS shift chargeback liability?

Generally yes — for successfully authenticated transactions, fraud chargeback liability shifts from the merchant to the issuer, subject to scheme rules.

← Payment Reference GuidesAuthentication Reference

3D Secure / EMV 3DS

The cardholder authentication protocol for card-not-present transactions. 3DS2 adds frictionless, decoupled, and challenge flows while enabling SCA compliance under PSD2 and reducing CNP fraud liability.

What is 3D Secure?

3D Secure (3DS) is the global card authentication protocol for card-not-present transactions. It reduces fraud by verifying the cardholder's identity at the time of purchase and shifts liability from the merchant to the card issuer when authentication succeeds. The "3 domains" are the issuer domain, the acquirer domain, and the interoperability domain (the card scheme).

3DS 1.0

3DS 1.0 (2001)

Browser-only redirect to issuer page
Static password or knowledge-based challenge
High cart abandonment rates (~50-70%)
No device fingerprinting or risk scoring
MPI (Merchant Plug-In) on merchant side
Payer Authentication Request (PAReq) / Response (PARes) messages

EMV 3DS 2.x

EMV 3DS 2.x (2016+)

Native SDK (iOS/Android) and browser iframe support
Frictionless flow — no cardholder interaction for low-risk transactions
100+ data elements sent to issuer for risk-based authentication
Challenge flow with OTP, biometric, or out-of-band methods
Decoupled authentication (async, up to 1 hour)
AReq/ARes/CReq/CRes/RReq/RRes message types

Liability Shift Rules

Scenario	Auth Result	Fraud Liability
Full 3DS authentication	transStatus = Y, valid CAVV	Issuer
3DS attempt (issuer not participating)	transStatus = A	Shared / Issuer
3DS not attempted (merchant eligible)	No 3DS	Merchant / Acquirer
Failed authentication	transStatus = N	Merchant / Acquirer

Keep reading

Card RailsPayment TokenizationFPAN→DPAN lifecycle, VTS vs MDES, TAVV cryptogramsRead article Open BankingOpen Banking & PSD2AISP/PISP roles, consent & SCA flows, FAPI security, UK / Berlin Group / STETRead article IdentityEUDI Wallet & PaymentseIDAS 2.0 deadlines, the SD-JWT VC / mdoc / OID4VP stack, wallet-based PSD2 SCARead article Card RailsISO 8583 ProtocolMessage structure, bitmap mechanics, 128 data elements, network variationsRead article

3D Secure / EMV 3DS

What is 3D Secure?

3DS 1.0 (2001)

EMV 3DS 2.x (2016+)

Liability Shift Rules

Related articles