What 3-D Secure is
3-D Secure is a protocol that lets the issuing bank confirm, during an online purchase, that the person using the card is the cardholder. The "three domains" are the merchant's (acquirer), the network's, and the issuer's. Each network brands its program: Visa Secure, Mastercard Identity Check, American Express SafeKey, Discover ProtectBuy. The protocol itself is EMV 3-D Secure, maintained by EMVCo; the current versions are 2.2 and 2.3.
The first version, from the early 2000s, redirected the customer to a bank page and asked for a static password. It was so disruptive that many merchants disabled it, and the networks retired it in October 2022. Version 2 was designed around three changes:
- Risk-based authentication. The merchant sends the issuer a large set of data about the transaction, the device and the customer, and the issuer decides whether it needs to challenge at all. Most transactions are approved without the customer noticing.
- Native mobile and in-page flows. No redirect to a bank page; challenges appear in an iframe or in the merchant's app, and can be a one-time code, a push notification to the banking app, or a biometric.
- Merchant-initiated and non-payment authentications. Cards can be authenticated when stored, and the issuer can be consulted for a later merchant-initiated charge.
In Europe, the PSD2 Strong Customer Authentication mandate made 3-D Secure effectively compulsory for most online card payments. In the United States there is no mandate: the merchant chooses, transaction by transaction, and the choice is the subject of this guide.
How an authentication flows
Three systems talk to each other in the second or two before the authorization is sent.
- The 3DS Server on the merchant side (usually your gateway's) collects the transaction data plus device and browser information gathered by a script on the checkout page, and sends an authentication request.
- The network's Directory Server routes the request to the issuer.
- The issuer's Access Control Server scores the request. It either authenticates immediately (the frictionless flow) or asks for a challenge, which the customer completes in the checkout page. The ACS returns a result.
- The merchant sends the authorization with the authentication result attached. The issuer sees an authenticated transaction and applies the liability shift.
The data that drives the frictionless decision is what makes version 2 work. Alongside the amount and card, a well-formed request includes the cardholder's name, email, billing and shipping addresses and whether they match, the account's age and order history with the merchant, device fingerprint and browser attributes, and for card-on-file customers, how long the card has been stored. The more of it you send, the more transactions clear without a challenge; a request with the minimum fields is challenged far more often.
The result codes that matter
| Outcome | Visa ECI | Mastercard ECI | Meaning | Liability |
|---|---|---|---|---|
| Fully authenticated | 05 | 02 | The issuer verified the cardholder, frictionless or by challenge | Shifts to the issuer for fraud disputes |
| Attempted | 06 | 01 | The issuer or card does not participate, and the network's attempts server stood in | Shifts to the issuer for fraud disputes, in most cases |
| Not authenticated | 07 | 00 | Authentication failed, was rejected, or was not attempted | Stays with the merchant |
The ECI (electronic commerce indicator) travels with the authorization along with the CAVV/AAV cryptogram and the DS transaction ID. All three must be passed to the processor for the liability shift to apply.
An authenticated transaction can still be declined at authorization. Authentication asks "is this the cardholder?"; authorization asks "will the bank pay?" A customer who passes the challenge and has no funds is still a 51.
What the liability shift covers, and what it does not
The liability shift is precise, and the precision is where merchants get surprised.
| Dispute | Covered by the shift? | Notes |
|---|---|---|
| Fraud: cardholder denies authorizing the transaction (Visa 10.4, Mastercard 4837) | Yes | The issuer cannot charge back an authenticated or attempted transaction under the fraud reason codes. This is the entire benefit. |
| Goods not received, not as described, cancelled service, credit not processed (Visa 13.x, Mastercard 4853) | No | Authentication proves who paid, not that you delivered. These disputes proceed normally. |
| Processing errors: duplicate, wrong amount (Visa 12.x, Mastercard 4834) | No | Unaffected. |
| Authorization disputes (Visa 11.x, Mastercard 4808) | No | Unaffected. |
| Fraud on a subsequent merchant-initiated charge | Depends | The initial stored-credential transaction can be authenticated and covered; later merchant-initiated charges are out of scope for the shift unless the issuer is consulted for that charge. See stored credentials and MITs. |
| Any dispute where the ECI, cryptogram or transaction ID was not passed in the authorization | No | The most common way to lose a shift you paid for: an integration that authenticates and then sends the authorization without the results. |
The networks also reserve the right to withdraw liability protection from merchants with sustained excessive fraud rates, and have narrowed protection for "attempted" outcomes in some regions.
Put simply: 3-D Secure removes the fraud reason codes from your dispute mix. For a card-not-present business, those are typically the largest single category and the hardest to win, so the effect is large. It does nothing for the disputes that come from unclear descriptors, slow refunds or late deliveries, which are addressed in chargebacks explained.
The cost: friction, abandonment and fees
Every authentication has three costs, and the policy in the next section is about spending them where they buy something.
- Challenge abandonment. When the issuer challenges, some customers do not complete it: they do not have the phone with the banking app, the one-time code does not arrive, the popup looks like phishing. Industry figures put challenge abandonment in the range of 10 to 25 percent, with wide variation by issuer and by customer demographic. Frictionless rates with good data are typically 80 to 95 percent, which means the blended loss across all authenticated transactions is a few percent; on transactions with poor data it is far worse.
- Authentication fees. Gateways charge a few cents to around ten cents per authentication request, and the networks charge small fees on top. Negligible on a $500 order, material on a $9 one.
- Latency. A frictionless authentication adds one to three seconds to checkout; a challenge adds however long the customer takes.
Against that, the benefit is the fraud chargebacks avoided, each worth the transaction amount plus a fee plus its effect on your dispute ratio. The arithmetic is per transaction type: on a first-time $800 order shipping to a new address, authentication is clearly worth it; on a $15 reorder from a three-year customer, it is not.
A policy for US merchants: who to authenticate
Because nothing forces you to authenticate everything, the right approach is rules that send the risky transactions through 3-D Secure and let the rest go straight to authorization. A workable starting policy:
| Situation | Authenticate? | Reasoning |
|---|---|---|
| Amount above a threshold (for example $250, tuned to your average ticket) | Yes | The fraud exposure per transaction justifies the friction. |
| First order from a new customer | Yes | No history to judge by; fraud concentrates in first orders. |
| Shipping address differs from billing, or shipping to a freight forwarder | Yes | Classic fraud pattern. |
| AVS or CVV mismatch that you would otherwise accept | Yes | Authentication resolves the doubt instead of declining the sale. |
| Issuer soft-declines with "authentication required" (Visa 1A, Mastercard 65) | Yes, always | The issuer is telling you it will approve if authenticated. Retrying without 3-D Secure fails. |
| Digital goods, gift cards, high-resale items | Yes | Fraud targets what can be resold. |
| Repeat customer, known device, matched address, modest amount | No | Low fraud risk; friction costs more than it saves. |
| Merchant-initiated recurring charge | Not possible | The customer is not present. Authenticate the initial stored-credential transaction instead. |
| Payment link paid on the customer's own phone (text-to-pay) | By amount and history | The customer-initiated, verified nature already lowers risk; reserve authentication for large or unusual amounts. |
Tune the thresholds to your own fraud and dispute history, and revisit quarterly.
Two refinements once the basic policy is running. Data-only authentication (Mastercard Identity Check Insights, Visa Data Only) sends the 3-D Secure data to the issuer for scoring without asking for authentication or a challenge: no liability shift, but issuers use the richer data to approve more, and there is no friction at all. It is a reasonable default for the transactions you would not otherwise authenticate. And request a frictionless outcome where the protocol allows the merchant to indicate a preference; issuers are not bound by it but many honor it for low-risk requests.
If you sell into Europe or the UK: SCA and its exemptions
Under PSD2 and the UK's equivalent rules, electronic payments require Strong Customer Authentication unless an exemption applies, and issuers decline unauthenticated transactions that needed it. 3-D Secure 2 is how card payments meet the requirement. The exemptions a merchant or acquirer can request:
| Exemption | Condition | Who applies it |
|---|---|---|
| Low value | Under €30 (£30), with limits on the count and cumulative value of consecutive exempted transactions | Acquirer, in the authorization |
| Transaction risk analysis (TRA) | The acquirer's fraud rate is below a threshold that sets the maximum exempted amount: €100, €250 or €500 | Acquirer, based on its own fraud rate |
| Trusted beneficiary (allow-listing) | The cardholder has added the merchant to a trusted list at their bank | Issuer, at the cardholder's request during a challenge |
| Recurring / merchant-initiated | Subsequent charges under a mandate whose first transaction was authenticated | Out of scope rather than exempt; the initial CIT must be authenticated |
| Secure corporate payments | Payments through dedicated corporate processes such as lodged cards | Acquirer |
| Mail order and telephone order | Not electronic, so out of scope | Not applicable |
Issuers may refuse an exemption and demand authentication. When an acquirer exemption is applied, fraud liability stays with the merchant; when the transaction is authenticated, it shifts.
The practical consequence for a US business with European customers: route them through 3-D Secure by default, apply exemptions only through a gateway that supports them, and expect a higher challenge rate than for US cards.
Integration: what has to be in place
- A 3DS Server. In practice your gateway's, invoked through its checkout components or API. Hosted checkout pages generally include it; direct integrations have to call it before authorization.
- The device-data script on the checkout page, so the browser and device attributes are collected. Without it every request is thin and challenges rise.
- Rich request data: customer name, email, phone, billing and shipping addresses, account age, order history, card-on-file age. Map every field you have; the frictionless rate tracks the completeness of this data.
- Challenge rendering in an iframe or native component, on both desktop and mobile, tested with real issuer challenges.
- Passing the results into the authorization: ECI, CAVV or AAV, DS transaction ID and protocol version. Verify in the gateway's transaction detail that authorized transactions show the authentication data; if they do not, the liability shift is not happening.
- Handling every outcome: authenticated, attempted, failed, rejected, unavailable and timed out. Decide in advance whether a failed authentication blocks the sale or falls back to an unauthenticated authorization (which keeps the sale and the liability).
- Handling the 1A / 65 soft decline by rerunning the transaction through authentication automatically rather than showing the customer a decline.
- Reporting: authentication rate, frictionless rate, challenge success rate and fraud chargebacks on authenticated versus unauthenticated transactions, so the policy can be tuned.
Where FloPay fits
FloPay's hosted checkout includes 3-D Secure 2 on every connected gateway that supports it, collects the device data on the page it serves, passes the authentication results through to the authorization, and reruns "authentication required" soft declines automatically. Because the same checkout is reached from an invoice, a text-to-pay link or an embedded iframe, one authentication policy covers every channel. The API exposes 3-D Secure for direct integrations with the same gateway-agnostic result handling.
Authenticate the risky ones, not everyone
FloPay hosted checkout runs 3-D Secure 2 on any gateway, passes the results through to authorization, and handles the soft declines. Ask us what your fraud chargebacks would look like with a rules-based policy.
See Hosted Checkout