SCA and 3DS2 Explained: PSD2 Payment Authentication
Selling online to European customers means dealing with SCA and 3DS2 whether you want to or not. Strong Customer Authentication is a hard legal requirement under PSD2, and 3D Secure 2 is how most merchants actually fulfill it. What sca 3ds2 means in practice, where the edge cases live, and what it costs to get wrong — that's what this guide covers.
What Is SCA? Strong Customer Authentication Defined
Strong Customer Authentication is a verification requirement under PSD2 — the EU's Payment Services Directive 2. It applies when a customer initiates an electronic payment and both their card's issuing bank and the merchant's acquiring bank are in the European Economic Area.
The rule itself is about factors. Secure authentication has to use at least two of three, and they have to come from separate categories:
- Knowledge — something the cardholder knows: a password, PIN, or security question
- Possession — something the cardholder has: a mobile phone, hardware token, or smart card
- Inherence — something the cardholder is: fingerprint, face recognition, voice ID
The factors must be independent of each other — compromising one can't expose the other. They also have to be dynamically linked to the specific transaction amount and payee. A static password that works on every purchase doesn't qualify.
Scope: SCA covers customer-initiated online card purchases. It doesn't apply to merchant-initiated transactions (recurring billing after the initial auth), mail order or telephone orders, or any transaction where the merchant or the cardholder's bank is outside the EEA. That last category is called one-leg-out, and it's relevant for merchants with mixed global customer bases.
What Is 3DS2 and How Does It Relate to SCA?
The name breaks down like this: 3D stands for three domains — the issuing bank that issued the cardholder's card, the acquiring bank that processes the merchant's payments, and the card network sitting between them. Version 2 distinguishes it from the original protocol, which Visa launched in 1999 under the name "Verified by Visa." EMVCo, jointly owned by Visa, Mastercard, Amex, and other schemes, built and now maintains the 3D Secure 2 standard.
What's the connection to SCA? PSD2 requires that card payments be authenticated with two factors. 3D Secure 2 is the mechanism merchants use to actually run that authentication for card-not-present transactions. Technically, open banking flows and bank app redirects can also satisfy SCA — but in the real world, 3DS2 handles the vast majority of online card payments.
Visa and Mastercard stopped supporting 3DS1 for European transactions in October 2022. After that cutoff, routing card payments through 3DS1 wasn't just outdated — it was out of scheme compliance. What was once optional became mandatory, and the 3D Secure 2 upgrade that processors had been recommending for years became the only path forward.
History of 3D Secure: From 3DS1 to 3DS2
3DS1 launched in the early 2000s. The authentication mechanism was a redirect popup, usually hosted by the card's issuing bank. Cardholders saw a new browser window, entered a static password they'd often forgotten, and either got through or dropped off. Abandonment at that step was a measurable problem for merchants across every category.
| Feature | 3DS1 | 3DS2 |
|---|---|---|
| Authentication UI | Redirect popup / new window | Embedded iframe or native SDK |
| Data sent to issuer | ~15 data points | 100+ data points (device, behavior, history) |
| Mobile support | Poor — no native SDK | Full native iOS and Android SDK |
| Frictionless flow | Not available | Yes — majority of transactions |
| Challenge method | Static password | OTP, push notification, biometric |
| Liability shift | Yes | Yes (expanded coverage) |
| EU status | Deprecated October 2022 | Mandatory |
3DS2 was designed to fix the conversion damage 3DS1 caused. By sending over 100 risk signals to the issuer at the start of the flow, the protocol gives banks enough data to approve most transactions without asking the customer to do anything at all. When a challenge does fire, it's an SMS code or biometric, not a password the cardholder set up three years ago.
How 3DS2 Authentication Works: Step by Step
Every 3DS2 transaction routes through one of two paths. The issuing bank picks which one based on the risk data it receives. In most cases, customers never notice authentication happened at all.
Frictionless flow (70–90% of transactions):
- The customer enters card details at checkout
- The merchant's payment gateway or 3DS server collects 100+ data points: device fingerprint, IP geolocation, browser characteristics, transaction history, behavioral signals
- These are sent in an Authentication Request (AReq) to the card network's directory server, then forwarded to the issuing bank's Access Control Server (ACS)
- The ACS runs automated risk assessment — typically in under a second
- If the transaction scores as low risk, the ACS issues a frictionless approval with no customer action required
- The transaction completes with liability shift to the issuing bank
Challenge flow (10–30% of transactions):
- Steps 1–3 are the same — data collection and AReq submission
- The ACS flags the transaction as higher risk: new device, unusual amount, new delivery address, or elevated fraud rate for that merchant category
- The customer gets prompted for a second factor — SMS one-time passcode, push notification from their banking app, or biometric
- Customer completes the challenge
- Transaction approves with liability shift to the issuer
The frictionless path is what separates 3DS2 from its predecessor. Most customers complete an authenticated transaction without doing anything extra. When a challenge does appear, it's a familiar method — the same push notification they use to approve a bank transfer.
SCA Exemptions and When They Apply
Not every transaction requires SCA. PSD2 defines exemptions that let payments go through without two-factor authentication. Requesting an exemption isn't the same as getting one. The issuing bank decides whether to honor it. Rejection means a soft decline, and the merchant has to resubmit with SCA triggered.
| Exemption type | Condition | Limit |
|---|---|---|
| Low-value transaction | Transaction under €30 | Max 5 consecutive transactions or €100 cumulative since last SCA |
| Transaction Risk Analysis (TRA) | Acquirer or issuer fraud rate below threshold | €100 at ≤0.13% fraud rate / €250 at ≤0.06% / €500 at ≤0.01% |
| Recurring transactions (fixed amount) | Same amount, same payee after initial SCA | No limit |
| Merchant-initiated transaction | Subscription billing, installments | SCA required only on the first transaction |
| Trusted beneficiary | Cardholder has whitelisted the merchant with their bank | Merchant-specific, cardholder-controlled |
| Secure corporate payments | Dedicated B2B payment systems | Regulator-approved systems only |
Liability follows who claimed the exemption. If the acquirer requests a TRA exemption and the issuer accepts it, the acquirer (and by extension, the merchant) holds fraud liability if something goes wrong. If the issuer applied the exemption independently, the liability sits with them. Merchants running any volume on TRA exemptions should track which path covered each transaction.
How SCA and 3DS2 Affect Merchants
The business case for getting sca 3ds2 right goes well past regulatory compliance:
- Liability shift: completed 3DS2 authentication moves fraud chargeback liability from the merchant to the issuing bank. No authentication means the merchant absorbs card fraud directly. EU card fraud runs 17 times higher in regions where SCA isn't required.
- Authorization rates: 3DS2 often improves authorization rates versus unauthenticated payments. Issuers approve more confidently when they have 100 data points instead of a card number and a CVV.
- Checkout conversion: challenge flow adds a step, but frictionless 3DS2 adds almost no friction at all. Well-implemented 3DS2 typically produces flat or positive conversion impact compared to 3DS1.
- Data quality: the quality of the AReq payload determines what percentage of transactions go frictionless. Merchants who send only mandatory fields get higher challenge rates than those populating optional fields — device fingerprint, historical transaction count, shipping address age.
- Geography: SCA rules differ across EEA member states, the UK (its own post-Brexit SCA timeline), and other markets. A global checkout needs to segment these correctly at the request level.
SCA Compliance Checklist for Online Merchants
Getting sca 3ds2 setup right requires more than enabling 3DS2 at the gateway. The ongoing work matters too:
- Verify your PSP or gateway supports 3DS2. Most major processors (Stripe, Adyen, Worldpay, Braintree) handle this automatically. Regional or older processors may still run on 3DS1 or have partial implementations.
- Audit your AReq data payload. Work with your payment provider to confirm you're sending all 100+ optional data fields, not just the mandatory minimum. Each additional field improves the issuer's frictionless approval confidence.
- Map your transaction types. Identify which payments are merchant-initiated (subscriptions after setup), mail order/telephone order, or one-leg-out. Flag these correctly — they don't go through 3DS2 and shouldn't be routed there.
- Test the challenge flow UX. When a step-up challenge fires, the experience should be clear and mobile-friendly. A confusing OTP screen costs conversions. Test across devices and browsers before go-live.
- Monitor frictionless vs. challenge rates. A drop in frictionless rate signals a problem — degraded data payload, an issuer changing its risk model, or a merchant category fraud rate crossing a TRA threshold.
- Track exemption outcomes. Know which exemptions you're requesting, which are accepted, and which are coming back as soft declines. Soft declines on low-value exemptions often mean the cumulative €100 limit was hit without a reset.
- Watch the PSD3 timeline. The European Commission's PSD3 proposal is in legislative process; member state implementation is expected 2026–2027. It extends SCA rather than replacing it — authentication requirements get more granular, not lighter.
One thing many merchants don't realize about sca 3ds2: the entire framework is scoped to electronic payment transactions regulated under PSD2, which means fiat currency moving through banks and card networks. Cryptocurrency payments sit entirely outside that scope.
When a customer pays with Bitcoin, Ethereum, or a stablecoin, the transaction doesn't touch a card network or bank. No issuer runs an ACS. There's no AReq, no directory server, no challenge flow to manage. SCA rules don't apply because the payment type falls outside the regulatory perimeter.
For merchants, this plays out concretely. A crypto checkout has no 3DS2 authentication step, no OTP request, and no challenge flow. The customer pays from their wallet; the funds arrive. Chargebacks don't exist either — crypto transactions are irreversible, which removes the fraud liability mechanics entirely.
For merchants looking to add a payment option completely outside the card authentication framework, Plisio supports 20+ cryptocurrencies with no SCA overhead, no chargeback exposure, and no dependency on an issuing bank's risk model.
What SCA and 3DS2 Mean for Your Payment Stack
SCA isn't getting simpler. PSD3 will extend authentication requirements further, and the UK runs its own SCA enforcement track post-Brexit. The practical question for merchants is how well the sca 3ds2 implementation is actually running, not whether to implement it.
Done well, the framework works for everyone involved. Merchants get liability protection on fraud chargebacks. Issuers get richer signals via 3D Secure 2's expanded data payload and approve more transactions confidently. Customers get secure authentication that usually doesn't interrupt their checkout at all. The merchants who get stuck are the ones who enabled 3DS2 at the gateway minimum and never looked at their frictionless rates, AReq payload quality, or exemption hit rates again.
