Knowledge Hub
Risk 7 min read

3DS2 and Strong Customer Authentication (SCA) Explained

SCA has been mandatory for UK and European card payments since 2021. Done well, it's nearly invisible to customers. Done poorly, it adds friction that kills conversion. Understanding how 3DS2 works — and how to use exemptions correctly — is one of the most commercially impactful things a merchant can do.

David Sampson · Founder, IceTree

Payment consultant specialising in PSP matching, card acquiring, and high-risk merchant solutions ·

What SCA Is and Why It Was Introduced

Strong Customer Authentication is a requirement of the EU's revised Payment Services Directive (PSD2), adopted into UK law post-Brexit. It mandates that electronic payment authentication must use at least two of three factors:

  • Knowledge: something the customer knows — a PIN, password, or security question
  • Possession: something the customer has — a phone, card reader, or hardware token
  • Inherence: something the customer is — fingerprint, face ID, or other biometric

The regulation was designed to address rising card-not-present fraud. A stolen card number and CVV — previously enough to complete many online transactions — are insufficient under SCA because the fraudster also needs access to the cardholder's phone or biometric.

How 3DS2 Works

3-D Secure 2 is the card-network protocol (run by Visa and Mastercard) that implements SCA at the point of sale. When a cardholder initiates an online payment, the following happens behind the scenes:

  1. The merchant's gateway sends the authorisation request to the acquirer, including a package of contextual data — device fingerprint, browser type, IP address, shipping address, transaction history, and more
  2. The acquirer routes this to the card scheme (Visa/Mastercard), which forwards it to the cardholder's issuing bank
  3. The issuing bank evaluates the data against its fraud models and decides: approve frictionlessly, or issue a challenge
  4. If frictionless: the transaction is authenticated and authorised without the customer doing anything additional
  5. If challenge: the cardholder is prompted for a second factor — typically a one-time passcode sent to their phone, or biometric confirmation via their banking app

The key difference from the original 3DS1 is the volume and quality of contextual data sent in step 1. 3DS1 sent very little context, meaning issuers defaulted to challenging most transactions. 3DS2 sends over 150 data points, enabling far more confident frictionless decisions.

Frictionless vs Challenge Flow

The two possible authentication outcomes have very different conversion implications:

  • Frictionless. The issuer authenticates silently using the contextual data. The customer sees nothing unusual. Conversion is unaffected. Most well-configured 3DS2 implementations achieve 70–90% frictionless rates.
  • Challenge. The customer is asked for additional verification — a push notification, OTP, or biometric. Challenges increase drop-off, typically by 15–30% depending on the audience and the quality of the bank's authentication UX. Mobile banking app challenges (native flows) have materially lower abandonment than SMS OTP challenges.

The conversion impact is real

Merchants who were on 3DS1 and saw a 3–5% decline rate improvement when moving to 3DS2 were not unusual. The contextual data 3DS2 provides lets issuers approve legitimate customers without challenge — and legitimate customers account for the vast majority of the drop-off that 3DS1 caused.

SCA Exemptions

The regulation provides a set of transaction-level exemptions that allow SCA to be bypassed where the fraud risk is demonstrably low. These are the most commercially important lever merchants have. The main exemptions are:

Low-Value Transactions

Transactions under €30 (approximately £25) are exempt. However, there is a rolling limit: after five consecutive exemptions, or once cumulative exempt spend reaches €100, SCA is required. This makes LVT exemptions useful for low-ticket items but not reliable for subscriptions.

Transaction Risk Analysis (TRA)

If an acquirer or issuer's fraud rate is below a defined threshold, they can apply TRA exemptions — effectively vouching for the transaction's low risk based on their data. TRA exemptions are available for transactions up to €500. The acquirer applies the exemption in the authorisation request; the issuer decides whether to honour it. Approval rates vary significantly by issuer.

Trusted Beneficiaries

Cardholders can whitelist a merchant with their issuing bank. Once whitelisted, future transactions are exempt from SCA. Adoption is low — most customers don't proactively whitelist merchants — but it can be an effective retention tool for subscription businesses.

Merchant-Initiated Transactions (MIT)

Recurring charges where the amount and frequency were agreed at the point of SCA (the initial transaction) are classified as merchant-initiated and are exempt. This is how subscriptions and recurring billing work post-SCA: the first payment requires SCA; subsequent payments are MITs and proceed without challenge.

Impact on Conversion and What Merchants Can Do

For most merchants, 3DS2 has improved or maintained conversion compared to pre-SCA. The merchants who see negative conversion impact typically have one of three problems:

  • Poor 3DS2 data quality. If your gateway sends minimal context data, issuers default to challenge. Ensure your integration sends the full device fingerprint, browser data, and shipping/billing address.
  • Not using exemptions. Many merchants leave TRA and LVT exemptions unclaimed because their gateway is not configured to request them. Ask your acquirer what exemption strategies they apply.
  • Incorrect MIT flagging. Subscriptions failing SCA are almost always misconfigured — the recurring charge isn't being flagged as MIT. Check with your payment provider that your subscription flows are correctly structured.

The practical checklist

Verify that your integration sends all 3DS2 data fields; confirm your acquirer actively applies TRA exemptions; check that subscriptions are flagged as MIT from payment two onwards; and monitor your challenge rate in your PSP dashboard — target under 10% of eligible transactions being challenged.

FAQ

Common questions answered.

Strong Customer Authentication is a regulatory requirement under the EU's PSD2 directive, adopted into UK law. It requires that electronic payments are authenticated using at least two of three factors: something the customer knows (a PIN or password), something the customer has (a phone or hardware token), and something the customer is (biometric). It's designed to reduce fraud by making it harder to use stolen card details alone.

3DS2 (3-D Secure version 2) is the technical protocol that implements SCA for card payments. Unlike the original 3DS1 — which redirected customers to a bank page and frequently showed a clunky password prompt — 3DS2 passes far more transaction context data to the issuing bank. This allows the bank to make smarter decisions about when to challenge, resulting in a better customer experience and a much higher rate of frictionless authentication.

A frictionless flow is when the issuing bank authenticates a transaction using the contextual data sent by 3DS2 — device fingerprint, transaction history, IP address, shipping address match — without requiring any additional input from the customer. The transaction is authenticated invisibly. Frictionless flows typically account for 70–90% of transactions when 3DS2 is properly implemented, preserving conversion while meeting SCA requirements.

The main exemptions are: low-value transactions (under €30, with a rolling limit of €100 or five transactions); low-risk transactions assessed by the issuer or acquirer (Transaction Risk Analysis / TRA); trusted beneficiaries listed by the customer with their bank; merchant-initiated transactions (MITs) for pre-authorised subscriptions; and corporate cards used in B2B contexts. Exemption approval rates vary by issuer and transaction profile.

The first payment in a subscription requires SCA. Subsequent recurring charges — where the amount and frequency are fixed — qualify as merchant-initiated transactions (MITs) and are exempt from SCA. However, changes to subscription amount, frequency, or merchant require a new SCA. If you're using a PSP for subscriptions, confirm that they correctly flag MITs in their authorisation requests; incorrect flagging is a common cause of decline uplift.

Seeing higher-than-expected decline rates?

SCA misconfiguration is one of the most common and most fixable causes of decline uplift. We can review your current setup and identify whether your 3DS2 integration and exemption strategy is costing you revenue.

Payment Stack HealthcheckSpeak to a Consultant

We use cookies to analyse site performance and measure the effectiveness of our outreach. Privacy policy