Strong Customer Authentication (SCA) — What Engineers Actually Need to Know

What SCA Actually Requires

Let's cut through the regulatory language. PSD2's Strong Customer Authentication boils down to one rule: when a European cardholder makes an online payment, you need to verify their identity using at least two of three independent factors. That's it. Everything else — 3DS2, exemptions, soft declines — is implementation detail around that core requirement.

The three factor categories are distinct, and your authentication flow must combine elements from at least two of them:

In practice, the most common combination you'll see is possession (the cardholder's phone receiving a push notification) plus either knowledge (a PIN entered in the banking app) or inherence (biometric unlock). As an engineer, you don't implement the authentication UI yourself — the issuing bank handles that. Your job is to trigger the right flow and handle the response correctly.

3DS2: The Implementation Mechanism

3D Secure 2 is how SCA gets implemented for card-not-present transactions. If you worked with the original 3D Secure (the dreaded "Verified by Visa" redirect pages), forget everything you know. 3DS2 is a fundamentally different protocol.

The key architectural difference is the data-rich authentication request. 3DS2 sends over 100 data elements to the issuer — device fingerprint, browser metadata, transaction history, shipping address match signals — which lets the issuer's risk engine make a decision without necessarily bothering the cardholder. This is what enables the "frictionless flow" that keeps your conversion rates from tanking.

Frictionless vs. Challenge: The Two Paths

Every 3DS2 authentication takes one of two paths. Understanding this fork is critical to your implementation:

The frictionless flow is the golden path. The issuer looks at the data you sent, decides the risk is low enough, and approves the authentication without the cardholder lifting a finger. From the user's perspective, nothing happened — the payment just went through. In my experience, a well-implemented 3DS2 integration sees 70-85% of transactions go frictionless, depending on the issuer mix and transaction profile.

The challenge flow kicks in when the issuer wants more proof. The cardholder gets redirected to an iframe or a pop-up (or a push notification to their banking app) where they complete the second factor. This is where you lose people. Challenge flows add friction, and friction kills conversion. I've seen drop-off rates of 15-30% on challenge flows, which is why exemptions matter so much.

SCA Exemptions: Your Conversion Rate's Best Friend

Not every transaction needs SCA. The regulation defines several exemptions, and knowing when to request them is arguably the most impactful thing you can do for your European payment conversion rates. Here's the breakdown:

The TRA exemption is the one most teams should focus on first. If your acquirer's fraud rate is below the regulatory threshold (for example, under 0.13% for transactions up to €100), you can request TRA and skip the challenge entirely. The catch: liability shifts to the acquirer, so your PSP needs to support it and your fraud numbers need to be clean.

For subscriptions, the rule is straightforward: authenticate the first payment with full SCA, then subsequent charges at the same fixed amount are exempt as merchant-initiated transactions. If the amount changes (say, a plan upgrade), you need to re-authenticate. I've seen teams get burned by not handling mid-cycle plan changes — the second charge gets declined, the customer churns, and nobody realizes it was an SCA issue until someone digs through the decline codes.

Handling Soft Declines

This is where most SCA implementations fall apart in production. A soft decline happens when the issuer rejects a transaction specifically because SCA wasn't performed — typically response code 65 or 1A in the ISO 8583 world, or the equivalent in your PSP's API.

The correct response to a soft decline is not to give up. It's to retry the transaction with 3DS2 authentication. Your payment flow needs a retry path that looks something like this:

// Simplified soft decline handling
async function processPayment(paymentIntent) {
  const result = await chargeCard(paymentIntent, { sca: 'exemption_requested' });

  if (result.declineCode === 'authentication_required') {
    // Soft decline — retry with 3DS2
    const authedResult = await chargeCard(paymentIntent, {
      sca: 'required',
      threeDSVersion: '2.2.0'
    });
    return authedResult;
  }

  return result;
}

The key insight: you should attempt the exemption first, then fall back to full authentication on soft decline. This "optimistic" approach means the majority of your transactions skip the challenge flow entirely, and only the ones the issuer flags actually go through 3DS2. I've measured this approach recovering 8-12% of transactions that would otherwise have been lost to unnecessary friction.

Impact on Conversion and What You Can Control

Let's talk numbers. Before SCA enforcement, European card payment conversion rates for well-optimized checkouts sat around 92-95%. Early SCA implementations saw that drop to 75-85% — a brutal hit. Today, with mature 3DS2 and smart exemption strategies, the best teams are back to 89-93%.

The things within your control that move the needle most:

1. Send rich data in the 3DS2 request. The more data the issuer has, the more likely they are to approve frictionless. Shipping address, email, phone number, device fingerprint, transaction history — send everything you've got.
2. Request exemptions strategically. Don't blanket-request TRA on every transaction. Use it where it makes sense based on amount, risk profile, and your acquirer's fraud rate.
3. Handle soft declines gracefully. Build the retry loop. Monitor your soft decline rate. If it's climbing, something in your exemption logic needs tuning.
4. Test with real issuers. Sandbox environments don't replicate issuer behavior accurately. The frictionless rate you see in testing will not match production. Plan for that gap.

Practical Implementation Checklist

If you're building or refactoring a European payment flow, here's what I'd prioritize:

• Ensure your PSP supports 3DS2 version 2.2.0 or later — earlier versions have lower frictionless rates and missing exemption support.
• Collect and pass browser fingerprint data (IP, user agent, screen dimensions, timezone) in every authentication request.
• Implement the soft decline retry loop before you go live. Not after. Not "in the next sprint."
• Set up monitoring for your frictionless rate, challenge completion rate, and soft decline rate. These three metrics tell you everything about your SCA health.
• Build exemption logic that's configurable without a code deploy — you'll be tuning thresholds as you learn your issuer mix.
• Handle the threeDSMethodURL device fingerprinting step. Skipping it tanks your frictionless rate because issuers get less data to work with.

References

• PSD2 Directive (EU) 2015/2366 — EUR-Lex
• EBA Regulatory Technical Standards on Strong Customer Authentication
• EMVCo 3-D Secure Specification
• Stripe — Strong Customer Authentication Documentation
• Adyen — 3D Secure 2 Integration Guide

Disclaimer: This article reflects the author's personal experience and opinions. Product names, logos, and brands are property of their respective owners. Pricing and features mentioned are subject to change — always verify with official documentation.