Contact

What is 3D Secure?

Definition

3D Secure is a protocol that lets the bank that issued a card authenticate the cardholder during an online card payment. Its current form, EMV 3-D Secure (3DS2), shares transaction and device data with the issuer so low-risk payments can be approved without any extra step, while riskier ones trigger a challenge such as a one-time passcode or approval in the banking app.

Also known as: 3DS, 3DS2, EMV 3-D Secure, 3-D Secure, card authentication

3D Secure sequence: the card issuer challenges the shopper during checkout and confirms authentication to the merchant after approval

The three domains in the name

The "3D" stands for three domains: the issuer domain (the cardholder's bank), the acquirer domain (the merchant and its bank) and the interoperability domain run by the card networks that connects them. The merchant side sends payment details to the network's directory server, which routes the request to the issuer's access control server, where the authentication decision is made. Card networks brand the protocol under their own programmes, with Visa Secure and Mastercard Identity Check being well-known examples.

From the original 3DS to EMV 3DS

First-generation 3D Secure interrupted every payment with a pop-up asking for a static password or SMS code, and it worked poorly on phones. EMV 3-D Secure, managed by EMVCo, changed the model. The merchant now sends a much richer data set, including amount, device characteristics and delivery address, and the issuer uses it to assess risk. Beyond browser checkouts, EMV 3DS supports in-app payments and merchant-initiated transactions when the cardholder is not present (3RI). EMVCo currently lists specifications in the 2.2 and 2.3 series.

Frictionless or challenge

  • Frictionless: if the issuer judges the transaction low risk from the data provided, the shopper sees nothing extra; clicking Buy completes the payment.
  • Challenge: if the transaction looks risky, the issuer asks for step-up authentication such as a one-time passcode, a biometric check or approval in the banking app.

The issuer, not the merchant, decides which flow runs. What the merchant controls is the completeness and consistency of the data it sends; integrations that pass thin data tend to see more challenges. In effect, the challenge is a form of multi-factor authentication operated by the cardholder's bank.

Regional practice and liability

How often shoppers meet a challenge varies by market. In the EU, the strong customer authentication requirements of PSD2 are typically met with 3DS for online card payments. In Turkey, shoppers usually know 3D Secure as the screen where they type an SMS one-time password from their bank, or as an approval in their mobile banking app, and many payment gateways there start transactions with 3D by default. Whether a non-3D payment is accepted at all depends on the bank, the merchant agreement and the provider's risk policy. Likewise, whether a successful authentication shifts fraud chargeback liability from merchant to issuer depends on card network rules, so confirm it with your provider in writing rather than assuming it.

Integration bugs that cost orders

The challenge step is the most fragile moment in checkout. A late SMS, a timeout or a challenge iframe that does not fit a phone screen all turn into abandoned carts. The most common technical bug is a lost session on return. After authentication, the bank typically sends the shopper back to the merchant's return URL with a cross-site POST. If the session cookie's SameSite attribute is Lax, the browser does not send it with that request, so a customer who has just paid appears logged out or finds an empty cart. The fix is to match the return request to the order by reference rather than relying on the session, and to confirm the payment result server-side through the provider's API.

Related terms

← Back to the glossary