3-D Secure
3-D Secure authenticates the cardholder during an online purchase, before the authorization. It is what stands behind the extra step a shopper sometimes sees at checkout.
Why it exists
Once a transaction is authenticated, liability for fraudulent chargebacks shifts from the merchant to the issuer, so cards enrolled in 3-D Secure see a different dispute profile.
Several markets also mandate strong customer authentication for online payments, and where that applies 3-D Secure is not optional.
What you control
| Yours | The Access Control Server's |
|---|---|
| The cardholder's contact details | Whether a purchase is challenged |
| Reacting to the resulting transaction | Which method is used, and delivering it |
| The challenge screen and its verification |
3-D Secure is switched on for a BIN range, with the network, as part of setting up your program. Once it is on, every card in the range is covered. There is nothing to enroll and no way to opt a single card out. Everything about the challenge itself happens in the ACS; see how a challenge works.
Challenge methods
| Method | What the cardholder sees |
|---|---|
| Frictionless | Nothing. Risk assessment passes silently |
| One-time passcode | A code by SMS or email, entered at checkout |
| Out-of-band | A prompt in an app, not a code to type |
Most authentications are frictionless. Design for the challenge cases anyway; they are the ones that fail.
Out-of-band is the better experience: a push notification and a biometric prompt instead of a code to copy across. The processor behind current programs can run it, and the API for delegating it to an app of yours is specified and stable, though not deployed yet. See out-of-band authentication.
In this section
- How a challenge works — what the ACS does, what you control, and whose support question is whose
- Out-of-band authentication — approving in your own app, and the contract to build against