How should payment organisations implement strong customer authentication without creating unnecessary checkout friction?

Why This Matters for Security Teams

strong customer authentication is meant to reduce fraud, but payment organisations still lose conversions when every checkout is treated as equally risky. The practical challenge is to distinguish low-risk, routine payments from transactions that need step-up verification without turning the flow into a series of abandoned screens. Standards-based control design, such as NIST SP 800-53 Rev 5 Security and Privacy Controls, helps teams anchor authentication decisions in risk and assurance instead of blanket friction.

This is also where identity failures become expensive. NHI Mgmt Group notes that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys in its Ultimate Guide to Non-Human Identities, a reminder that payment journeys increasingly depend on back-end systems, not just the customer-facing login step. If those systems are overprivileged or poorly monitored, even a perfect checkout challenge can be undermined after authentication. In practice, many security teams encounter checkout fraud and customer drop-off only after a blunt MFA policy has already been rolled out across low-risk payment paths.

How It Works in Practice

The best implementation starts with transaction risk, not with a fixed rule that every payment must be challenged. Payment organisations typically combine possession and inherence factors where the risk engine indicates a need for stronger assurance, then keep lower-risk purchases on a lighter path. The deciding inputs usually include device reputation, geo-velocity, merchant category, amount, prior customer behaviour, and signals from transaction monitoring.

That approach works best when customer authentication is tied to the specific payment event being authorised. The customer should see what is being approved, including amount, merchant, and destination where available, so the factor challenge is understandable rather than arbitrary. This also reduces the chance of approving one action while the attacker performs another. Guidance from ISO/IEC 27001:2022 Information Security Management supports control discipline around identity, logging, and monitoring, but the payment-specific design still needs runtime decisioning.

• Use at least two independent factors only when the transaction risk exceeds a defined threshold.
• Prefer short-lived, transaction-bound challenges over repeated prompts during a single checkout session.
• Link the authentication event to device telemetry and fraud analytics so step-up decisions are explainable.
• Log the full decision path for dispute handling, fraud review, and control tuning.

For back-end payment orchestration, the same principle applies to service identities: limit secrets exposure, rotate credentials, and avoid broad standing access. NHIMG research on the Ultimate Guide to Non-Human Identities shows why overexposure of credentials creates a wider attack surface than the checkout screen alone suggests. These controls tend to break down in high-volume mobile checkout flows because repeated step-up prompts, app switching, and cross-border risk signals can introduce latency and false declines faster than the fraud model can adapt.

Common Variations and Edge Cases

Tighter authentication often increases abandonment and support overhead, so organisations have to balance fraud reduction against conversion, accessibility, and regulatory expectations. Best practice is evolving for high-friction channels such as app-to-app transfers, wallet-based payments, and recurring card-on-file transactions, where a rigid rule set can do more harm than good.

One common edge case is cross-border commerce. A transaction that looks unusual from one country may be completely normal for a travelling customer, so velocity and geography should influence the challenge rather than trigger it automatically. Another is recurring or merchant-initiated payments, where customer presence is not always practical and the control objective shifts toward strong initial enrolment, secure tokenisation, and ongoing monitoring.

Teams should also be careful not to confuse stronger customer authentication with broader account protection. If the payment platform or fraud stack relies on long-lived secrets, weak service account controls, or poor auditability, the checkout challenge may be effective while the surrounding environment remains easy to abuse. The Twitter Source Code Breach is a reminder that identity and access weaknesses outside the user journey can still create major downstream impact. For that reason, current guidance suggests combining adaptive authentication with transaction-specific policy, customer transparency, and back-end identity hygiene rather than treating SCA as a standalone checkout widget.

Related resources from NHI Mgmt Group

• How should organisations implement two-factor authentication in high-risk digital services without creating unnecessary user friction?
• How should mobility platforms implement biometric authentication without creating unnecessary friction?
• How should security teams implement push authentication in remote work environments without creating approval fatigue?
• How should organisations implement PSD2 controls without adding too much checkout friction?