3-D Secure 2
3-D Secure 2 is EMVCo's rebuilt authentication protocol for card-not-present payments: the merchant sends the issuer rich transaction and device data, the issuer authenticates most transactions without a challenge, challenges the rest in the banking app inside the merchant's page, and the SCA exemptions ride in the messages. It replaced version 1 in 2022 and made strong customer authentication in Europe workable.
- Also known as
- 3DS2, EMV 3-D Secure, 3DS 2.x
- Used at
- every online card payment in the EU and UK (where SCA applies), and increasingly elsewhere for liability shift; mandatory for scheme participants since the 2022 retirement of v1; versions 2.1, 2.2 and 2.3 add features (exemptions, decoupled authentication, better app flows)
- Binding
- the EMVCo specification and each scheme's programme rules (Visa Secure, Mastercard Identity Check); liability shift on authenticated transactions; the SCA regulatory technical standards for the exemptions it carries
- Typical flows
- frictionless (the issuer authenticates on the data alone — 60–85% of transactions at good merchants), challenge (in-app push, biometric, one-time code — in a frame, no redirect), and decoupled (authentication completed outside the checkout, for merchant-initiated and out-of-band cases)
- Typical metrics
- authentication rate, frictionless rate, challenge success rate, abandonment at challenge; a well-run merchant in Europe sees 75% frictionless, 90%+ challenge success, and under 3% total loss to authentication
- Parties
- the merchant and its 3DS server (the "3DS requestor"), the directory server run by the scheme, the issuer's access-control server, the cardholder's banking app, and the PSP or orchestrator managing it all
How 3-D Secure 2 works in practice
A customer pays online. Before authorisation the merchant's 3DS server sends an authentication request through the scheme's directory server to the issuer's access-control server: the card, the amount, the merchant, and around a hundred fields — device fingerprint, IP, browser, shipping and billing addresses, account age, purchase history, whether a TRA exemption is requested. The issuer's engine scores it: known device, matching addresses, low amount, good merchant — frictionless, authenticated, liability shifted, no customer interaction. Or: new device, high amount, mismatch — challenge: the customer's banking app pushes a prompt, she approves with a fingerprint, the result returns, the merchant authorises with the authentication value attached.
The data is the product. A merchant that sends rich, accurate data earns high frictionless rates; one that sends the minimum gets challenged. Issuers differ — some challenge everything above a threshold, some almost nothing — and the merchant's routing and exemption strategy adapts to them. Exemptions ride inside: a TRA exemption request in the authentication message, which the issuer accepts (frictionless, but liability stays with the merchant) or refuses (challenge). Merchant-initiated transactions skip 3DS after the first; decoupled authentication handles cases where the customer is not present at the checkout.
For a payments company the 3DS 2 implementation is a competitive product: frictionless rates and challenge success are what sells it.
Example
A subscription service migrates from 3DS 1 to 3DS 2 in 2021 with its PSP. It builds full data population — device data, account history, address match — and a strategy: TRA exemptions on first payments under €100, merchant-initiated flags on renewals, challenge for the rest. Results: authentication on 100% of first payments; frictionless 78%; challenge success 91% on the 22% challenged; abandonment 2%; renewals exempt from authentication entirely; fraud liability shifted on 96% of first payments; chargebacks for fraud down 60%. Its abandonment under 3DS 1 had been 17%. The CFO's note to the board: "authentication now costs us two points and saves us a fraud team".
Common mistakes
- Populating the minimum data fields and wondering why every transaction is challenged. - Renewals sent through 3DS with nobody present, instead of flagged as merchant-initiated. - No exemption strategy, so the merchant pays for challenges it could have avoided. - Measuring authentication success and not abandonment at challenge. - Assuming liability shifted on an exempted frictionless transaction; it did not.