diagrams
Payments

3D Secure Authentication

3D Secure (3DS) is a cardholder authentication protocol that adds a verification step between the payment gateway and the issuing bank before authorization proceeds. "3D" refers to the three domains involved: the acquirer domain (merchant and gateway), the interoperability domain (card network), and the issuer domain (cardholder's bank). Version 2.x (EMV 3DS) is now standard and enables frictionless authentication for most transactions.

diagram.mmd — sequence
Edit in Graphlet →
3D Secure Authentication sequence diagram
About Source

3D Secure (3DS) is a cardholder authentication protocol that adds a verification step between the payment gateway and the issuing bank before authorization proceeds. "3D" refers to the three domains involved: the acquirer domain (merchant and gateway), the interoperability domain (card network), and the issuer domain (cardholder's bank). Version 2.x (EMV 3DS) is now standard and enables frictionless authentication for most transactions.

The 3DS flow begins after the merchant submits transaction data to the payment gateway and the gateway (or the merchant's 3DS SDK) initiates an authentication request to the 3DS Server, which communicates with the card network's Directory Server. The Directory Server checks whether the card is enrolled in 3DS and routes the request to the issuer's Access Control Server (ACS).

In 3DS2, the ACS receives a rich set of contextual data: device fingerprint, browser information, shipping/billing address match, transaction history, account age at merchant, and more. The ACS uses this data to attempt frictionless authentication — if the risk is low enough, it approves the authentication without any interaction from the cardholder. This is the key improvement over 3DS1, where a challenge was always shown.

If the ACS determines the transaction is high-risk or requires cardholder verification, it triggers a challenge flow: the cardholder sees a native UI (in-app) or an iframe (web) from their bank, prompting them to enter a one-time password, use a biometric, or confirm via their banking app. On successful challenge, the ACS issues a signed authentication value (CAVV) and ECI (Electronic Commerce Indicator) code.

The CAVV and ECI are passed with the authorization request to the card network and issuing bank. The presence of a valid 3DS authentication shifts liability from the merchant to the issuer — if a fraud chargeback is filed on a 3DS-authenticated transaction, the issuer (not the merchant) bears the financial loss. See Fraud Detection Pipeline for how risk scoring determines which transactions are routed to 3DS.

Free online editor
Edit this diagram in Graphlet
Fork, modify, and export to SVG or PNG. No sign-up required.
Open in Graphlet →

Frequently asked questions

3D Secure (3DS) is a cardholder authentication protocol that adds a verification layer between a payment gateway and the issuing bank before authorization proceeds. The "3D" refers to the three domains involved: the acquirer, the card network, and the issuer.
If the issuer's Access Control Server (ACS) judges a transaction high-risk, it triggers a challenge: the cardholder completes an OTP, biometric, or banking-app confirmation. On success the ACS issues a signed CAVV and ECI code that travels with the authorization request and shifts fraud liability to the issuer.
3DS is required by regulation in many markets (e.g., PSD2 SCA in Europe) and strongly recommended wherever fraud rates are elevated. Merchants processing card-not-present payments benefit from the liability shift even when 3DS adds a small amount of checkout friction.
Common mistakes include not verifying the CAVV before submission, handling only frictionless responses and ignoring challenge redirects, failing to pass device-fingerprint data that enables frictionless flows, and not testing the challenge path in staging environments.
3DS1 almost always showed a challenge iframe, disrupting checkout. 3DS2 sends rich contextual signals (device, history, address) so the ACS can approve low-risk transactions silently (frictionless), reserving the challenge only for genuinely suspect transactions.
mermaid
sequenceDiagram participant Customer participant Merchant participant ThreeDSServer as 3DS Server participant DirectoryServer as Card Network Directory Server participant ACS as Issuer Access Control Server Merchant->>ThreeDSServer: Authentication request (card, amount, device data) ThreeDSServer->>DirectoryServer: Check card enrollment DirectoryServer->>ACS: Route to issuer ACS ACS->>ACS: Evaluate risk signals (device, history, address match) alt Frictionless authentication ACS-->>DirectoryServer: Authentication approved (low risk) DirectoryServer-->>ThreeDSServer: CAVV + ECI code (frictionless) ThreeDSServer-->>Merchant: Authentication result else Challenge required ACS-->>DirectoryServer: Challenge required DirectoryServer-->>ThreeDSServer: Challenge URL ThreeDSServer-->>Merchant: Trigger challenge Merchant->>Customer: Display ACS challenge (OTP or app push) Customer->>ACS: Submit OTP or biometric ACS->>ACS: Verify challenge response ACS-->>DirectoryServer: Challenge passed — CAVV + ECI DirectoryServer-->>ThreeDSServer: Authentication result ThreeDSServer-->>Merchant: CAVV + ECI code end Merchant->>Merchant: Include CAVV + ECI in authorization request note">Note over Merchant: Liability shifts to issuer on success
Copied to clipboard