Strong Customer Authentication: 3DS2 Engineering Guide (2026)

Implementing strong customer authentication is no longer just a compliance checkbox but a critical conversion optimisation challenge for high-volume merchants. In our experience, poorly integrated 3D Secure 2 flows destroy up to 15% of checkout conversions, whereas modern gateways can shift liability while preserving a frictionless checkout flow.

The Technical Reality of SCA and 3DS2 in 2026

Under the UK's Payment Services Regulations 2017 and the EU's evolving PSD3/PSR framework, strong customer authentication (SCA) mandates multi-factor verification for card-not-present transactions. The compliance landscape has solidified around EMV 3D Secure (3DS2) as the primary execution mechanism. The protocol has evolved from legacy 3DS 1.0 redirect loops to the modern 3DS 2.3.1 standard, which supports WebAuthn, passkeys, and direct device binding.

In our work with high-volume merchants, we have found that the transition from basic compliance to transaction-level optimisation is where engineering teams struggle. Under the hood, 3DS2 establishes a secure data conduit between the merchant's checkout, the acquirer, and the issuer. When a customer initiates checkout, the merchant's frontend collects and transmits device fingerprints, browser capabilities, and transaction context. This data exchange allows the issuing bank to silently verify the cardholder's identity. If the risk is low, the transaction proceeds via a frictionless flow; if not, the bank triggers a challenge flow, prompting the customer for biometric approval or a one-time passcode.

Frictionless vs Challenge: The 150-Data-Point Handshake

The core of the 3DS2 protocol is the rich data exchange that happens before the payment is authorised. Modern integrations using the Adyen 3D Secure 2 authentication or Stripe equivalent transmit over 150 potential data points to the issuer. This includes historical data like account age, previous billing addresses, IP geolocation, and device identifiers.

When the issuing bank receives this payload, it runs a real-time risk assessment. In the good cases, this silent handshake completes in roughly 200ms to 400ms, and the customer is authenticated without a single popup or redirect. However, if the data is sparse or the risk profile is elevated, the issuer issues a 'soft decline,' forcing a step-up challenge. We once audited a checkout that triggered a 3DS challenge on its own test cards. It was very secure; nobody could buy anything. That is the risk of a misconfigured 3DS rule engine: treating legitimate, repeat local customers with the same suspicion as a brute-force carding attack.

Navigating SCA Exemptions to Protect Conversion

To prevent checkout friction from killing your conversion rates, your integration must actively request SCA exemptions. Under the historical psd2 sca rules and the incoming PSR regulations, several transaction types are eligible for exemptions, though the final decision to grant them always rests with the cardholder's bank.

The most common exemptions we design into custom payment flows include:

• Low-Value Transactions: Payments under £25 (or €30 in the EEA) are exempt from SCA. However, the exemption is capped: banks must trigger authentication if the customer's cumulative spending without SCA exceeds £85 (or €100), or after five consecutive low-value transactions.
• Transaction Risk Analysis (TRA): This is the most valuable exemption for enterprise merchants. If your payment provider has a low fraud rate, they can request a TRA exemption for transactions up to £425 (or €500), depending on the provider's audited fraud tier.
• Merchant-Initiated Transactions (MIT): Recurring subscription charges, card-on-file billing, and delayed fulfilment charges do not require SCA after the initial setup transaction is authenticated.
• Trusted Beneficiaries (Allow-listing): Customers can choose to add your store to their bank's 'trusted list' during a challenge flow, exempting future purchases from 3DS.

Dynamic Linking: The Cryptographic Glue of 3ds2 Ecommerce

A fundamental but often overlooked requirement of strong customer authentication is dynamic linking. Enforced strictly under both PSD2 and the incoming Payment Services Regulation (PSR), dynamic linking requires that the authentication token generated during 3DS must be cryptographically linked to both the specific transaction amount and the specific payee.

If a customer approves a transaction of £120 to your store, the generated authentication code cannot be intercepted and applied to a different amount or a different merchant. This prevents man-in-the-middle attacks where a malicious actor alters the transaction details post-authentication.

For developers, this means any change to the cart's final total after the 3DS handshake has been initiated — such as applying a discount code or modifying shipping options — will invalidate the authentication. The transaction will fail at the gateway with a hard decline. In our experience, the cleanest way to handle this is to lock the cart state completely the moment the checkout submit button is pressed, ensuring no late-stage mutations can break the dynamic link.

Implementing 3DS2 and SCA: A 5-Step Integration Blueprint

If you are building or maintaining a custom checkout, you cannot rely on native platform handshakes to manage step-ups. You must implement a robust 3DS2 orchestration layer. Here is our recommended engineering path to execute this:

Gateway Behaviours: Stripe PaymentIntents vs Adyen Advanced Flow

The way you orchestrate these flows depends heavily on your choice of payment partner. As we detailed in our Adyen vs Stripe UK payment guide, both gateways handle SCA differently at the API level.

Stripe abstracts the complexity of 3DS2 through its Payment Intents API. When a card payment is processed, Stripe's Stripe 3D Secure documentation explains that the API automatically handles the decision to trigger 3DS based on regulatory requirements and fraud risk. If authentication is required, the PaymentIntent status changes to requires_action, and you must use Stripe's frontend helper confirmCardPayment to display the modal.

Adyen, by contrast, offers a more granular, developer-first approach through its Advanced Flow API. You send payment requests directly to /payments with parameters like shopperInteraction set to Ecommerce and recurringProcessingModel set to CardOnFile. If the issuer demands a challenge, Adyen returns a resultCode: IdentifyShopper or ChallengeShopper with an action object. Your frontend must then mount the Adyen Web Component to handle the specific challenge type. This granular control is highly beneficial for enterprise merchants who want to run custom routing logic, but it increases the engineering surface area compared to Stripe's fully managed flows.

SCA in Headless Commerce: The PCI Scope Catch

If your storefront is built on a headless architecture using Hydrogen or Next.js, handling SCA introduces significant compliance risks. In a standard monolithic setup (like Shopify Plus with Checkout Extensibility), the platform manages the payment iframe, keeping the merchant's servers out of scope for card data handling.

However, if you build an API-only checkout where card data hits your frontend before being tokenised, your engineering team is taking on severe compliance overhead. As we discuss in our guide to PCI-DSS 4.0 headless scoping rules, transmitting or handling raw card data requires SAQ D-level compliance, which involves rigorous external audits and penetration testing.

To avoid this, headless architectures should always use hosted fields or drop-in UI components provided by your gateway. For instance, you can use Next.js Route Handlers or Supabase Edge Functions to securely proxy API calls to your gateway without ever touching raw card data. By ensuring that raw credentials go directly from the client's browser to Stripe or Adyen, you limit your compliance scope to SAQ A, which is infinitely easier to maintain. For Shopify Plus merchants, utilising Checkout Extensions allows developers to customise checkout flows without modifying core checkout liquid files, which helps maintain a secure, compliant architecture. Headless checkouts using Shopify's Storefront API rely on the checkoutCompleteWithTokenizedPaymentV2 mutation to process external credit cards after the token has been secured. Unlike Shopify Functions, which limit WebAssembly execution to around 11 million instructions per invocation, custom edge functions can run complex validation rules without strict platform sandbox constraints. We use tools like the shopify.dev MCP server with its support for Polaris web components to build internal merchant tools that monitor these webhooks.

Optimising the Step-Up Flow: What to Do Next

Protecting your checkout from SCA-induced abandonment requires continuous monitoring and optimisation. You cannot simply build the integration and leave it; card networks update their rules, and issuing banks adjust their risk appetites.

To secure your conversion rates, start by auditing your current checkout analytics. Measure the delta between your frictionless and challenge flows, and identify which issuing banks are generating the highest abandonment rates. Ensure your payment gateway is configured to actively request TRA exemptions, and consider implementing smart routing rules to send high-risk transactions through gateways with superior local acquiring relationships. If you are running a headless checkout, review your frontend architecture to ensure you are not inadvertently pulling your servers into PCI scope. If you need help auditing your checkout performance, optimising your payment routing rules, or migrating your legacy checkout flows to a compliant, high-performing setup, our engineering team is here to help. Reach out to No7 Software to schedule a technical review of your payment stack.