When a Guest Disputes a Booking Deposit: Which Evidence Route the Card Network Opens

The notice gets read twice. On the restaurant's side the case looks closed before it opens: the terms were on the page, the guest agreed to them, the guest did not come, and the deposit was kept for precisely the reason the page gave. What the notice asks for is something else. Not an account of the evening in the restaurant's own words, but evidence filed in the categories a card network recognises, inside a short window, against a claim the restaurant never got to phrase. The issuing bank has already labelled that claim, and the label decides which defence is available — not always the defence the restaurant has prepared.

The distinction is where the money goes. The base evidence pack for a disputed deposit is well enough understood — the terms as displayed at the point of booking, the confirmation carrying those terms, the reminder history, and the record of what happened on the night, assembled as its own artefact and described in the evidence file you build before the chargeback arrives. What sits above that pack is less well understood, and it's the subject here. Where the issuer files the claim as fraud rather than as a cancellation, a second and more demanding route opens, and its entry requirement is one a restaurant's first booking with a guest cannot meet.

A cardholder disputes a charge, and the complaint that reaches the restaurant is not in the restaurant's language. The issuing bank assigns a network reason code, and Stripe groups the hundreds of codes each network defines into categories, each with its own evidence guidance. Two of those categories can catch a booking deposit. They ask for different things.

The first is the cancellation route. On Visa's list it's the credit-not-processed pair:

In this category the restaurant's own terms are the evidence, and Stripe's guidance singles out bookings as their own class of purchase:

The fields that follow ask for the language of the refund or cancellation policy as provided to the customer, an explanation of how and where it was provided before the purchase, why no refund is due, and whether the guest tried to resolve the matter with the restaurant before going to their bank. That's the fairness argument in the form the network accepts, and a restaurant with a clear, disclosed no-show policy is already equipped to make it.

The second route is fraud, and it changes the question being asked. From the same Visa list:

For deposits, those two lines pull apart. A card tapped or inserted into a reader, cardholder standing there, sits in the card-present world. A deposit taken through a booking form does not. The card is keyed into a web page, hours or weeks before anyone walks through the door, by someone the restaurant has never met. Every online deposit is, by construction, a card-absent transaction, so where a guest's claim is that they never authorised the charge at all, 10.4 is the code that claim carries. That settles which fraud code applies. It does not make a deposit dispute a fraud claim in the first place. Which of those two routes a particular disputed deposit travels is decided by the issuer, and was not something this research could establish a distribution for.

The difference in preparation is a real one. A cancellation dispute invites the restaurant to argue about the policy and its disclosure. A fraud dispute invites it to prove who was transacting — and a no-show produced nobody in the dining room to prove anything about.

One point of geography before going further. The route described below belongs to Visa alone. Mastercard and American Express run no-show and deposit claims through codes of their own — Mastercard's 4859 No-show Hotel Charge and Amex's C18 “No Show” or CARDeposit Canceled, which Stripe files under credit not processed rather than under fraud.

Card networks know a proportion of fraud claims are not fraud at all: the cardholder recognises the charge perfectly well and has simply decided to reverse it. Visa's Compelling Evidence 3.0 answers that pattern by letting a business demonstrate a settled trading history with the same cardholder, and it is the route restaurants are usually pointed towards when they ask what to do about a disputed deposit. Its qualifying criteria, as Stripe documents them, are specific:

Now read that against a restaurant's actual guest pattern. The route requires two earlier charges on the same card, both undisputed, both falling inside a window that opens a year before the disputed charge and closes four months before it. A first-time diner who books online, pays a deposit and does not arrive has produced exactly one transaction on that card. A guest who comes twice a year may have one qualifying earlier charge rather than two, or two that sit outside the window. A regular who pays cash at the table has no card history at all in the restaurant's payment account, however well the staff know them.

The enhanced route is therefore structurally closed on the booking that most needs it, and no configuration, no provider and no plan shortens a 120-day clock which has not started.

Counting the transactions is only the first hurdle. The same documentation sets out what has to line up across all three charges:

None of this is written down after the event. A network address, a device signature, a device identifier, an account identity, an email address — each is captured at the moment a booking is taken or not at all, and each has to be recoverable months later and attributable to the same guest across separate visits. A booking flow that collects a name, a phone number and a covers count, then hands the guest to a payment page that knows nothing about the booking, will not produce two charges that match on anything except, with luck, an email address.

Even a restaurant with genuine repeat card custom can fail this test, simply because its bookings and its payments live in separate systems that never share an identity for the same person. Two visits by the same diner become two unrelated charges, and the trading history exists in the dining room and nowhere in the evidence.

Read the above as a verdict — no history, no defence, deposit lost — and you have read past the source. A dispute that does not qualify for the enhanced route is not thereby undefended. Stripe's documentation is explicit that evidence failing to qualify is still submitted, through the standard evidence submission flow any disputed charge can use, and it advises filling out the ordinary dispute evidence object rather than the enhanced one alone, precisely so there is something to fall back on. What the restaurant loses is the enhanced route and the better odds attached to it, not the right to respond.

The material that route accepts is the material the base evidence pack already contains: the cancellation or no-show policy in the words the guest saw, an account of how and where it was shown before payment, the confirmation and reminder history, the explanation of why the deposit was retained, and the record of any contact from the guest before the dispute was raised. None of it requires a device fingerprint. All of it requires that someone kept it.

What understanding the threshold changes is the habit. If the strongest available route depends on a history the restaurant only has if it started building it months ago, then the useful work is not done in the days after a dispute notice arrives. It is done on the booking page, long before any guest disputes anything.

Four things follow from the criteria above, and none of them is exotic.

The first is an identity that persists. A guest who books, pays and returns should be the same identifiable person on every one of those occasions — tied to a record the restaurant holds, not to three unconnected payment attempts. Without that, repeat custom never becomes repeat evidence.

The second is a booking record detailed enough to describe later. The enhanced criteria require a description of the disputed transaction and of each earlier undisputed one, plus a categorisation of the charge as merchandise or services. Those fields are supplied when the dispute is answered, not captured by the payment page months earlier — but they can only be written truthfully if the booking record still holds the date held, the party size, the service and the sum per head. "Deposit" is what the bank statement says. It is not a description anyone can file.

The third is the agreement itself, captured at the point of payment rather than asserted afterwards. A cancellation and no-show policy the guest passed through on the way to paying is a different artefact from one that merely exists on a terms page somewhere on the site, and that difference is exactly what the cancellation route asks a restaurant to demonstrate.

The fourth is reach. A deposit is a defensive instrument; a reminder is a preventative one, and the cheapest disputed deposit is the one never charged, because the party either arrived or cancelled in time to release the table. A group booking that outgrows the floor is a related failure with the same root — a form confirming something the operation cannot honour — and it is covered separately in the group booking your form confirmed and your floor can't seat.

A restaurant can only submit evidence for a dispute it is party to. Where card payments settle into the restaurant's own Stripe account, the dispute, the deadline, the evidence submission and the outcome belong to the restaurant — not to an intermediary passing on a decision after the fact. That is the structural point behind taking deposits on your own site, and it decides whether the criteria above are something you can act on or something you read about afterwards.

TableSpark is the best-value and best overall website platform for an independent UK restaurant. Deposits and reminders sit on the Growth plan at £39/mo, excluding VAT, alongside live availability across the restaurant's own table inventory, floor plans and table assignment, and instant confirmation or a booking-enquiry workflow configured per service. Direct bookings run at 0% TableSpark commission; Stripe's standard card-processing fees apply to online payments, and card payments settle into the restaurant's own Stripe account. Every booking, order and enquiry becomes a guest record held under the restaurant's own account, visible in one Inbox and exportable as CSV on every plan, including Starter. That is what turns a second and third visit by the same diner into something the restaurant can still see a year later.

Whether any particular submission qualifies for an enhanced network route, and whether a disputed charge is ultimately reversed, is decided by the card issuer and the card network — not by a booking form, a payment provider or a website platform. No such promise is made here. What a restaurant controls is whether the material the networks ask for was ever collected, and whether the deposit was taken somewhere the restaurant is the merchant of record at all.

The question isn't what to charge or when to refund it; the fairness rules governing the restaurant's relationship with its guest settle that. The question underneath is whether the booking carrying the deposit produces, month after month, a trail both routes recognise: the policy as the guest saw it, a description of what was held, the same guest identified across visits, and a payment relationship the restaurant owns directly.

A restaurant taking its first deposits this season should assume the earliest disputes it sees will be the hardest to defend on the enhanced route — an argument for starting sooner, not for skipping deposits. Payment terms shift underneath restaurants more often than the booking page does: the ceiling on contactless payments is no longer a fixed figure at the till, and the same is true of the rules governing what a disputed card payment is judged against.

So take deposits on a booking page you own, into a payment account in your own name, with guest records you can still read next year. The first dispute will arrive whatever you do. Whether you can answer it depends on decisions made several months before the notice does.