3D Secure
What is 3D Secure?
3D Secure (3DS) is an authentication protocol that adds an identity-verification step to online card payments, confirming that the person entering the card details is the legitimate before the payment is approved.
The name is short for "Three-Domain Secure," after the three parties it connects: the that holds the card, the merchant's acquiring bank, and the card network that links them. During checkout, the transaction is passed to the issuer, which decides whether the payment can go through as-is or needs an extra identity check.
Key facts
- Full name: Three-Domain Secure, named after the issuer, acquirer, and interoperability domains it connects.
- Also known by scheme brand names: and are the card networks' own implementations of 3DS.
- Versions: 3DS1 (being phased out) and 3DS2, which adds risk-based, device-aware authentication.
- Verification flows: frictionless (approved in the background) and (the cardholder completes an extra step).
- Applies to: such as e-commerce and in-app payments; required to meet rules in the EEA.
How it works
Three systems exchange messages during a 3DS check, one in each domain:
- 3DS Server (merchant side): collects the transaction and device data at checkout and sends the authentication request, usually run by the merchant's payment provider.
- Directory Server (interoperability domain): operated by the . It confirms the card's range supports 3DS and routes the request to the right issuer.
- Access Control Server (ACS) (issuer side): run by or for the issuer. It assesses the risk and, when needed, presents the challenge to the cardholder.
- Checkout: the cardholder enters card details on the merchant's payment page.
- Authentication request: the payment is routed to the issuer with transaction data and, in 3DS2, device and behavioral signals.
- Risk assessment: the issuer evaluates the data and picks a frictionless or challenge flow.
- Challenge (if required): the cardholder confirms their identity with a one-time password, a banking-app approval, or .
- Result and authorization: the issuer returns an authentication result, the liability shift is recorded, and the transaction moves on to authorization.
3DS authentication vs authorization
3DS and are separate checks, and both come from the issuer. 3DS answers "is this the real cardholder?", while authorization answers "can this account pay this amount?". A payment can pass 3DS and still be declined at authorization.
| 3DS authentication | Authorization | |
| Question it answers | Is the person paying the cardholder? | Can the account cover this payment? |
| When it happens | Before authorization | After 3DS, or alone if 3DS isn't used |
| Result | Authenticated, challenged, or failed | Approved or declined with a |
Why it matters
3DS reduces on card-not-present payments by requiring proof that the person paying controls the card, not just knowledge of the card number. It blocks a common attack pattern where a stolen card number alone is enough to complete a purchase.
It also changes who pays when fraud slips through. For a payment authenticated through 3DS, the moves fraud costs from the merchant to the issuer. And in the EEA, 3DS is how card payments satisfy PSD2 , so a working 3DS setup is what keeps those transactions from being declined for missing authentication.
3D Secure for the cardholder
For the cardholder, 3DS shows up as a verification screen or a banking-app prompt during checkout, and only when the issuer chooses the challenge flow. In the frictionless flow, nothing extra appears.
- 3DS password: the code or credential used to pass the challenge. In 3DS2 it's usually a one-time code sent by SMS or an approval in the banking app. The static password that 3DS1 relied on is being retired along with that version.
- Enrollment: the issuer enrolls its cards in 3DS, so most cardholders don't activate it themselves. Some issuers still ask cardholders to register a phone number or the banking app first, and the steps vary by issuer.
- Failed or unavailable check: if the cardholder fails the challenge, the issuer rejects the authentication and the payment doesn't go through. If the card isn't enrolled, the merchant can continue to authorization without 3DS in markets where it isn't mandatory, but loses the liability shift.
3DS versions
Two versions are in use. 3DS1 is the original protocol and it's being retired; it leans on static passwords and usually redirects the cardholder to a separate verification page. 3DS2 is the current standard and sends far more context, including device and transaction data, so the issuer can clear most payments through the frictionless flow without interrupting the cardholder. It also supports merchant-initiated authentication such as for recurring charges. For a full breakdown of what changed between the versions, see the .
