How should merchants prepare for PSD2 strong customer authentication without sacrificing too much conversion?

Merchants should map which transactions are in scope, identify usable exemptions, and test the customer journey before the deadline. The practical goal is to reduce friction where authentication is mandatory, while preserving exemption eligibility through low fraud rates and good payment data. Teams should also align early with payment providers so the authentication flow does not create avoidable decline spikes.

What PSD2 strong customer authentication means for checkout design

PSD2 strong customer authentication changes checkout from a single payment handoff into a risk-based decision point. Merchants have to know which transactions trigger step-up authentication, which ones may qualify for exemption, and where the payment provider can absorb complexity so the customer does not face an unnecessarily broken flow.

The practical design issue is not simply adding more checks. It is deciding when authentication should be explicit, when friction can be reduced through exemptions, and how to preserve trust in the payment flow when the issuer or acquirer introduces extra challenge steps.

For teams building the journey, the key constraint is that authentication outcomes affect conversion in real time. If the payment page surprises customers, misroutes them, or creates repeated declines, merchants often see abandonment before they see any security benefit. That is why the journey needs to be designed and tested as a payment control, not as a late-stage compliance checkbox.

How merchants reduce friction without weakening compliance

Merchants usually get the best balance by preparing around three practical questions: which transactions are in scope, which exemptions are realistic, and where the customer experience breaks when authentication is inserted. That means checking card-not-present flows, recurring and low-value patterns, and the payment methods or geographies where SCA is most likely to appear.

Exemptions matter because they let merchants preserve conversion without removing security. But exemptions are not a free pass, they depend on the transaction profile and on keeping fraud performance strong enough to remain eligible. The operational implication is that fraud monitoring, payment data quality, and exemption strategy have to be managed together, because a weak risk signal can turn a useful exemption into a missed approval or forced challenge.

Merchants should also work early with their PSP, acquirer, and fraud stack owners so that friction is introduced in the right place. If the provider integration is only checked at launch, merchants often discover avoidable decline spikes, confused redirect handling, or inconsistent authentication prompts after the customer journey is already live.

Why testing the journey matters more than assuming the regulation is just a gateway issue

PSD2 SCA is often treated as a technical payment gateway task, but the real failure mode is cross-team misalignment. Checkout, fraud, payments, customer support, and analytics all see different symptoms if authentication is configured badly, and those symptoms can look like fraud loss, issuer declines, or a broken UX rather than a simple compliance gap.

Testing should cover the full path from basket to authorization result, including exemption handling, challenge flows, fallback behaviour, and mobile checkout edge cases. The point is to see whether the control works under real customer conditions, not just whether it exists on paper.

Current guidance from the payment and identity ecosystem increasingly favours reducing friction through stronger, more user-friendly authentication methods and better risk decisions rather than relying on weaker fallback patterns. NIST’s digital identity guidance is useful here because it reinforces the value of phishing-resistant authentication and clear assurance levels in journeys where fraud and customer abandonment are both material concerns. NIST SP 800-63 Digital Identity Guidelines provides a useful external reference point for how assurance and user experience should be balanced.

Risk and Threat Considerations

The main risk is that merchants overcorrect for conversion and end up with weak exemption governance, or overcorrect for compliance and create unnecessary abandonment. In both cases, the business impact shows up quickly: higher drop-off, more false declines, more customer support load, and weaker payment performance.

Failure mechanism: Authentication is introduced too late in the journey, exemption logic is not tested against real issuer behaviour, or the payment provider integration does not handle step-up and fallback cleanly. That can produce challenge loops, unnecessary declines, and loss of exemption eligibility when fraud or transaction-quality signals deteriorate.

Impact: Merchants can lose approved payments, damage customer trust, and create a checkout experience that is both less secure and less profitable. In payment environments, the same weakness can also make fraud patterns easier to exploit because teams stop trusting the authentication flow and disable or bypass controls informally.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-63 and OWASP ASVS set the technical controls, while PCI DSS v4.0 and ISO/IEC 27001:2022 define the regulatory obligations.

Framework	Control / Reference	Relevance
NIST SP 800-63	Digital Identity Guidelines	SCA balancing assurance and user friction aligns with digital identity assurance guidance.
Recommendation — Apply assurance levels and phishing-resistant methods to reduce friction without lowering trust.
OWASP ASVS	V6 — Authentication	Checkout authentication flows depend on clear authentication requirements and step-up handling.
Recommendation — Verify authentication paths, challenge handling, and fallback behaviour before launch.
PCI DSS v4.0	8.6 — Interactive Access for System and Application Accounts	Payment environments need tight control over authentication and account access around sensitive payment flows.
Recommendation — Restrict interactive access and protect payment-related authentication paths from misuse.
ISO/IEC 27001:2022	A.5.15 — Access control	SCA rollout needs defined access and transaction-control governance across payment journeys.
Recommendation — Define and enforce access and control rules for payment authentication workflows.

Practitioner Guidance

What to prioritise: Map the exact transaction types that are likely to trigger SCA, then separate them from flows that may legitimately qualify for an exemption. That gives you a concrete view of where conversion risk is real versus where the payment team is assuming risk that the regulation does not require.

What to verify: Test live-like checkout journeys with your provider before launch, including challenge, exemption, and decline paths on desktop and mobile. Make sure the payment state returned to the front end is unambiguous enough for support teams, analysts, and fraud teams to interpret quickly.

Decision rule: If a control reduces fraud but materially harms conversion, treat the issue as a payment-flow design problem, not just a compliance problem. If exemption eligibility depends on poor data quality or rising fraud, preserve the exemption only after you can show the underlying risk signal is stable.

Practitioner takeaway: The best SCA rollout is one that makes authentication visible only when it is truly needed, while keeping exemption logic, provider integration, and fraud signals disciplined enough that reduced friction does not become hidden risk.