PSD2 changed the way electronic payments are regulated across Europe and introduced many of the security and Open Banking concepts that businesses still encounter today.
But for UK merchants in 2026, there is an important distinction:
PSD2 is an EU directive. UK payment-service rules are now primarily contained in the Payment Services Regulations 2017 and related Financial Conduct Authority technical standards, which were adapted following the UK's withdrawal from the EU.
For merchants accepting online card payments, the most visible legacy of PSD2 is usually Strong Customer Authentication (SCA).
This affects areas including:
- online card payments;
- 3D Secure;
- recurring payments;
- saved cards;
- payment links;
- subscription billing;
- merchant-initiated transactions;
- telephone payments;
- international transactions; and
- checkout conversion.
This guide explains what UK businesses need to understand about PSD2, SCA and 3D Secure today, without assuming that every card transaction follows the same authentication rules.
Does PSD2 still apply in the UK?
PSD2 itself is European Union legislation.
The UK implemented PSD2 primarily through the Payment Services Regulations 2017.
Following Brexit, those UK regulations were amended and the FCA introduced UK technical standards covering Strong Customer Authentication and secure communication.
So it is common to hear people refer to:
“PSD2 compliance”
when discussing UK payments.
For a UK merchant, however, the more accurate question is usually:
Does my payment setup meet the current UK requirements for electronic payment authentication?
Businesses operating within the European Economic Area may also need to consider the separate EU regulatory framework depending on where the merchant, customer and payment providers are established.
What is Strong Customer Authentication?
Strong Customer Authentication is intended to provide additional security when a customer accesses a payment account or makes certain electronic payments.
Authentication generally requires at least two independent elements from different categories.
Knowledge
Something only the customer knows, such as a password or PIN.
Possession
Something the customer possesses, such as a registered mobile device.
Inherence
Something inherent to the customer, such as a fingerprint, face or other biometric characteristic.
The merchant does not normally build these authentication systems itself.
The payment gateway, acquirer, card network and issuing bank work together to support the authentication journey.
What does 3D Secure have to do with SCA?
3D Secure is widely used to support authentication for ecommerce card payments.
Current 3D Secure technology allows information about the transaction to be shared with the customer's card issuer so the issuer can assess the payment.
A transaction can broadly result in one of two customer experiences.
Frictionless authentication
The issuer has enough information to authenticate or assess the transaction without asking the customer to complete an additional challenge.
Challenge
The issuer asks the customer to complete an additional authentication step.
That might involve:
- banking-app approval;
- biometric authentication;
- a passcode;
- another approved authentication method.
3D Secure and SCA are related, but they are not the same thing.
SCA is the regulatory authentication requirement. 3D Secure is one of the main card-industry technologies used to support it.
Is authentication causing payment problems?
If customers are experiencing failed authentication, soft declines or excessive checkout friction, the issue may sit within the gateway, acquiring setup or payment journey.
Merchant Advice Service can help businesses map their payment requirements and identify gateway or merchant account providers that may support the required setup.
Review my payment setup
When can Strong Customer Authentication apply?
The FCA states that SCA requirements apply in circumstances including when a payer:
- initiates an electronic payment transaction;
- accesses their payment account online; or
- carries out certain remote actions that may present a risk of payment fraud.
However, not every transaction requires the customer to complete an additional authentication challenge.
The regulatory framework contains exemptions and there are also payment types that sit outside the standard customer-initiated ecommerce SCA journey.
This distinction matters.
An exempt transaction and an out-of-scope transaction are not necessarily the same thing.
What SCA exemptions can apply?
Depending on the payment, provider and circumstances, the regulatory framework includes exemptions that can include areas such as:
- certain low-value transactions;
- transaction-risk analysis;
- trusted beneficiaries;
- certain secure corporate payment processes;
- some recurring-payment circumstances; and
- other defined scenarios.
Merchants should be careful with the word “exemption”.
It does not normally mean the merchant can simply decide to skip authentication.
The payment provider, acquirer and issuer are involved in determining how a transaction is processed.
An issuer may also require authentication even where an exemption has been requested.
Transaction Risk Analysis exemptions
Transaction Risk Analysis, often shortened to TRA, can allow qualifying low-risk transactions to be processed without a customer challenge where the relevant regulatory conditions are met.
The ability to use TRA depends on factors including the payment provider's fraud performance and the characteristics of the transaction.
This means a merchant cannot assume:
“Our transactions are low risk, so SCA does not apply.”
The provider's authentication strategy matters as well as the merchant's own fraud performance.
Low-value payments
The regulatory framework contains exemptions for qualifying low-value transactions.
However, there are cumulative controls designed to prevent a customer making an unlimited sequence of unauthenticated payments simply because each individual payment is small.
The issuer or payment provider may therefore require authentication even where an individual transaction is relatively low value.
Merchants should rely on the provider's payment and authentication configuration rather than hard-coding assumptions into the checkout.
How does SCA affect recurring card payments?
Recurring payments need particular care because the first customer-authorised payment and later payments may not follow exactly the same authentication journey.
A typical subscription setup might involve:
customer signs up → payment method authenticated where required → credential tokenised → subsequent scheduled payments processed.
Depending on the structure, subsequent transactions may be treated differently where they form part of an agreed recurring arrangement.
The payment provider should correctly identify and submit the transaction type.
Businesses should not simply store card details themselves and repeatedly charge them without an appropriate consent, tokenisation and transaction framework.
For more detail, read our subscription payment processing guide.
What are merchant-initiated transactions?
A merchant-initiated transaction, or MIT, is generally a payment initiated by the merchant following an earlier agreement with the customer rather than a new payment actively initiated by the customer at that moment.
Examples can include certain:
- subscription payments;
- instalments;
- later charges authorised under an agreement;
- no-show charges; or
- other appropriately structured card-on-file transactions.
This does not mean any card-on-file payment can simply be labelled as merchant initiated to avoid authentication.
The original customer agreement and transaction need to be structured and identified correctly through the payment provider.
Do telephone payments require SCA?
Genuine mail-order and telephone-order transactions are treated differently from customer-entered ecommerce payments.
A genuine telephone payment is initiated through the telephone channel rather than through the normal online SCA journey.
That does not mean a merchant should use MOTO as a way of avoiding authentication.
The payment must genuinely originate through the relevant channel and should be configured correctly by the payment provider.
For example:
customer telephones business → gives payment details to employee → employee enters them into an approved virtual terminal.
This is different from:
customer receives payment link → enters card details online → ecommerce transaction takes place.
The second journey can use 3D Secure and online authentication.
Read our guides to MOTO merchant accounts and payment links for the differences.
What happens with international card payments?
International payments can make authentication more complicated because the merchant, acquirer, customer and card issuer may not all be located within the same regulatory area.
A business should not assume that every international transaction follows identical SCA rules.
Relevant factors can include:
- merchant location;
- acquirer location;
- issuer location;
- customer location;
- card scheme;
- transaction type; and
- provider configuration.
The gateway and acquirer should determine how the transaction should be submitted.
For businesses expanding internationally, see our international merchant account and card-processing guide.
What is an SCA soft decline?
A payment may sometimes be declined because the issuer requires stronger authentication rather than because the card itself is invalid or the customer lacks funds.
This is commonly referred to as a soft decline.
A properly configured ecommerce payment flow should be able to recognise relevant responses and, where appropriate, route the customer through authentication before the transaction is attempted again.
If a business experiences large numbers of unexplained payment failures, useful questions include:
- Was authentication requested?
- Was 3D Secure attempted?
- Was the customer challenged?
- Did authentication succeed?
- Was the transaction subsequently authorised?
- Was an exemption requested?
- Did the issuer reject the exemption?
- Was the gateway able to handle the resulting soft decline?
Does SCA reduce ecommerce conversion?
Authentication can introduce additional steps into checkout, so merchants should monitor its effect.
But SCA should not simply be treated as a conversion problem.
A good payment setup aims to balance:
- regulatory compliance;
- fraud prevention;
- authentication success;
- authorisation performance; and
- customer experience.
Useful payment metrics can include:
- 3D Secure authentication rate;
- frictionless versus challenged transactions;
- challenge completion rate;
- authentication failures;
- soft declines;
- authorisation rate after authentication; and
- checkout abandonment.
Read our guide to ecommerce payment KPIs for more detail.
Payment links and SCA
A payment link normally directs the customer to an online checkout hosted by the payment provider.
The journey can therefore support online authentication such as 3D Secure where required.
This can be useful where a business wants to take a remote payment without an employee manually handling card details.
For example:
salesperson agrees order → secure link sent by SMS or email → customer opens checkout → customer enters card details → authentication takes place where required.
This differs from a genuine MOTO transaction and should be treated as an ecommerce payment journey.
PSD2 also helped create the framework for Open Banking
PSD2 was not only about card authentication.
It also created a regulatory framework for services including:
- payment initiation services; and
- account information services.
This helped support the development of Open Banking alongside the separate UK Competition and Markets Authority reforms.
Open Banking enables authorised providers, with the customer's permission, to access specified account information or initiate account-to-account payments.
For merchants, Open Banking payments can provide an additional payment method alongside cards rather than simply replacing card acquiring.
Read our Open Banking guide for more information.
Is the UK replacing the PSD2-derived payment framework?
The UK payment-services framework is currently being modernised.
In July 2026, HM Treasury launched a consultation on modernising payment-services regulation.
The government is considering how the future framework should deal with areas including:
- payment services regulation;
- electronic money;
- Open Banking;
- tokenised payments;
- innovation;
- security; and
- consumer protection.
However, businesses should not treat the consultation as though the current rules have disappeared.
The Payment Services Regulations 2017 and current FCA requirements remain relevant while the future framework is developed and implemented.
What should UK merchants actually do about SCA?
For most ordinary merchants, the practical requirement is not to interpret the entire Payment Services Regulations themselves.
Instead, make sure the payment setup supports the transactions the business needs to process.
Ask your provider:
- Does our ecommerce checkout support current 3D Secure?
- How are SCA challenges handled?
- How are exemptions managed?
- How are soft declines handled?
- How are recurring payments identified?
- How are merchant-initiated transactions configured?
- How are saved cards tokenised?
- How are payment links classified?
- How are MOTO transactions submitted?
- How are international transactions handled?
- What authentication reporting can we access?
- Can we measure challenge and authentication failure rates?
When might authentication justify reviewing your payment gateway?
A provider review may be worthwhile where a business experiences persistent problems such as:
- high authentication failure rates;
- poor soft-decline handling;
- limited 3D Secure reporting;
- subscription payments failing after the first transaction;
- difficulty supporting card-on-file payments correctly;
- international authentication problems;
- poor payment-link functionality;
- limited transaction-level data; or
- an integration that no longer supports the required payment journeys.
But authentication alone should not automatically trigger a switch.
The issue could sit with:
- checkout design;
- gateway configuration;
- issuer behaviour;
- integration;
- customer behaviour;
- fraud rules; or
- the way transaction types are being submitted.
Need a payment provider that supports your payment journey?
Tell us how customers pay, whether you use subscriptions or stored cards, where customers are located and which systems the gateway needs to connect with.
Merchant Advice Service can help identify payment providers whose technical and acquiring setup may support those requirements.
Get personalised recommendations
How Merchant Advice Service helps
Merchant Advice Service does not provide regulatory compliance advice or determine whether a business meets the Payment Services Regulations.
We can help businesses understand the payment requirements that sit around the regulation.
That can include:
- ecommerce gateway requirements;
- 3D Secure support;
- recurring payments;
- merchant-initiated transactions;
- payment links;
- MOTO;
- tokenisation;
- international payments;
- fraud tools;
- authentication reporting;
- gateway integrations; and
- merchant account requirements.
We can then help identify gateway and merchant account providers that may fit the required payment setup.
Editorial & Commercial Disclosure
This article provides general information about PSD2, the UK Payment Services Regulations, Strong Customer Authentication and payment technology. It is not legal or regulatory compliance advice.
The precise treatment of a payment can depend on the merchant, customer, payment provider, transaction type and jurisdictions involved. Businesses should confirm specific regulatory and authentication requirements with their payment provider or appropriate professional adviser.
Merchant Advice Service is an independent payments information and provider-matching service. MAS is not a bank, payment processor, card scheme or regulatory body.
MAS may receive a referral fee or commission from some payment providers where a business proceeds following an introduction. Commercial relationships do not determine the factual information or provider-selection principles within this guide.
Final payment configuration, authentication, acquiring acceptance and contractual terms remain the responsibility of the relevant providers.
