How Strong Customer Authentication (SCA) Works
Strong Customer Authentication is triggered when a customer initiates an electronic payment that falls within the scope of PSD2. The issuing bank evaluates whether authentication is required and, if so, challenges the customer to verify their identity using at least two independent factors before the transaction is approved.
Customer initiates payment
The cardholder enters their payment details at checkout. The merchant's payment gateway evaluates whether the transaction requires SCA based on amount, region, and exemption eligibility.
Merchant signals authentication intent
The merchant passes transaction data — device fingerprint, billing address, order history — to the acquirer. Using 3D Secure 2, this data is sent to the card network's access control server for risk scoring.
Issuer performs risk analysis
The issuing bank scores the transaction risk. For low-risk transactions, it approves a frictionless flow and authenticates silently. For higher-risk transactions, it triggers a challenge step.
Customer completes two-factor challenge (if required)
The customer provides two of three factors: something they know (PIN or password), something they possess (a one-time passcode sent to their phone), or something they are (biometric authentication such as a fingerprint or face scan).
Liability shifts to issuer
Once SCA is successfully completed, liability for fraudulent chargebacks shifts from the merchant to the card issuer, reducing the merchant's financial exposure.
Why Strong Customer Authentication (SCA) Matters
SCA was introduced to address a measurable rise in card-not-present fraud as ecommerce volumes grew across Europe. The regulation creates a consistent authentication baseline, but its business impact extends well beyond compliance — it directly affects authorisation rates, chargeback liability, and customer trust.
Card-not-present fraud accounted for 73% of total card fraud losses in Europe before SCA enforcement, according to the European Central Bank's report on card fraud. Following mandatory SCA rollout, several acquirers reported a 25–40% reduction in fraud on authenticated transactions. At the same time, Stripe's analysis of SCA adoption found that merchants using intelligent exemption management maintained conversion rates within 1–2 percentage points of pre-SCA baselines, demonstrating that friction can be minimised when authentication is implemented thoughtfully.
Liability Shift
When a transaction is authenticated under SCA, fraud-related chargeback liability moves from the merchant to the card issuer. Merchants who skip authentication on in-scope transactions remain fully liable.
Strong Customer Authentication (SCA) vs. Traditional Password Authentication
Traditional password-only authentication relies on a single factor — knowledge — which is easily compromised through phishing, credential stuffing, or data breaches. SCA raises the bar by mandating two factors from different categories, making attacks that steal only one factor insufficient.
| Dimension | Traditional Password Auth | Strong Customer Authentication |
|---|---|---|
| Factors required | 1 (knowledge only) | 2 from distinct categories |
| Regulatory basis | None | PSD2 / EBA RTS |
| Fraud liability | Merchant | Issuer (post-authentication) |
| Scope | All digital services | EEA electronic payments |
| Exemptions available | No | Yes (TRA, low-value, recurring) |
| Technical standard | None mandated | 3DS2 for card payments |
| Frictionless option | No | Yes, via risk-based authentication |
Types of Strong Customer Authentication (SCA)
SCA encompasses several authentication methods, and issuers may offer different experiences depending on their technology stack and customer base.
App-based authentication is the most seamless approach. The customer approves the payment directly inside their bank's mobile app, often using a biometric scan. No redirect or OTP entry is needed, resulting in the lowest friction path.
One-time passcode (OTP) via SMS or email remains the most common fallback. The issuer sends a time-limited code to the customer's registered device. This satisfies the possession factor (the registered phone) alongside a knowledge factor such as a PIN.
Hardware tokens are used primarily in business banking and high-value retail contexts. The customer generates a code on a physical device. Whilst highly secure, hardware tokens are rare in consumer ecommerce flows.
Biometric authentication — fingerprint, face ID, voice recognition — satisfies the inherence factor. When embedded in a banking app, biometrics allow silent or near-silent SCA completion, supporting frictionless multi-factor authentication flows within 3DS2.
Out-of-band authentication involves verifying on a separate channel from the payment initiation — for example, approving a web purchase via a push notification on a mobile device. Regulators accept this as satisfying both the possession and inherence factors when biometrics are involved.
Best Practices
Every H2 section should serve the reader's practical needs. SCA compliance is partly regulatory and partly an engineering problem — the advice for merchants and developers differs meaningfully.
For Merchants
Audit your transaction mix before optimising. Categorise transactions by amount, geography, and customer relationship to understand which exemptions apply. Recurring fixed-amount subscriptions, trusted beneficiaries, and transactions below €30 can often proceed without SCA, reducing friction for your best customers.
Work with your payment provider to ensure 3DS2 data richness. The more contextual data you send during authentication — device fingerprint, shipping address match, purchase history — the more likely the issuer approves a frictionless flow. Sending minimal data increases the chance of a step-up challenge.
Implement retry logic with SCA. When a transaction is soft-declined due to missing authentication, automatically resubmit with a 3DS2 challenge flag rather than presenting a generic decline to the customer.
For Developers
Request the correct exemption flags in your 3DS2 authentication request. Incorrectly flagging a transaction as TRA-exempt when your acquirer has not assessed the risk shifts liability back to you and may increase decline rates.
Handle all 3DS2 challenge flows client-side. Redirect-based 3DS1 is largely deprecated — implement the native 3DS2 SDK or iframe-based challenge UI to ensure a smooth in-context experience. Redirecting users away from checkout at payment confirmation is a known conversion killer.
Use webhook-driven authorisation flows. Listen for authentication status callbacks before submitting the authorisation request to the network. Submitting an authorisation without a valid authentication reference on an SCA-required transaction will result in a hard decline.
Common Mistakes
Treating SCA as binary. Many merchants assume every transaction either needs full SCA or is fully exempt. In practice, exemption eligibility is assessed per transaction at the issuer level, not the merchant level. Building rigid exemption logic without fallback authentication leads to decline spikes.
Confusing authentication and authorisation. SCA governs the authentication step. A successfully authenticated transaction can still be declined at authorisation for insufficient funds or card restrictions. Conflating the two leads to poor error messaging and incorrect retry logic.
Applying exemptions without liability awareness. Merchants sometimes request TRA exemptions without understanding that incorrect exemption requests can result in the merchant — not the issuer — bearing chargeback liability for disputed transactions.
Neglecting recurring payment setup. The initial payment in a recurring series requires SCA. Subsequent merchant-initiated transactions (MITs) are exempt, but only if the first transaction was correctly authenticated and the MIT flag is set in subsequent requests. Skipping initial SCA breaks the entire recurring exemption chain.
Ignoring regional enforcement dates. SCA enforcement timelines varied across EEA countries and the UK. Merchants operating across multiple markets sometimes applied UK-specific exemption thresholds to EEA transactions or vice versa, causing inconsistent authentication behaviour.
Strong Customer Authentication (SCA) and Tagada
Tagada's payment orchestration layer sits between merchants and their acquirer/processor connections, making SCA configuration a centralised concern rather than a per-integration task.
With Tagada, SCA exemption logic, 3DS2 data enrichment, and soft-decline retry flows are configured once at the orchestration layer and applied consistently across all connected acquirers — eliminating the need to re-implement SCA handling for each processor integration.
When routing transactions, Tagada evaluates SCA requirements and exemption eligibility before dispatching to the optimal acquirer, ensuring that authentication requests carry the correct flags and that frictionless flows are requested wherever the transaction profile supports them. This reduces checkout friction while maintaining full PSD2 compliance across every payment route.