Skip to main contentArrow Right

Table of Contents

Customer authentication is the process of verifying that a buyer is who they claim to be—a critical safeguard in today’s high-volume, semi-anonymous digital payment landscape. Effective authentication reduces fraud, protects user accounts, and increases trust across every step of the transaction journey. For businesses operating in or serving customers across Europe, authentication also ties directly into regulatory compliance. Under the EU’s Revised Payment Services Directive (PSD2), most electronic payments require strong customer authentication (SCA), a set of rules designed to increase payment security.

This guide explains:

  • What strong customer authentication means under PSD2

  • When customer authentication is required for online transactions

  • The authentication methods and technologies used to meet SCA

  • Which transactions qualify for exemptions

  • How SCA affects conversion, fraud, and customer experience

  • How to prepare for fast-moving regulations 

What is strong customer authentication?

Strong customer authentication (SCA) is a PSD2 requirement designed to reduce fraud in electronic payments across the European Economic Area (EEA). It ensures that customers verify their identity using two or more independent authentication factors.

How SCA verifies identity

PSD2 requires using at least two of the following authentication factors:

  • Knowledge — something the customer knows (PIN, password)

  • Possession — something the customer has (phone, card, security key)

  • Inherence — something the customer is (fingerprint, face ID)

Requiring factors from different categories prevents attackers from using stolen passwords or compromised devices alone to complete a transaction.

Where SCA applies (PSD2 / EEA)

SCA is required when both the payer’s and payee’s payment service providers (PSPs) are located in the EEA. This covers 30+ EU and EFTA countries.

While region-specific, SCA is increasingly seen as a global best practice, especially as frameworks like PCI DSS and U.S. state privacy regulations introduce similar expectations for MFA and identity verification.

When strong customer authentication is required

Under PSD2, SCA applies primarily to customer-initiated electronic payments, especially online and remote transactions where fraud risk is higher.

Customer-initiated vs. merchant-initiated transactions

SCA is required when the customer is directly involved in approving an action, such as:

  • Checking out on an ecommerce site

  • Logging into an account that can initiate payments

  • Starting a bank transfer

SCA is generally not required for merchant-initiated transactions (MITs), including:

  • Subscription renewals after an SCA-approved mandate

  • Variable recurring billing

  • No-show or delayed charges

Online vs. offline scenarios

Most SCA requirements apply to remote or online payments. In contrast, in-person transactions follow different rules:

  • Chip-and-PIN payments usually satisfy SCA because the PIN acts as a second factor.

  • Low-value contactless payments may be exempt until cumulative limits are reached.

  • Card-present transactions generally carry lower fraud risk and may fall outside SCA requirements entirely.

Example scenarios

Scenario

SCA Required?

Why

Shopper enters card details online

Yes

Customer-initiated online transaction

Monthly subscription renews

No (typically)

MIT after SCA-approved mandate

Customer books a hotel online

Yes

Remote customer-initiated payment

No-show fee charged

Often no

Merchant-initiated

Contactless tap for €20

Often exempt

Low-value card-present payment

Strong customer authentication methods and technologies

Modern customer authentication builds on PSD2’s factor categories to offer secure MFA with minimal friction—especially for mobile checkout. Below are the most common authentication methods used for SCA.

Passkeys

Using public key cryptography, passkeys leverage biometric auth functionalities on users’ devices (e.g., Apple Face ID) to verify identity seamlessly without the need for passwords.

Strengths: Phishing-resistant, fast and low-friction, works well across mobile and desktop ecosystems

Best for: High-value payments, mobile banking apps, repeat customers who prefer a one-tap login experience

Magic links

Magic links authenticate users through a time-sensitive link sent to an email address they control.

Example of magic link authentication used by Medium
Fig: Example of magic link authentication used by Medium

Strengths: Easy for users to understand, removes password-related issues, accessible across devices

Best for: Guest checkout, low-risk transactions, early user onboarding

Authenticator apps

Authenticator apps like Google Authenticator or Authy generate time-based one-time passwords (TOTPs) that refresh every 30-60 seconds.

Fig: Screenshots of Google Authenticator with TOTP codes (Source: Vox)
Fig: Screenshots of Google Authenticator with TOTP codes (Source: Vox)

Strengths: Stronger than SMS codes, widely adopted and familiar, works offline once installed

Best for: Customer-initiated payments, accounts storing sensitive financial information, or recurring transactions where the customer is actively involved

Hardware security keys

Hardware security keys (USB, NFC, or Bluetooth) use FIDO2 / WebAuthn standards to verify identity with very high assurance. Because the private key never leaves the device and authentication requires a physical touch or presence check, these keys are inherently phishing-resistant—making them one of the strongest options for SCA in high-risk environments.

Strengths: Highly resistant to phishing and credential theft, high assurance factor for regulated payment flows, reliable across mobile, desktop, and hardware-constrained environments

Best for: High-value payments, fintech applications, B2B transactions, or any scenario where preventing account takeover is critical

Multi-factor choice

Allowing customers to choose between passkeys, TOTPs, or security keys reduces friction and increases conversion—while still meeting PSD2’s requirement for two independent factors.

Exemptions and out-of-scope transactions

SCA is mandatory for most electronic payments under PSD2—but not all transactions require a multi-factor challenge. Exemptions exist to reduce friction where fraud risk is low.

These decisions are made by issuers, acquirers, and PSPs based on real-time risk analysis. Common exemption categories include:

  • Low-risk transactions (TRA-based): Issuers may waive SCA when fraud rates stay below network-defined thresholds and the transaction appears low risk. Payment networks such as Mastercard historically set specific fraud-rate and value criteria for TRA exemptions, though exact thresholds vary by network and can change over time.

  • Low-value transactions: Payments under €30 until cumulative limits are reached (e.g., five consecutive low-value payments or €100 total).

  • Merchant-initiated or recurring payments: Subscriptions, variable recurring charges, and delayed charges after SCA has been performed once during mandate setup.

  • Whitelisted / trusted beneficiaries: Customers can designate certain merchants as trusted with their bank, reducing future SCA prompts.

  • Corporate payments: Certain B2B payment flows (e.g., lodge cards, virtual corporate cards) may be exempt due to existing enterprise controls.

  • Technical exceptions: Temporary scenarios where SCA cannot be performed due to service outages or authentication failures.

These exemptions streamline normal payment flows, but issuers can still require SCA at any time. Having flexible MFA options ensures transactions remain secure when exemptions do not apply.

Impacts on business and customer experience

Developers directly shape how SCA affects checkout speed, conversion, and fraud protection. Strong customer authentication reduces unauthorized transactions, but poorly implemented flows can introduce unnecessary friction.

Friction and conversion

According to Infosecurity Magazine, 24% of customers abandon purchases due to frustrating login or verification steps. Page load delays can further reduce conversions by 7% per second.

To minimize drop-off:

  • Use mobile-friendly MFA

  • Reduce redirects

  • Offer familiar options like biometrics or passkeys

Security and liability

Strong MFA significantly reduces fraud and strengthens the business’s position during disputes or chargebacks. Legal analyses from Jones Day emphasize that SCA decreases the likelihood of unauthorized payments—but UX trade-offs must still be managed.

Developer takeaway

The best results come from:

  • Keeping low-risk flows low-friction

  • Triggering step-up MFA only when risk signals warrant it

  • Supporting multiple verification methods to reduce user lockouts

SCA implementation considerations

Implementing SCA affects both user experience and backend systems, so developers should plan for a few key considerations.

  • Designing low-friction flows SCA can introduce friction if prompts appear unexpectedly or on mobile-unfriendly screens. Supporting intuitive methods (passkeys, device biometrics, authenticator apps) and minimizing redirects helps reduce drop-off.

  • Handling onboarding and support Any change to authentication typically increases support requests at launch. Developers should expect higher usage of account recovery, device enrollment, and MFA setup flows until users adapt.

  • Coordinating with PSPs Payment service providers may interpret PSD2 rules differently. Aligning on supported exemptions, soft-decline handling, and fallback paths ensures transactions aren’t rejected due to mismatched logic.

  • Planning for failures and edge cases —Authentication can fail due to outages, lost devices, or exemption mismatches. Build fallback flows—such as alternative MFA factors or secure recovery options—to maintain conversion and avoid user lockouts.

The future of strong customer authentication

SCA requirements are evolving quickly. Developers should expect more adaptive, secure, and interoperable requirements over time.

Growing regulatory expectations

Even outside the EEA, SCA-style protections are becoming more common. Frameworks like PCI DSS already require MFA for payment-related access, and several U.S. states are introducing stricter identity verification rules. Many analysts view SCA-level authentication as a matter of “when, not if” for global businesses.

Advances in authentication technology

Passkeys, device biometrics, and FIDO2/WebAuthn adoption continue to expand. These methods reduce reliance on passwords and improve both security and user experience—especially in mobile checkout flows. Developers should design systems that can incorporate these newer factors as they become mainstream.

AI-driven threat patterns

As attackers use AI to scale phishing, account takeover, and credential-stuffing attempts, authentication systems will need stronger risk signals. Adaptive or risk-based authentication—which evaluates device, behavior, and context in real time—is likely to become a default expectation.

Shifts driven by payment networks and PSPs

Major payment providers are already pushing for more flexible, outcomes-based approaches to SCA. For example, PayPal has advocated for SCA frameworks that prioritize reduced fraud—not rigid authentication steps—allowing PSPs to tailor flows that balance security and user convenience.

As networks adopt more adaptive interpretations of PSD2, developers may need to support dynamic, context-aware authentication logic.

Building strong customer authentication

Strong customer authentication protects users, supports PSD2 compliance, and reduces fraud across online payment systems. For developers, implementing secure and low-friction MFA requires:

  • Support multiple MFA methods (e.g., passkeys, authenticator apps, device biometrics)

  • Work seamlessly across mobile and web checkout

  • Handle recurring and merchant-initiated transactions without unnecessary SCA prompts

  • Adapt as regulations and payment network requirements evolve

A flexible approach to customer authentication helps teams maintain security while minimizing friction, ultimately improving conversion rates and reducing churn.

Implementing strong customer authentication with Descope

Descope provides a low-code and no-code platform for building MFA and customer authentication flows that support PSD2 SCA requirements. Developers can:

  • Add passkeys, OTPs, magic links, and biometric authentication without custom infrastructure

  • Create tailored authentication flows using visual drag-and-drop builders

  • Manage tokens, session logic, and MFA challenges through SDKs and APIs

Sign up for a Free Forever account to start building secure, scalable customer authentication flows today. Have questions about SCA or implementing MFA for payments? Book time with our experts.

MFA Dark
Fig: Drag & drop strong MFA with Descope