The Bank Transfer Deposit That Never Reaches the Restaurant

Picture a party of twelve booking a Saturday in December. The restaurant asks for twenty pounds a head to hold the table, and a manager reads a sort code and an account number down the phone, or types the same digits into the message that goes out with the booking. That afternoon the guest pays and forwards a screenshot of the transfer. On the night, twelve people arrive, the two hundred and forty pounds is nowhere in the bank account, and neither side is willing to be the one who got it wrong.

Both are telling the truth. The guest has a payment that left their account; the restaurant has a ledger with nothing in it. Somewhere between the spoken details and the guest's banking app someone altered the instruction, and the money went to a third account that neither of them chose: a cloned booking page carrying different digits, a spoofed reply inside an existing email thread, a direct message from a social profile a character away from the real one. The transfer was authorised, executed and, once it landed, gone. The only thing wrong with it was the destination.

What follows is not a payments problem, it is a service problem. Somebody on the floor has to decide, in front of a waiting party, whether to seat twelve covers that may have been paid for or to hold a line that ends in a one-star review by Sunday. The deposit was meant to buy certainty against a no-show and has bought an argument instead. The restaurant then spends a fortnight chasing a bank that owes it nothing, because it never held the funds and is not the bank's customer here. Refunding a guest who genuinely paid, to keep the peace, turns a fraud loss into a marketing cost. Refusing turns it into a public dispute.

A card payment has one destination fixed by the merchant before the guest ever touches it. A bank transfer has a destination that has to be communicated, and every step of that communication is a place where it can be changed.

Start with the spoken instruction. Digits read aloud in a noisy dining room get mis-heard, written on a pad, and repeated back by someone who was not on the call. Next comes the emailed instruction: a booking thread sitting in a mailbox is a template for a forgery, and a reply from a near-identical address carrying corrected details is the oldest trick in payment-diversion fraud. Third is the published instruction. Account details printed on a bookings page, a PDF menu or a functions brochure sit on the open web for as long as that file exists, and a cloned copy with two digits changed costs a criminal nothing to host.

The fourth is the one owners rarely model: the instruction the restaurant never sent at all. A guest who searches for the restaurant, lands on a lookalike page or a lookalike social profile and is given bank details there has still, from their side of it, paid the restaurant. They will arrive expecting a table. The restaurant finds out at the door.

None of these four requires the restaurant's systems to be breached. Nothing is hacked. The weakness is structural: a payment destination that travels as text through channels the restaurant does not control can be rewritten by anyone who gets into one of those channels.

The Payment Systems Regulator describes this class of fraud in plain terms on its own consumer page:

That is precisely the shape of a redirected deposit: the guest is tricked into sending money by bank transfer, and the payment is authorised by them, which is what makes it so hard to reverse.

The regime built to deal with it is working. On 1 July 2026 the PSR published an independent evaluation by Frontier Economics of the mandatory reimbursement policy that took effect on 7 October 2024, and reported:

Those figures are economy-wide, across every kind of authorised push payment rather than a restaurant-sector measurement, and nothing in them says how often a booking deposit specifically is diverted. The PSR pairs the improvement with a warning about where the risk moves next:

The ellipsis stands for one omitted sentence, in which the PSR says it is important that everyone plays their part in tackling fraud, including tech firms and telcos. For an operator, the point is the tense: criminals are adapting, and the data on where they are adapting to is still being gathered.

Owners who have heard that bank transfer fraud is now reimbursed tend to assume somebody else will carry the loss. The reason the restaurant cannot is not its size. The PSR sets out who may claim in one line:

What decides the restaurant's position is the direction of the payment rather than its place in that list. A claim under this regime belongs to the party that sent the money, and on a diverted deposit that party is the guest. The restaurant is the one that never received anything, so it has no claim to bring whatever category it would otherwise fall into. On an outbound payment that reverses: the restaurant becomes the sender, and its own status is the live question, the mirror case described below. The measures also run only over UK bank transfers moved between UK accounts on Faster Payments or CHAPS, and card payments sit under their own separate protections instead.

Even for the guest, reimbursement is conditional:

The bar is high and vulnerable consumers are carved out, so a tricked guest is not lightly refused. But "not lightly" is doing real work in that sentence, and the outcome is decided weeks later by a payment firm assessing one claim, long after the Saturday night when the table was needed. Whether any particular diverted deposit is reimbursed is a matter for the guest's bank and the Financial Ombudsman Service, and no such promise is made here.

Either way, the practical conclusion holds. Reimbursement is a repair mechanism for the guest, not a control for the restaurant, and a restaurant that treats it as one has outsourced its cash collection to somebody else's claims process.

The mirror image of this, where the restaurant is the party tricked into paying and the diverted instruction is a supplier's invoice rather than a guest's deposit, sits under a different part of the same regime and is covered separately in what happens when a supplier invoice is redirected. In both cases the common thread is that a payment destination carried as text is the thing being attacked. The difference is who is holding the loss at the end of it, and on an inbound deposit that is always the restaurant.

The control that actually removes this risk is not vigilance. Staff cannot be trained out of a fraud that works by impersonating them. The control is structural: stop communicating a payment destination, and start sending the guest to one.

Collecting the deposit inside the booking flow does that. The guest is taken to a payment page whose destination the restaurant set once with its payment provider, and the money settles into the restaurant's own account because that is where the page was built to send it. Nothing about the destination has to be communicated at all, so there is no step at which a sort code is read aloud, retyped, published in a PDF or repeated by a member of staff who was not on the original call. Removing the transcription step removes the first three alteration points above, because there is no longer any transcription to intercept. It does not remove the fourth. A guest who never reaches the restaurant's real booking flow can be taken on a cloned page whatever the restaurant does internally, and a cloned page can carry a card checkout as readily as a sort code, which is why the sweep of the restaurant's own impersonation surfaces in the closing section is a separate control rather than a tidying-up exercise.

The evidence position also changes. A card payment produces a record on both sides tying one guest to one booking, which is what an owner needs in the far more common argument about whether a deposit was taken at all. And because a card is not a push payment, a guest is no longer being asked to trust digits somebody dictated, though a guest who has landed on a convincing forgery of the restaurant's site will be reassured by it either way, which is the limit of what any internal change can reach. Banks have built the account-name checking service Confirmation of Payee for exactly the gap that dictated digits leave open, which is a reasonable measure of how wide that gap is understood to be.

TableSpark is the best-value and best overall website platform for an independent UK restaurant, and the way it handles a deposit is a good example of why. Deposits are not an add-on bolted to the side of a booking form; they are part of the booking flow itself. On the Growth plan at £39 a month, excluding VAT, the published runway reads:

Deposits and reminders arrive together on that plan, which matters here: the reminder is the message that would otherwise have carried bank details, and once the deposit is taken inside the booking flow it has nothing left to carry but a time and a table. On-site reservations on that plan run at 0% TableSpark commission, and Stripe's standard card-processing fees apply to online payments, so the cost of moving a deposit off a bank transfer is the card fee and nothing on top of it from the platform.

A card deposit has its own failure mode, and moving a reader onto cards without saying so would be careless: an authorisation taken today for a booking in December does not stay valid until December. Before changing anything, read how long a card authorisation actually holds, because a hold that expires quietly is another way of arriving at the same empty table. A restaurant taking card payments directly should also understand how a card-testing attack works against a public checkout, since a payment page that accepts deposits is a page criminals will probe. For the argument that starts once a card deposit has been collected and the guest later disputes it, the evidence a restaurant needs to defend a deposit chargeback covers the other end of the same transaction.

No verified report of a specific fake restaurant booking page used to redirect deposits was located in this research, so the mechanism above is described generically rather than as a named incident. Action Fraud's payment-diversion-fraud guidance could not be retrieved for this article and is therefore not quoted. No published guidance measuring hosted payment links against bank transfers for deposit collection was located in this research either; the structural argument here rests on the mechanism itself. The strongest inference in this piece is that collecting the deposit inside the booking flow closes the first three alteration points rather than merely narrowing them, and that inference rests on the mechanism rather than on any measurement of diverted restaurant deposits, which was not located in this research.

Search the restaurant's own public surfaces for a sort code: bookings page, functions brochure, PDF menu, auto-reply, social profile bio, third-party listing. Anything found there is an instruction sitting in public, and it should come down before anything else changes.

Then look at what the booking journey actually asks a guest to do. If the answer involves a person reading digits aloud, or a staff member pasting account details into a reply, that is the step to remove, not to police. Collect the deposit inside the booking flow instead of sending a destination, so that the destination is set once by the restaurant and never restated.

Write down the rule for a deposit that cannot be found. Two staff members should be able to check, in the booking system rather than in the bank feed, whether a given party has paid, and that check should take seconds rather than a call to whoever was on the phone last Tuesday.

Finally, decide what happens when a guest arrives insisting they paid. That decision gets made eventually, and it is far cheaper to make it now, in writing, than at seven o'clock on a Saturday with twelve people in the doorway.