PSD2 Strong Customer Authentication and 3DS2: A Merchant's Guide

PSD2 strong customer authentication (SCA) requires most online card payments in Europe to pass a two-factor check, and 3DS2 is how card merchants run that check. Done well, it stops fraud without stopping the sale. This guide covers what SCA requires, how 3DS2 meets it, which payments are exempt, and how to keep checkout friction low.

Payment fraud across the EEA reached €4.2 billion in 2024, according to the joint EBA and ECB fraud report. The same report found that transactions verified with SCA were generally less likely to be fraudulent, especially card payments. Card fraud was 17 times higher when the payee was outside the EEA. SCA works. Your job is to meet it without making good customers jump through extra hoops.

PSD2 sets the rules for payment services in Europe

The second Payment Services Directive (PSD2) replaced the original 2007 directive and applied from January 2018. It has two goals that matter to merchants. It opens banking to competition by requiring banks to give licensed third parties access to customer accounts. It also cuts fraud by requiring stronger authentication for electronic payments.

That second goal is SCA. The detailed requirements sit in the EBA's regulatory technical standards, which applied from 14 September 2019. Regulators gave card ecommerce a migration period that ended on 31 December 2020.

PSD2 applies across the European Economic Area. The UK now runs its own version, covered below.

Strong customer authentication requires two of three factors

SCA asks the customer to prove who they are with at least two independent factors from different categories:

• Knowledge: something only the customer knows, such as a password or PIN
• Possession: something only the customer has, such as a registered phone or card reader
• Inherence: something the customer is, such as a fingerprint or face scan

The factors must be independent, so stealing one doesn't compromise the other. A password plus a one-time code sent to a registered phone meets the rule. So does approving a payment in a banking app with a fingerprint, which covers possession and inherence in one step.

Remote payments add one more requirement, called dynamic linking. The authentication code must be tied to the exact amount and the specific payee. If either changes, the code is no longer valid.

SCA applies when a customer initiates an electronic payment, accesses a payment account online, or takes a remote action that carries a risk of fraud. For card merchants, that means most online checkouts where both the issuing bank and the acquiring bank are in the EEA.

3DS2 is how card payments meet SCA

3-D Secure (3DS) is the authentication protocol card networks use for online payments. EMVCo, the body owned by the major card networks, maintains the EMV 3DS specification. The PCI Security Standards Council publishes a separate standard for securing the systems that run 3DS: the 3DS Server, the issuer's Access Control Server (ACS), and the Directory Server. EMVCo defines how 3DS works. PCI SSC defines how to protect it.

The first version of 3DS sent shoppers to a bank web page to type a static password. It broke on mobile, confused customers, and drove up cart abandonment. Visa and Mastercard retired it in October 2022.

3DS2 fixes those problems with data. The merchant sends the issuer a much richer set of information about the device, browser, transaction, and shipping details. The issuer's ACS scores the risk and returns one of two outcomes:

1. Frictionless: the issuer approves the authentication without asking the customer to do anything.
2. Challenge: the issuer asks the customer to verify, usually through a banking app or a one-time code. The challenge appears inside the merchant's checkout or app instead of a full-page redirect.

In the EEA, a frictionless result on an in-scope payment means the issuer applied an exemption, such as its own risk analysis. Either way, a successful 3DS2 authentication generally shifts fraud chargeback liability from the merchant to the issuer.

Version matters. The card networks ended support for 3DS 2.1 in September 2024 (see the 3DS 2.1 sunset notice). Versions 2.2 and 2.3.1 are current. Version 2.2 added support for PSD2 exemptions, merchant-initiated authentication when the cardholder isn't present (3RI), and decoupled authentication. Version 2.3.1 added data for Secure Payment Confirmation and out-of-band authentication, plus more options for the challenge step.

Some payments fall outside SCA scope

Out of scope and exempt are different things. An out-of-scope payment never needed SCA. An exempt payment needed SCA, but the rules allow it to skip the check.

‍

These payments are out of scope:

‍

• Merchant-initiated transactions (MITs), such as subscription renewals, usage-based billing, and delayed charges, where the customer isn't present
• Mail order and telephone order (MOTO) payments
• One-leg-out payments, where the issuer or acquirer sits outside the EEA (SCA applies on a best-effort basis)

‍

MITs need care. Authenticate the first payment when the customer sets up the agreement. Then flag every later charge as merchant-initiated and include the reference to the original transaction. An MIT sent without the right indicators looks like a customer-initiated payment, and the issuer may decline it for missing SCA.

PSD2 SCA exemptions cut friction on lower-risk payments

Exemptions let low-risk, in-scope payments skip the challenge. They are defined in Articles 10 to 18 of the regulatory technical standards. Articles 10 and 15 cover account access and transfers between a customer's own accounts, so they rarely matter for card merchants.

TRA is the exemption with the most room to grow. The provider applying it must keep its fraud rate for remote card payments under these thresholds:

Payments over €500 can't use TRA.

Three rules decide how exemptions play out in practice:

1. The issuer has the final say. A merchant or acquirer can request an exemption, but the issuer can refuse and ask for SCA.
2. Liability follows the exemption. When the acquirer applies an exemption, fraud liability stays with the acquirer and merchant. When the issuer applies one, the issuer carries it.
3. The request has to travel with the payment. Exemptions are flagged in the 3DS2 authentication request or in the authorization message, and a missing flag means no exemption.

Recover SCA soft declines by authenticating and retrying

When an issuer wants SCA on a payment sent without it, it returns a soft decline. Issuers usually signal this with response code 1A or 65, though gateways format the response differently. Spreedly normalizes these responses to a single failure reason, cardholder_authentication_required, so your retry logic doesn't need to parse each gateway's codes.

A soft decline is a request for authentication. Trigger 3DS2, let the customer complete the challenge, and resend the authorization with the authentication data attached. Retrying the same payment without authentication will fail again and can count against you with the issuer.

Track soft decline rates by issuer and by exemption type. A spike usually points to an exemption one issuer won't honor, and that data tells you where to send full authentication from the start.

The UK runs its own version of SCA

After Brexit, UK SCA rules sit in the Payment Services Regulations 2017 and the FCA's version of the technical standards. The core requirement matches the EU's: two independent factors and dynamic linking for remote payments. The FCA set 14 March 2022 as the deadline for full SCA compliance on UK ecommerce.

The two regimes have drifted apart. The UK contactless exemption allows up to £100 per payment, with SCA required after £300 cumulative or five consecutive contactless payments. From March 2026, the FCA lets firms with strong fraud controls set their own contactless limits. The FCA also expects firms to offer authentication methods that don't rely on a mobile phone, according to its SCA guidance.

If you sell to both EEA and UK cardholders, confirm your exemption logic and limits for each market separately.

PSD3 and the PSR update the rules without replacing SCA

The EU is replacing PSD2 with two new laws: a third Payment Services Directive (PSD3) and a directly applicable Payment Services Regulation (PSR). The European Parliament and Council reached a provisional agreement in November 2025, and final compromise texts followed in April 2026. Most PSR rules apply 21 months after the regulation enters into force. [UPDATE AT PUBLISH: if the PSR has appeared in the Official Journal, add the publication date and application date here]

For card merchants, SCA stays. Two-factor authentication and 3DS2 remain the standard. The main changes are:

• SCA rules move into a regulation, so they apply the same way in every member state instead of through national laws
• Merchant-initiated transactions get clearer treatment in the text
• SCA methods must be free of charge, can't depend solely on a smartphone, and must work for more vulnerable users, such as people with disabilities and older customers
• Payment providers can rely on technical service providers to support SCA, and a provider that fails to deliver those services can be liable for the resulting losses [VERIFY: confirm against final PSR text]
• Banks must refund customers in full when a fraudster impersonates the bank, with the burden of proof on the bank

The EBA will publish new technical standards under the PSR, including the detailed exemption rules. Until then, PSD2's exemptions and thresholds remain the working rules.

Spreedly lets you run SCA across your gateways from one integration

Spreedly gives you two built-in ways to add 3DS2 to your payment flow.

Spreedly 3DS2 Global runs authentication through a 3DS server Spreedly connects you to, separate from your gateway. It’s built on EMV 3DS 2.3.1 and supports Visa, Mastercard, American Express, Discover, Diners, JCB, Dankort, UnionPay, and Cartes Bancaires. Because authentication happens independently of processing, you can authenticate once and send the payment to any of 50+ supported gateways. You can request low-value and TRA exemptions in the same call, and run non-payment authentication to verify a cardholder without charging the card.

Gateway Specific 3DS2 uses your gateway’s own 3DS service. Spreedly gives you a single field to flag MOTO payments as out of scope and to request low-value exemptions on supported gateways.

Spreedly is a PCI DSS Level 1 service provider, so card data stays protected in the Spreedly vault while you authenticate and route.

Build SCA into your checkout once

SCA is now a permanent part of selling online in Europe. The merchants who handle it best authenticate only when they need to, request the right exemptions, and recover soft declines automatically. Spreedly gives you the 3DS2 tools to do all three across every gateway you use.

Talk to Spreedly about adding 3DS2 to your payment flow.