TL;DR: Under PSD2, merchants can use up to five SCA exemptions to skip 3DS on low-risk payments — but most apply only one or two, leaving frictionless approvals on the table and pushing low-risk transactions through authentication they did not need. PainHunt's data shows the revenue leak. An engine that selects the right exemption per transaction is the wedge.
The evidence
Payment processing surfaced 470 high-scoring signals in the latest batch (avg intensity 7.6/10), concentrated on BlueSky (50 in the analyzed sample), with Discourse, Medium, and Dev.to.
The cluster is specific and technical. Merchants report using only one or two of the five available SCA exemptions, leaving frictionless approvals unclaimed. The downstream costs follow: high cart abandonment at the 3DS authentication step, and revenue lost to failed authentication even on low-risk transactions that should never have been challenged. The root cause named repeatedly is that manual configuration of 3DS rules is complex and error-prone — teams lack a clear way to know which exemption applies to which transaction type.
The requested fix is consistent: an automated SCA exemption selection engine that decides, per transaction, which exemption to claim to maximize frictionless approvals without raising fraud exposure.
Why this exists now
PSD2 made SCA mandatory across Europe and the UK, and 3DS is the default enforcement. The exemptions exist precisely to keep low-risk payments frictionless, but they are buried in processor APIs as flags a merchant has to reason about transaction by transaction. Small and mid-size teams do not have a risk analyst tuning this, so they default to the safe-but-lossy path of authenticating everything. Every needless challenge is a conversion risk and, when authentication fails, a lost sale on a transaction that qualified for an exemption.
The wedge
A decision layer that sits between the merchant's checkout and the processor.
- Score each transaction and select the optimal exemption — low-value, transaction-risk-analysis, trusted-beneficiary, or recurring — to maximize frictionless approval.
- Fall back to 3DS only when the risk profile or the issuer actually requires it.
- Report recovered approvals and avoided friction so the merchant sees the revenue impact directly.
Land on "stop sending low-risk payments through 3DS," then expand into issuer-level approval optimization and decline recovery.
Risks and honest caveats
- Fraud-liability tradeoff: claiming an exemption can shift liability away from the issuer; the engine has to be conservative and transparent about that tradeoff, not just chase approval rate.
- Processor dependence: the value depends on processor support for granular exemption flags, which varies — the product must map cleanly to each integration.
- Regulatory drift: SCA rules and issuer behavior change; the rule set needs maintenance, which is also part of the moat.
How to validate this further
Read the checkout and authentication threads in the Pain Point Browser, pressure-test demand with how to validate a startup idea, and check the search terms in the Idea Validator. Related: after-fee revenue and tax calculator and in-app browser checkout compatibility.