How a challenge works
The authentication challenge is not yours to run. This page explains what that means for your integration and your support team.
Before you begin
This page covers what happens during an online purchase on a program with 3-D Secure enabled. If you are not sure whether yours is, ask your account contact before reading on.
How it works
There is no challenge API, by design. Once a card is enrolled, the Access Control Server (ACS) decides whether to challenge at all, chooses the method, delivers any passcode, renders the challenge screen, and verifies the answer.
Your system is not in that loop. You learn the outcome from the transaction that settles afterwards.
What you control, and what you do not
| You control | The ACS controls |
|---|---|
| Whether the card is enrolled | Whether a purchase is challenged at all |
The cardholder's phone and email | Which method is used |
| Reacting to the resulting transaction | Passcode generation and delivery |
| The challenge screen the cardholder sees | |
| Verification, retries, and lockout |
There is no endpoint to trigger a passcode, verify one, resend one, or configure delivery. The ACS owns all of it.
Challenge methods
| Method | What the cardholder sees |
|---|---|
| Frictionless | Nothing. Risk assessment passes silently |
| 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, because modern 3-D Secure challenges only where the risk warrants it. Design your checkout for the challenge case anyway; that is the case that fails.
Steps
1. Keep contact details accurate
The ACS delivers passcodes using the phone and email on the cardholder
record. A stale phone number means a code sent somewhere the cardholder cannot
read it, and a purchase that fails for a reason neither of you can see.
2. Expect no event for a passcode challenge
A passcode challenge produces no webhook and no object. The ACS runs it from end to end, and what reaches you is the settled transaction if the purchase completes.
An authentication the cardholder abandons produces no transaction either, so it is invisible to you. When a cardholder says they tried to buy something and you hold no record of it, an abandoned challenge is the usual explanation.
Out-of-band is the exception. Those challenges do reach you, because your app is what answers them. See out-of-band authentication.
3. Do not build a passcode UI
Your application does not display the challenge, collect the code, or submit it. The merchant's checkout hands off to the ACS, which renders its own screen.
Verifying
Since you do not control the challenge, verification is about your side of the boundary:
- The cardholder's
phoneandemailare current and match what they expect - Your checkout flow, if you also operate a merchant surface, tolerates a redirect to an ACS screen and a return
- Your support team knows which questions are yours and which belong to the ACS; the table below sorts them
- An abandoned authentication produces no transaction, and nothing in your system waits indefinitely for one
Whose support question is it
| Cardholder says | Owner |
|---|---|
| "I didn't get a code" | Yours first. Check phone on the record, then escalate |
| "The code didn't work" | ACS. Escalate with the card id and the time of the attempt |
| "I wasn't asked to authenticate" | Expected. Most purchases are frictionless |
| "My card isn't protected online" | Ours. 3-D Secure is enabled per program, not per card. Raise it with your account contact |
| "The checkout page looked wrong" | ACS or merchant, not us |
The first row is both the most common and the one you can resolve yourself, by
checking the phone on the cardholder record.
Common errors
No API call produces a challenge, so there is no error table for this page. The failure modes are all elsewhere:
| Mistake | Symptom |
|---|---|
| Program not set up for 3-D Secure | Purchases are never challenged; no liability shift |
Stale phone on the cardholder | Passcodes sent where the cardholder cannot read them |
| Building a passcode UI | Dead code that never receives input |
| Waiting for a challenge event | A handler that never fires |
Related
- Transactions — what you do see
- Creating a cardholder — keeping contact details current