Interactive walkthrough · built on public EMVCo standards
The EMV 3DS challenge flow.
When you pay online with a card, a short protocol runs before the money moves — EMV 3-D Secure. Its job is to answer one question: is the real cardholder here? Most of the time the answer is decided silently. Sometimes you get asked for a code. Below, you decide the risk signals and step through the exact messages — with the screen the cardholder sees shown alongside.
Nothing here is proprietary: it's the public EMVCo message flow, the kind of thing the spec describes and every issuer implements. Named parties are explained on first use, and in the glossary at the bottom.
Risk signals — you are the ACS
Frictionless
Checkout
The cardholder submits their card
§ The parties
- Cardholder
- The person paying, and their browser. Only ever talks to the merchant and — during a challenge — to the ACS.
- 3DS Server
- Runs for the merchant (the "3DS Requestor"). It kicks off authentication and collects the signed result. It never sees the cardholder's password or one-time code.
- Directory Server
- Operated by the card network — Visa, Mastercard, RuPay, and so on. A switchboard: it routes messages between the 3DS Server and the correct ACS, and enforces the network's rules.
- ACS
- Access Control Server — stands in for the card's issuer. It makes the risk decision, runs the challenge if there is one, and signs the authentication result.
- Issuer
- The bank that issued the card. Authorises the actual payment — over the card network, a separate rail from the 3DS messaging shown here.