What is the difference between an exemption strategy and a fallback process for abandoned authentication?

Why the Two Paths Solve Different Problems

An exemption strategy and a fallback process sit at different points in the customer journey. The exemption path is a pre-authentication decision: it tries to keep eligible transactions out of unnecessary SCA challenges by applying a valid PSD2 exemption. The fallback path is a recovery mechanism after authentication was still required, but the user abandoned or failed the flow.

That distinction matters because the business objective is different in each case. Exemptions are about reducing friction without breaking compliance; fallback is about salvaging conversion when the auth step was not completed. Treating them as the same control usually leads to either over-challenging good transactions or losing recoverable revenue.

For payment risk context, exemption handling is part of transaction governance, while fallback handling is part of transaction continuity. Both affect checkout completion, but only one changes whether the authentication journey starts at all.

How They Differ Operationally in the Checkout Flow

An exemption strategy usually depends on transaction attributes, issuer behavior, risk signals, and the exemption type being claimed. It is typically evaluated before or during the decision to request SCA, and its success is measured by how often eligible payments can proceed without interruption. In practice, it needs strong rule design and evidence that the exemption is being applied only where allowed.

A fallback process starts after a failed or abandoned authentication attempt. It is a recovery workflow, not a pre-approval shortcut. Good fallback design focuses on what to do next: whether to retry, reroute, notify the customer, preserve the basket, or allow a later completion path without pretending the original authentication succeeded.

The two controls also differ in where mistakes show up. Exemption errors usually appear as avoidable challenge rates, issuer declines, or compliance exposure. Fallback errors usually appear as abandoned carts, lost authorisations, duplicate attempts, or broken recovery journeys.

What Practitioners Should Watch For

Exemptions work only when the eligibility logic is disciplined. A common failure is using exemption language as a generic friction-reduction tactic, then applying it too broadly and weakening the control objective. A common failure in fallback is to build a dead-end recovery path that does not actually help the customer complete payment after the first attempt fails.

What to prioritise: separate the decision rules for exemption eligibility from the recovery rules for abandoned authentication, then instrument both so you can see challenge rate, failure rate, and post-failure completion rate. If those metrics are blended, you cannot tell whether the issue is bad exemption selection or weak fallback design.

Decision rule: if the transaction is still eligible to bypass SCA under PSD2, use the exemption strategy; if authentication was required and the customer dropped out, switch to fallback recovery logic rather than retrying the same control path blindly.

Practitioner takeaway: The exemption strategy reduces avoidable authentication, while fallback protects conversion after required authentication breaks down, so the right design is to govern them separately and measure them separately.

Risk and Threat Considerations

When exemption and fallback paths are blurred, merchants can either over-rely on exemptions or create weak recovery handling. That can increase fraud exposure, issuer rejection risk, and checkout abandonment, especially when authentication outcomes are not clearly logged and the customer journey is not cleanly separated.

Failure mechanism: overly broad exemption rules can let in transactions that should have been challenged, while poor fallback design can encourage repeated failed attempts, stale payment states, or abandoned but recoverable orders that never convert.

Impact: the merchant may see lower conversion quality, higher dispute or fraud exposure, and less reliable insight into whether losses are caused by policy, issuer behavior, or user drop-off.

Practitioner Guidance

What to verify: confirm that exemption logic is tied to documented eligibility criteria and that fallback logic only activates after an authentication attempt has genuinely failed or been abandoned. The two paths should not share a single catch-all state.

What good looks like: the checkout flow can show, for each transaction, whether it was exempted, challenged, failed, abandoned, retried, or recovered. That visibility is the only reliable way to tune friction without hiding risk.

Common mistake: teams often optimise for fewer challenges and assume that lower challenge volume is always better. In practice, the better question is whether the right transactions are being exempted and whether failed authentications are being converted through a recoverable fallback path.

Practitioner takeaway: Separate policy decisions from recovery mechanics, because the first prevents unnecessary SCA and the second preserves revenue when SCA still interrupts the payment flow.

Related resources from NHI Mgmt Group

• What is the difference between certificate-based authentication and passkeys in a phased authentication strategy?
• What is the difference between passkeys and multifactor authentication in a modern access strategy?
• What is the difference between strong authentication and process verification in AI-enabled attacks?
• What is the difference between a Passport.js strategy and Passport.js middleware in an authentication flow?