Blog / Fundamentals

How 3-D Secure Works, and What It Means for Your Cardholders

3-D Secure explained: what happens during a step-up challenge, why liability shifts, how one-time codes should be delivered, and how to keep it from costing sales.

13 August 2026 9 min read

You have used 3-D Secure even if you have never heard the name: the moment during an online checkout where you are asked for a code, or bounced to your bank's app, before the payment goes through. The "3-D" is three domains — the acquirer's, the issuer's, and the interoperability layer between them.

What actually happens

1. The cardholder submits a payment at a merchant.
2. The merchant's system asks whether authentication is needed for this transaction.
3. The issuer assesses the risk from what it knows: amount, merchant, history, device signals.
4. Frictionless — if risk is low, it is approved with no challenge and the cardholder sees nothing.
5. Challenge — if not, the cardholder is asked to prove presence, usually with a one-time code.
6. The result returns to the merchant and the payment proceeds or fails.

Most transactions are frictionless. The challenge path is the exception, and it is the exception that determines how many customers you lose.

Why it exists: liability shift

The commercial reason 3-D Secure is used at all is liability shift. On a normal online transaction, if a payment is fraudulent, the merchant generally eats the chargeback. On an authenticated transaction, liability moves to the issuer.

That is why merchants ask for it on risky transactions and why regulation in some regions mandates it. In Europe, Strong Customer Authentication under PSD2 requires two independent factors on most electronic payments, with a set of exemptions for low-value or low-risk transactions.

Where the code comes from

This is the part relevant to anyone running a card programme. The issuer decides how the cardholder is challenged. SMS was the default for years; it is now widely regarded as the weakest option, because SIM swap attacks are cheap and effective and delivery is unreliable across borders.

On ON5, step-up codes are delivered by email, to the address fixed on the card at issue. Three consequences follow, and they are worth designing around:

• Get the cardholder email right at issue. It cannot be changed afterwards. This is deliberate: a card's step-up codes must not become redirectable by editing a profile later, which would turn a profile-edit vulnerability into a card-takeover vulnerability.
• The email carries your brand. Your name, logo and support contacts — not ON5's. A cardholder mid-checkout who receives a code from a brand they do not recognise will abandon the purchase, and rightly so.
• The message states the context. Merchant and amount, where known. A code with no context is exactly what a phishing caller relies on: "read me the code you just received". A cardholder who did not just check out can see that and stop.

Designing the experience

The challenge step is where purchases die. A few things reliably help:

• Tell cardholders in advance. The welcome email should say a code may be required and that you will never ask for it. The first time someone sees a step-up should not be mid-purchase with no context.
• Make the code easy to read. Large, monospaced, well-spaced digits. People are reading it off one device and typing it into another, often in a hurry.
• Put the code in the subject line. Most people can complete the challenge from a notification without opening anything.
• Never ask for it yourself. Every message should say so. Then make sure your support team genuinely never does, because one exception trains customers to be phished.

What it does not protect against

Worth being clear about the limits. 3-D Secure confirms the cardholder is present and consenting at that moment. It does not detect a cardholder who has been socially engineered into making a payment themselves — authorised push payment fraud passes every authentication check by design, because the real customer really did approve it.

It also does nothing for card-present fraud, and nothing for merchant disputes about goods and services. It is one control among several, not a fraud strategy.

Practical guidance

• Validate the cardholder email at issue — a typo there is a card whose codes go to a stranger.
• Fill in your brand details before issuing anything real. The step-up email inherits them.
• Warn cardholders about codes in onboarding, not at first challenge.
• Have a documented answer for "someone called asking for my code" before it happens.

Frequently asked questions

Related reading

• Virtual Card Issuing: A Complete Guide
• White-Label Card Programmes: Getting the Branding Right
• KYC and Compliance for Card Programmes: A Primer