Home / Wiki / 0-9 / 3-D Secure (3DS)

3-D Secure (3DS)

Cards and IssuanceUpdated 05 Nov 2026

3-D Secure (3DS) is a security protocol for online card payments that lets the card issuer verify that the person entering card details on a website or app is the genuine cardholder. It runs between the merchant's checkout and the issuer just before the card is sent for authorization, and it is the main way card payments meet strong customer authentication rules. Card brands market it under their own names, such as Visa Secure, Mastercard Identity Check and American Express SafeKey.

The protocol was first developed by Visa around 2001 and later handed to EMVCo, the card industry's standards body, which publishes the current EMV 3-D Secure specifications. Version 1 relied on a pop-up password page and was widely disliked; version 2, introduced in the late 2010s, shares much richer data so most payments can be approved without any visible step. 3DS is one tool within broader payment authentication, and it applies only to card-not-present transactions.

01

3-D Secure in plain terms

Picture ordering a delivery to a building with a concierge. Most of the time the concierge recognises the courier, sees the parcel is expected and waves it through. Now and then something looks odd, so the concierge phones the resident to ask: "did you order this?" Only then does the parcel go up.

3-D Secure is that concierge for online card payments. The shop sends information about the purchase and the shopper's device to the bank that issued the card. If everything looks normal, the bank quietly approves the check. If something looks unusual, the bank asks the shopper to confirm, usually in their banking app or with a code, before the payment can go ahead.

02

The three domains and how a check runs

The "3-D" refers to three domains. The acquirer domain covers the merchant and its acquirer, whose software (a 3DS Server or merchant plug-in) builds the request. The interoperability domain is run by the card networks, whose directory servers route each request to the right issuer. The issuer domain contains the issuer's access control server, which decides whether to authenticate the cardholder. A typical sequence is:

  1. The shopper enters card details, and the merchant's 3DS software sends an authentication request with order, device and account data.
  2. The card network's directory server forwards the request to the issuer's access control server.
  3. The issuer runs a risk assessment. Low-risk requests are approved in the frictionless flow with no shopper interaction; higher-risk ones go to the challenge flow, where the cardholder confirms using an app approval, a one-time password or biometric authentication.
  4. The issuer returns a result and a cryptogram, which the merchant includes in the normal authorization request to the issuer.
03

From 3DS 1.0 to EMV 3DS 2.x

The first version redirected shoppers to a static password page, offered no mobile app support and caused many abandoned checkouts. EMV 3-D Secure (version 2) added native app support, a much larger set of order, account and device data for risk scoring, and ways for the merchant to request or avoid a challenge. EMVCo recommends version 2.2 or higher, which supports European exemption signalling and decoupled authentication; later versions add features such as out-of-band browser flows. Visa ended support for 3DS 1.0.2 in October 2022 and Mastercard did the same that month, with temporary extensions for a few markets such as India into 2023.

04

Liability shift and regulation

Network rules give merchants a reason to use 3DS. When a transaction is successfully authenticated, liability for most fraud-related chargebacks generally moves from the merchant to the issuer, which lowers the merchant's chargeback risk. The exact conditions vary by card brand and region and change with network rule updates, so merchants check their acquirer's current guidance.

In the EEA, PSD2 made strong authentication mandatory for most online card payments, and the European Banking Authority stated in June 2019 that EMV 3DS can support it. The UK adopted the same requirement for online cards from March 2022. Exemptions let issuers skip the challenge for low-value payments, low-risk transactions identified by transaction risk analysis, trusted beneficiaries and merchant-initiated payments such as recurring payments. India's card rules also rely heavily on 3DS-based checks for e-commerce. In the US, 3DS is optional and used mostly by merchants with high fraud rates or international traffic.

05

Effects on merchants and shoppers

For merchants, 3DS is a balance between fraud and conversion. A challenge reduces payment fraud and card testing but adds a step at which shoppers may give up, and failed or timed-out authentications become a source of payment declines. Payment providers therefore use data-rich frictionless requests, exemptions where allowed, and network tokens, which also carry issuer-trusted data. A payment service provider or payment gateway usually runs the 3DS server on the merchant's behalf.

3DS has limits. It does not protect card-present payments, it cannot stop a genuine cardholder being tricked into approving a purchase, and it does not apply to bank transfers. It also does not replace good fraud prevention on the merchant side, since an authenticated payment can still be fraudulent or later disputed for non-fraud reasons.

Last updated 05 Nov 2026