3-D Secure and strong customer authentication
3-D Secure adds an identity check to online card payments. How frictionless and challenge flows work, and what strong customer authentication requires.
L0 Explain simply
An everyday analogy: 3-D Secure is the doorbell camera of online card payments. In a shop, the card itself helps prove who is paying — chip, PIN, tap. Online, the merchant sees only typed digits that anyone could have copied. So the card world added a way for the shop to ring the issuer at the front door: someone claiming to be your customer is buying — have a look before I let them in. Usually the issuer recognises enough from what it sees — the device, the history, the pattern — and waves the payment through without the shopper noticing anything. Sometimes it asks the customer to confirm in their banking app or with a one-time code. That standardised doorbell conversation is 3-D Secure; the legal duty, in some regions, to actually run a strong check is strong customer authentication.
L1 Core concepts
3-D Secure — the three domains are the merchant's, the issuer's, and the network infrastructure between them — is an EMVCo protocol that lets a card-not-present merchant ask the issuer to authenticate the cardholder before authorisation. The merchant's 3DS component sends rich context — device data, addresses, order details — to the issuer's access control server. Two outcomes exist: the frictionless flow, where the issuer authenticates from the data alone and the shopper notices nothing, and the challenge flow, where the shopper must approve in their banking app or enter a one-time code. The result rides into the authorisation as a cryptographic value the issuer can verify. In the EU and UK, strong customer authentication (SCA) — two independent factors drawn from knowledge, possession and inherence, required by the second Payment Services Directive (PSD2) — applies to most electronic payments, and 3-D Secure is the card world's standard way to meet it. Authenticated traffic also generally shifts fraud liability from the merchant to the issuer.
L2 Practitioner view
In practice, teams tune 3-D Secure as a risk dial, not a switch. Challenging every payment costs sales — some shoppers abandon at the extra step — so issuers approve what they can frictionlessly from the data, and merchants choose where to request authentication at all. SCA law shapes the dial with exemptions: low-value payments, recurring transactions after the first one, transaction risk analysis under fraud-rate thresholds, and trusted-beneficiary lists can skip the challenge, while merchant-initiated transactions sit outside SCA's scope entirely. Each exemption has an owner, and the party claiming it generally keeps the fraud liability — the liability shift only moves to the issuer when the issuer actually authenticated. So the operational questions are concrete: when do we claim an exemption instead of authenticating, what do decline and abandonment rates say, and does the liability we shed cover the disputes we actually see? A failed challenge is calm territory: the payment simply is not made, and the shopper can pay another way.
Sources for this topic3
- Official requirement
PSD2 and the RTS on strong customer authentication and secure communication ↗ — European Banking Authority
Referenced from the European Banking Authority's public summaries, guidelines, and technical standards on payment services.
- Market practiceMarch 2003 edition
A glossary of terms used in payments and settlement systems ↗ — CPSS (now CPMI), Bank for International Settlements
Terminology has evolved since this edition; newer CPMI publications refine some definitions.
- Simplified educational illustration
Payments Signal editorial teaching models — Payments Signal
Used wherever diagrams, scenarios, figures, or example values are didactic constructions rather than sourced facts; every such use carries a simplifications disclosure. All people, companies, banks, and list entries in examples are fictional.
Deepest material on this page: L2 — Practitioner view. Where a topic stops short of implementation depth, that is a deliberate coverage decision, not an oversight — see coverage.