Instant Payments and Verification of Payee: What Changed in European Checkout

Payment regulation rarely produces visible interface changes. The Instant Payments Regulation is an exception. It added a new screen to bank transfers across the euro area, changed what merchants can expect from settlement, and quietly made a whole category of European payment products possible.

If you build checkout flows, payout systems, invoicing tools or anything that moves money in euros, here is what actually changed and what it means for your code.

The Regulation in Short

Regulation (EU) 2024/886, usually called the Instant Payments Regulation, amends the SEPA rules to make instant credit transfers a baseline service rather than a premium one.

The obligations arrived in stages:

• 9 January 2025: euro area payment service providers had to be able to receive instant credit transfers.
• 9 October 2025: euro area PSPs had to be able to send instant credit transfers, could not charge more for them than for standard transfers, and had to offer Verification of Payee free of charge.
• 9 July 2027: the equivalent obligations apply to PSPs in Member States whose currency is not the euro.

Two things follow. Instant euro transfers are now universally available, available around the clock, priced the same as ordinary transfers, and settle in under ten seconds. And every euro transfer initiation now includes a name check before confirmation.

What Verification of Payee Does

Before a payer confirms a transfer, their payment service provider checks whether the payee name they entered matches the name held on the account for that IBAN. The payer sees the result before authorising.

The outcome is not a simple yes or no. There are typically four states:

• Match: the name matches.
• Close match: it nearly matches, and the payer is usually shown the actual account name so they can decide.
• No match: it does not match. The payer can still proceed, but they have been warned.
• Verification not possible: the payee's PSP could not answer, for example due to a timeout.

The purpose is fraud reduction. Misdirected payments and invoice redirection fraud both depend on the payer not noticing that the account name does not correspond to who they think they are paying. Putting the check in front of the confirmation button closes a large part of that gap.

Why This Matters If You Are Not a Bank

Most teams reading this are not payment service providers, so the direct obligation is not yours. The effects still reach you.

Your business name has to match your bank account

This one catches companies out constantly. If your invoices, your checkout page and your payment instructions use a trading name, but the bank account is registered under a legal entity name, every customer paying you by transfer now sees a close match or a no match warning.

Some of them will stop. Some will call support. A few will conclude that your invoice is a phishing attempt, which is exactly the behaviour the regulation is designed to encourage.

The fix is unglamorous but important: make the payee name you publish match the name registered on the account, everywhere. Invoice templates, checkout instructions, payment reminders, the footer of your website, the onboarding email. If the mismatch is unavoidable, tell customers up front what name they will see.

Batch payouts need a plan

If you run payouts to suppliers, contractors, marketplace sellers or refund recipients, Verification of Payee applies to bulk files too, with some flexibility in how results are surfaced for large batches.

Your payout pipeline needs to handle a result set rather than a simple accepted or rejected. That means storing the verification outcome against each payee record, deciding what your business does with a close match, and having a workflow for a human to review no-match cases rather than either blocking everything or ignoring the warning.

If you onboard payees, collect the account name as a separate field and verify it at onboarding rather than at payment time. Fixing bad payee data during a payment run is expensive and slow.

Settlement timing changes assumptions

Instant settlement means money arrives in seconds, at any hour, including weekends and holidays.

That breaks assumptions in reconciliation code written for batch settlement. Systems that expect a daily statement file, that assume no credits arrive outside business hours, or that reconcile once per day, now behave oddly. Order fulfilment logic gated on "payment cleared" can suddenly fire at 2am on a Sunday, which may be fine or may collide with a maintenance window.

None of this is hard, but it needs to be looked at deliberately rather than discovered in production.

The Bigger Consequence: A2A Payments Became Viable

The most significant effect of the Instant Payments Regulation is not the name check. It is that ubiquitous, cheap, instant euro rails made account-to-account payment products practical at consumer scale.

You cannot build a consumer wallet on rails that settle in one to two business days. Merchants will not release goods against a transfer that might arrive on Tuesday. Once instant became universal and no longer carried a premium price, that objection disappeared.

Which is how Wero arrived. The European Payments Initiative's wallet moves money over SEPA Instant, settles in about ten seconds, and bypasses the card schemes entirely. It reached roughly 43 million users on person to person transfers, then moved into e-commerce, and picked up merchants including Lidl, Decathlon, Rossmann and Eventim. We wrote a full integration walkthrough in the Wero guide.

If you are wondering why bank transfer is suddenly a serious checkout option in markets where it used to be a fallback for people without cards, this is why.

What Comes Next: PSD3 and the PSR

The next regulatory step is the payment services package. The state of play as of August 2026:

• Parliament and Council reached provisional political agreement on 27 November 2025.
• Final agreed texts were published on 23 April 2026.
• Official Journal publication is expected in the second half of 2026.
• The Payment Services Regulation applies 21 months after entry into force, with Verification of Payee provisions at 27 months. PSD3 requires national transposition on a similar timeline.

Realistically that puts application in 2028. Content is effectively settled, so you can plan against it, but there is no reason to build for it this year.

The changes that matter most for product teams:

Open banking interfaces get stronger. The package tightens requirements on the dedicated interfaces banks must provide, with the debate around removing the fallback to the customer-facing interface. For anyone building on account information or payment initiation services, API quality and availability become enforceable rather than aspirational.

Fraud liability shifts. There is an expanded framework around authorised push payment fraud and impersonation, which changes who absorbs losses in scenarios that currently fall on the consumer.

Strong customer authentication gets refined. Some of the friction introduced by PSD2 is being reconsidered, particularly around transaction risk analysis and recurring payments.

Payment institutions and e-money institutions merge into a single licensing category, which simplifies life for fintechs.

A Practical Checklist

If you want to spend an hour on this and come away with something useful:

1. Send yourself a transfer to your own business account from an unrelated bank. Look at what name comes back. If it is not what customers see on your invoices, you have a job.
2. Grep your codebase for reconciliation logic that assumes settlement batches or business hours.
3. Check whether your payout provider exposes Verification of Payee results in its API, and whether you store them.
4. Look at your payee onboarding form. Does it capture the account holder name, and do you validate it at onboarding?
5. If you are in a non-euro Member State, put 9 July 2027 in the plan. It is further away than it feels.

Where This Fits

Payments are one part of a much wider regulatory build-out in Europe. The 2026 EU digital compliance guide maps the rest, and the practical work around personal data in payment flows is covered in our GDPR engineering guide.

We build and maintain payment and payout systems for companies operating across Europe, including checkout flows, order orchestration, reconciliation and the unglamorous reporting that finance teams actually need. If you want a review of how these changes land in your stack, write to office@c9group.dev, or read more on our European market entry page.