3-D Secure 2 (3DS2)

3-D Secure 2 (3DS2) is the second generation of the 3-D Secure protocol, the industry standard that allows a card issuer to check that the person making an online or in-app card payment is the genuine cardholder. It is used by merchants, payment service providers, card schemes and issuing banks on almost every major card network, and exists to cut fraud in card-not-present transactions, where no physical card or PIN is available.

The specification is published by EMVCo, the technical body owned by the major card schemes, and each scheme runs it under its own brand, such as Visa Secure, Mastercard Identity Check and American Express SafeKey. It replaced the original 3-D Secure protocol, often called 3DS1, and in the European Economic Area and the United Kingdom it is the main way card payments meet the strong customer authentication rules that came with PSD2.

The first version of 3-D Secure appeared in the early 2000s. It sent shoppers to a pop-up or redirect page where they typed a static password, which was easy to forget, looked like a phishing page and caused many abandoned purchases. It also worked poorly on mobile phones and inside apps. EMVCo took over the protocol and published the first 3DS2 specifications in the second half of the 2010s, with later versions (2.1, 2.2 and 2.3) adding features such as decoupled authentication and support for requests made without the cardholder present. Visa and Mastercard ended support for 3DS1 in October 2022, so 3DS2 is now the only version in normal use.

A 3DS2 check involves three domains, which give the protocol its name: the merchant or acquirer domain, the card scheme's interoperability domain and the issuer domain. The main components are:

• 3DS Server. Run by the merchant, its gateway or the acquirer, it gathers transaction and device data and sends the authentication request.
• Directory Server. Operated by each card scheme, it routes the request to the right issuer based on the card number range.
• Access Control Server. Operated by or for the card issuer, it decides whether the cardholder is authenticated and returns the result.

The 3DS Server sends far more data than the first version did, including the device, browser or app details, shipping and billing addresses, account age and purchase history. The issuer feeds this into a risk-based authentication engine. If the risk is low it can approve silently, which is called frictionless authentication. If not, it starts a challenge flow and asks the cardholder to prove who they are, for example with a one-time password, a banking app approval or biometric authentication. Version 2.2 also allows decoupled authentication, in which the shopper confirms on a separate device, sometimes minutes later.

The outcome is returned to the merchant as an authentication value and an Electronic Commerce Indicator, which the merchant includes in the authorisation request. Authentication and authorisation are separate steps: a successful 3DS2 check does not guarantee that the issuer will approve the payment.

When a payment is successfully authenticated through 3DS2, the card schemes generally move liability for fraud-related chargebacks from the merchant to the issuer. This liability shift is a strong reason for merchants to use the protocol even where it is not mandatory. It does not cover every dispute: claims that goods never arrived or were not as described remain with the merchant. Schemes also attach conditions, and merchants that request an exemption instead of authentication usually keep the fraud liability.

In Europe, PSD2 requires two independent factors from knowledge, possession and inherence for most electronic payments, and 3DS2 is the carrier that delivers those factors for cards. The regulation also allows exemptions, such as low-value payments, transactions judged low risk by the acquirer or issuer, trusted beneficiaries and payments initiated by the merchant. 3DS2 messages carry flags that let the merchant or acquirer request a strong customer authentication exemption, while the issuer always keeps the final say. Outside Europe, 3DS2 is used voluntarily or under local rules, for example in India, where additional factor authentication for online card payments has long been required.

• Conversion loss. Challenges still interrupt checkout, and badly built issuer screens or slow one-time passwords cause abandoned payments.
• Uneven issuer quality. Frictionless rates vary widely between issuers depending on how well their risk models use the extra data.
• Social engineering. Fraudsters who trick a cardholder into approving a challenge can defeat the protocol, which is why issuers add context such as the merchant name and amount to approval screens.
• Integration effort. Merchants must collect and pass correct data, handle app and browser flows, and keep up with scheme rule changes and version updates.

• EMVCo