Merchants should build explicit rules to identify transactions that are out of scope for PSD2, such as certain MOTO or MIT orders, and route them directly to authorization instead of challenge flows. The goal is to preserve a frictionless customer experience while still applying strong authentication where required. Clear flagging, testing, and ongoing monitoring are essential to avoid unnecessary abandonment.
Why PSD2 Scope Rules Should Remove Friction, Not Add It
Out-of-scope PSD2 transactions should be identified as early as possible in the payment journey so they can bypass challenge flows and move straight to authorization. The practical aim is not to weaken control, but to avoid applying strong customer authentication where the transaction type does not require it. That usually depends on clean transaction classification, correct merchant flags, and stable gateway behaviour.
For merchants, the core design choice is whether the payment stack can distinguish a legitimate out-of-scope request from a transaction that merely looks unusual. If that classification is sloppy, customers get forced into unnecessary authentication steps, abandonment rises, and the checkout experience becomes more expensive without improving security.
- Common out-of-scope examples include certain mail order and telephone order flows, some merchant-initiated transactions, and other cases where the PSD2 exemption logic or transaction model places the payment outside the SCA path.
- The routing decision should happen before the customer hits an interactive challenge, because once a friction step is presented the damage to conversion is already underway.
- Merchants should treat exemption handling as a rules-and-evidence problem, not a user-interface workaround, because the payment network and acquirer still need consistent metadata to support the decision.
For implementation context, the merchant logic should be aligned with the broader control pattern of least-friction, policy-based routing: classify the transaction, attach the correct indicators, then send it to the proper authorization path. That is also why testing matters. A rule that works in one acquirer flow can fail in another if the integration suppresses exemption signals, rewrites transaction types, or triggers a fallback challenge by default.
Where Checkout Breaks: Misclassification, False Challenges, and Inconsistent Flagging
The biggest operational failure is not usually non-compliance, but misclassification. If a transaction that should be out of scope is not flagged correctly, the system may send it through a challenge flow unnecessarily. If the opposite happens, a transaction that should be authenticated may bypass the expected control, creating both compliance and fraud exposure.
That means merchants need a stable decision model across web, app, recurring billing, and call-centre channels. A rule that is safe for one channel may be wrong for another, especially when tokenized cards, recurring initiations, or back-office initiated payments are involved. Monitoring should look for sudden changes in challenge rate, issuer soft declines, and unexpected conversion drops after rules or gateway settings change.
- Validate exemption logic in sandbox and production-like test cases, not just in a single happy-path checkout journey.
- Watch for duplicate or conflicting flags between the merchant platform, PSP, acquirer, and fraud stack, because one override can undo the intended routing.
- Review abandonment and retry patterns after release, since a checkout that silently falls back into challenge flow often looks like ordinary customer friction before it becomes a revenue issue.
For governance, the merchant should be able to explain why a given transaction was treated as out of scope and who owns the rule that made that decision. If that explanation cannot be produced quickly, the process is too brittle for a payment environment where disputes, issuer behaviour, and scheme guidance can shift over time.
Risk and Threat Considerations
Out-of-scope handling creates risk when merchants over-apply challenge flows, under-apply them, or let inconsistent metadata decide the outcome. The practical exposure is wasted conversion in one direction and weakened payment control in the other, especially where recurring or merchant-initiated transactions are wrongly routed.
Failure mechanism: A weak rule set, bad transaction classification, or broken flag propagation causes legitimate out-of-scope payments to be challenged, or in-scope payments to bypass the intended authentication path.
Impact: Customers abandon checkout, operational costs rise, disputes increase, and merchants can accumulate compliance or fraud exposure if the routing logic is not consistently tested and monitored.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC — Access Control | PSD2 routing controls who is challenged and when. |
| DE.CM — Continuous Monitoring | Monitoring challenge rates and routing failures is central to detecting checkout friction issues. | |
| GV.RM — Risk Management Strategy | Merchants must balance friction reduction against compliance and fraud exposure. | |
| Recommendation — Enforce policy-based access decisions for payment flows and exemption handling. Monitor routing outcomes and alert on abnormal challenge or abandonment patterns. Define a payment-risk policy that governs when out-of-scope routing is acceptable. | ||
| CIS Controls v8 | 6 — Access Control Management | Checkout routing depends on correct authorization and exception handling. |
| 8 — Audit Log Management | Merchant exemption decisions need traceable evidence for testing and monitoring. | |
| Recommendation — Implement and review payment access rules that prevent unnecessary challenge flows. Log transaction classification, exemption flags, and challenge outcomes for review. | ||
Practitioner Guidance
What to prioritise: Build the exemption decision into the payment orchestration layer, not into ad hoc front-end logic. The merchant should be able to prove which transaction types are routed straight to authorization and why, because the right control is a repeatable policy decision, not a manual exception.
What to verify: Confirm that the gateway, acquirer, fraud tooling, and checkout application all preserve the same transaction classification and exemption indicators across test, staging, and production. If those systems disagree, the user sees friction even when the merchant believes the flow is out of scope.
What to measure: Track challenge rate, abandonment rate, issuer declines after exemption routing, and the percentage of out-of-scope transactions that still enter challenge flows. Those signals tell you whether the rules are actually reducing friction without creating blind spots.
Practitioner takeaway: The best PSD2 checkout design is not “challenge less”, it is “decide earlier and more accurately”, so eligible transactions move frictionlessly while every exception remains explainable and testable.
Related resources from NHI Mgmt Group
- How should organisations implement PSD2 controls without adding too much checkout friction?
- How should ecommerce merchants implement age checks for restricted products without creating unnecessary checkout friction?
- How should merchants use digital identity to reduce cart abandonment without adding checkout friction?
- How should ecommerce merchants handle CID mismatches without increasing checkout friction or fraud exposure?
