When Is SCA Required for Online Card Payments?

A customer reaches checkout, enters their card details and sees an unexpected authentication challenge. If it is requested at the wrong time, conversion suffers. If it is missed where regulation requires it, the issuer can decline the payment. The question, “when is SCA required?”, is therefore not simply a compliance question. It directly affects approval rates, recurring revenue and the customer experience.

Strong Customer Authentication (SCA) is a core requirement for many electronic payments under PSD2 in the European Economic Area (EEA), with equivalent requirements applying in the UK under its retained regulatory framework. For merchants, the practical challenge is to apply authentication where needed while using legitimate exemptions and transaction design to avoid unnecessary checkout friction.

What SCA means in practice

SCA requires a payer to authenticate using at least two independent elements from different categories: something they know, such as a passcode; something they possess, such as a registered mobile device; or something they are, such as a fingerprint or facial recognition.

For card payments, this is commonly delivered through EMV 3-D Secure 2 (3DS2). A frictionless 3DS2 flow may assess the transaction in the background using data shared by the merchant, acquirer and issuer. A challenge flow asks the customer to approve the payment through their banking app, biometrics or a one-time passcode.

The distinction matters commercially. SCA does not always mean the customer must complete an extra step. Well-configured 3DS2 and high-quality transaction data give issuers more confidence to approve legitimate payments without a challenge.

When is SCA required under PSD2?

SCA is generally required when a customer initiates an electronic payment and both the payer’s payment service provider and the merchant’s payment service provider are in the EEA. This is often called a two-leg transaction. A typical example is an online card purchase where a French customer pays an EEA-based merchant through an EEA acquirer.

It can apply to card-not-present purchases, account-to-account payments and the initial set-up of certain recurring payment arrangements. It is not limited to high-value purchases. Low-value payments can also fall within scope unless an exemption is available and accepted.

The final decision to authenticate normally sits with the card issuer. A merchant or acquirer can request an exemption, but the issuer may still require a challenge based on its own fraud analysis, customer profile or internal risk policy. This is why merchants should treat exemption logic as an optimisation tool rather than a guarantee of a frictionless payment.

For transactions involving a payment provider outside the EEA, known as one-leg-out transactions, PSD2 SCA may not apply in the same way. However, the issuer, scheme rules or acquiring partner may still require 3DS. A global payments strategy should therefore account for the actual issuer country, acquirer location and payment method rather than relying on a simple domestic-versus-international rule.

The main SCA exemptions merchants should know

Exemptions exist to protect low-risk commerce from unnecessary disruption. They are valuable, but eligibility depends on the transaction, the payment flow and the risk appetite of the issuer and acquirer.

• Low-value transactions: Card payments of up to €30 may be exempt, subject to cumulative limits. SCA will generally be required after five consecutive exempt transactions or when the cumulative exempt amount exceeds €100.
• Transaction Risk Analysis (TRA): Acquirers may request an exemption where their fraud levels meet regulatory thresholds. The available value threshold depends on the acquirer’s monitored fraud rate, with larger transactions requiring lower fraud performance.
• Trusted beneficiaries: Customers can authenticate once to add a merchant to their bank’s trusted beneficiary list. Later payments to that merchant may be processed without a challenge, although issuers may still intervene.
• Fixed-amount subscriptions and recurring payments: SCA is normally required when the customer sets up a recurring series. Later payments of the same amount to the same merchant may be exempt.
• Merchant-initiated transactions: A payment initiated by the merchant under a prior agreement, rather than actively initiated by the customer, can be outside the normal SCA requirement. This is especially relevant for variable recurring billing, no-show charges and certain subscription top-ups.

Other exemptions may apply to secure corporate payments using dedicated protocols, or to payments made through an authenticated wallet. Their availability varies by payment method and market.

Recurring billing: the point where many payment flows fail

Subscription, telecoms, travel and gaming merchants need particular care when distinguishing a customer-initiated transaction (CIT) from a merchant-initiated transaction (MIT). The initial customer payment, or the customer’s agreement to a future payment schedule, generally needs SCA where it is in scope. The merchant must then retain the relevant credentials, agreement evidence and transaction references for subsequent MITs.

A fixed monthly subscription is comparatively straightforward. The customer authenticates the first payment, then later charges use the stored credential framework where the amount and cadence remain unchanged. A variable utility-style charge, usage-based plan or booking amendment is more complex. The merchant needs clear contractual authority for the later charge and must submit it with the correct payment indicators.

Using an MIT label to avoid SCA on a payment that the customer is actively initiating is not a sustainable workaround. It can lead to issuer declines, disputes and scheme compliance exposure. The correct approach is to design the original consent journey carefully, then pass the right data through the gateway and acquirer for every subsequent charge.

Why a blanket 3DS policy can reduce conversion

It may seem safest to challenge every payment, particularly in higher-risk sectors. Yet forcing authentication on all transactions can create avoidable abandonment, particularly on mobile devices or when customers are travelling. It also does not remove the need for effective fraud monitoring, chargeback management and issuer-quality transaction data.

The stronger approach is to use 3DS2 dynamically. Send complete customer, billing, delivery and device information where appropriate. Use network tokenisation for stored credentials. Route transactions through suitable acquiring relationships, and apply risk rules that identify cases where SCA, an exemption request or a different payment method is the best commercial response.

This requires a realistic view of trade-offs. A low-friction checkout may improve conversion, but aggressive exemption use can lead to more issuer challenges or higher fraud exposure. Conversely, mandatory authentication can be sensible for a new customer, a high-value order, an unusual device or a transaction that triggers fraud signals. Payment performance improves when authentication policy reflects transaction risk rather than a single rule applied to every customer.

How to operationalise SCA without losing control

Start by mapping payment flows rather than reviewing SCA as a standalone legal requirement. Identify where the customer actively pays, where credentials are stored, where a merchant later initiates billing, and which acquirer processes each flow. This reveals whether a transaction is a CIT, an MIT, a recurring fixed-amount charge or a potentially exempt low-value payment.

Next, make sure the checkout and gateway integration support 3DS2 properly. Hosted payment fields and hosted checkout can reduce PCI scope while collecting the data needed for authentication. API-led integrations need to handle authentication responses, redirects, browser data and payment status updates reliably. Webhooks should update order handling so that a payment is not marked as failed while the customer is completing a bank challenge.

Monitor more than raw authentication rates. Payment teams should compare challenge rates, frictionless approval rates, soft declines, issuer responses, fraud outcomes and chargebacks by country, issuer, acquirer and payment method. A rise in soft declines with an “authentication required” response often indicates that a payment should be retried through the appropriate 3DS flow, not abandoned immediately.

For merchants operating across multiple acquirers and territories, payment orchestration can help apply the right routing and exemption strategy to each transaction. AllSecure supports this type of configuration through gateway technology, 3DS2 capabilities and acquiring connectivity designed around approval performance as well as compliance.

UK and EEA considerations

The UK and EEA share the same broad objective: reduce payment fraud through stronger authentication. But merchants should not assume identical operational rules, timelines or issuer behaviours in every market. A British merchant selling across Europe may process transactions through different acquiring entities, face different local issuer patterns and support payment methods with their own authentication journeys.

The practical answer is to build a payment flow that captures the required SCA data, supports 3DS2 challenges cleanly and adapts by transaction type and market. That gives the business room to meet regulatory expectations without treating every payment as equally risky.

The best SCA strategy is not the one that produces the most challenges. It is the one that authenticates the right transactions, documents recurring consent correctly and gives legitimate customers the clearest possible path to payment.