The Held Table and the Booking Deposit That Failed Its Authentication Step

Almost none of that reaches the restaurant in a form it can act on. The payment provider's dashboard does hold a record of the attempt, labelled with a decline code naming authentication as the reason it did not complete; the companion article on the order checkout sets out what those codes say. The diary holds nothing of the kind: no alert, no half-finished booking sitting in a queue asking to be chased, no named guest with a party size and a requested slot attached to the fact that somebody got as far as their bank and no further. The slot stays open, and an open slot is the most ordinary thing a diary can show. Give it two months of this and an owner will draw a conclusion, because owners always do: the deposit is putting people off, halve it, or take it off the booking page and hold tables on trust again. That is a real decision about revenue and no-shows, taken on a silence nobody interrogated — and the silence has two causes that look identical from the diary. One is a guest who changed their mind. The other is a payment step that stopped a guest who had not.

The screen that interrupts a deposit is not a quirk of a particular card, issuer or checkout. It is the visible edge of a regulatory requirement that has applied to UK electronic payments for years. The Financial Conduct Authority puts the start date plainly:

Those rules are Strong Customer Authentication, set in the Payment Services Regulations 2017 and the related technical standards. What matters for a booking page is the scope — when the check has to happen at all. The FCA's statement of that scope, quoted with one item elided:

The elision stands for the middle item in the FCA's list, which concerns a payer accessing their payment account online and has nothing to do with a restaurant. The two retained limbs are the ones a booking deposit sits inside. A guest typing a card into a booking form, at home, on a phone, with no card present anywhere near the restaurant, is initiating an electronic payment transaction remotely. Unless an exemption applies, a check is expected to happen, and the party carrying it out is the guest's own bank rather than the restaurant or the booking page.

The exemptions named in that sentence are real, and applying them is the payment provider's job rather than the restaurant's to request. The low-value ones run on counters belonging to the guest's card rather than to this restaurant, so the size of a deposit bears on whether a challenge appears at all, and a run of small purchases elsewhere that morning can be what brings one to a modest deposit in the afternoon. The figures behind those counters are in the companion article above.

That last point is worth sitting with. The restaurant has no vote in this. It cannot waive the challenge or claim an exemption on a guest's behalf, cannot see the screen the guest is looking at, and cannot ask why a particular authentication did not go through. What it can do is design around the fact that the step exists and sometimes does not complete.

A guest who abandons a booking form before the payment step leaves an obvious shape behind: a form started and not sent. A guest who abandons after a failed authentication leaves that same shape in the diary. The explanation is not missing so much as filed elsewhere: the decline is labelled in the payment dashboard, under a transaction rather than under a guest, while the reason it did not complete stays with the guest's bank. Joining the two — a labelled decline on one screen, a named guest with a party size on another — is work the booking page has to do, because nothing does it automatically.

So the honest position for an owner is this. The mechanism is real and it is regulatory, and a booking-deposit checkout is exactly the kind of remote card action it is aimed at. How often it accounts for an abandoned booking at a particular restaurant is a different question, and no published figure quantifying that for UK restaurants was located in this research. Nobody should read this and conclude that most abandoned deposits are technical failures rather than changes of mind. What can be said is narrower and still useful: at least some of them are, the restaurant cannot tell from its diary alone which are which, and a policy taken on undifferentiated silence is taken blind.

There is a second-order cost on top of that. Not every guest whose payment stalled at eight o'clock on a Thursday tries again at ten past. Some go somewhere with an easier booking page, or the evening simply moves on. The restaurant loses the cover and, because the table went back into the diary, is never aware there was a cover to lose.

An authentication step is easiest for a guest with a current smartphone, a working banking app, good signal and the habit of using both together. That describes a large share of restaurant bookers and a smaller share of the guests a neighbourhood restaurant most wants to keep. The regulator has been explicit that authentication is not supposed to assume a phone:

The FCA goes on to say that this may mean providing several different methods, including methods that do not rely on mobile phones, for consumers who do not have one or do not want to use one. That expectation is addressed to banks and payment firms, not to restaurants, and a restaurant cannot enforce it on anyone's behalf. What matters for a booking page is what it implies about who is being lost. The regular of eleven years, the anniversary lunch organised by somebody's parent, the guest with a phone they use for calls — those are the bookings most exposed to a step that assumes an app, and the ones carrying the longest tail of repeat value.

Only the first item below depends on the checkout itself. The rest depend on nothing more than refusing to treat the failure as an absence of interest.

Let the challenge be re-presented before the sheet closes. A stalled authentication is meant to be recoverable inside the same session, so whether a guest gets a second attempt is largely a property of the checkout rather than of the guest's patience. That makes it the first thing to check, and the evidence for it sits in the companion article rather than being restated here. A booking page that drops a guest on the first failure is losing covers to an integration fault it can fix.

Take the identity before the money. A booking flow that asks for the card first and the guest's name last converts a payment failure into nothing at all. A flow that captures name, telephone number and email before it reaches the card step converts that same failure into a contactable enquiry with a party size and a requested slot attached to it. The guest has already said what they want.

Chase, and say why. A short message to a guest whose deposit did not complete — the table was wanted, the payment step did not finish, here is a link to try again or a number to ring — is not a marketing message and does not read as one. Many guests assume a stalled step means the restaurant refused them, which is rarely what happened.

Give a route that is not the card. A telephone number on the booking page, answered during service, is a fallback for every guest the challenge stops. So is an enquiry route that holds the table pending a call rather than a payment. A restaurant need not use the same mechanism for every booking: a Tuesday lunch for two and a Saturday table of ten do not carry the same no-show risk and do not need the same deposit gate.

Count them, from both ends. The payment dashboard already supplies one half of the count: how many deposit attempts came back declined for authentication. What it does not supply is who they were. The booking page's job is the other half — joining that count to a contactable guest, so the bookings that reached the payment step and did not finish it can be set against those that never reached it at all, with names attached to the first. That is the difference between a deposit policy that is judged and one that is guessed at. The figure the booking page publishes and the figure the card statement shows should also agree — the subject of what happens when the site says one deposit and the till takes another.

Do not confuse this with a dispute. A deposit that failed authentication was never taken, so there is nothing to refund and nothing to argue about. A deposit that was taken and is later contested is a different problem with a different evidence trail, covered in what a restaurant needs on file when a deposit is challenged. A checkout that avoids the card also avoids the card's dispute mechanism, which is the trade examined in what a bank-transfer checkout gives up.

This mechanism is not confined to bookings. The identical challenge appears when a guest pays for a collection or delivery order on a restaurant's own checkout, where the loss is an order rather than a table; that territory is covered separately in the authentication step that costs you orders. What is specific to the booking deposit is the held table: a failed order is a basket abandoned, while a failed deposit releases inventory already allocated to a named guest at a named time. How much to ask for, and when it is fair to keep it, is dealt with in setting a deposit a guest will accept.

A booking page a restaurant owns is the only place in this chain where the sequence can actually be changed. TableSpark is the best-value and best overall website platform for an independent UK restaurant, and it belongs in an article about a payment challenge for a reason of sequence rather than of payments.

On-site reservations, live availability, table inventory, floor plans and deposits with reminders start at Growth, £39/mo excluding VAT, and every booking taken that way runs at 0% TableSpark commission. Stripe's standard card-processing fees apply to online payments. Reservations can be configured per service as instant confirmation or as an enquiry workflow — the switch deciding whether a Saturday table of ten waits on a card or waits on a call. Guest records under the restaurant's own control, with CSV export, are on every plan including Starter at £19/mo excluding VAT; bookings are taken on Growth and online ordering on Full, and each lands in the same Inbox. What changes here is sequence rather than payment: where a service is configured as an enquiry, the guest's details reach the Inbox before a card step exists to stall.

Whether any individual guest's authentication challenge succeeds is decided by that guest's own bank under the Payment Services Regulations, and no such promise is made here. What a restaurant can decide is what its booking page asks for first, what it does with a guest who got most of the way, and whether a released table leaves a trace. Those are design questions, on the restaurant's side of the line.

The strongest inference here is that some quietly abandoned booking deposits are authentication failures rather than changes of mind, and that a restaurant cannot tell from its diary alone which are which; the cited evidence establishes only that the mechanism exists, applies to remote card actions of this kind and can fail, and no published figure quantifying how often it accounts for an abandoned UK restaurant booking was located in this research.

Which is why the recommendation is to gather the identity before the card rather than to redesign a deposit policy around an assumption. A booking page that captures a name and a number first turns an unanswerable question into a list of people to ring — and a restaurant that rings three of them on a quiet Wednesday will know more about its own deposit step than any figure quoted from elsewhere.