Square Payments and Verification of Payee: What to Know

The short answer: Square Payments is a platform for accepting card payments in person and online, plus the point-of-sale software and hardware around it. Verification of Payee is a different thing entirely - a name-to-IBAN check that runs on SEPA euro credit transfers. Square does not perform that check, and it does not need to for card payments. It matters only for the bank transfers your business sends out.

That distinction is missing from most pages about Square, which describe rates and hardware but never mention the EU Instant Payments Regulation. This article covers both sides, in the order a merchant actually meets them.

What Square Payments is - and what it is not

Square is a payments and point-of-sale platform owned by Block, Inc. In practice it gives a business four things: a card reader or terminal, software to run sales and take payments online, tools for invoicing and staff management, and settlement of the card money into a bank account. It is popular with small shops, cafés, market stalls, salons and service businesses because you can start without a long contract.

Two limits are worth stating plainly. First, Square is available in a limited set of countries, so a business outside those markets cannot simply sign up. Second, and more important for this topic: Square is primarily a card acquirer and point-of-sale provider. It is not a SEPA Verification of Payee scheme participant, and it does not answer name-check requests about your suppliers' accounts.

Square's pricing at a glance

Square publishes its fees openly, and the structure is simple: a percentage per transaction, with a different rate depending on how the payment is taken. The categories are consistent across markets even where the numbers differ.

• In-person payments: the lowest rate, because the card is present and the risk is lower.
• Online payments: a higher rate, because the card is not present.
• Manually entered payments: usually the highest rate, because keyed-in card details carry more risk.
• International cards: an additional surcharge on top of the standard rate when the card is issued outside your market.
• Hardware and software: readers and terminals are typically bought outright, while some software features are billed monthly.

Rates are set per market and change over time, so treat any figure you read - here or elsewhere - as a starting point rather than a quote. Check Square's own fee pages for your country before you model costs, and read the small print on refunds, chargebacks and instant-transfer fees, which are billed differently from sales.

Where Verification of Payee fits for a Square merchant

Verification of Payee comes from the EU Instant Payments Regulation. It requires payment service providers that offer euro credit transfers to check the payee name against the account behind the IBAN before the payment is sent, and to show the result to the payer. The full background is on our page on the Instant Payments Regulation.

Now apply that to a Square merchant. When a customer taps a card, no credit transfer happens: the money moves through the card schemes and settles to your bank account. VoP does not apply to that flow at all. So a business that only takes card payments through Square has no VoP obligation of its own, and nothing in its checkout needs to change.

The picture changes when your business sends money out by bank transfer: paying a supplier's invoice, a landlord, a freelancer, a refund by transfer, or staff salaries. Those are SEPA credit transfers, and the check belongs to the bank or payment institution that sends them - not to Square, and not to your till.

If you build on Square: VoP in your payment stack

Software vendors and fintechs often embed Square's APIs to take card payments inside their own product. That is a sensible split: Square handles card acceptance, your platform handles everything else. VoP is part of the everything else.

If your product also moves money by SEPA transfer - paying out to sellers, refunding by bank transfer, settling with suppliers - you need a name-check layer alongside Square, not inside it. In practice that means one of two routes: rely on your bank's VoP service, or connect to a VoP provider through a REST API that returns the standardised outcomes for a single payment or a whole file.

• Keep the two flows separate in your code: card authorisation through Square, bank transfers through your PSP or VoP provider.
• Normalise payee data once, so the name you send to the check is the legal or registered name, not a display label from your own database.
• Treat 'not available' as a normal outcome, not an error - it is what you get when the payee's bank cannot answer.
• Log the outcome with the payment record, so you can show what you checked and when.

The API shape is deliberately small: send a name and an IBAN, receive one of four outcomes. Our Verification of Payee API page describes the contract, and the integration guide covers the path from sandbox to go-live.

Checking a payee before you pay a supplier

For a treasury or accounts-payable team, the useful habit is simple: check the payee before the money leaves, not after. Here is the sequence that works whether you use Square for card sales or not.

1. 1 Confirm the payee name from the source document - the invoice, contract or payroll record - not from an email that arrived with new bank details.
2. 2 Run the name-to-IBAN check through your bank or a VoP service, and read the result before you release the payment.
3. 3 On a match, proceed with normal confidence.
4. 4 On a close match, accept the verified name the check returns, or correct your record to it, rather than overriding it.
5. 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. 6 On not available, treat a new or changed payee with extra care and consider a second confirmation through another channel.
7. 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 exactly 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.

Common misconceptions

Three ideas come up again and again, and each one is worth correcting.

• 'Square does VoP.' It does not. Square is a card-acceptance and point-of-sale platform. The name check on euro credit transfers is performed by the payer's PSP, or by a VoP provider the payer connects to.
• 'My card payments need a VoP check.' They do not. VoP applies to euro credit transfers. Card payments run on the card schemes and are covered by different controls, such as 3-D Secure and the acquirer's fraud tools.
• 'A VoP check replaces my fraud controls.' It does not. It confirms that the name matches the account, which is a strong defence against invoice redirection and impersonation. It says nothing about whether the invoice itself is genuine, so keep your approval workflows and your supplier-change process.

On timing: PSPs in the euro area have had to offer VoP on euro credit transfers since 9 October 2025, and PSPs in non-euro EU Member States follow by 9 July 2027. If your bank has not shown you a name-check result on a transfer yet, ask why.

How RoxPay's VoP API complements Square

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.

For a business already using Square for card acceptance, that means one integration for the bank-transfer side of the house: supplier payments, payroll, refunds and payouts. Square keeps doing what it does well; the name check sits where the SEPA transfers are.