Explainer
Compliance & security3DS2 and SCA for High-Risk Merchants
What 3DS2 and Strong Customer Authentication actually do, how the liability shift works, which exemptions apply, and how high-risk merchants should route authentication.
- By the OpenGate underwriting desk
- Updated
- 10 min read
3DS2, short for 3D Secure 2, is the second version of the card industry’s authentication protocol, built by EMVCo so that banks and merchants exchange far more data during a payment. SCA is Europe’s legal requirement, under PSD2, that electronic payments be authenticated with at least two independent factors. Together they decide who pays when a transaction is disputed.
What 3DS2 changed
3DS2 is the second generation of the protocol EMVCo built to let an issuing bank confirm that the person paying is the cardholder. Version 2 exchanges over a hundred data points during a payment: device information, account history with the merchant, shipping address, purchase details. The issuer’s risk engine reads that data in real time and decides between two outcomes. The payment passes frictionless, with no extra step for the customer, or the issuer challenges the cardholder, usually with a code or a biometric in their banking app.
The first version of the protocol was a clunky redirect page that killed conversions. Version 2.2 runs inside apps and browsers, and the merchant controls which transactions request a challenge and which request exemptions. For a high-risk merchant, that control is the point. Authentication is no longer a blanket yes or no. It is a routing decision, made per transaction, per segment and per market.
Version 2.2 also brought the exemption flags that make routing possible. The merchant’s request travels inside the authentication message, the issuer’s risk engine accepts or overrides it, and the outcome returns with the authorization. That exchange is what lets the same checkout feel different for different customers, and it is the layer a high-risk merchant tunes.
What SCA requires
Strong Customer Authentication is the legal layer, written into European payment regulation under PSD2. When a European customer pays, the payment must be authenticated with at least two of three independent factors: something the customer knows, like a password or PIN, something they possess, like the card or a registered device, and something they are, like a fingerprint or face scan. Two of the three factors must come from different categories.
SCA applies to card payments the customer initiates within the EEA. The first transaction of a recurring series gets authenticated; later scheduled payments count as merchant-initiated and do not repeat the challenge. The regulation is European, but the protocol is global, and issuers outside Europe increasingly challenge high-risk transactions the same way. If you sell to European customers, SCA is not optional. The acquirer and the schemes expect it, and skipping it puts the file at risk.
A transaction, step by step
A 200 euro first deposit from a new player lands in the gateway. The merchant’s 3DS2 message carries the device fingerprint, the account age and a request for a challenge, because first deposits on this site are a fraud-heavy segment. The issuer reads the message, scores the device against the cardholder’s history and challenges. The player approves in the banking app, the transaction authenticates and the funds authorize. If that deposit later comes back as unauthorized, the issuer pays, not the merchant.
The same transaction from a returning player who has paid this merchant monthly for a year goes the other way. The gateway requests frictionless with transaction risk analysis. The issuer’s engine sees the history, agrees the risk is low and authorizes with no step for the player. Two transactions, same value, different routing, and the difference is the data in the message plus the issuer’s score. That is the entire routing discipline in miniature.
How the liability shift works
The liability shift is the mechanism that makes authentication worth your attention. When a transaction runs through 3DS and the issuer authenticates the cardholder, the issuer carries the liability if that transaction later comes back as fraud. When a transaction skips authentication and comes back as fraud, you carry it. The shift covers fraud reason codes, where the cardholder says they never authorized the payment, including much of what merchants call friendly fraud. It does not cover service disputes, where the cardholder says the product never arrived or was not as described. Those still need evidence, and the chargeback guide explains how to build it.
High-risk merchants should care more than most, for two reasons. Fraud-coded disputes take a larger share of their mix, so the shift protects real revenue. And acquirers often require authentication attempts on high-risk merchant categories as a condition of the account. Skipping authentication to save friction can put the account itself at risk, not just the transaction. One limit applies in the United States: as of the April 2026 edition of Visa’s rules, authenticated transactions get no protection from Visa’s card-absent fraud dispute condition when the merchant is coded for adult content, gambling, wire transfers and money orders, cryptocurrency and quasi-cash, or stored-value loads. Ask your acquirer which code you carry before you count on the shift.
The distinction matters because so many high-risk disputes are service-coded. A nutraceutical subscription that does not cancel cleanly produces not-as-described disputes, and no amount of authentication shifts those. The shift protects the fraud slice of the book. The service slice still runs on evidence, terms and refund policy, which is where the rest of the dispute toolkit earns its keep.
The exemptions that matter
PSD2 and the scheme rules allow certain payments to skip the challenge, or skip authentication entirely, when the risk is demonstrably low. Mail and telephone orders are treated in practice as outside SCA, on a narrower official reading than most merchants assume, which is why MOTO payments carry rules and risks of their own. These are the exemptions a high-risk merchant actually uses:
- Low-value payments. Purchases below 30 euros can skip authentication, subject to cumulative limits the issuer tracks per card and per method.
- Transaction risk analysis. The acquirer and issuer run real-time fraud scoring on the transaction. If the score is low and the acquirer’s fraud rates stay under the reference levels the regulation sets, the payment passes without a challenge.
- Trusted beneficiaries. A customer can whitelist your business with their own bank. Later payments to a trusted merchant skip the challenge.
- Merchant-initiated recurring payments. After the first authenticated setup, scheduled subscription charges do not repeat authentication.
Low-value and trusted-beneficiary exemptions carry the least operational weight, because they depend on cardholder behavior you cannot control. The exemption that moves real volume for a high-risk merchant is transaction risk analysis, which rests on the acquirer’s fraud rates and therefore on the whole book’s discipline. One bad month of fraud from another merchant in the acquirer’s portfolio can tighten the exemption that was working for you, which is why the routing logic must read the acquirer’s status, not just your own.
An exemption is a request. The issuer can refuse any exemption and challenge the transaction anyway, and when it does, the liability shift applies as usual. When an exemption you asked for is granted, the payment goes through without a challenge and fraud liability generally stays on your side, so request exemptions on the traffic you trust.
How to configure 3DS2 routing
Authentication routing is a tuning exercise you repeat as the traffic changes. Work it in this order:
- Establish a baseline. Enable 3DS2 on all transactions, allow frictionless where the issuer permits it, and log three numbers per segment: challenge rate, approval rate and fraud-coded chargebacks.
- Request exemptions on the safe segments. Low-value purchases and recurring payments are the obvious candidates. Ask for transaction risk analysis where your acquirer supports it, then watch the fraud rate, because your right to the exemption depends on staying under those regulatory levels.
- Force challenges on the risky segments. New customers, first purchases on an account, high-ticket orders, mismatched country or device, velocity outliers. These are the transactions where the liability shift is worth the friction.
- Handle soft declines deliberately. When an issuer returns a soft decline, retry the transaction with authentication or a different exemption path instead of dropping the customer. A soft decline is often the issuer asking for more proof.
- Review monthly. Split approval rates and chargebacks by authentication status, then move the thresholds. A segment that stops producing fraud gets lighter authentication. A segment that starts producing disputes gets challenged.
Approval rate versus protection
Every challenge is friction, and friction costs conversions. A measurable share of challenged checkouts abandons, which is why blanket authentication is the wrong answer for a healthy business. The trade-off runs the other way too. Fraud-coded chargebacks cost the sale twice: the funds, the fee and the ratio pressure that puts the account at risk. The right setting splits the traffic by risk.
The practical rule: challenge where the fraud risk or the ticket size is high, and go frictionless where the customer is known, the purchase is small or the recurring relationship is established. If your vertical is heavy with fraud-coded disputes, like gaming or CBD, err toward challenge on first deposits. If your vertical is heavy with service disputes, authentication will not fix it, and you should spend the effort on delivery proof and refund policy instead.
The split should follow the vertical. For gaming, first deposits are the risk. For CBD, the recurring rebill is. Tune the challenge rules where the disputes actually originate, and leave the rest frictionless.
What breaks when routing is misconfigured
Routing failures show up as symptoms, and each one traces to a setting:
- Challenge rates near zero on new customers: the risky segments are not being challenged, and the fraud liability is sitting with you.
- Challenge rates near a hundred percent: the gateway is challenging everything, and conversion is paying for it.
- Rising issuer soft declines: the exemptions you request do not match what the acquirer supports, so issuers push back with retry requests.
- Fraud chargebacks that arrive authenticated: the liability shift was never confirmed, or the transaction fell into a reason code the shift does not cover.
- Frictionless traffic that suddenly gets challenged: the acquirer lost its exemption eligibility, usually after a fraud-rate movement, and the routing did not adapt.
Each symptom has a fix in the settings, but only if you look at the authentication data monthly. Merchants who treat 3DS2 as a compliance checkbox get the approval rates of a checkbox. Merchants who treat it as a risk tool get the split they designed.
What to check in your own 3DS2 setup
Start with your own numbers. Pull three months of data split by authentication status: challenge rate, approval rate and fraud-coded chargebacks for new customers, returning customers and recurring charges. Add the list of exemptions your current acquirer accepts. Those figures show whether the routing matches your risk or works against it.
If the routing cannot be tuned where you process today, request a written offer and describe the segments that hurt. OpenGate’s 3DS2 routing handles exemptions, and the rules are configured for your vertical at go-live. A human underwriter reads the file and answers within 1 business day: an offer, a list of the documents still missing, or an honest no. Applying is free.