PSD2 Explained

PSD2 Explained: What Merchants Need to Know About Payment Authentication and Compliance

PSD2 changed European payments in ways merchants still feel at checkout every day.

It introduced stronger security requirements for electronic payments, expanded the regulated payment-services market, enabled new forms of open banking, and strengthened consumer protections. For ecommerce merchants, its most visible consequence is Strong Customer Authentication (SCA): the requirement that payment service providers authenticate customers more strongly for many electronic payments.

But PSD2 does not mean that every European transaction must trigger a password, biometric check, or one-time code.

Some transactions can qualify for exemptions. Others, such as certain merchant-initiated transactions, may fall outside the SCA requirement when the relevant conditions are met. And even where a merchant or its payment provider requests an exemption, the issuer can still decide that authentication is necessary.

For merchants, the practical task is therefore not simply to “comply with PSD2.” It is to understand which payment flows are affected, where SCA belongs in the checkout, which transactions may be exempt or outside scope, and whether the payment stack can communicate those distinctions correctly.

As of August 2026, PSD2 remains the operative EU payment-services framework. The proposed PSD3 and new Payment Services Regulation have reached an advanced stage following political agreement in November 2025 and committee approval in 2026, but the current EU legislative record still describes them as close to adoption rather than already replacing PSD2.

What is PSD2?

PSD2, or the Second Payment Services Directive, is the EU directive that establishes rules for payment services, payment service providers, payment security, consumer protection, and access to payment accounts.

Its formal name is Directive (EU) 2015/2366.

PSD2 became applicable in January 2018, with its Strong Customer Authentication requirements becoming operational later under the accompanying Regulatory Technical Standards. The European Commission describes PSD2 as intended to make internet payments safer, improve consumer protection, encourage new mobile and online payment services, and increase competition in the payments market.

PSD2 covers substantially more than authentication. Among other things, it establishes rules involving:

•payment institutions;

•payment initiation services;

•account information services;

•consumer payment rights;

•payment-service information requirements;

•security requirements;

•access to payment accounts; and

•Strong Customer Authentication.

For an ecommerce merchant, however, SCA is usually the part of PSD2 that affects checkout most directly.

What does PSD2 mean for merchants?

PSD2 primarily places payment-services obligations on regulated payment service providers rather than turning ordinary ecommerce merchants into regulated payment institutions.

But merchants still have to build payment flows that allow their PSP, acquirer, and the customer's issuer to satisfy the applicable rules.

That can affect:

•how an online card payment is authenticated;

•whether 3D Secure is invoked;

•whether a transaction can be submitted for an SCA exemption;

•how stored credentials are established;

•how recurring payments are classified;

•how merchant-initiated transactions are identified;

•which information is passed to issuers;

•what happens when an issuer asks the customer to authenticate; and

•what payment behavior to expect when expanding into Europe.

The key operational distinction is therefore:

The regulated obligation may sit with the payment service provider, but the merchant's checkout and payment integration must support the process.

A merchant can have a technically functioning payment integration and still see unnecessary declines, repeated authentication, or subscription failures if transactions are classified or transmitted incorrectly.

What is Strong Customer Authentication under PSD2?

Strong Customer Authentication requires authentication using at least two independent elements from different categories:

•knowledge — something the customer knows;

•possession — something the customer possesses; and

•inherence — something the customer is.

PSD2 defines SCA around two or more independent elements from those categories. For remote electronic payments, PSD2 also requires dynamic linking, connecting authentication to the specific transaction amount and payee.

In practical ecommerce terms, compliant authentication might involve combinations such as a banking app on a registered device plus biometric verification.

Entering ordinary card information alone is not SCA. The European Banking Authority has previously clarified that static card details do not by themselves constitute the necessary independent authentication factors.

When does PSD2 require SCA?

Article 97 of PSD2 requires payment service providers to apply SCA when the payer:

•accesses a payment account online;

•initiates an electronic payment transaction; or

•performs a remote action that may create a risk of payment fraud or other abuse.

The Regulatory Technical Standards then define circumstances in which a PSP can refrain from applying SCA.

For ecommerce merchants, this means a customer-initiated electronic purchase within the relevant geographic scope should generally be designed so authentication can occur, even if an exemption may ultimately be used.

PSD2 does not mean every payment requires a customer challenge

This is one of the most important merchant distinctions.

SCA requirement, SCA exemption, and an actual customer challenge are not the same thing.

A transaction might be:

•within the scope of the SCA requirement and authenticated;

•within scope but eligible for an exemption;

•outside the SCA requirement under the applicable payment structure; or

•sent with an exemption request but still challenged by the issuer.

A merchant therefore should not interpret “SCA compliant” as “force every European customer through two-factor authentication.”

A well-designed payment flow determines what type of transaction is occurring and lets the PSP, acquirer, issuer, and authentication infrastructure apply the appropriate treatment.

What SCA exemptions are available?

The PSD2 Regulatory Technical Standards provide several exemptions under defined conditions.

They include areas such as:

•low-value remote transactions;

•trusted beneficiaries;

•certain recurring transactions;

•qualifying secure corporate payments; and

•transactions assessed as sufficiently low risk under Transaction Risk Analysis.

These are exemptions from applying SCA, not promises that a transaction can never be authenticated.

For example, the current EU RTS allows a low-value exemption for qualifying remote electronic transactions not exceeding €30, subject to cumulative limits since the customer's last SCA event.

Transaction Risk Analysis, or TRA, takes a different approach. A PSP may refrain from applying SCA to a qualifying remote transaction where the transaction is assessed as low risk and the PSP satisfies the regulatory fraud-rate and transaction-monitoring conditions.

Those subjects deserve separate treatment because exemption eligibility depends on more than transaction amount.

Merchants should also distinguish between requesting an exemption and controlling the issuer's authentication decision. The merchant or acquirer can provide information supporting a particular treatment, but the customer's issuer remains central to the authentication decision.

How is 3D Secure related to PSD2?

3D Secure and PSD2 are closely connected, but they are not the same thing.

PSD2/SCA is a regulatory requirement.

EMV 3-D Secure is an authentication messaging protocol.

EMVCo describes EMV 3DS as a protocol that lets merchants and issuers exchange transaction, device, and payment information so the issuer can assess an ecommerce transaction and authenticate the cardholder where necessary.

In a typical card-not-present payment:

Customer checks out → Merchant/PSP sends 3DS data → Issuer evaluates risk → Frictionless authentication or challenge → Authorization continues

If the issuer has sufficient confidence in the transaction, the authentication process may be completed without requiring an interactive challenge.

If more assurance is needed, the issuer may ask the cardholder to authenticate through a banking app, biometric method, one-time code, or another supported approach.

This is why merchants should avoid equating 3D Secure with “sending the shopper an OTP.”

Modern 3DS is fundamentally a data exchange and authentication framework, and one of its purposes is to support risk-based authentication with less unnecessary checkout friction.

Where does PSD2 apply?

PSD2 is European payment regulation, not a global SCA law.

Its payment-service and authentication scope depends in part on where the payment service providers involved in the transaction are located.

For card payments, the important parties generally include:

•the payer's PSP — typically the card issuer; and

•the payee's PSP — typically the merchant's acquirer.

EBA guidance confirms that the location of those payment service providers is central to determining the regulatory scope; the physical location of the shopper and merchant is not by itself the decisive test. PSD2 also contains rules applying to parts of certain “one-leg” transactions where only one PSP is within the Union.

For merchants, this makes a simple rule such as “European customer = SCA” too crude.

A merchant should instead verify with its PSP or acquirer how the provider determines:

•issuer location;

•acquirer location;

•transaction scope;

•exemption eligibility; and

•authentication treatment for cross-border transactions.

This becomes particularly important for global merchants using several acquiring entities.

What is the difference between recurring payments and merchant-initiated transactions?

Subscriptions are one of the areas where PSD2 terminology causes the most implementation problems.

Recurring transactions under the SCA exemption

The RTS contains an exemption for a series of recurring payments with the same amount and same payee.

SCA is applied when the series is created, amended, or initiated for the first time. Subsequent transactions in the qualifying series can then be processed without SCA under the exemption.

That is a specific regulatory exemption.

Merchant-initiated transactions

A Merchant-Initiated Transaction, or MIT, is conceptually different.

Under relevant EBA interpretations, subsequent transactions initiated by the merchant pursuant to an appropriate prior mandate can be treated as payee-initiated transactions rather than new payer-initiated electronic transactions.

Where a mandate is established remotely, SCA generally needs to be applied when that mandate is established if the relevant conditions are to be satisfied.

This distinction matters for subscriptions with variable amounts, usage-based billing, hotel charges, no-show fees, and other stored-credential payment models.

A merchant should therefore not label every recurring charge “SCA exempt.”

The more accurate question is:

Is this a customer-initiated recurring payment relying on an exemption, or a subsequent merchant-initiated transaction based on a valid mandate?

Those structures can produce similar customer experiences while relying on different regulatory reasoning.

Who decides whether the customer is actually challenged?

A merchant influences the authentication flow but does not control every outcome.

Several participants matter:

Merchant

Provides checkout context and correctly identifies the payment flow.

Payment service provider / gateway

Transmits authentication and transaction information and provides the merchant's integration.

Acquirer

Processes the transaction on the merchant's side and may support exemption strategies.

3DS infrastructure

Carries authentication messages between the relevant participants.

Issuer

Evaluates the cardholder and transaction and determines how authentication should proceed.

EMVCo's 3DS materials emphasize that issuers use transaction and device information to determine what authentication is needed. Higher-risk transactions can result in an active challenge, while other transactions can follow a frictionless path.

That has a practical implication:

An exemption strategy should optimize the probability of appropriate frictionless processing, not promise that a shopper will never be challenged.

How PSD2 can slow a payment launch

PSD2 becomes a launch problem when authentication is treated as a final integration detail.

A merchant can build a checkout, subscription system, stored-card flow, and retry logic before discovering that the payment provider needs different transaction indicators, mandates, 3DS data, or exemption handling.

Common sources of unnecessary delay include:

•implementing 3DS too late;

•failing to distinguish customer-initiated and merchant-initiated payments;

•treating every recurring payment identically;

•misunderstanding which party requests an exemption;

•not supporting authentication when an issuer requests it;

•testing only with domestic cards;

•assuming an existing non-European checkout can simply be copied into Europe;

•missing PSP-specific requirements for stored credentials;

•using inconsistent transaction references between initial and subsequent payments; and

•designing fallback or retry logic without considering authentication status.

The regulatory requirement itself is not the only source of friction.

Incorrect transaction classification can be just as damaging.

What should merchants verify before launching?

Before launching payments in a PSD2-affected market, the merchant's payment and product teams should be able to answer several operational questions.

Which transactions are customer initiated?

Identify payments where the customer is actively present and initiating the purchase.

These are the transactions most likely to need an authentication-capable checkout.

Which transactions happen later without the customer?

Map subscriptions, delayed charges, usage billing, no-show charges, incremental payments, and other stored-credential activity.

Determine which model applies rather than treating all off-session transactions as identical.

How does the PSP handle SCA exemptions?

Understand which exemptions the provider supports and how they are requested.

Do not assume that because an exemption exists in the regulation, every PSP, acquirer, or transaction flow uses it in exactly the same way.

Is EMV 3DS implemented correctly?

Authentication should be able to pass sufficient transaction and device information to support issuer risk assessment and challenge the customer where needed.

What happens after a failed or incomplete authentication?

The checkout should distinguish between authentication failure, authorization decline, technical error, and other outcomes rather than routing all failures through the same retry behavior.

Which acquiring entity processes the transaction?

For multinational merchants, geographic scope can change based on the issuer and acquirer involved.

Has the full lifecycle been tested?

Do not test only the first purchase.

Test:

first purchase → stored credential setup → subscription renewal → variable charge → payment retry → expired/replaced card → authentication request

The launch architecture should reflect the merchant's real payment lifecycle.

Is PSD2 being replaced by PSD3?

Yes—but not yet in the sense that merchants should stop designing around the current framework.

The European Commission proposed PSD3 and a new Payment Services Regulation in 2023. Parliament and Council negotiators reached a provisional agreement in November 2025, and the agreed text advanced further during 2026. Current official legislative tracking still describes the package as close to adoption, with formal legislative steps remaining before the replacement framework enters into force.

The planned framework is intended to update areas including fraud prevention, consumer protection, open banking, payment-institution regulation, and harmonization of payment rules.

For merchants, the right response is not to delay current PSD2 work.

It is to:

comply with the framework that applies today while avoiding payment architecture that is so rigid it cannot adapt to the next one.

What about the United Kingdom?

PSD2 itself is EU legislation.

The UK originally implemented PSD2 through the Payment Services Regulations 2017, but after leaving the EU it established its own domestic payment-services and Strong Customer Authentication framework.

The FCA confirms that the UK's Payment Services Regulations and UK SCA technical standards remain the applicable domestic framework. Those standards were derived substantially from the earlier EU regime but should no longer be described simply as “PSD2 rules” applying because the UK is part of the EU framework.

For international merchants, that means European authentication planning should distinguish:

EU regulatory framework ≠ UK regulatory framework, even where many practical payment concepts remain similar.

Key takeaway

PSD2 is much bigger than a checkout authentication rule, but for merchants its most visible operational effect is how electronic payments are authenticated.

The central merchant lesson is not that every European payment needs extra friction.

It is that the payment stack needs to distinguish correctly between:

•payments that require SCA;

•payments that may qualify for an exemption;

•transactions that may be outside the SCA requirement;

•customer-initiated and merchant-initiated payments; and

•authentication protocols such as 3D Secure and the regulation those protocols help payment providers satisfy.

Merchants do not make every authentication decision themselves. Issuers, acquirers, PSPs, transaction data, and the relevant regulatory scope all influence what ultimately happens.

That is why PSD2 planning should start with the payment flow, not with the authentication screen.

Map the initial purchase, stored credentials, recurring charges, merchant-initiated payments, exemptions, retries, acquiring entities, and cross-border flows before launch.

When those distinctions are built into the payment architecture early, Strong Customer Authentication becomes a normal part of payment orchestration.

When they are discovered after checkout and billing logic are already built, PSD2 becomes exactly the kind of compliance issue that delays launch.

🙂 🙂 🙂 🙂 🙂 🙂 🙂

SEO & editorial guidance — not part of the article

The uploaded material provides the cluster-level authentication brief but does not contain a separate topic-specific editorial subsection, so this version uses PSD2 Explained, the lead topic in the supplied cluster, as the article focus.

Recommended SEO title: PSD2 Explained: What Merchants Need to Know About SCA

Recommended URL: /psd2-explained/

Meta description: Learn what PSD2 means for merchants, when Strong Customer Authentication applies, how exemptions and 3D Secure work, and what to check before launching payments in Europe.

The strongest SEO opportunities are the direct distinctions already built into the article: PSD2 vs SCA, SCA vs 3D Secure, SCA exemption vs outside scope, and recurring payments vs merchant-initiated transactions. These are much more useful than adding generic PSD2 history or padding the piece with an artificial FAQ.

For internal linking, I would link Strong Customer Authentication to Strong Customer Authentication Explained from the first SCA section; SCA exemptions to SCA Exemptions; 3D Secure to 3D Secure Compliance; recurring payments to Recurring Payments and SCA; merchant-initiated transactions to Merchant-Initiated Transactions and SCA; and the specific low-value and TRA mentions to their respective exemption articles rather than expanding those sections here.

Recommended reader visuals

The highest-value visual would be “PSD2 → SCA → 3D Secure: How the Concepts Fit Together.” Use three nested layers: PSD2 = regulation, inside it SCA = authentication requirement, and alongside the execution layer EMV 3DS = protocol used for cardholder authentication. This immediately resolves one of the most persistent points of merchant confusion.

A second visual should be a transaction classification flow:

Customer initiates payment

→ Is SCA in scope?

→ Is an exemption potentially available?

→ PSP/acquirer submits transaction

→ Issuer risk decision

→ Frictionless / challenge

Beside it:

Merchant initiates later payment under valid mandate

→ Assess MIT/out-of-scope treatment

→ Submit correct stored-credential/MIT indicators

→ Authorization

A third useful graphic would be a compact comparison:

Concept

What it means

Merchant implication

SCA required

Authentication requirement applies

Checkout must support authentication

SCA exemption

PSP may be allowed not to apply SCA

Exemption can be requested; challenge may still occur

Outside SCA scope

Transaction is not treated as payer-initiated SCA event under applicable conditions

Correct transaction classification becomes critical

3D Secure

Authentication messaging protocol

Carries data and supports issuer authentication decisions

The article should be reviewed once PSD3/PSR formally clear the remaining EU legislative steps. The current official position still shows the package as close to adoption rather than already replacing PSD2.