The short answer: Stripe does not perform Verification of Payee or Confirmation of Payee for you. Stripe is a payment processor - it accepts card and wallet payments, and it can pay money out to bank accounts. CoP and VoP are name-to-account checks that run on bank transfers, and they are performed by the payment service provider that sends the transfer. For a UK business, that is your bank or payment institution, not your card processor.
That distinction is missing from almost every page about Stripe in the UK, which describe pricing, hardware and support but never mention the name-check rules. This article covers the parts a finance or platform team actually meets, in order.
What 'Stripe payments UK' actually covers
The phrase means two different things, and mixing them up is where most confusion starts.
- Stripe as a payment processor: a UK business opens a Stripe account, accepts cards and wallets online and in person, and can pay out to a bank account. This is the meaning that matters for your operations.
- Stripe as a name on a bank statement or in a payment directory: a settlement credit, a direct debit, or an entry in a SWIFT/BIC lookup. This is bookkeeping, not payment acceptance.
This article is about the first meaning, and specifically about the verification duties that sit around money movement. It is not a review of Stripe's products or pricing, and it makes no claims about features Stripe may or may not offer.
Two different rails
A card payment runs on the card schemes. A bank transfer runs on a credit transfer scheme - Faster Payments and CoP in the UK, SEPA and VoP in the euro area. Name checking was built for the second rail. Accepting money by card and sending money by transfer are separate flows with separate rules.
Where payee verification sits in a Stripe payment flow
When a customer pays you by card, no credit transfer happens. The money moves through the card schemes and settles to your bank account. CoP and VoP do not apply to that leg at all, so a business that only takes card payments through Stripe has no name-check obligation of its own in its checkout.
The picture changes in three places:
- 1 Money out. When you pay a supplier, a contractor, a landlord or your staff by bank transfer, that is a credit transfer. The check belongs to the PSP that sends it.
- 2 Payouts to sellers or contractors. If your platform pays third parties into their own bank accounts, those payouts are transfers, and the account details need to be right before the money moves.
- 3 Bank-based payment methods at checkout. Some checkout methods are built on account-to-account rails rather than cards. Where a transfer is involved, the name check is a transfer control, not a card control.
In each case the question to ask is not 'does my processor do this?' but 'who sends the transfer, and what does that provider show me before it goes?' Our page on how Verification of Payee works sets out the request-and-response flow behind that question.
UK Confirmation of Payee vs EU Verification of Payee
Both schemes do the same job - check a payee name against the account behind the number - but they are separate systems with separate rules.
- Confirmation of Payee is the UK scheme. It works on sort code and account number, and it returns match, close match or no match. UK payment service providers have offered it on Faster Payments and CHAPS payments since 2020.
- Verification of Payee is the EU/SEPA scheme, coordinated by the European Payments Council and mandated by the Instant Payments Regulation. It works on IBANs and returns match, close match, no match and not available.
A UK business can meet both without leaving the office. You pay a UK supplier: CoP applies. You pay a German supplier in euro from a euro account: VoP applies. You pay a French contractor from a UK account in sterling: the payment is a cross-border transfer, and the name check depends on the rails and the providers involved - which is exactly why you should not assume it happened.
The scheme-level differences are covered in more depth on our Confirmation of Payee page and in our comparison of Verification of Payee and Confirmation of Payee.
Who carries the obligation when you use a provider like Stripe
Responsibility is split across the chain, and each party owns a different piece.
- The payer's PSP - your bank or payment institution - must run the name check on the transfers it sends, where the scheme requires it, and show you the result.
- The payee's PSP - the bank that holds the account you are paying - answers the check from its own account records.
- The processor - Stripe, or any other acquirer - handles card acceptance and settlement. That is a different rail, so the name-check duty does not sit there.
- Your business - the merchant, platform or corporate treasury team - owns the decision. You choose the payee details, you read the result, and you decide whether to release the payment.
That last line is the one finance teams miss. A scheme check tells you whether the name matches the account. It does not tell you whether the invoice is genuine, whether the email that changed the bank details came from the real supplier, or whether the person instructing you is who they claim to be. Those are your controls, and no processor removes them.
A processor is not a control
Using Stripe for card acceptance does not discharge your duty to verify supplier, contractor and payroll accounts before you pay them. The processor sits on the collection side; the verification duty sits on the payment side.
Practical checks for a UK business paying into SEPA
If your finance team sends supplier, contractor or payroll payments to euro IBANs, here is the routine that holds up.
- 1 Take the payee name from the source document - the invoice, contract or payroll record - not from an email that arrived with new bank details.
- 2 Run a name-to-IBAN check through your bank or a VoP service, and read the result before you release the payment.
- 3 On a match, proceed with normal confidence.
- 4 On a close match, accept the verified name the check returns, or correct your record to it, rather than overriding it.
- 5 On a no match, stop. Call the payee on a number you already had, never one from the message that gave you the new details.
- 6 On not available, treat a new or changed payee with extra care and confirm through a second channel.
- 7 Re-verify whenever an IBAN or a name changes, and keep the result with the payment record.
If you pay many suppliers, run the check across the whole payment file before release rather than one payee at a time. That catches the single mismatched account in a run of two hundred - which is the one that costs you. Our guide to verifying the account holder of an IBAN explains why you cannot look this up yourself, and what your bank can do instead.
For payroll, the riskiest moment is a bank-detail change, not the monthly run. Verify the employee name against the new IBAN when the change is requested, and again before the file is released. Our payroll guide covers that routine in detail.
What to ask your provider before you assume it is covered
These are questions, not claims about any named provider. Ask them of your bank, your processor and any VoP service you consider.
- Which payment methods are in scope? Cards, wallets and account-to-account methods have different controls.
- Do name checks run on the outbound transfers I send, or only on incoming payments?
- How is a mismatch surfaced to the person releasing the payment - a screen, a file flag, a webhook?
- What is logged for audit, and for how long? Can I show what was checked and when?
- Does the service cover both UK sort-code payments and SEPA IBAN payments, or only one?
- What happens when the payee's bank cannot answer - is 'not available' handled as a normal outcome?
If the answer to the second question is 'we do not check outbound transfers', you have found the gap. That is where a standalone IBAN name check fits alongside your existing setup: one integration for the transfer side of the house, while your processor keeps doing what it does well.
RoxPay delivers Verification of Payee on the SEPA scheme through one REST API and a dashboard, covering both the requesting and the responding direction. It returns the standardised outcomes - match, close match, no match and not available - in well under a second, with the verified name on a close match, for a single payment or a whole payment file.