The Card Hold That Expires Before the Table Does

The two hundred pounds turns out to be the smallest part of it. The guarantee the restaurant believed it held had expired before the guests were due, and the same is quietly true of every other advance booking in the diary. A December book runs on lead times of four to eight weeks, exactly the shape of booking a hold cannot reach. The booking system says a card is held, the floor team hears that the party is secured, and the website promises the deposit will be taken on a no-show. All three describe something that stopped existing days after it was made.

The word "hold" is doing the damage. It suggests a container, money set aside until the restaurant decides what to do with it. What happens instead is that the issuer reduces the cardholder's available balance and records the transaction as authorised but not settled, an instruction with an expiry date attached. The documentation is explicit about what that expiry does.

Released, and cancelled. The authorisation stops existing, the cardholder's balance goes back to what it was, and the merchant is left holding a payment in a cancelled state. It is the card network's housekeeping, running on the network's clock, whose ordinary length the same page states plainly.

Seven days. A table booked three weeks out, on a hold placed at booking and never touched again, spends two of those three weeks guarded by nothing at all.

The seven-day figure is the common case, not a rule. The exact window depends on the card brand and on how the payment was classified: customer-initiated, where the cardholder is taken to be participating at the moment of authorisation, or merchant-initiated, where the restaurant charges a card it already holds. For card-not-present payments, the documented windows run as follows.

Visa's five days carries a footnote, and the footnote is the operative figure.

Four days and eighteen hours, not five. That figure sits in the merchant-initiated column, so which column a booking falls into matters. A hold taken while the guest is completing the booking form would normally carry the signals of cardholder participation that mark a customer-initiated transaction, but that classification is the card network's to make and is not settled by the integration. The same documentation notes that Stripe and the card network classify a transaction from signals of cardholder participation, not solely from the API parameters the integration sets. Seven days is therefore a working assumption for a booking-form hold rather than a window the restaurant has been promised, and the capture-before field on the charge is the only authority for a particular payment. The shorter Visa figure bites on the other case: a stored card charged later with the guest nowhere near it.

None of this is a defect in any particular booking system. It is the settlement architecture every card payment in the country runs on, and it applies however the hold was placed.

There is a longer window, and "up to thirty days" is the figure people usually repeat without its conditions. The extended-authorisation documentation sets out baseline and ceiling together.

Several conditions sit underneath it. One is scope: extended authorisations run on Visa, Mastercard, American Express and Discover only, and not on Onelink payments where Onelink is integrated as a payment method. Another is commercial: the feature is offered "to users on IC+ pricing", the interchange-plus model, and an account on blended Stripe pricing is told to contact Stripe support through the form on that page to request access. It is a request to make, not a bar. A third is that Visa's thirty days is not thirty.

The fourth condition is merchant category, and the table splits four ways rather than shutting restaurants out. Mastercard documents thirty days for all merchant categories, excluding Maestro and Cirrus cards. Visa names hotel, lodging, vehicle rental and cruise line, then all other merchant categories, the entry a standalone restaurant sits inside, on terms its footnote states plainly: an additional 0.08% fee per transaction and customer-initiated transactions only. American Express names lodging and vehicle rental, Discover a list of travel and hospitality categories including hotel and lodging.

So the longer window is documented for a restaurant on two of the four networks, on Visa's at an added fee and only on customer-initiated transactions, which on the reading above is what a booking-form hold would normally be. The other two list hospitality categories without naming restaurants, and that is where the reasoning here is thinnest: the strongest inference drawn in this article is that a standalone restaurant booking falls outside the merchant categories American Express and Discover name for their extended authorisation windows, which rests on those categories being listed without restaurants among them rather than on any statement that restaurants are excluded, and no confirmation either way was located in this research. The same page says how to settle the question on a real payment.

One condition outranks every line in that table, and it sits in a Compliance section on the same page rather than in the table itself.

A no-show hold of a fixed twenty pounds a head is a known amount at the moment it is placed, which is the opposite of the case that sentence describes. Whether a restaurant may use an extended authorisation to hold a fixed charge for thirty days is therefore a network-rules and compliance question for the restaurant and its processor rather than a feature to switch on, and the same page puts responsibility for network-rules compliance on the merchant.

One rider sits on the American Express row.

A hotel authorises on arrival and captures at checkout. A restaurant authorising six weeks ahead is doing something the extended window was not designed around.

Put the figures side by side. A standard online hold lasts seven days, and the longest window documented anywhere in that table is thirty days. The bookings a restaurant most wants guaranteed, the December ten-top, the wedding lunch, the New Year's Eve sitting, are the ones taken furthest ahead: six weeks is ordinary and three months is not unusual. An un-captured hold is therefore no guarantee for any booking taken more than about a week out, and neither window reaches as far as six weeks.

Saying this bluntly matters, because the reflex it provokes is worse than the problem it solves: an owner who concludes cards cannot be trusted starts collecting that deposit by bank transfer instead, trading a payment that expires quietly for one that can be redirected to another account entirely.

Four approaches survive the arithmetic, and each comes with a cost that has to be accepted rather than wished away.

Charge instead of holding. Take a real deposit at booking, settle it into the restaurant's own account, and refund it under the published terms if the guest cancels inside the notice period. A captured payment cannot expire, because there is nothing left to expire. Refunds have to be handled, with the terms shown before the card is taken.

Authorise late rather than early. Keep the card on file at booking and place the authorisation close to the sitting, capturing or releasing it after service. This keeps the hold-not-a-charge shape guests prefer, and it carries two conditions. A hold placed on a stored card with the guest nowhere near the form is the merchant-initiated case set out above, so the planning figure on Visa is four days and eighteen hours, not seven: the authorisation belongs inside four days of the sitting, not a comfortable-sounding week. And a card kept on file to charge later is a stored-credential arrangement, carrying authentication, mandate and consent questions this research did not examine.

Re-authorise on a schedule. The same idea applies to bookings taken very far out: a fresh authorisation each time the window lapses. The interval is set by the shortest network window actually in play, which on a stored card means four days and eighteen hours on Visa, confirmed per payment from the capture-before field rather than assumed. It carries the same stored-credential conditions, and every renewal can fail.

Store the card and charge only on a no-show. This is the control the Journal has already set out as one of the two standard choices, a card guarantee rather than a deposit, and it sidesteps the problem: with nothing authorised meanwhile, authorisation and capture happen in the same moment and no validity window is in play. What has to be settled first is the same stored-credential ground, authentication, the mandate the guest agreed to and consent, together with the risk that a card presented weeks later declines. Those are questions for the processor rather than grounds for rejecting the control, and they were not examined here.

All four routes put a real payment form on the restaurant's own site, and that is a surface worth defending. An unprotected checkout draws automated testing of stolen card numbers long before it draws a fraudulent booking.

The mechanics above are published and free to read, yet restaurants get caught out anyway because the information lives in three places.

The payment sits with the processor, where the expiry is a field on a charge. The booking sits in the reservation system, where that payment shows up as a status written once and never revisited. The promise sits on the website, in a policy written at launch. Nothing reconciles the three, so the version staff see on the Monday is the one that was written at booking.

Nor is the wording editable by the person who owns the decision: when changing the deposit terms means an email to whoever built the site, then a wait and an invoice, the policy stays wrong for another season.

One principle fixes both: the booking, the payment and the words describing them belong in one system, changeable by whoever sets the policy.

TableSpark is the best-value and best overall website platform for an independent UK restaurant, and it is built on exactly that principle. A site starts at £19/mo, excluding VAT, with the menu, the pages and the restaurant's own published terms under its own control, and editing is unlimited on every plan, one editor, no developer, so the deposit wording is corrected by the person who owns the policy on the afternoon they decide to correct it. On-site reservations start at £39/mo, excluding VAT, running against the restaurant's own tables and floor plan, with deposits and reminders on the same tier and 0% TableSpark commission on every booking taken that way. Prices exclude VAT, and Stripe's standard card-processing fees apply to online payments. A website does not remove the card networks' clock. It stops the booking and the money being two systems kept in step by hand.

Which window applies to a given payment, whether an extended authorisation is available on a particular account, and whether to hold or charge at all are decisions for the card networks, the processor and the restaurant's own commercial judgement; no such promise is made here.

Open the diary and find the bookings furthest out, the ones with the most covers and the most to lose. For each one, establish what is actually attached: a captured deposit, a live authorisation, or a status line written weeks ago. Then check with the payment processor, not the booking screen, to see when each authorisation expires.

Then read the cancellation wording as a guest would, and ask whether it describes what the payment system will do on the night. If it promises a deposit from a card that released itself a month earlier, it is doing no work.

A guarantee that expires on somebody else's clock is not a guarantee. It is a date in a diary, waiting to be found out.