Strong Customer Authentication and 3-D Secure 2 for EU and UK Checkouts

A practical guide to Strong Customer Authentication for online stores: when it applies to EEA and UK cards, the main exemptions, how 3-D Secure 2 works, how Stripe, PayPal, Shopify and WooCommerce handle it, and how to fix failed subscription payments.

Strong Customer Authentication and 3-D Secure 2 for EU and UK Checkouts article cover image

Strong Customer Authentication (SCA) is the PSD2 rule that requires most online card payments to be verified with two independent factors when both the cardholder's bank and the merchant's acquirer are in the European Economic Area. In practice it is delivered through 3-D Secure 2, the challenge or frictionless check that appears at checkout. The UK applies an equivalent regime, so any store charging European or British cards needs a checkout that can authenticate on-session and handle off-session payments correctly.

This guide covers when SCA applies, which exemptions merchants can rely on, how the 3-D Secure 2 flow works, what Stripe, PayPal, Shopify and WooCommerce do for you, and how to diagnose failed or abandoned payments, with a checklist for subscription stores at the end.

*This is general information, not legal advice. Your payment provider and acquirer decide how exemptions are requested on your account.*

When SCA applies

SCA comes from the revised Payment Services Directive, Directive (EU) 2015/2366 (PSD2), and its detailed rules sit in the Regulatory Technical Standards, Delegated Regulation (EU) 2018/389. Authentication must use at least two of three categories:

  • Knowledge: something the customer knows, such as a password or PIN.
  • Possession: something the customer has, such as a phone with the banking app.
  • Inherence: something the customer is, such as a fingerprint or face scan.

The requirement applies to electronic payments initiated by the payer. For card e-commerce it applies in full when both the issuer (the customer's bank) and the acquirer (the merchant's bank or payment provider) are in the EEA. The practical consequences:

  • A US store using a US acquirer that charges a German card is generally outside the full requirement, although the issuer may still request authentication, and many providers apply it on a best-efforts basis where only one side is in the EEA.
  • A store using a European entity of Stripe, Adyen or PayPal to charge EEA cards is squarely in scope.
  • Mail-order and telephone orders are outside scope, as are payments initiated by the merchant under a prior agreement (covered below).

The RTS applied from 14 September 2019, and national authorities allowed card e-commerce a migration period that the European Banking Authority set to end on 31 December 2020.

The UK equivalent

After Brexit the UK kept SCA through its own version of the technical standards, supervised by the Financial Conduct Authority. The FCA's final deadline for SCA on e-commerce transactions was 14 March 2022. The UK rules follow the same structure, with thresholds expressed in sterling, and the FCA maintains its own guidance on Strong Customer Authentication.

The exemptions merchants rely on

Exemptions are requested by the acquirer or payment provider, but the issuer always has the final say. An issuer can refuse an exemption and demand a challenge, which is why a checkout must always be able to fall back to 3-D Secure.

Exemption or exclusionWhat it meansKey limits (EEA)
Low-value remote payments (RTS Article 16)Small payments can skip SCAUp to €30 per payment, until five consecutive exempt payments or €100 cumulative since the last authentication
Transaction risk analysis (TRA) (RTS Article 18)The acquirer or issuer assesses the payment as low riskUp to €100, €250 or €500, depending on the provider's fraud rate staying at or below 0.13%, 0.06% or 0.01% for remote card payments
Recurring payments of the same amount (RTS Article 14)A series of payments of the same amount to the same payeeSCA on the first payment and when the amount or payee changes
Trusted beneficiaries (RTS Article 13)The customer adds the merchant to an allowlist held by their bankDepends on issuer support
Merchant-initiated transactions (MITs)Payments the merchant initiates without the customer present, under a mandate the customer agreed toTreated as outside SCA scope, provided the mandate was set up with SCA

The low-value and TRA thresholds are the figures in the RTS; the UK has equivalent sterling limits. Stripe's SCA guide summarises both sets.

Two points are often misunderstood. First, the recurring exemption only covers fixed amounts, so variable-amount subscriptions, usage billing and top-ups rely on the merchant-initiated transaction framework instead. Second, an MIT is only treated as outside scope if the original setup was authenticated and the customer agreed to future charges. A card saved without authentication and a clear agreement is likely to be challenged later.

How 3-D Secure 2 works

3-D Secure 2 (EMV 3DS) is the card networks' protocol for delivering SCA. Visa, Mastercard and other networks each brand their own version, but the flow is the same:

  1. 1Data collection. The checkout sends the issuer device and transaction data: browser details, billing and shipping address, email, purchase history and whether the card has been used before.
  2. 2Risk assessment. The issuer evaluates the data. If risk is low, or an exemption applies and is accepted, it approves without interrupting the customer. This is the *frictionless* flow.
  3. 3Challenge. If the issuer wants proof, the customer sees a challenge, usually an in-app approval in their banking app, a one-time passcode or a biometric check.
  4. 4Authorisation. After authentication the payment is sent for authorisation as normal.

Payments authenticated with 3-D Secure generally benefit from a liability shift for certain fraud-related disputes, moving that liability from the merchant to the issuer. Rules vary by network and dispute reason, so treat it as risk reduction, not a guarantee.

Richer data leads to more frictionless approvals. Passing the billing address, email and a stable customer ID helps the issuer recognise returning customers.

How payment platforms handle SCA

Stripe

Stripe's Payment Intents API is built around SCA. A PaymentIntent moves through statuses such as requires_action when authentication is needed, and Stripe.js displays the 3-D Secure challenge automatically. The two parameters that matter most for returning customers:

  • setup_future_usage: "off_session" on the first, on-session payment tells Stripe to save the payment method and authenticate it for future merchant-initiated use.
  • off_session: true on later payments tells Stripe the customer is not present, so Stripe requests an exemption or MIT treatment using the earlier authentication.

A minimal Node.js example:

`js

import Stripe from "stripe";

const stripe = new Stripe(process.env.STRIPE_SECRET_KEY);

// 1. First payment, customer on-session: charge and save the card.

export async function createFirstPayment(customerId) {

const intent = await stripe.paymentIntents.create({

amount: 2900, // €29.00 in cents

currency: "eur",

customer: customerId,

automatic_payment_methods: { enabled: true },

setup_future_usage: "off_session",

});

return intent.client_secret; // send to the browser

}

// 2. Later renewal, customer off-session.

export async function chargeSavedCard(customerId, paymentMethodId) {

try {

return await stripe.paymentIntents.create({

amount: 2900,

currency: "eur",

customer: customerId,

payment_method: paymentMethodId,

automatic_payment_methods: { enabled: true },

return_url: "https://example.com/account/billing",

off_session: true,

confirm: true,

});

} catch (err) {

if (err.code === "authentication_required") {

// The issuer wants SCA. Email the customer a link back to your site

// and confirm this PaymentIntent on-session there.

const paymentIntentId = err.raw.payment_intent.id;

await notifyCustomerToAuthenticate(customerId, paymentIntentId);

return null;

}

throw err;

}

}

`

In the browser, the first payment is confirmed with the Payment Element, which handles any challenge:

`js

const { error } = await stripe.confirmPayment({

elements, // created with the PaymentIntent's client secret

confirmParams: { return_url: "https://example.com/checkout/complete" },

});

if (error) showMessage(error.message);

`

notifyCustomerToAuthenticate is your own function. On the page it links to, retrieve the PaymentIntent's client secret and confirm it again on-session with the saved payment method so Stripe.js can show the challenge. If you use Stripe Billing for subscriptions, listen for the invoice.payment_action_required webhook and use Billing's customer email and hosted invoice page settings rather than building this yourself.

PayPal

PayPal wallet payments authenticate the customer through their PayPal login. For direct card payments via PayPal's advanced card processing, the PayPal 3D Secure documentation describes passing a verification method of SCA_WHEN_REQUIRED (authenticate only when a mandate such as PSD2 requires it) or SCA_ALWAYS (authenticate every transaction). The older 3D_SECURE value is deprecated.

Shopify

According to Shopify's PSD2 and 3D Secure help page, stores using Shopify Payments automatically use a 3-D Secure checkout flow that invokes a challenge only when the issuer requires it. With third-party gateways, SCA support depends on the provider, so confirm it before enabling a gateway for European customers. Subscription apps built on Shopify's subscription APIs handle renewals through Shopify's checkout and payment infrastructure, but check how each app notifies customers when a renewal needs authentication.

WooCommerce

The official WooCommerce Stripe gateway uses Payment Intents and supports SCA for one-off payments, saved cards and subscription renewals. When an off-session renewal requires authentication, the gateway can email the customer a link to return and authenticate the payment. Test that journey for logged-out customers, since a login step between the email and the payment page can interrupt it. Other WooCommerce gateways vary, so check each one's documentation for SCA and saved-card support.

Diagnosing failed and abandoned payments

When European payments fail more often than domestic ones, check these patterns in your payment provider's dashboard.

`authentication_required` declines. The issuer wanted SCA on a payment you sent without the customer present. Typical causes: the card was saved without setup_future_usage or an authenticated setup, the amount changed so a fixed-amount exemption no longer applies, or the issuer simply refused the exemption. Fix the setup flow and build a recovery path that brings the customer back on-session.

Soft declines. A soft decline asks for a retry with authentication, rather than refusing outright. If your integration treats every decline as final, you lose payments that would have succeeded after a challenge. Payment Intents-based integrations handle this automatically on-session; off-session, route the customer to authenticate.

Abandonment at the challenge. Customers who start a 3-D Secure challenge and never finish show up as incomplete payments or PaymentIntents stuck in requires_action. Common causes are challenges shown in an iframe that breaks on mobile, a customer switching to their banking app and not returning, or checkout pages with aggressive timeouts. Test on real mobile devices with test cards that trigger a challenge.

Missing data. Checkouts that omit email or billing address give issuers less to work with, so more payments are challenged. Collect what 3-D Secure uses, while keeping forms short.

Mismatched descriptors or currencies. Unfamiliar statement descriptors and unexpected currencies raise issuer suspicion. Use a recognisable descriptor and charge in the customer's currency where possible.

For the conversion side of checkout, including reducing form friction without weakening security, see the e-commerce checkout optimization guide. For recovering abandoned carts before payment, see WooCommerce cart abandonment with webhooks.

SCA checklist for subscription stores

First payment and card setup

  • [ ] Authenticate the first payment on-session and save the card with setup_future_usage: "off_session" (or a SetupIntent for free trials).
  • [ ] Show clear terms for future charges: amount or how it is calculated, frequency, and how to cancel.
  • [ ] Record the customer's agreement with a timestamp.
  • [ ] Pass email, billing address and a stable customer ID to the payment provider.

Renewals

  • [ ] Send renewals as off-session, merchant-initiated payments.
  • [ ] Treat plan changes, price increases and currency changes as events that may require re-authentication.
  • [ ] Handle authentication_required separately from hard declines such as stolen or closed cards.

Recovery

  • [ ] Email customers a direct link to authenticate, and test it logged out and on mobile.
  • [ ] Keep the subscription in a grace period while the customer authenticates, rather than cancelling immediately.
  • [ ] Use your provider's retry logic for soft declines, not blind repeated charges.
  • [ ] Update saved cards automatically where your provider supports card updater services.

Monitoring

  • [ ] Track authentication rate, challenge rate and failed renewals by card country.
  • [ ] Review PaymentIntents stuck in requires_action weekly.
  • [ ] Retest the full flow with provider test cards after every checkout or plugin update.

SCA is manageable once the first payment is authenticated properly and off-session failures have a clear recovery path. If your WooCommerce, Shopify or custom Stripe checkout is losing European or UK payments to authentication failures, our e-commerce solutions team can audit the flow, or you can contact us to discuss your payment setup.

Related posts

Author

Anushka Dahanayake

Anushka Dahanayake builds SEO-focused websites, e-commerce platforms, dashboards, and automation systems for businesses worldwide.