How 3D Secure 2 Works

Three D Secure, often called 3DS, is a protocol that adds an authentication step to online card payments. The original version, 3DS 1, redirected the customer to their bank's page to enter a password, which was secure but clumsy and caused many customers to abandon their purchases. Version 2, known as 3DS 2, was redesigned to work smoothly on mobile devices, to support biometric authentication such as fingerprint and face recognition, and to use risk based decisioning so that most transactions pass without any challenge at all. The flow begins when the customer enters their card details at checkout. The merchant's system sends the transaction data to the issuer through the scheme's 3DS directory server. Along with the amount and merchant details, the merchant sends rich contextual data, such as the customer's device information, their purchase history, the delivery address, and how long they have held an account with the merchant. The issuer's access control server analyses this data and decides whether the transaction looks low risk, in which case it authenticates silently, or high risk, in which case it asks for a challenge. If authentication succeeds, the issuer returns a cryptogram, which is a piece of data that proves the authentication happened, and the merchant includes it in the authorisation request. If the transaction later turns out to be fraudulent, the liability for the loss generally shifts from the merchant to the issuer, because the issuer authenticated the cardholder. This liability shift is a powerful incentive for merchants to adopt 3DS, and it is a key reason regulators in Europe have made strong customer authentication mandatory for most online payments under the revised Payment Services Directive. Follow two customers through the same checkout. The first buys a phone for Rs 12,000. The merchant sends the 3DS data. The device is recognised, the customer has held an account with the merchant for two years, and the delivery address matches the billing address. The issuer scores the transaction as low risk and authenticates it silently, so the customer sees no challenge at all and the purchase completes. The second customer uses the same card from a new device in another country for Rs 95,000, with a delivery address the merchant has never seen. The issuer scores it as high risk and sends a challenge, and the customer approves it with a fingerprint. Both payments are authenticated, but only one interrupted the customer. Now take the failure modes. The issuer's authentication server is down, so the merchant cannot get a 3DS result. Depending on the scheme rules and the merchant's settings, the merchant either proceeds without authentication and keeps the liability, or declines the transaction. Or the customer closes the app in the middle of the challenge, in which case no authentication result exists, the authorisation never happens, and the merchant must show a clear message that the payment did not complete, not a silent failure. An analyst specifies 3DS as a data contract, not just a feature. The integration document should list every data field the merchant must send, device information, purchase history, delivery address, and account age, because the issuer's risk decision is only as good as the data it receives. It should state the exemptions the merchant will use, such as low value transactions and trusted beneficiaries, and the fallback behaviour when the authentication server is unavailable. The test pack needs at least four cases. A low risk transaction that passes silently, a high risk transaction that challenges, a challenge that the customer abandons, and an authentication server outage. A merchant that has only tested the happy path will discover the other three in production, in front of customers.