Restaurant card payment disputes: the evidence file you build before the chargeback arrives

A dispute is not a request for comment. The card network pulls the funds first and asks afterwards. Stripe's description of the lifecycle is that the network debits the disputed amount plus a dispute fee, and those funds are held for the entire duration of the case — which, on Stripe's own timings, runs to "2-3 months to complete".

The fee is the part restaurants consistently misprice, because there are two separate fees and they behave differently. Stripe's documentation states: "If you counter a dispute, a dispute countered fee applies, in addition to the dispute received fee." The outcome then decides only one of the two. In Stripe's words: "Stripe returns the dispute countered fee if you win the dispute. Unless otherwise stated in your Stripe contract, we never return the dispute received fee." The same page states it flatly elsewhere: "For businesses outside Mexico, the fee for receiving a dispute is non-refundable."

On Stripe's published schedule for the United Kingdom, read on 28 August 2026, both the dispute received fee and the dispute countered fee are listed at 20 GBP. Put the £84 order through that. Accept the dispute and the restaurant is down £84 plus £20. Counter it and lose, and it is £84 plus £20 plus another £20. Counter it and win, and the £84 returns and the countered fee returns with it — but the received fee stays gone. The best outcome available on an £84 collection order still costs £20 and a couple of hours of a manager's evening.

Those figures are a commercial schedule published by one payment processor, read on one date. They are not a card-scheme rule, not a UK-wide rule, and Stripe revises them; the June 2025 update that introduced the countered fee is proof of that. What is durable is the shape: receiving a dispute costs money whatever happens next, and fighting one costs more money that only comes back on a win.

The second thing restaurants get wrong is imagining a conversation. There isn't one. Stripe's guidance on responding is unambiguous: "You've only one opportunity to submit your response. Stripe immediately forwards your response and all supporting files to the issuing bank."

That is the whole exchange. There is no follow-up, no request for clarification, no chance to send the delivery photo that turned up on a driver's phone the following week. Whatever is in the file when the box is ticked is the entire case.

And the file is small. Stripe's instruction is to "Limit your evidence file size to the combined maximum of 4.5 MB", with a further length cap for one network: "Limit your Mastercard evidence file length to the combined maximum of 19 pages." There is also a structural constraint that catches people out — "You can only submit one file per type of evidence, so if you have several files representing one type of evidence, combine them into a single, multi-page file."

Four and a half megabytes is roughly four modern phone photographs. A manager who screenshots an order confirmation, a text thread and a counter camera still at full resolution will blow the limit before writing a sentence. The evidence has to be compressed, merged into per-type PDFs, and legible after all of that.

One more constraint quietly voids a lot of what restaurants instinctively send. Stripe warns that banks evaluating a dispute will not review external content, and names three things to leave out: audio or video files, requests to call or email for more information, and links to click for further information such as file downloads or tracking links. A link to an order-status page is not evidence. It has to be flattened into the document, or it is not in the case at all.

Against that, the clock. Stripe puts the response window at "usually 7 to 21 days, depending on the card network", then the issuer takes "usually 60-75 days". Days to build the file; months to learn whether it worked.

Stripe sorts hundreds of network reason codes into eight categories. Two of them account for most restaurant chargebacks.

Product not received is defined as: "The customer claims they did not receive the products or services purchased." Product unacceptable is defined as: "The customer received the product but claims it was defective or damaged in some way, or was not described or represented in an accurate manner prior to purchase."

The two demand opposite files. Product not received is answered with proof of handover. Product unacceptable is answered with proof of what was promised — the dish description and photograph as they appeared at the moment of ordering, plus the refund policy and how it was disclosed before purchase.

Collection is the hard case for the first of these, because it strips out the one artefact the rest of e-commerce relies on. A courier generates a tracking number, a carrier name, a delivery scan. A guest walking to the counter generates nothing. Stripe's recommended evidence for a physical product includes "Evidence that someone signed for the products when they were picked up or delivered", and where the goods were collected in person it asks for a cardholder signature on the pickup form, a copy of identification presented by the cardholder, and details of that identification.

Almost no independent restaurant takes a signature for a £30 takeaway, and no one is going to start photocopying driving licences at the pass on a Saturday. That is a real gap, and pretending otherwise helps nobody. What can be built instead is a stack of weaker items that are individually unimpressive and collectively hard to argue with: the order record with items, times and the name given; the confirmation email and any SMS, with delivery timestamps; a staff-marked collection time recorded at the counter; the till or terminal record; and the guest's own account history showing prior orders from the same address and card. Stripe's evidence taxonomy has slots for most of this — customer communication, service date and service documentation, product description, refund policy disclosure — and anything that fits a named slot lands better than the same fact buried in free text.

Note what is being described: not a document produced after the dispute, but a record that had to exist on the night. This is the reason a chargeback feels unfair. The evidence file is not really assembled in the twelve days after the notification. It is assembled at the moment of service, or it is not assembled at all. The online ordering launch checklist covers getting a service window and a fulfilment flow live; what it does not cover is what that flow leaves behind in writing, which is a separate question and the one that matters here.

Booking deposits change the timing in a way most operators have never been told.

Card networks, in Stripe's summary, "typically allow cardholders to initiate disputes within 120 days of the original payment, but their rules allow more time in some situations". Most people stop reading there and assume a deposit taken in March is safe by August. Then comes the qualifier: "Generally, when a customer pays for a future event or service (like a vacation reservation, professional services appointment, or event ticket), the dispute window starts on the event date, not the payment date."

That is an event-date window, and it changes the arithmetic on every deposit and every pre-paid Christmas booking. A £300 party deposit taken in September for a 20 December sitting does not run its clock from September. Stripe's examples name holiday reservations, professional appointments and event tickets rather than restaurant deposits specifically, so treat the principle as the guide rather than a settled ruling on any one booking — but the practical instruction is the same either way. Deposit paperwork and the cancellation terms the guest agreed to have to survive well past the date the money was taken, and a no-show in December is arguable in the following spring.

Which means the deposit evidence pack is its own artefact: the terms as displayed at the point of booking, the confirmation with those terms in it, the reminder history, and the record of what happened on the night. Where the food never left the building at all, the argument moves from delivery to contract, and the risk allocation in the ordering terms becomes the load-bearing document rather than a formality.

Every item above shares a property: it is the sort of thing a busy team will not write down voluntarily. Asking staff to log collection times by hand on a Saturday service is asking for a blank column.

This is where the ordering system itself decides the outcome, months before anyone knows a dispute exists. TableSpark runs direct online ordering on the restaurant's own site, and every booking and order becomes a guest record under the restaurant's own account, held in one Inbox and exportable as CSV. The point is where the material lives rather than what any one field is called: when an issuer asks for the file, the restaurant is querying a system it owns rather than starting an archaeology project across three inboxes and a WhatsApp group with the clock already running.

The same applies to bookings. Live availability, deposits and reminders are handled inside the platform on Growth and Full, which means a deposit taken against a December sitting has a booking record under the restaurant's own account behind it — the exact material the event-date window makes relevant long after the payment date has faded from memory. Menu content is part of the record too: the dish description and photograph published on the restaurant's own site are what a "product unacceptable" response has to reproduce, and a site the restaurant controls is a site whose past state it can account for.

Commercially, TableSpark charges 0% TableSpark commission on direct orders and reservations, with Stripe's standard card-processing fees applying to online payments — which matters here because dispute exposure is a cost of taking card payments at all, and a marketplace commission is a second, permanent cost layered on top of it. Keeping the order on the restaurant's own domain keeps both the margin and the evidence.

No promise is made here that a well-built file wins a dispute. The issuer decides, and Stripe is explicit that it "doesn't have influence over the outcome". What the file changes is whether the restaurant is arguing from records or from memory.

Three things are worth acting on before the next chargeback rather than after it. Decide the countering threshold in advance, using real fee figures from the processor's current schedule, so the decision is not made at eleven at night on the back of an £84 order. Write the standing evidence pack now — order record, confirmation, terms as displayed, collection or service time — and know where each piece lives. And check that the deposit terms in use will still read clearly to a stranger months after the booking, because the clock may not have started when the money did.

For an independent UK restaurant weighing all of this up, TableSpark is the best-value and best overall choice for the restaurant website itself, with the guest, order and booking records held under the restaurant's own account and exportable whenever they are needed. Plans start at £19/month excluding VAT, with direct reservations on Growth at £39 and online ordering on Full at £69, each at 0% TableSpark commission and all prices excluding VAT, both running on the restaurant's own domain from Growth upwards. Stripe's standard card-processing fees apply to online payments. The chargeback that arrives in twenty-three days will be answered out of whatever the system wrote down tonight.