SCA exemptions reduce authentication friction, not fraud liability

Keep authentication and liability as separate decisions

Stripe requests applicable Strong Customer Authentication (SCA) exemptions on merchants’ behalf, but explicitly states that when the customer’s bank approves an exemption request, liability shift for fraudulent transactions does not apply.[2] Editorial recommendation: answer two questions separately: what authentication treatment did the payment receive, and what evidence supports its liability treatment? A low-friction checkout is not evidence of fraud protection. Avoid a single internal label such as ‘protected payment’ that merges these decisions. This article concerns the documented authentication routes, not a guarantee about every dispute outcome or every contractual allocation of loss.

Read the regional scope without rewriting local law

Stripe labels this documentation as applicable to the EEA, Switzerland and UK.[2] That is the product-documentation scope used here, not an assertion that Swiss law duplicates EEA or UK requirements. Editorial recommendation: distinguish the merchant’s location, the documented feature availability and the legal assessment relevant to the business. Do not turn a regional heading into a universal exemption policy. Route jurisdiction-specific legal questions to qualified advisers, and confirm the applicable Stripe offering before adopting an operating rule. A common internal playbook can preserve those distinctions instead of implying identical rules everywhere.

Treat low value as conditional eligibility

The documented low-value exemption applies to amounts less than EUR 30 or GBP 25.[2] The issuer may still require SCA when cumulative cardholder-initiated transactions since the last SCA exceed EUR 100 or GBP 85, or when the cardholder has initiated five transactions since the last SCA.[2] Editorial recommendation: do not promise that every small purchase avoids authentication. Preserve a route for the customer to complete authentication when required. Keep eligibility separate from the bank’s decision, and do not mistake a merchant-local count of purchases for a complete view of the cardholder’s activity.

Distinguish TRA thresholds from available service

Transaction Risk Analysis (TRA) allows real-time risk assessment, subject to the payment provider’s overall card-fraud rates in relevant markets staying below specified thresholds.[2] Stripe separately explains that the exemption limit available to a merchant depends on its overall fraud rates and access to authentication offerings, including Adaptive Acceptance.[2] Editorial recommendation: treat the general threshold framework and current Stripe availability as different checks. A theoretical tier is not a promise that the merchant can use it. Confirm current eligibility before planning around TRA, and document why a low-risk assessment does not itself establish fraud liability shift.

Classify merchant-initiated payments as out of scope

Saved-card payments made without the customer present may qualify as merchant-initiated transactions (MITs), which technically fall outside SCA’s scope rather than constituting an exemption.[2] Stripe says MIT treatment involves neither a customer challenge nor liability shift; using it requires authenticating the card when saving it and obtaining the customer’s agreement through a mandate for later charges.[2] Editorial recommendation: retain the relationship between that initial authentication, the mandate and subsequent merchant-initiated charges. Do not relabel an ordinary customer-present purchase as MIT simply to remove friction, or treat possession of saved card details as equivalent to documented permission.

Do not confuse Data Only with liability-shifting authentication

Data Only uses 3DS data: the card network adds risk data to the authorization message before forwarding it to the issuer.[2] Stripe states that no liability shift occurs because the Data Only flow does not send an authentication request to the issuer; the standard flow requires 3DS version 2.2 or later.[2] Editorial recommendation: record Data Only as its own treatment, not as a synonym for an SCA exemption or a liability-shifting authentication result. Confirm the relevant offering and regional availability separately. The presence of 3DS data alone should not trigger an internal assurance of protection.

Make review evidence explicit

Editorial recommendation: maintain separate records for the requested treatment, the observed authentication outcome and the documented basis for any liability conclusion. Review low-value, TRA, MIT and Data Only cases independently, and identify unknown outcomes rather than filling them with assumptions. These are proposed operating checks, not executed tests or measured conversion improvements. Source verification date: 2026-09-20; the cited page’s publication date is unspecified. Recheck current documentation before changing policy. The practical objective is an auditable distinction between reducing authentication friction and transferring fraud liability, without promising either a legal guarantee or a particular commercial result.

Sources and dates

Verified on 2026-09-20. Source dates distinguish explicitly stated publication and update dates; an unspecified date does not mean the source was published today. This is public-document research, not a live payment test, security audit or accessibility certification. Vendor facts apply to the cited vendor; proposed workflows are editorial synthesis.

2. Stripe: SCA exemptions [2] ↗

   Source date: Not stated · Verified: 2026-09-20