---
title: "3-D Secure 2"
url: "https://mahouse.world/glossary/3-d-secure-2"
type: "glossary term"
topic: "Payment security"
author: "Ihor Vlasov"
reviewed: "2026-09-20"
published: "2026-08-10"
---

# 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

## Key facts

- **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.

## Related terms

- [3-D Secure](https://mahouse.world/glossary/3-d-secure.md)
- [Strong Customer Authentication](https://mahouse.world/glossary/strong-customer-authentication.md)
- [SCA Exemption](https://mahouse.world/glossary/sca-exemption.md)
- [Frictionless Flow](https://mahouse.world/glossary/frictionless-flow.md)
- [Risk-Based Routing](https://mahouse.world/glossary/risk-based-routing.md)
- [Approval Rate](https://mahouse.world/glossary/approval-rate.md)

— Ihor Vlasov, M&A FinTech Expert. Last reviewed 2026-09-20. https://mahouse.world/authors/ihor-vlasov