SCA & 3DS: balancing compliance and conversion
Using exemptions and DataOnly flows to stay SCA-compliant without adding checkout friction.
Strong Customer Authentication is often implemented as a switch: challenge everything and accept the conversion loss, or challenge nothing and absorb the soft declines. Both are expensive. The regulation is built around exemptions precisely so that neither is necessary, and the merchants who do well treat exemption selection as a per-transaction decision rather than a policy.
The exemptions worth operating
| Exemption | Applies when | Trade-off |
|---|---|---|
| Transaction risk analysis | The acquirer's fraud rate sits under threshold and the transaction scores low | Depends on the acquirer's portfolio fraud rate, not just yours |
| Low value | Under €30, subject to cumulative amount and count caps | The counter is issuer-side; you cannot see when it trips |
| Merchant-initiated | Subsequent transactions in an agreed series | Only if the initial transaction was correctly flagged and authenticated |
| Trusted beneficiary | The cardholder allowlisted you with their issuer | You cannot initiate it; adoption is issuer-dependent |
Claiming an exemption moves liability. Without authentication, a fraudulent transaction is generally the merchant's loss. That is the actual price of a frictionless flow, and it is worth paying on a low-risk €18 reorder from a returning customer and not worth paying on a €900 first-time purchase shipping to a new address.
DataOnly: authentication data without the challenge
The most under-used option is sending 3DS data without requesting a challenge. The issuer receives the device, session, and cardholder context that 3DS carries, and uses it to make a better decision — but the cardholder is never interrupted.
It does not shift liability the way a full authentication does. What it buys is a materially better-informed issuer decision at zero friction, which on issuers that weight this data heavily converts a meaningful share of what would otherwise be 05 declines.
The soft decline you must not treat as a decline
When an issuer returns a code indicating authentication is required — 1A on Visa and its equivalents elsewhere — that is not a refusal. It is an instruction. The correct response is to authenticate and re-present, and merchants that treat it as terminal are discarding transactions the issuer explicitly offered to approve.
ECI values are the receipt
The ECI returned with an authentication records what actually happened — fully authenticated, attempted, or not authenticated — and determines where liability sits. It is worth storing per transaction and reconciling against chargeback outcomes, because a gap between the ECI you believe you obtained and the one the scheme recorded shows up only when a dispute lands.
Building the decision
A workable policy is a small decision tree, not a model: amount band, customer history, card product, issuer's observed response to DataOnly, and the acquirer's current TRA headroom. Below a threshold, exemption. Above it, DataOnly first. Above a higher threshold or on a risk signal, full challenge. On 1A, always step up and retry.
The part that needs measurement rather than judgement is the issuer-level response: which issuers approve DataOnly at a rate that justifies skipping the challenge. That varies enough between banks that a single global policy leaves conversion on the table in both directions.
See these patterns in your own traffic
Apex analyzes every transaction against the decline, routing, and cost signals described here.
Request a demo