The short answer: Apron is a UK business finance platform. It brings bill payments, payroll, expenses and accounting reconciliation into one place, uses AI to read invoices and receipts, and asks you to approve what it has prepared. It is not a bank, and it does not hold your money as a deposit account would. Payments are made from your own bank account or card.
That last point is the one that matters for payee verification. When a platform lines up a batch of supplier bills, a payroll run and a tax payment, the money still moves through a bank or payment provider. The name-to-IBAN check on those transfers belongs to that provider - and the decision to release the payment stays with you.
What is Apron payments?
Apron is a finance platform built for small and mid-sized UK businesses. In practice it gives a finance team four things in one place: bill capture and payment, payroll, expense management with expense cards, and reconciliation back into the accounting ledger. The AI layer reads invoices and receipts and pre-fills the data; a person reviews and approves.
Two different things share the name, and mixing them up is where most confusion starts.
- The platform, at getapron.com: the product you sign up to, with the dashboard, the payment flows and the mobile app.
- APRON PAYMENTS LTD: the UK company behind it - company number 13779960, incorporated on 3 December 2021, and previously registered as HELLO CASH LTD. That earlier name is why some searches turn up a company record that looks unrelated.
Platform and company are not the same question
If you are checking who you are dealing with, the Companies House record answers the legal-entity question. If you are checking how a payment is made and verified, the platform's own documentation answers that. Neither one tells you whether a supplier's IBAN is correct.
Is Apron a bank?
No. Apron is a payments and finance platform, not a bank. It does not take deposits in the way a bank does, and it is not the institution that holds your business current account. Payments are made from your own bank account or card, which is why the platform can connect to the accounts and cards you already use.
That distinction has a practical consequence. A name-to-IBAN check - Verification of Payee (VoP) in the EU and SEPA, Confirmation of Payee (CoP) in the UK - is performed by the payment service provider (PSP) that sends the transfer, and answered by the PSP that holds the payee's account. If your money leaves from your own bank account, your bank is the PSP in that flow. The platform prepares and presents the payment; it does not replace the bank's check.
So the honest answer to 'who is responsible when a payment goes to the wrong account?' is: the obligation to run the check sits with the sending provider, and the decision to release the payment sits with you. A platform can make that decision easier by showing you the result, but it cannot take the decision away.
What Apron payments cover: bills, payroll, HMRC and expenses
Apron describes several kinds of payment. Not all of them carry the same risk, so it helps to separate the outbound ones - the payments where a wrong IBAN or a wrong name costs real money.
- Supplier bills, often paid in batches: the classic outbound flow, and the one most exposed to invoice redirection, where a fraudster changes the bank details on a genuine invoice.
- Payroll: salaries to staff, where the riskiest moment is not the monthly run but a request to change an employee's bank details.
- HMRC payments: tax and other payments to a public authority, where a mistyped reference or account detail can delay or misdirect a payment that is hard to unwind.
- Team expenses and expense cards: smaller amounts, but the same discipline applies when reimbursing a person to a bank account.
- Payment links: money coming in rather than going out, so the payee-verification question is different.
The first three are where a name check earns its place. When you approve a batch of forty supplier bills in one click, a single mistyped or fraudulently changed IBAN travels with the batch. That is the failure mode to design against.
How much does Apron charge?
Apron's own pages describe its pricing in outline rather than as a full tariff: a small fee applies when you earn rewards points on payments, card cashback is advertised at up to 1%, and payment links are described as 0% on pay by bank and business cards versus a 1% fee on personal cards.
Those are the figures the source pages state, and they are a starting point, not a quote. Plans, eligibility for cashback and the treatment of specific payment types change over time, so check Apron's own pricing pages for your business before you build a cost model. This article does not estimate fees, licensing or bank partners beyond what those pages say.
Why payee verification matters for platform-initiated payments
A platform makes paying faster. Faster is good, until the speed applies to a payment that should never have been sent. Authorised push payment (APP) fraud - where a payer is tricked into sending money to an account controlled by a fraudster - is difficult to reverse once the money has left, and instant payments make the window even shorter.
Verification of Payee is the control built for exactly this moment. Before a euro credit transfer is sent, the payer's PSP asks the payee's PSP whether the name supplied matches the account behind the IBAN, and shows the answer to the payer. In the UK, Confirmation of Payee does the same job on sort code and account number payments. The check does not block the payment; it puts a bank-sourced answer in front of the person releasing the money while they can still act on it.
For a finance team, the value is simple: a mismatch caught before release costs a phone call. A mismatch caught afterwards costs a recovery process, a supplier relationship and, often, the money itself.
Checking supplier, payroll and HMRC payee details before you pay
These steps are process, not product. They work whatever platform you use to prepare the payment.
- 1 Confirm the account holder name from the source document - the invoice, the contract, the payroll record - not from an email that arrived with new bank details.
- 2 Run a name-to-IBAN check when a supplier or employee is first set up, and store the verified name that comes back.
- 3 Run the check again before the first payment, and across the whole payment file before release if you pay in batches.
- 4 Re-verify whenever an IBAN or a name changes. A change request is the highest-risk event in the whole cycle.
- 5 Treat urgency as a red flag. A supplier who needs bank details changed today, by email, and cannot take a call, is describing the shape of a scam.
- 6 Keep the outcome with the payment record: what was checked, which institution answered, and when.
For HMRC and other public-authority payments, the same discipline applies to the reference and the account details: confirm them from the authority's own published guidance rather than from a forwarded message, and check the payee name the same way you would for a supplier.
Where VoP fits alongside a platform like Apron
VoP is a bank-side and PSP-side check. If your transfers leave from your own bank account, your bank runs it. Corporates and treasury teams can also run IBAN name checks through an API or a dashboard before loading payees into any payment platform, which is useful when you want the check to happen at onboarding and again at file level, not only at the moment of release.
Whichever route you use, the outcomes are the same four, and each asks something different of the finance team.
- Match: the name is consistent with the account holder. Proceed with normal confidence.
- Close match: the names are similar but not identical - a missing middle name, a trading name instead of a registered name. Accept the verified name the check returns, or correct your record to it, rather than overriding it.
- No match: the name does not belong to that account. Stop, and call the payee on a number you already had - never one from the message that gave you the new details.
- Not available: the payee's provider could not answer. Neither good nor bad news; treat a new or changed payee with extra care and confirm through a second channel.
If you want the mechanics in more depth, our explainer on what Verification of Payee is and the walkthrough of how Verification of Payee works cover the request-and-response flow and the scheme rules. For the corporate side, the guide to VoP for businesses and corporates sets out how supplier, payroll and payout checks fit together.
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.