SCA exemptions 2026: what triggers 3DS and what doesn't

Strong Customer Authentication (SCA) rules under PSD2 require two-factor authentication for most online card payments in the European Economic Area. But four exemptions let merchants process payments without the friction of a 3DS challenge: merchant-initiated transactions (MIT), transaction risk analysis (TRA), low-value payments under €30, and whitelisted merchant flows. Understanding which exemption applies to which payment determines whether your customer sees a redirect or a clean checkout.

SCA exemptions 2026: the four paths that skip 3DS

The SCA exemption framework exists because regulators recognized that requiring every card payment to trigger a text message or biometric check would break legitimate use cases. The European Banking Authority's revised technical standards define exactly which transactions qualify for exemption. Stripe, Adyen, and every other EU payment processor built their authentication routing logic around these four categories.

Merchant-initiated transactions (MIT) are card payments you trigger without the customer present — subscription renewals, installment payments, automatic top-ups. If the customer authenticated the first payment with SCA, all subsequent MIT payments on that saved card can skip 3DS entirely. This exemption is why subscription businesses can process recurring charges without re-authenticating every billing cycle.

Transaction risk analysis (TRA) is a conditional exemption your acquiring bank grants in real time based on fraud rates. If your payment processor's fraud rate is below 0.13% for transactions under €100 (or 0.06% for transactions under €250, or 0.01% for transactions under €500), the bank can approve a TRA exemption and let the payment go through without SCA. The thresholds tightened in the 2024 revision, but the mechanism is unchanged: low fraud earns you the right to skip authentication.

Low-value payments under €30 skip SCA automatically, with one rule: the issuing bank tracks cumulative spend since the customer's last SCA challenge. Once cumulative spend crosses €100 or the customer makes five consecutive low-value payments, the sixth transaction requires SCA. This exemption is why quick €15 purchases rarely trigger 3DS, but the mechanism resets periodically.

Whitelisted merchant (also called trusted beneficiary) lets a customer add your business to their bank's whitelist after the first SCA-authenticated payment. Subsequent payments to your merchant ID skip SCA because the customer explicitly trusted you. Adoption varies by issuer — some banks surface the whitelist prompt in their 3DS flow, others bury it in account settings. When it works, it is the cleanest exemption because there is no transaction-value limit and no cumulative spend tracking.

All four exemptions are requests, not guarantees. The issuing bank has final say. If your processor requests a TRA exemption and the issuer declines it, the payment either soft-declines with a request for SCA or hard-declines outright depending on the decline code returned. Stripe's SCA engine requests the most aggressive exemption your transaction qualifies for, then falls back to 3DS if the issuer refuses.

What changed in 2026 for SCA exemptions?

The January 2024 EBA opinion on SCA exemptions clarified two ambiguities that had let acquirers interpret TRA thresholds loosely, and those clarifications took full effect across the EEA in early 2026. The fraud-rate calculation window shortened from rolling 90 days to rolling 30 days, which means a single fraud spike now impacts your TRA eligibility faster. And the fraud-rate denominator now counts all transactions your acquirer processes, not just the subset where TRA was requested — so you cannot game the number by selectively requesting TRA only on low-risk payments.

The practical result: TRA exemption approval rates dropped 8-12 percentage points for mid-size merchants between Q4 2023 and Q1 2026, based on aggregate data across our customer base. If your blended fraud rate sits between 0.10% and 0.15%, you likely lost access to the €250 and €500 TRA buckets and now only qualify for €100-and-under TRA exemptions. Merchants below 0.06% fraud saw almost no change.

The second shift is issuer behavior on MIT exemptions. Several large EU issuing banks — including BNP Paribas, ING, and Deutsche Bank — tightened their MIT validation rules in late 2025. They now require the initial customer-present transaction (the one that created the card-on-file token) to have been SCA-authenticated within the past 18 months. If the original authorization is older than that, the issuer may reject the MIT exemption and request a new SCA challenge to re-validate the cardholder. This creates a new failure mode for subscriptions that have run uninterrupted for two years: the card is valid, the customer is happy, but the issuer wants a fresh SCA check.

Stripe started surfacing this as a distinct decline code — authentication_required — in March 2025. If you see that code on an MIT renewal, the correct recovery path is a dunning email asking the customer to re-authenticate, not a silent retry. Re-attempting the charge without SCA will fail again. The 18-month window is not codified in PSD2, so issuers interpret it differently; some enforce 12 months, some 24, a few have no cutoff at all. You cannot predict it — you can only handle the decline gracefully when it appears.

How do merchant-initiated transaction exemptions actually work?

Merchant-initiated transactions cover any card payment you trigger on behalf of the customer without their active participation at the moment of charge. Subscription renewals, split installment payments, account auto-reloads, and unattended IoT device payments all fall under MIT. The rule: the customer must have authenticated the original purchase with SCA, and you must flag the subsequent charges as MIT when you send them to your processor.

Stripe (and Adyen, Checkout.com, and Mollie) handle MIT flagging automatically if you use their subscription or saved-card APIs correctly. When you create a PaymentIntent with off_session: true and attach a PaymentMethod that was previously confirmed with SCA, Stripe sets the MIT indicator in the authorization request sent to the card network. The issuing bank sees the MIT flag and applies the exemption if the original SCA check is still within their validity window.

The gotcha: not all saved cards qualify. If the customer saved their card by typing it into your account settings page without completing a purchase, that card-on-file token does not carry an SCA mandate. The first time you charge it — even as an MIT — the issuer may still request SCA because there was no authenticated "original transaction" to reference. The cleanest pattern is to create the card-on-file token during an actual SCA-authenticated purchase, then reuse that token for future MIT charges. Stripe calls this "setup intent with payment," and it became the recommended MIT flow in their SCA migration guide published in 2021 and updated through 2025.

MIT exemptions do not exempt you from liability shift. If the payment is later disputed as fraud, you own the chargeback because SCA did not occur at the time of that specific transaction. The original SCA check from 18 months ago does not protect you. This is why MIT fraud rates matter: if fraudsters compromise a card-on-file token, they can drain it via MIT requests until the cardholder notices and disputes. That risk is the reason issuers started enforcing re-authentication windows.

When does transaction risk analysis let you skip SCA?

Transaction risk analysis is the only exemption where your processor's aggregate fraud performance determines whether your individual payment can skip SCA. The European Banking Authority sets three fraud-rate thresholds and three corresponding transaction-value caps. If your acquirer's fraud rate for the relevant transaction band is below the threshold, the acquirer can request a TRA exemption from the issuer for payments in that band.

The thresholds as of 2026:

• Transactions up to €100: acquirer fraud rate must be below 0.13%
• Transactions up to €250: acquirer fraud rate must be below 0.06%
• Transactions up to €500: acquirer fraud rate must be below 0.01%

Fraud rate is calculated as (fraudulent transaction value / total transaction value) over a rolling 30-day window, counting all transactions the acquirer processes in the EEA regardless of whether TRA was requested. If Stripe's fraud rate for €0–€100 transactions in the past 30 days is 0.09%, they can request TRA for any €85 purchase. If the rate climbs to 0.15%, they lose TRA eligibility for that band until the rate drops again.

The issuer still decides. Requesting a TRA exemption does not guarantee approval. Conservative issuers — particularly in Germany and the Netherlands — reject 40-60% of TRA requests even when the acquirer is well within the fraud threshold. The issuer runs its own risk model against the cardholder's spending pattern, and if the transaction looks anomalous (new merchant category, unusually high amount, different shipping country), the issuer declines the exemption and requests SCA.

When TRA is declined, Stripe's SCA engine automatically triggers a 3DS challenge if the payment is still in pending state. The customer sees the redirect, completes authentication, and the payment continues. From your perspective, this looks like a slight delay and a lower conversion rate (because 3DS challenges drop 8-15% of customers depending on issuer UX). You do not see a hard decline unless the customer abandons the 3DS prompt.

One edge case: if your cart flow is entirely client-side and you did not configure Stripe Elements to handle dynamic 3DS, a TRA rejection can cause a silent failure. The payment intent stays in requires_action status waiting for the customer to authenticate, but your frontend never renders the authentication modal. This is why Stripe's official recommendation is to always enable handleCardAction even if you expect most transactions to qualify for TRA — the exemption is never guaranteed.

What counts as a low-value payment exemption?

Any card payment under €30 qualifies for the low-value exemption, with two cumulative limits enforced by the issuing bank. The customer can make up to five consecutive low-value payments OR spend up to €100 cumulatively before the bank requires SCA on the next transaction. Once the customer completes an SCA challenge, both counters reset to zero.

The exemption is automatic — you do not request it, the issuer applies it. When you send a €22 authorization request to the card network, the issuer checks the customer's cumulative spend and transaction count since their last SCA event. If both limits are still satisfied, the payment approves without SCA. If either limit is exceeded, the issuer returns a soft decline with authentication_required, and your processor must trigger 3DS.

The €100 cumulative cap is across all merchants, not per-merchant. If a customer buys €25 of groceries, €30 of fuel, and €28 of clothing across three different stores without hitting SCA, their cumulative spend is €83. The next €20 purchase at your store will push them over €100, so the issuer will require SCA even though your individual transaction is well under €30. You cannot see the customer's cumulative total — the issuer tracks it opaquely.

The five-transaction cap works the same way: five consecutive sub-€30 purchases across any merchant combination, then mandatory SCA on the sixth. The word "consecutive" matters. If the customer makes three low-value purchases, then one €50 purchase that triggers SCA, the counter resets. The next five sub-€30 purchases start a new sequence.

Low-value exemptions are rarely useful for subscription businesses because the cumulative cap triggers too quickly. A €15/month subscription will hit the five-transaction limit on the sixth billing cycle (month six) even though cumulative spend is only €90. The customer will see an SCA challenge mid-subscription, which often looks like a payment failure if your dunning email does not explain what happened. MIT exemptions are a much cleaner path for recurring revenue.

How does the whitelisted merchant exemption work in practice?

The whitelisted merchant (trusted beneficiary) exemption lets customers add your business to a persistent allowlist maintained by their issuing bank. Once whitelisted, all future payments to your merchant ID skip SCA regardless of transaction amount. The customer opts in during or after their first SCA-authenticated payment, and the whitelist entry remains active until the customer explicitly removes it or the bank purges inactive entries (policies vary by issuer).

The friction: most issuing banks hide the whitelisting UI. A few — Revolut, N26, bunq — surface a "Trust this merchant?" prompt immediately after the 3DS challenge. The majority require the customer to log into online banking, find the "Trusted merchants" section (if it exists), and manually add your merchant name or ID. Adoption is low because the UX is buried. Across our customer base, fewer than 2% of EU customers have whitelisted any merchant, and the rate skews heavily toward neobanks with modern app flows.

When it works, the exemption is invisible to you as the merchant. The issuer sees your merchant ID on the authorization request, checks the customer's whitelist, and approves the payment without requesting SCA. You do not set a flag, you do not request the exemption — it happens silently on the issuer side. The only signal you might see is a higher exemption approval rate for repeat customers compared to first-time buyers, but that pattern is also consistent with TRA, so you cannot isolate whitelist impact without issuer-level data.

One consequence: if a fraudster compromises a card that has whitelisted your store, they can make unlimited purchases without triggering SCA. The whitelist exempts transactions from authentication, not from fraud monitoring, but it does widen the window before the cardholder notices. Liability shift still applies — if the payment was exempted from SCA via whitelist and later disputed as fraud, you own the chargeback. This is the tradeoff: whitelist exemptions improve conversion and reduce auth costs, but they concentrate fraud risk.

Frequently asked questions

Do SCA exemptions apply to non-EU cards used in the EU?

SCA requirements apply to the acquiring bank and the issuing bank, not the cardholder's location. If a US-issued card is used to pay an EU-based merchant, SCA does not apply because the issuing bank is outside the EEA. The payment processes as a standard authorization without 3DS unless the US issuer independently requests authentication. Conversely, if an EU-issued card is used to pay a non-EU merchant, SCA still applies because the issuing bank is EU-regulated — though enforcement is inconsistent when the acquirer sits outside the EEA.

Can I request a specific exemption or does Stripe choose automatically?

Stripe's SCA engine selects the most permissive exemption your transaction qualifies for based on transaction amount, your fraud rate, whether the payment is MIT, and issuer-specific rules. You cannot override the exemption type directly, but you control the inputs: flagging a payment as off_session: true makes it eligible for MIT, keeping fraud below 0.06% improves TRA eligibility, and structuring subscriptions as MIT instead of customer-initiated charges changes which exemption applies. The selection happens in milliseconds during authorization.

What happens if an exemption is declined mid-transaction?

If Stripe requests an exemption and the issuer declines it, Stripe automatically falls back to 3DS if the payment is still pending. The customer sees a redirect to their bank's authentication page, completes the challenge, and the payment continues. If the customer abandons the 3DS flow or the issuer hard-declines the payment, you receive a payment_intent.payment_failed webhook with the corresponding decline code. There is no merchant action required — the fallback is automatic if you have 3DS enabled in your Stripe integration.

Does using a TRA exemption increase my chargeback risk?

Yes. When a payment is exempted from SCA via TRA, liability for fraud chargebacks stays with you as the merchant rather than shifting to the issuing bank. If the payment is later disputed as unauthorized, you cannot point to SCA authentication as proof the cardholder approved it — because SCA did not happen. The tradeoff is conversion rate versus fraud liability. Payments that go through 3DS convert 8-15% worse but carry near-zero fraud chargeback risk. Payments that skip SCA via TRA convert better but leave you exposed if the card was stolen.

Run a leak scan on your own stack

SCA exemption logic is one of 147 leak patterns Omesta scans when you connect your Stripe account. If your integration is requesting MIT exemptions on card tokens that were never SCA-authenticated, or if your fraud rate is high enough that TRA requests fail more than 50% of the time, those patterns show up as recoverable revenue in your first scan. Start the leak scan — free until we recover $1,000 for you.