SCA and 3DS: Strong Auth UX That Doesn't Kill Conversion

Design SCA/3DS UX by pushing as many payments as possible into the frictionless 3-D Secure flow, using PSD2 exemptions where they apply, and making the challenge step fast and legible when it does appear. Send rich data to the issuer, prefer native app authentication over redirects, and treat error recovery as a first-class screen.

What is SCA and when does it actually apply?

Strong Customer Authentication is a PSD2 requirement in the EEA and UK that most electronic payments authenticate with two of three independent factors: knowledge, possession, and inherence. It applies to card and account payments where both the payer’s and payee’s payment service providers are in scope. It is not a US requirement.

The two-of-three rule

The EBA Regulatory Technical Standards on SCA define three factor categories: knowledge (something the customer knows, such as a passcode), possession (something they have, such as a phone or a card), and inherence (something they are, such as a fingerprint or face scan). SCA requires two factors from two different categories, and the factors must be independent so that breaching one does not compromise another (EBA RTS on SCA and CSC, Commission Delegated Regulation (EU) 2018/389).

The regulatory basis sits in PSD2 (Directive (EU) 2015/2366) with the technical detail delegated to the EBA. The European Commission’s PSD2 pages describe the objective plainly: reduce fraud and make electronic payments safer (finance.ec.europa.eu). One practical consequence for product teams: an SMS one-time passcode plus a card PAN is weak, because both can travel together. A device-bound key plus a biometric is strong.

What is 3-D Secure and how does it deliver SCA?

EMV 3-D Secure (3DS 2.x) is the messaging protocol that carries authentication between the merchant, the card networks, and the issuing bank. It is how SCA is applied to online card payments. The protocol supports two outcomes: a frictionless flow where the issuer authenticates silently on risk data, and a challenge flow where the customer completes a step.

Frictionless versus challenge

In 3DS 2.x the merchant or its payment service provider sends a block of contextual data to the issuer’s Access Control Server: device fingerprint, billing and shipping details, transaction history signals, and more. The EMVCo 3-D Secure specification defines these data elements precisely (emvco.com). The issuer’s ACS scores that data and decides. If confidence is high enough, the payment is authenticated with no customer interaction: frictionless. If not, the ACS returns a challenge, and the customer authenticates in an issuer-controlled screen, typically inside their banking app or via a passcode.

The design goal is blunt: maximise the share of payments that clear frictionless, and make the challenge tolerable for the rest. Stripe’s Strong Customer Authentication documentation gives a clear practitioner-level account of how 3DS 2.x, exemptions, and issuer behaviour interact (stripe.com/docs/strong-customer-authentication).

Which SCA exemptions can reduce friction?

PSD2 permits several exemptions from SCA, defined in the EBA RTS. Used well, they let a payment skip the challenge entirely while staying compliant. The main ones are low-value transactions, transaction risk analysis, trusted beneficiaries, recurring transactions of fixed amount, and merchant-initiated transactions that sit outside SCA scope.

The exemptions at a glance

Exemptions are requested by the merchant or acquirer, but the issuer decides whether to honour them. If the issuer declines the exemption, it can still force a challenge, so an exemption is a request, not a guarantee.

Exemption	Typical condition	Who requests it	Notes
Low-value	Under EUR 30, with count and cumulative-amount caps	Acquirer/merchant	Issuer tracks counters; may challenge to reset
Transaction risk analysis (TRA)	Fraud rate below RTS thresholds, tiered by value band	Acquirer (needs low fraud)	Highest-value lever for mature portfolios
Trusted beneficiary	Customer allowlists the merchant with their bank	Issuer maintains list	Merchant flags; issuer controls the list
Recurring (fixed amount)	Same payee, same amount, SCA on first payment	Merchant	Subsequent charges exempt
Merchant-initiated (MIT)	Cardholder not present; agreement set up with SCA	Merchant	Outside SCA scope, not strictly an exemption

The TRA exemption is the one most worth engineering for, because it scales with volume and rewards a clean fraud record. Its thresholds are set in the RTS: the reference fraud rates decrease as the transaction value rises, so a low-fraud acquirer can exempt higher-value payments (EBA RTS on SCA and CSC, Articles 18 and following). For teams weighing whether to own this logic or lean on a processor, our note on build vs buy fintech infrastructure frames the trade-off, and the Stripe vs Adyen comparison covers how each handles exemption routing.

How do you maximise the frictionless rate?

Frictionless authentication depends almost entirely on the quality and completeness of the data you send the issuer. Populate every 3DS data element you legitimately can, keep cardholder details accurate and consistent, request the right exemptions, and give the issuer a reason to trust the transaction before it ever considers a challenge.

Data completeness is the lever

The 3DS 2.x message supports a large set of optional fields. Many merchants send the minimum and then wonder why challenge rates are high. Send more: cardholder name, email, phone, billing address, prior-transaction indicators, and accurate device and browser data. The EMVCo specification enumerates these fields and the ACS uses them directly.

Practical levers, in rough order of impact:

• Pass complete, correctly formatted billing and contact data. Mismatches read as risk.
• Request the TRA or low-value exemption where eligible, so the issuer can skip the challenge.
• Keep your fraud rate low, because TRA eligibility is gated on it.
• Use network tokenization where available, so the credential itself is stronger.
• Reuse device and behavioural signals across sessions for returning customers.

The same discipline that lifts frictionless rates also lifts checkout conversion generally. The habits we describe in fintech onboarding UX best practices and designing KYC flows that convert apply here: collect clean data once, reuse it, and never make the customer re-enter what you already hold.

Native app authentication or browser redirect?

Prefer native app authentication. When a customer can approve a payment with a biometric inside their banking app, the challenge is fast, familiar, and rarely abandoned. Browser redirects to an issuer’s authentication page are slower, easier to mistrust, and more prone to timeouts, especially on mobile web.

Why the channel matters

3DS 2.x was built with mobile in mind, and out-of-band authentication, where the issuer pushes the challenge to its own app, is often the smoothest path. The customer never leaves your flow for long, and the biometric they already use for banking does the work. Card networks describe this app-based, out-of-band pattern in their 3DS 2 programme material, such as Visa Secure and Mastercard Identity Check documentation.

The redirect path still matters for customers without the issuer app. There, the details decide the outcome: keep the transition visibly connected to your brand where the protocol allows, show a clear loading state, and never leave a blank screen while the ACS responds. On native mobile apps, use the 3DS SDK challenge presentation rather than a raw web view, so the challenge renders as part of the app.

How should you handle errors and recovery?

Treat challenge failure and timeout as expected states, not edge cases. When a challenge fails or the customer abandons it, show a plain-language screen that explains what happened, preserves the cart and entered details, and offers an immediate retry or an alternative payment method. Never dump a raw decline code on the customer.

Recovery patterns that hold conversion

The failure modes are predictable: the customer mistypes a passcode, the OTP never arrives, the session times out, or the issuer soft-declines. Each deserves a specific, calm response.

• Preserve state. The customer should never re-enter card or address data after a failed challenge.
• Explain in human terms. “Your bank needs to confirm this payment” beats an error code.
• Offer a fast retry, then an alternative method if the retry also fails.
• Distinguish a hard decline from an authentication hiccup, and route them differently.
• Log the 3DS transaction status and reason so support and analytics can see what happened.

Recovery is where trust is won or lost, and the principles overlap heavily with our guide to designing trust in fintech UX: clarity, continuity, and never making the customer feel they did something wrong. This is also core product-design work, and it is exactly the kind of flow we build with clients through our product design service.

Why does issuer behaviour vary so much?

Because the issuer’s Access Control Server makes the final call. Two banks receiving identical 3DS data can reach different decisions: one authenticates frictionless, the other issues a challenge. Issuers tune their own risk models, honour or decline exemptions on their own logic, and support different challenge channels, so real-world outcomes vary across a card portfolio.

Designing for a range you do not control

You cannot make an issuer skip a challenge. You can only make the challenge more likely to succeed and less likely to cost you the sale. That means instrumenting outcomes by issuer, BIN range, and transaction band so you can see where challenge rates and abandonment cluster, then adjusting the data and exemptions you send.

Some issuers lean heavily on out-of-band app authentication; others still fall back to SMS OTP, which is slower and more failure-prone. You design for the whole distribution, not the best case. Monitoring these patterns over time is a measurement discipline, and the analytics mindset in what makes a fintech marketing site convert carries over: watch the funnel, segment it, and act on where it leaks.

A closing reminder on scope: SCA and 3DS challenge logic apply to EEA and UK payments. If your customers are primarily in the US, the compliance driver is absent, though 3DS can still be used voluntarily as a fraud and liability-shift tool. Build the flow to the regulation that governs each transaction, not a single global default.

Where should you start?

Start by measuring your current frictionless rate and challenge abandonment, then close the data gaps feeding your issuer. Most conversion loss in SCA flows comes from thin 3DS data, unrequested exemptions, and clumsy error screens, all of which are fixable without waiting on the card networks or the banks.

If you want a checkout that stays compliant in the EEA and UK while holding conversion, FinWeb designs and builds these flows end to end, from exemption routing to the challenge and recovery screens your customers actually see. Talk to us.