What SCA is in the UK (and why it affects checkout performance)
Strong Customer Authentication (SCA) is a UK payments security requirement that asks many online card payments to be verified using at least two independent checks. In practice, this usually means a customer confirms a purchase with something they know (like a passcode), something they have (a phone or banking app), or something they are (biometrics). Most shoppers experience SCA through 3D Secure (often shown as “Verified by Visa” or “Mastercard Identity Check”), where their bank prompts them to approve the payment.
SCA affects checkout performance because it can add an extra step at the most sensitive moment in the funnel. If the authentication page loads slowly, looks unfamiliar, or fails on mobile, customers may abandon. It can also increase “soft declines” (temporary refusals) when a bank wants authentication but the payment attempt doesn’t trigger it correctly.
For a practical UK SCA compliance checklist, focus on what improves both approval rates and customer experience:
- Use a payment provider that supports 3D Secure 2 and can request exemptions where appropriate.
- Make authentication mobile-first (fast load, clear messaging, minimal redirects).
- Handle soft declines by retrying with SCA rather than showing a generic “payment failed.”
- Keep customers informed with short, plain-language prompts (“You may be asked to confirm this payment with your bank”).
- Track metrics like authentication rate, challenge rate, and drop-off at the payment step to spot friction quickly.
When SCA applies: ecommerce, in-app, subscriptions, and B2B edge cases
SCA (Strong Customer Authentication) generally applies when you take an electronic payment where the customer is in the UK (or EEA) and the payment is initiated online, in-app, or otherwise “remote.” In practice, you should expect SCA on most card-not-present purchases unless an exemption is used and accepted by the card issuer.
Ecommerce checkouts: One-off online card payments typically trigger SCA. If you use 3D Secure (3DS2) via your payment provider, the issuer may challenge the customer (e.g., app approval or one-time passcode) or approve frictionlessly. Don’t assume exemptions will always apply—issuers can still request a challenge.
In-app payments: SCA usually applies to in-app card payments where you control the checkout flow. If payments are processed through platform wallets or app stores, SCA may be handled by the platform, but you still need clear records of what method was used and how chargebacks/refunds are handled.
Subscriptions and recurring billing: SCA is commonly required for the initial setup (or first payment) and for certain changes (e.g., new card, higher amount, altered schedule). Subsequent recurring payments may be treated as “merchant-initiated” and can be out of scope, but only if the mandate is properly established and referenced.
B2B edge cases: “Corporate” cards can still be in scope. Some transactions using secure corporate payment processes may be exempt, but eligibility varies by issuer and scheme rules. If you sell B2B, build a fallback: support 3DS challenges, store mandate/transaction references, and ensure your invoicing and payment links can handle SCA when the issuer requires it.
Step-by-step SCA compliance checklist (from payment flow to monitoring)
- Map every payment journey: List checkout, saved cards, subscriptions, in-app, phone/mail order, and marketplace flows. Note where authentication happens (or fails) across web, mobile, and embedded payments.
- Confirm your SCA scope: Identify customer-initiated card payments, account-to-account payments, and recurring setups that may trigger SCA. Flag edge cases like one-click, pay-by-link, and guest checkout.
- Choose your authentication method: Prioritise 3D Secure 2 (3DS2) with challenge and frictionless paths. Ensure your payment provider supports exemptions and provides clear reason codes.
- Implement exemptions with guardrails: Configure low-value, trusted beneficiary, recurring (MIT/CIT), and transaction risk analysis (TRA) where supported. Add fallbacks so a declined exemption automatically retries with a 3DS challenge.
- Handle recurring and stored credentials correctly: Use a 3DS-authenticated first payment (CIT) to set up, then process subsequent charges as MIT with the right flags and references to reduce unnecessary challenges.
- Optimise UX for challenges: Keep customers in-session, avoid redirect loops, and display clear prompts. Test on iOS/Android, Safari/Chrome, and with ad blockers enabled.
- Instrument and log: Capture 3DS status, exemption requested/applied, issuer response, soft vs hard declines, and drop-off points. Store only what you need for operations.
- Test with realistic scenarios: Run sandbox and live tests for frictionless, challenge, exemption accepted/rejected, and step-up after soft decline.
- Monitor weekly: Track approval rate, challenge rate, abandonment, and issuer-specific declines. Review provider dashboards and set alerts for sudden shifts after scheme or issuer updates.
SCA exemptions and optimisations: TRA, low value, MIT, trusted beneficiaries, and corporate cards
Use exemptions to reduce checkout friction while staying SCA-compliant. The key is to request an exemption only when you can support it with clean data and a fallback to step-up authentication.
- Transaction Risk Analysis (TRA): Work with your PSP/acquirer to enable TRA and pass richer signals (device ID, account age, delivery address history, velocity checks). Keep fraud and chargeback rates monitored; if thresholds are exceeded, TRA may be removed or ignored. Ensure your integration can handle a “challenge” response without breaking the user journey.
- Low value: For payments typically under €30 (or equivalent), request the low-value exemption, but expect periodic challenges due to cumulative limits and transaction counters. Optimise by saving carts and retrying seamlessly if a challenge is triggered.
- Merchant-initiated transactions (MIT): Use MIT for subscriptions, top-ups, and no-show/late-cancel fees only after an initial customer-authorised transaction with SCA (a “CIT” with a stored credential). Store the network transaction IDs and flag subsequent charges correctly as MIT to avoid unnecessary challenges.
- Trusted beneficiaries: Encourage customers to add you as a trusted merchant during an SCA challenge (where supported). Track issuer support rates and only surface prompts when it won’t distract from completion.
- Corporate cards: Some commercial/corporate payments may be out of scope or eligible for different treatment depending on the card and issuer. Capture card type/BIN data and route via your PSP’s recommended settings, while still supporting 3DS fallback.
3DS2 options compared: frictionless vs challenge, 3DS requestor-initiated vs issuer-driven
Frictionless 3DS2 is the “silent” path: the customer isn’t asked to do anything extra because the issuer is comfortable with the risk based on the data shared (device, transaction, account history). It’s ideal for maximising conversion, but it’s not something you can force—your job is to enable it by sending rich data (billing/shipping match, customer tenure, previous successful payments, delivery method) and keeping checkout clean.
Challenge 3DS2 is the step-up flow: the issuer asks the customer to authenticate (for example via their banking app). It increases friction and drop-off risk, but it’s often the safest route for higher-risk transactions, first-time customers, unusual baskets, or cross-border orders. Make it tolerable by ensuring your 3DS screens are mobile-first, branded where possible, and clearly explain why verification is needed.
3DS requestor-initiated means you (via your payment gateway/PSP) request 3DS on a transaction. This is useful when you want consistent SCA handling—e.g., you’re seeing soft declines without 3DS, or you’re routing certain segments (high value, high fraud categories) through 3DS by default. You still can’t guarantee frictionless; the issuer decides.
Issuer-driven 3DS happens when the issuer requires authentication regardless of your preference (or when they reject a non-3DS attempt). Expect this when risk signals are elevated or exemptions aren’t accepted. Your checklist action: support 3DS2 end-to-end, handle retries gracefully, and log outcomes (frictionless/challenge, exemption attempted, issuer response) to tune rules without harming conversion.
PSPs and gateways compared for UK SCA readiness: what to ask before you switch or renew
When comparing a payment service provider (PSP) and a gateway for UK Strong Customer Authentication (SCA) readiness, focus on what will actually happen in your checkout when authentication is required. Start by asking which 3DS version is supported (3DS2 should be standard) and whether the provider can run “frictionless” flows where possible, with step-up challenges only when needed. Confirm support for app-based challenges and fallback options (SMS is less ideal, but still relevant for coverage).
Next, clarify who owns the SCA decisioning: does the PSP handle exemptions and routing automatically, or do you need to configure rules in the gateway? Ask specifically about exemption support and reporting for low-value, trusted beneficiary, recurring/merchant-initiated transactions, and transaction risk analysis (TRA). If TRA is offered, request the provider’s approach to risk scoring and how it impacts approval rates (not just “we support TRA”).
Operational questions matter as much as features. Can you see authentication rate, challenge rate, and soft-decline recovery in the dashboard? Is there a clear retry strategy for “authentication required” responses, and does the integration handle it without breaking the user journey? For subscriptions, ask how initial customer-initiated payments are authenticated and how subsequent payments are flagged.
Finally, check integration and resilience: hosted payment pages vs API, support for network tokens and card updater services, latency and uptime SLAs, and whether the gateway/PSP can route across acquirers to reduce unnecessary challenges. Ask for UK-specific case studies and a test plan you can run before renewal.
UK SCA compliance FAQs for ecommerce and SaaS billing teams
What is SCA and when does it apply in the UK?
Strong Customer Authentication (SCA) is a payments security requirement for most UK online card payments, typically when the customer is present (e.g., checkout) and the transaction is initiated electronically. It usually means using two independent factors (such as something the customer knows, has, or is).
Do all online payments need SCA?
No. Some transactions may qualify for exemptions (for example, low-risk or low-value scenarios), but eligibility depends on the payment flow and the provider’s risk controls. Plan as if SCA is required, then use exemptions selectively.
How does SCA affect subscriptions and recurring billing?
Many subscription models require SCA at setup (the first payment or mandate) and then allow subsequent “merchant-initiated” charges without repeated customer challenges. Ensure your billing system correctly flags subsequent charges and stores the right reference data from the initial authenticated payment.
What’s the difference between 3DS1 and 3DS2?
3DS2 is designed for SCA and supports “frictionless” authentication using richer data. 3DS1 often triggers more step-up challenges and can reduce conversion.
What should we test before going live?
Test success and failure paths: challenge flows, exemptions, retries, partial captures, refunds, and chargeback scenarios. Validate mobile and in-app browsers, and confirm webhooks/notifications update order status correctly.
How can we reduce checkout friction?
Send complete customer and order data to your payment provider, enable 3DS2, monitor exemption performance, and tune retry logic to avoid repeated challenges after soft declines.