3D Secure Explained: How Strong Customer Authentication Works

3D Secure Explained: How Strong Customer Authentication Works

3D Secure is an authentication step that asks the cardholder to prove they are the person authorized to use the card before the payment is approved. Strong Customer Authentication (SCA) is the regulatory requirement behind it in Europe, and 3D Secure 2 is the protocol version most issuers now use to meet it.

The practical effect for a merchant is a trade: you shift some fraud risk to the issuer, and in return you accept more friction, more declined checkouts and less control over the decision. Whether that trade pays off depends on your order values, your chargeback history and where your customers are.

What is 3D Secure in a card payment?

A 3D Secure check is a redirect or in-app challenge that happens between the shopper and their bank, outside the merchant's checkout system. The name comes from the three parties in the original protocol: the merchant's acquiring domain, the card issuer's domain, and the interoperability domain that connects them.

When the check succeeds, the issuer returns a result to the merchant that includes an authentication value and a transaction status. That result is what later supports a liability shift, meaning the issuer rather than the merchant may absorb certain fraud chargebacks on that transaction. The shift is conditional. It applies to fraud claims on authenticated transactions in most cases, but it does not cover every dispute type, and it does not protect you if you cannot prove you shipped the goods.

3D Secure 2 versus the original version

The first version was built for browser payments and leaned heavily on static passwords and redirects. Success rates suffered, especially on mobile, and shoppers often abandoned the checkout mid-redirect. Version 2 redesigned the flow around risk-based decisions and added support for in-app and device-based authentication, which changes how much control you have over the challenge.

Four practical differences matter to merchants, and each one shifts work from the shopper to the data you send:

  • More data in the request. You can send dozens of optional fields about the transaction and the shopper. Richer data raises the chance of a frictionless approval.
  • Fewer visible challenges. Low-risk transactions are approved silently. The challenge rate depends on the fields you send and the issuer's own models.
  • Mobile and in-app support. The protocol works inside apps through software development kits rather than sending shoppers to an external browser page.
  • Delegated authentication. Under SCA, a merchant can ask a wallet provider such as Apple Pay or Google Pay to perform the authentication, which reduces duplicate prompts.

In practice, the upgrade rewards merchants who populate the optional fields consistently and treat authentication as a data problem rather than a checkout step. If your integration still sends only the minimum, you get the old behavior with a new name: more challenges, more abandoned carts, and little of the frictionless approval that version 2 was designed to allow.

How the authentication flow works, step by step

1. The shopper submits card details

Your checkout sends the card data, order amount, currency and transaction context to your payment service provider. You also send descriptive data: whether the order is a first purchase or a repeat, the shipping address, the account age. That data is what the issuer uses later to judge risk without asking the customer for anything.

2. The request is routed to the issuer

The payment network passes an authentication request to the bank that issued the card. In 3D Secure 2 this happens through an application programming interface, so the message carries far more context than the old redirect flow that 3D Secure 1 used.

3. The issuer decides whether a challenge is needed

This is the part most merchants miss. 3D Secure 2 allows for frictionless authentication: if the issuer is confident the transaction is genuine, it approves without showing the shopper anything. The shopper never sees a password prompt or an app notification, and the checkout completes as normal. A challenge is only raised when the issuer wants more evidence.

4. The challenge runs on the issuer's side

If challenged, the shopper confirms identity with an element their bank controls. Under SCA that means two independent factors from different categories: something they know (a password or PIN), something they have (a phone, a hardware token), or something they are (a fingerprint or face check). Two passwords do not qualify. Two SMS codes to the same phone do not qualify either.

5. The result comes back and the payment is authorized

The issuer returns an authentication result, and the merchant's system then submits the authorization request with that result attached. Authentication and authorization are separate steps. A successful authentication does not guarantee an approval, and an approval does not guarantee the funds will not be disputed for reasons other than fraud.

A worked example, with illustrative numbers

Say a US electronics store sells a $480 order to a customer in Germany paying with a Visa credit card. The numbers here are illustrative only.

The checkout sends the transaction with full billing and shipping addresses, the customer's account history and a device fingerprint. The issuer's model returns a frictionless approval in about 1.5 seconds. The merchant sees a successful authentication, submits the authorization, ships the goods and records the authentication value for the order file.

Now compare a second order on the same store: $1,900, a new account, a shipping address different from the billing address. The issuer challenges, the customer approves in their banking app, and the authentication succeeds. The merchant still reviews the order manually, because authentication says the cardholder is genuine, not that the order is legitimate. That second order could be a cardholder buying for a relative, or a cardholder under pressure from a scammer to approve the payment. In both cases the authentication passes.

Common misconceptions about 3D Secure

“It means every shopper gets a password prompt”

Most transactions under 3D Secure 2 never show a challenge. The visible prompt rate depends on the issuer, the risk signals in your request and the transaction value. Sending better data is the main lever a merchant has.

“An authenticated payment cannot be charged back”

Authentication supports a liability shift for fraud claims, subject to the card network's rules. It does nothing for claims that the item never arrived, arrived damaged, or did not match the description. Those remain your responsibility and are the largest category of chargebacks for most online stores.

“3D Secure replaces my fraud screening”

It answers one question: is the shopper the cardholder? It does not answer whether the order should be fulfilled. Friendly fraud, where a real cardholder disputes a real purchase, still passes authentication. You still need velocity checks, address verification and manual review thresholds.

“The issuer takes the loss automatically”

The shift is conditional on the transaction being correctly flagged as authenticated in the authorization message and on you holding the evidence. Misconfigured integrations are a common reason merchants lose disputes they thought were covered.

Why this matters for your chargeback ratio and checkout

Card networks monitor merchant chargeback ratios against thresholds that vary by network and merchant tier. Fraud chargebacks count toward those ratios. Pushing card-not-present fraud risk to the issuer can lower your exposure on stolen-card orders, which is often the fastest way to reduce a ratio that has drifted upward.

The cost shows up at checkout. Every challenge is a chance for the shopper to abandon, and challenge rates are not uniform across issuers, regions or device types. Large-ticket orders and new customer accounts see more challenges than repeat purchases from known devices. Measure your approval rate by issuer country and by order value band rather than trusting a single store-wide figure.

Know where the rule applies. SCA is a European requirement implemented through the second Payment Services Directive and national regulators, with enforcement timelines and exemption rules set per jurisdiction. The UK applies its own version. The US has no equivalent mandate, but many issuers there still run 3D Secure and many merchants enable it voluntarily to cut fraud. Verify current requirements with the relevant regulator or your acquirer, since thresholds and exemption guidance change.

If you are evaluating payment methods that sit outside the card dispute system entirely, crypto acquiring has no chargebacks, which removes one dispute category but not the need to verify the customer on delivery. Merchants who run both card and digital asset payments often find the contrast useful when sizing their overall fraud budget.

Deciding whether to enable 3D Secure and how to configure it

Start with your current dispute data. Split chargebacks into fraud claims and non-fraud claims. If fraud claims dominate and your average order value is high, authentication is likely to help. If most disputes are “item not received,” authentication will not move the number.

The table below summarizes the main decision factors.

Factor Favors enabling 3D Secure Favors leaving it off or partial
Dominant dispute type Fraud claims on stolen cards Item not received or not as described
Average order value High, where a single fraud loss hurts Low, where challenge abandonment costs more than fraud
Customer base New accounts, cross-border orders Repeat buyers on known devices
Regulatory context Selling into SCA jurisdictions Markets with no authentication mandate

Then work through configuration, in this order:

  1. Pass every optional data field your payment provider supports. Missing fields mean the issuer has less to work with and challenges more often.
  2. Check that your integration marks authenticated transactions correctly, then confirm the flag appears in settlement records.
  3. Study exemption rules in the markets you sell to, and ask your acquirer which ones you can use without losing liability shift.
  4. Run a controlled test: enable authentication on one country or order value band, then compare approval rate, fraud rate and dispute rate against the control group before rolling out wider.
  5. Store the authentication result with each order so you can retrieve it when a dispute arrives.

Treat 3D Secure as one control in a layered stack, not a switch that solves fraud. The stores that get the most from it are the ones that feed it good data and keep reviewing orders it approves. This article is general information, not financial, legal or tax advice.

Related Articles

  1. Account Takeover: How It Happens and How to Stop It

    Account takeover turns a customer login into fraud: stolen cards, drained credit, rerouted orders. See how attackers get in and how to stop them.

    · Payment Fraud Detection and Prevention

    Payment Fraud Detection and Prevention

  2. Fraud Detection: Methods Merchants Use to Spot Bad Transactions

    Fraud detection decides whether an order is real before you ship. See the methods merchants use, the chargeback costs, and the trade-offs in each check.

    · Payment Fraud Detection and Prevention

    Payment Fraud Detection and Prevention

  3. Ecommerce Fraud Prevention: A Practical Playbook

    Stop bad ecommerce orders before they ship. A practical playbook on chargebacks, order checks, US and EU rules, and safeguards that hold up at volume.

    · Industry Benchmarks, Case Studies, and Merchant Playbooks

    Industry Benchmarks, Case Studies, and Merchant Playbooks