Changing a booking: transfers, deferrals and the night a service is cancelled

Can a guest hand their seat to somebody else?

Yes, and it is the option most restaurants forget they have. From the link in their confirmation email the guest picks the seat, names the new holder and gives their address; the new holder answers the dinner's own per-guest questions themselves, so their dietary answers replace rather than inherit the previous ones. The new code is emailed to them, and the old one stops admitting in the same transaction — on the door list and on the scan.

Nothing about the money moves: the order stays paid for the same amount, no cover is released or taken, and the ledger is untouched. A seat that has already checked in, been refunded, or sits on a cancelled sitting cannot be handed on, and the previous holder is told the handover happened without being sent the new code.

How do I move a guest to another night?

From the orders page, as a deferral, which issues a credit rather than changing a date. The guest is emailed a code worth what they paid, spendable on any future dinner at your restaurant for a year. The value comes off your balance and sits as a liability until it is redeemed, which is the point: you are never paid out for a dinner nobody has eaten, and the guest's money is genuinely still theirs.

Two limits shape how you use it. Only the restaurant can start a deferral — there is no self-service move button, deliberately, because the alternative is guests reshuffling a sold-out sitting between themselves. And the seat they left stays counted against the original sitting, so if you want to resell it, raise that sitting's cover count by one.

• Deferral is restaurant-initiated, from the orders page, beside the refund action.
• The credit is worth the whole booking and lasts a year.
• The original seat is not returned to sale automatically.
• A deferred booking stops admitting, so the old code will not get anyone in.

What happens to the money when a refund is issued?

It reverses in a fixed order — your proceeds first, then tax, then the platform fee — so the ledger never ends up unbalanced and you are not left carrying a fee for a sale that was undone. A guest can refund themselves from the signed link in their email where you allow it and the sitting has not started; you can refund from the console at any point.

One case behaves differently and it is worth knowing before you use it: an order keyed in the back office as paid outside the platform has no card charge behind it, so there is nothing for bindro to reverse and the refund is refused honestly. Money taken on your own terminal goes back through your own terminal.

What happens when the restaurant cancels a service?

The sitting stops admitting and the guests are refunded — and crucially the money is still with the platform to do it with. Bindro releases funds two days after the dinner has actually happened, and pre-event advances are forbidden in every vertical, so a cancelled service is a refund rather than a conversation with somebody who has already spent the takings.

If the night is being moved rather than abandoned, deferral is usually the kinder instrument: a credit for everyone, and a re-launch of the dinner on the new date. It keeps the money in the relationship instead of paying it back and hoping people rebook.

Who can start each of these, and what does the guest see?

Handover and self-refund belong to the guest, from the signed link in their confirmation email — no account, no app, and it works with scripting off. Deferral and organiser-side refunds belong to you, under the same permission as a refund, because they move the same money; both are audit-logged with who did it. Whatever happens, the guest is emailed: a new code, a credit code, or a refund confirmation.