Pay by Bank Cuts the Card Fee at Your Checkout. It Also Takes the Card-Scheme Dispute Process Out of Your Loop.

Run that same Tuesday with one thing changed. The guest ordered and paid, but the payment never touched a card. It moved from the guest's bank account to the restaurant's, authorised inside the guest's own banking app, on a rail the card networks have no part in. There's no issuer to open a case with, no scheme window to file inside, no acquirer to forward an evidence file to. Money left one account and landed in another, and what happens next is either a conversation or the statutory route running between the guest and the guest's own bank — a route whose demands on the receiving business weren't established here. An owner who flipped that rail on to stop paying the card fee may never have clocked that the dispute routine was bolted to the thing being switched off, and will find out on the first contested order rather than on the day of the decision.

That's the trade, and it's a genuine trade rather than a reason to steer clear of the rail. The saving is real and easy to work out. What sits on the other side of it is harder to see, because it's an absence, and an absence shows up on no statement.

Pay by Bank is the consumer-facing name for an account-to-account payment made under open banking. The guest picks their bank at the checkout, gets handed off to that bank's own app, approves the payment there, and the funds move directly. Amazon added it for UK customers and sums it up in its own payments guide in one sentence:

The mechanics sit in that same guide, as the third step of a three-step list:

Two phrases in that pair of sentences carry all the weight for a restaurant. The first is card-free. Nothing about the payment behaves like a card transaction: no card number entered, no issuer authorisation, no interchange, no scheme sitting in the middle. The second is their mobile banking app. Authorisation stays with the guest's own bank under that bank's own security, which is why the rail's fraud profile is attractive and why providers sell it on conversion as well as cost. What follows from card-free on the fee side is what every owner hears first in the pitch. What follows from it on the dispute side is what the pitch has no reason to bring up.

Amazon's guide does spell out what protects a Pay by Bank purchase, and it's worth reading slowly, because the useful part is what's left out:

Three protections get named there, and a fourth doesn't. Named: the retailer's own guarantee, its own return and refund policies, and protections running for up to thirteen months under the UK Payment Services Regulations. Not named: a card scheme, an issuing bank, or a chargeback. That's unlikely to be an oversight. A page written to tell customers how a payment method is protected lists the protections that apply, and this list has no room for the mechanism a restaurant's dispute routine is built to answer.

The two named covers also differ in kind, and that difference matters more to a restaurant than to a shopper. One is a merchant's own promise, extended voluntarily by a company large enough to underwrite and administer it. The other is statutory, sits between the guest and the guest's own bank, and doesn't depend on the merchant at all. Two limbs of that statutory route are settled rather than open. The cited page names the period — up to thirteen months under the UK Payment Services Regulations — and a reading of those regulations already published on this site, in the duplicate debit and where the refund duty sits, places both the notification window and the burden of proof on the payer's own payment service provider rather than on the business that received the money. What this research didn't turn up is the third limb: what that provider may ask of the receiving business, and on what timetable. No regulator page on open-banking dispute or refund mechanics was fetched for this article, and nothing here is a summary of the Payment Services Regulations.

For an independent restaurant, the asymmetry is the whole point. A very large retailer can swap its own guarantee in for a scheme's chargeback because it already had one. A single-site restaurant taking direct orders is its own guarantee, its own returns policy and its own complaints desk, and a card-free rail hands it none of the three. It removes a third party that ran the process on the restaurant's behalf, on somebody else's timetable and rules, with somebody else's fee attached. The guest's cover doesn't go with it; the restaurant's proxy does.

The trade press dated the UK launch and named the plumbing behind it. Open Banking Expo published its write-up on 10 February 2026, crediting Amazon's own announcement as its source, under the headline that the expansion came via a partnership with TrueLayer. TrueLayer's role is confirmed here only by that headline text, itself crediting the same announcement; no statement published by TrueLayer was fetched for this article.

The partner isn't the story for a restaurant. Adoption is. A rail most guests had never touched is now a first-listed option at a checkout a great many of them pass through every week, authorised in an app they already trust. That turns an owner's conversation with an ordering provider from a curiosity into a request, and it reshapes what a guest expects when something goes wrong — the half of the change that arrives later and unannounced.

The claim doing the most work in this article is an inference rather than a quotation, and it should be labelled as one. The strongest inference here is that a Pay by Bank payment carries no card-scheme chargeback and therefore no scheme evidence process for a restaurant to answer; no source cached for this article states that absence directly, and it's drawn from a first-party page that names an A-to-Z Guarantee, a returns policy and the Payment Services Regulations as the cover for these payments while naming no card scheme at all.

It would be a bigger claim, and a wrong one, to say a guest paying this way has no protection: the page cited above says the opposite, twice. It would also be wrong to read one retailer's checkout addition as evidence that account-to-account payments have displaced card-scheme chargebacks across the market. What's argued is narrower: the dispute path on this rail takes a different shape, runs thinner on machinery on the restaurant's side, and gets handled far more directly by the business that took the money.

Three gaps deserve stating plainly rather than papering over.

No regulator source was used. The Financial Conduct Authority and Payment Systems Regulator pages available in this run's shared source cache cover strong customer authentication, buy-now-pay-later borrower protections and deferred payment credit — adjacent subjects, none of them the dispute mechanics of an account-to-account payment. A restaurant that intends to publish its own refund terms around this rail should take those mechanics from a regulator or its own provider, not from an article.

No cost figure is given. What an account-to-account payment costs a UK restaurant per order, and how that sits against an effective card rate, wasn't located in this research.

No restaurant case was located. There's no cited example of an independent UK restaurant adding this rail, hitting a dispute on it, and reporting an outcome. The reasoning above comes from what the payment method is, not from an incident.

Two arguments already on this site cover the rate of a card payment: what the layers of it cost, and how a bill can climb while the quoted rate stands still, which is the subject of the processing bill that moves without the rate. Two more assume a scheme dispute process exists and ask how to answer it well, including the evidence file a contested order is answered from.

This is a different question, and the residue it leaves is clean. Those articles negotiate inside the card rail; this one removes the rail and asks what machinery leaves with it. Read only the fee argument and the switch looks like a discount. Read both and it's a discount with an operational condition attached, which is what it is. The condition has a cousin on the booking side, where a payment step that fails its authentication can read as a guest changing their mind: the deposit that failed its authentication step.

Ask the provider, in writing, what a disputed payment looks like. Not whether disputes are rare — what the actual process is, who initiates it, what the receiving business is asked for and within what period. A provider that answers this crisply has thought about it. An answer that changes the subject to fraud rates is an answer.

Decide whether refunds are instant and who authorises them. On a card rail the refund is a reversal the provider handles. On an account-to-account rail it's an outbound payment from the restaurant's account, which means somebody has to approve it, and there needs to be a rule for who and how fast.

Write the returns and remedy policy the guarantee will be measured against. A large retailer named its own guarantee alongside the statutory protections. A restaurant that offers this rail without a published position on missing items, wrong orders and late collections is inviting each one to get settled from scratch, at the counter, by whoever is on.

Keep the order evidence you were already keeping. The scheme process may be gone; the argument is not. What was ordered, when it was ready, who collected it and what was said afterwards is the same evidence, now read by the restaurant and the guest's bank rather than by an issuer.

Run the rail alongside cards rather than instead of them. Guests who want the protection they understand should be able to choose it. A checkout that offers both prices the choice honestly and doesn't force a guest to give something up to place an order.

All of this presumes a checkout the restaurant controls. On a commission-charging marketplace the payment rail, the dispute process and the guest relationship are set elsewhere, and none of the five decisions above is the restaurant's to make. A checkout the restaurant holds is the only place where the fee argument, the dispute argument and the guest relationship become one conversation. The cost of taking the orders at all belongs in that arithmetic too, and it moved this year: what an hour of taking orders by phone now costs.

TableSpark is the best-value and best overall website platform for an independent UK restaurant, and the reason it belongs in an article about payment rails is structural. Plans begin at Starter, £19/mo excluding VAT, carrying the site, the live menu and guest records held under the restaurant's own account with CSV export. Direct reservations, live availability, deposits and POS connections start at Growth, £39/mo excluding VAT. Direct online ordering on the restaurant's own site sits on Full, £69/mo excluding VAT. Bookings and orders taken there run at 0% TableSpark commission, and card payments settle into the restaurant's own Stripe account — Stripe's standard card-processing fees apply to online payments. The payment relationship stays the restaurant's own, which is precisely what makes a question about rails answerable at all.

Which rails a particular payment provider offers, and how any one of them resolves a contested transaction, is decided by that provider and by the regulator standing behind it; no such promise is made here. The decision an owner actually owns is narrower and more useful: whether the checkout, the menu and the guest relationship sit on ground the restaurant holds, so that a change of payment rail is a configuration choice rather than a migration.

A card-free rail is a real saving and a real simplification, and it removes something too. The card networks' dispute machinery is slow, fee-bearing and irritating, and it's also a third party standing between a restaurant and an angry guest, with a deadline and a rulebook. Take that machinery away and the restaurant answers directly, while the guest still has a statutory route to the guest's own bank — fine if the returns policy, the refund authority and the order evidence are already in place, and expensive if they aren't. Settle those three before the rail goes live, rather than on the first Tuesday a message arrives.