Abandonment after SCA challenge measures the proportion of customers who leave checkout once additional authentication is requested. It captures the practical conversion cost of PSD2 friction. Teams use it to understand whether poor mobile UX, latency, or customer confusion is causing otherwise valid transactions to be lost.
What the metric captures in practice
Abandonment after SCA challenge is not just a checkout metric, it is a signal about where strong customer authentication adds friction at the point of payment. It helps teams separate legitimate security step-up from avoidable loss caused by poor timing, broken flows, or weak recovery paths.
Because the metric sits at the boundary between payments security and conversion, it is most useful when read alongside device type, challenge method, issuer behaviour, and page performance. A high abandonment rate can mean the authentication step is doing its job but the experience around it is failing customers.
Where the challenge is triggered by PSD2 or similar step-up requirements, the metric becomes a practical way to see how much friction the control introduces. That makes it useful for product, security, and payments teams that need to balance fraud resistance with completion rates.
Why abandonment rises after a challenge
The most common causes are not exotic. Users may not understand why they are being interrupted, may be redirected into a slow or confusing issuer flow, or may fail on mobile because the handoff between checkout and bank authentication is clumsy. Latency and inconsistent browser behaviour often make these problems worse.
Some abandonment is structural: any additional step will reduce completion. But avoidable loss usually comes from bad orchestration, unclear messaging, or weak fallback design when the authentication provider is slow or unavailable. In those cases, the control is not the only issue, the user journey around the control is.
The metric is therefore a diagnostic, not a verdict. It tells you where the step-up flow is costing more than it should, and whether the issue is issuer friction, page design, or an integration that does not recover cleanly when the user hesitates.
How teams use the metric
Teams use abandonment after SCA challenge to compare payment journeys, test alternative challenge placements, and assess whether the authentication path is too disruptive for specific customer segments. It is especially helpful when paired with A/B testing or funnel analysis, because the same challenge can behave very differently across devices, markets, and issuers.
It also supports operational decisions about retry logic, messaging, and escalation. If a challenge repeatedly causes drop-off, the response is usually not to weaken authentication by default, but to improve the interaction so valid customers can finish the transaction.
For payments and fraud teams, the useful question is whether the abandonment is acceptable relative to the fraud reduction gained. That trade-off should be explicit rather than assumed, because the metric exposes the cost of strong authentication in real customer behaviour.
Security implications and measurement context
Abandonment after SCA challenge sits inside a broader security design problem: stronger verification usually reduces fraud exposure, but it can also raise checkout friction. The key is to measure the security benefit and the conversion cost together, rather than treating authentication as free once it has been mandated.
Useful analysis normally separates true abandonment from temporary hesitation, retries, and issuer failures. A customer who eventually completes after a delay should not be counted the same way as one who exits immediately, because those outcomes imply different control and UX problems.
Where the metric is persistently high, teams often find a mix of friction points, including slow redirects, unclear instructions, excessive challenge frequency, or mobile authentication paths that are hard to complete. Those are implementation problems with direct business impact, not just cosmetic defects.
Risk and Threat Considerations
High abandonment after SCA challenge creates a commercial and operational risk because legitimate transactions are lost at the exact point where trust is being enforced. It can also hide a control-quality problem: teams may assume the challenge is effective simply because it is being triggered, even when the customer journey is too brittle to support completion.
Failure mechanism: The payment flow adds authentication friction, then fails to recover cleanly when the customer stalls, switches devices, gets a slow redirect, or does not understand the challenge. The result is lost conversion, inconsistent authentication outcomes, and poor visibility into whether the issue is user confusion or control design.
Impact: The organisation absorbs lower revenue, weaker customer experience, and potentially more support contacts or cart abandonment without improving fraud outcomes in a proportional way. Over time, this can encourage overcorrection, where teams pressure the control to be reduced instead of fixing the journey that surrounds it.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8, NIST SP 800-63 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 14.1 — Security Awareness and Skills Training | SCA challenge abandonment often reflects user confusion at the authentication step. |
| 8.1 — Audit Log Management | Checkout and challenge telemetry are needed to distinguish abandonment from technical failure. | |
| Recommendation — Use security guidance in user flows to reduce authentication confusion and failed completion. Log challenge start, completion, retry, and failure events to measure where drop-off occurs. | ||
| NIST SP 800-63 | 5.2 — Authenticator and Verifier Requirements | SCA challenge design overlaps with authenticator and verifier behaviour at step-up. |
| Recommendation — Align challenge design with verifier requirements and keep the authentication step usable on mobile. | ||
| NIST CSF 2.0 | PR.AA — Identity Management, Authentication, and Access Control | Strong step-up authentication changes transaction completion and control assurance at checkout. |
| Recommendation — Balance authentication assurance with user completion by testing the end-to-end checkout flow. | ||
Practitioner Guidance
What to watch for: Treat this metric as a funnel diagnostic, not a standalone success measure. A high rate should trigger inspection of challenge latency, mobile completion, issuer handoff quality, and whether the same customers fail repeatedly at a specific step.
Governance implication: Own the metric jointly across payments, security, and product teams so that fraud policy does not silently degrade conversion, and conversion pressure does not silently weaken authentication. The right decision is usually to tune the experience, not to abandon step-up entirely.
Practitioner takeaway: The best outcome is not the lowest friction at any cost, it is the lowest avoidable friction that still preserves the authentication assurance the business needs.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 17, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
