Strong Customer Authentication is the one place in the checkout where regulation, not optimization, sets the floor. Under PSD2 and its UK equivalent, most remote card payments in the European Economic Area and the UK must carry two independent authentication factors. The naive way to comply is to challenge every transaction, and that is exactly the mistake that bleeds conversion. The job in this module is narrower and harder: satisfy the rule on the traffic that needs it, and let everything else through clean.
This sits downstream of the authorization funnel and upstream of routing decisions. A challenge that fails or times out never reaches the issuer for an auth decision, so SCA strategy is partly a funnel problem and partly a fraud-liability problem at the same time.
The two ways through SCA
There are only two compliant outcomes for a regulated transaction: it gets authenticated, or it qualifies for an exemption. Everything in this module is about choosing between those two per transaction.
Authentication runs over EMV 3-D Secure (3DS2). The protocol passes 100-plus data elements to the issuer's Access Control Server (ACS) at the start of the flow. The ACS then decides between two paths.
Frictionless versus challenge
In the frictionless flow, the ACS authenticates on the passed data alone. No screen, no one-time passcode, no app handoff. The cardholder never knows it happened. This is the outcome you want for the overwhelming majority of authenticated traffic.
In the challenge flow, the ACS interrupts the checkout and asks the cardholder to prove themselves, usually a one-time passcode or a tap in the banking app. Every challenge is a chance to drop the customer, and challenge abandonment is real money.
The split between frictionless and challenge is the issuer's call, not yours. What you control is the quality of the 3DS data you send and whether you ask for an exemption instead.
Exemptions: skip the screen and keep the rule
An exemption lets a regulated transaction proceed without SCA. The acquirer or merchant requests it; the issuer's ACS accepts or rejects it. The two that carry real volume are low-value payments and transaction risk analysis.
Low-value payments
Any remote card transaction under 30 EUR can be exempted as a low-value payment. The exemption is not unlimited. The issuer must apply SCA once the cardholder has used the exemption five times since their last authentication, or once the cumulative un-authenticated total passes 100 EUR. Those counters reset on the next successful SCA, and the issuer tracks them, not you.
Transaction risk analysis (TRA)
TRA is the lever that matters at scale. It lets a payment service provider skip SCA on a remote payment if its overall fraud rate sits under a threshold tied to the transaction value. The EBA regulatory technical standards set those thresholds:
- Fraud rate at or below 0.13 percent: exemption allowed up to 100 EUR
- At or below 0.06 percent: up to 250 EUR
- At or below 0.01 percent: up to 500 EUR
Any transaction above 500 EUR always requires SCA. Fraud rates are recalculated on a rolling 90-day basis, so a bad quarter shrinks your exemption ceiling automatically. Both the issuer and the acquirer can hold their own TRA permission off their own fraud numbers, and the two are scored independently.
The fraud-liability consequence is the part teams forget. When the acquirer applies a TRA exemption and the issuer accepts it, the fraud liability stays with the acquirer, and in practice with the merchant. Authenticate the transaction through 3DS instead and the liability shifts to the issuer. So exemptions are a trade: you buy conversion with liability. Whether that trade is worth it depends on the segment's chargeback profile, which is why exemption strategy belongs to the same team that owns fraud, not to checkout in isolation.
The soft-decline retry loop
Requesting an exemption is a request, not a guarantee. The issuer can refuse it and return a soft decline, a response that effectively says "I will not authorize this without SCA." A soft decline is recoverable, and the only correct response is to step the transaction up: send it back through 3DS as a full challenge rather than treating it as a hard failure.
This is where checkouts quietly lose money. If your stack reads a soft decline as a dead transaction, the customer sees a generic failure on a card that would have gone through after a single passcode. The retry has to be automatic and invisible up to the challenge screen.
A worked example
Take a 45 EUR cart from a returning EEA customer, on a merchant whose acquirer holds a fraud rate under 0.13 percent.
- The value sits under the 100 EUR TRA ceiling for that fraud band, so the acquirer flags the 3DS message as a TRA exemption, requesting no challenge.
- The issuer's ACS scores the transaction. If it agrees the risk is low, it accepts the exemption. The payment proceeds with no screen, and fraud liability stays with the merchant.
- If the ACS disagrees, it returns a soft decline. The stack does not surface an error. It immediately resubmits the same transaction as a 3DS challenge.
- The customer enters a passcode, the issuer authenticates, liability shifts to the issuer, and the auth proceeds.
The customer who would have abandoned at a needless passcode now sails through. The riskier-looking one gets a single, well-timed challenge instead of a dead checkout. That is the whole point of "adaptive": the friction lands where the risk is, not everywhere.
What to instrument
Three numbers tell you whether your SCA strategy is working, and they pull in opposite directions, so watch them together.
- Exemption acceptance rate. Of the exemptions you request, how many does the issuer honor? A low rate means you are asking on traffic issuers do not trust, and every rejection costs a round trip.
- Challenge rate and challenge abandonment. What share of traffic hits a screen, and how many of those customers leave. This is where conversion lives.
- Fraud rate by exemption band. Drift here is not just a fraud problem. Cross a TRA threshold and your exemption ceiling drops on the next 90-day recalculation, which silently pushes more traffic into challenges.
Takeaway
SCA is a routing problem dressed as a compliance problem. The rule sets a floor; the work is choosing, per transaction, between an exemption that you back with liability and an authentication that shifts liability to the issuer, and recovering cleanly when the issuer says no. Get the soft-decline retry right, keep your fraud rate inside the TRA bands, and you protect the regulated flows without taxing the customers who were never going to commit fraud in the first place.