PSD3 and the Payment Services Regulation: what changes for online merchants

Every few months another headline says PSD3 has arrived. It has not. The rules are agreed in substance, the final text is public, and the last formal steps are under way, but a merchant’s checkout today still runs under PSD2. The useful question is which parts are settled enough to plan around, and which are still to be written.

This article sets out the legislative status as of 2 November 2026, then what the agreed text says about strong authentication, fraud liability, open banking and fees, with the likely timeline. It reads the text from a merchant’s side: most duties fall on payment service providers and reach you through them. It relies on the Council’s published first-reading text, which could still be adjusted in legal-linguistic checks, and it is not legal advice.

What are PSD3 and the PSR, and what is their status?

The package has two laws. The Payment Services Regulation (PSR) applies directly in every member state and holds the rules that matter to merchants: authentication, liability, transparency, fraud. PSD3 is a directive, which covers licensing and supervision of payment institutions and has to be written into national law. Together they replace PSD2.

Step	Date	Status
Commission proposal	28 June 2023	Done
Provisional political agreement	27 November 2025	Done
Council’s Coreper approves the compromise	22 April 2026	Done
Parliament’s ECON committee approves it	5 May 2026	Done
Council adopts first-reading position (PSR)	29 October 2026	Done
Parliament’s second reading	Not yet known	Pending
Signature and Official Journal publication	Not yet known	Pending
Technical standards from the EBA	After publication	Not written

Sources: the Council’s statement of reasons and Parliament’s Legislative Train.

The Council’s statement says the chair of the ECON committee wrote on 13 May 2026 that, if the Council’s position followed the agreement, she would recommend that the plenary accept it, subject to legal-linguistic verification. So the outcome looks settled, but it has not happened. Adyen, writing on 12 October 2026, expected formal adoption and publication by December 2026. Earlier estimates have already slipped, so treat any date as a forecast.

When will the new rules apply?

Later than the headlines suggest. The Council’s text says the regulation enters into force on the twentieth day after publication in the Official Journal and applies 21 months after that. Articles 51 and 58, on verifying a payee’s name and the related liability, apply after 27 months. Articles 92 and 118 apply from entry into force.

Article 92 is the one early item with a merchant angle, since it allows recurring credit transfers without strong authentication under set conditions. Compliance Support, as at 15 October 2026, gives 21 months for PSD3 transposition as well. Summaries from earlier in 2026 quote 18 and 24 months, so check the date of anything you read; Norton Rose Fulbright’s March 2026 briefing, for example, gave those shorter periods.

Example figures, for illustration only. If the PSR were published on 1 March 2027, it would enter into force on 21 March 2027 and apply from 21 December 2028, with payee verification from 21 June 2029.

What changes for strong customer authentication?

The core stays and the edges tighten. Article 91 keeps strong customer authentication for placing an electronic payment order, with two elements from different categories, and it still requires remote payments to be dynamically linked to a specific amount and payee. There is one addition: a provider may use two elements from inherence alone if it shows that they are independent.

The points that matter for an online store are about what falls outside it:

Area	What the agreed text says	Article
Merchant-initiated transactions	Defined for the first time. Setting up a mandate remotely with the provider involved needs strong authentication	3, 91
Later payee-initiated payments	Not subject to it if there is no payer involvement	91(2)
Mail and telephone orders	Outside it only if the order is placed non-digitally, with some checks by the payer’s provider	91(5), recital 158
Token creation or replacement	Remote creation with the customer involved requires it	91(1), recital 169
Exemptions	Set by the EBA, based on risk, amount, recurrence, channel and whether the payer is a consumer. Never mandatory	91(9)
Transaction risk analysis	The EBA is to write rules on scope, audit and data	Recital 166

The text closes two common workarounds. Recital 158 says exemptions should not be relied on in an unjustified way, and that authentication should not be circumvented by using an acquirer outside the EU. Teams that label ordinary online payments as merchant-initiated or telephone orders should review that now.

Article 91(9) repeats a point worth planning for: an exemption is never guaranteed, because a provider can always decide that authentication is needed. Adyen lists its first suggested step as measuring how much volume relies on exemptions. Our article on 3DS2 exemptions explains how they work today. The exemptions themselves will change only when the EBA’s technical standards are finished, and Adyen expects those in 2027 to 2028.

Who pays for fraud under the new rules?

Mostly the providers, but some of it can flow to the merchant side. The headline measure is for consumers. Article 60 says a provider must refund a consumer manipulated by someone pretending to be that provider, using its communication channels, if the consumer reports the fraud to the police and the provider. The Council’s statement calls this strict liability for spoofing where a provider fails to deploy sufficient systems. This does not concern merchants directly, but it raises the pressure on providers to scrutinise payments.

The parts closer to a merchant are these:

• Exemptions. Article 63(4) says that where the payee’s provider applies an exemption, it is liable to the payer’s provider for any financial loss. Expect acquirers to care more about which exemptions they request and for whom.
• Failure to support authentication. Article 63(3) says that where the payee or its provider fails to develop or amend the systems needed, it must refund the loss caused to the payer’s provider.
• Technical providers. Article 59 makes technical service providers and scheme operators liable for direct financial damage from failing to support authentication, capped at the transaction amount and proportionate to their failure. Recital 15 lists payment gateway services among technical services. Check your contracts with any gateway.
• Monitoring by the payee’s provider. Article 87(3) says it must carry out transaction monitoring before funds reach the payee. Adyen expects acquirers to ask for more transaction data, and warns that chargebacks may reach merchants more often as issuers seek to recover losses.

Fraud information sharing is also new. Article 88 requires providers to share data on objectively suspicious behaviour, keeps it for no more than five years, and bars them from ending a relationship solely on information received from others without assessing it. A merchant’s customer data can therefore sit inside these arrangements. Our article on payment data and GDPR covers the roles involved.

The scheme rules on liability shift, which decide who pays for a card chargeback day to day, are separate from these articles. Do not assume one changes the other.

What changes for open banking?

It should work better for pay-by-bank, though not soon. The Council’s statement says banks may not impose technical obstacles or discriminatory delays on authorised third parties. Article 36 requires dedicated access interfaces and Article 45 lists prohibited obstacles. Article 44 gives the customer a dashboard to see and withdraw data access, and that also covers payment initiation for multiple or recurrent payments.

For merchants, the relevant piece is Article 92. A bank can run recurring credit transfers at a payee’s request without further authentication, if the payer and payee have agreed the frequency and amounts, the payer has set this up with its bank under strong authentication, and no further action is needed. That creates a route for repeat bank payments, with refund rights aligned to merchant-initiated payments. Whether banks and providers offer it is another matter. For the current state of bank payments in Europe, see our article on iDEAL, Bancontact and Wero.

What changes for fees and transparency?

Four provisions touch a merchant’s costs or checkout:

1. Surcharges. Article 28(3) bars charges for regulated cards and for all credit transfers, including instant ones, and direct debits in the EU. PSD2 covered only euro payments under the SEPA Regulation, so the ban grows. Our article on surcharges and payment fees has the wider picture.
2. Charges shown up front. Article 6 says a payee requesting a charge or offering a reduction must say so before the payment starts, and the customer only owes charges it was told about in full.
3. Scheme and processing fees. Article 32 requires schemes and processing entities to categorise fees clearly, separating mandatory scheme fees from those linked to behaviour and those for optional services. Recital 35 says this should lead to lower merchant service charges. Whether it does depends on your acquirer’s pricing, which is where interchange++ contracts help.
4. Your name on statements. Articles 16 and 25 require the payer’s provider to show the payee’s commercial trade name, meaning the name you use to market your business, plus the legal name where it is available and different. Our article on statement descriptors covers why this matters for disputes.

Parliament’s summary also mentions shops offering cash withdrawals without a purchase, within limits of EUR 100 to 150. That is optional and matters little for online stores.

What should a merchant do now?

Not much in a hurry, but a few things are worth starting.

1. Keep following PSD2. Do not remove anything on the strength of an agreed text.
2. Measure exemption reliance by acquirer and country, since exemptions are the part most likely to move.
3. Audit your labels. Check that merchant-initiated and telephone order flags match what really happens.
4. List your technical providers and read how contracts deal with authentication failures.
5. Ask each acquirer how it will pass on liability for exemptions and what extra data it will want.
6. Check your trading name matches what customers see, at every acquirer.
7. Watch the EBA. Technical standards on authentication and risk analysis are where the checkout detail will land.

How does Omno help merchants prepare?

Omno is not a bank or acquirer, so duties under the PSR fall on your providers and on you. Routing is merchant-set: by card BIN, country, currency, amount, browser information or customer segment. When a provider’s terms change, a team can edit rules and provider eligibility from the dashboard, without a release. The transaction trail keeps every attempt and provider response, which helps with the audits above. The payment orchestration page explains the setup.