Prepaid & Ticketed Restaurant Bookings

The vertical decides the vocabulary, the questions asked at checkout, the inventory model, the door, the payout terms and the theme. This page says "seat" and "dinner" because that is what a restaurant says; a config whose primary call to action is generic ticketing wording fails validation rather than shipping.

Who this is not for. Excludes ordinary reservations, which are not ticketing. If that is closer to your operation, the vertical you want is probably a different one — all twenty are listed here.

The kitchen orders for a number nobody has committed to

A reservation is an intention and a food order is a purchase, and the gap between them is where the margin on a set menu goes. Twenty-eight confirmed covers become twenty-three on a wet Tuesday, the langoustines were bought for twenty-eight, and the five absent diners have cost nothing and lost nothing. Every defence the trade has invented for this — the card held against a table, the confirmation text, the ring-round at four o'clock — is an attempt to make an intention behave like a purchase after the fact, and none of them survives contact with a guest who simply does not answer.

What bindro does: The seat is sold, not reserved, so the commitment happens at the moment of booking rather than at the door. A cover is paid in full when it is taken, the money is held by the platform until after the night, and a guest who does not arrive has already bought the food. Covers move only under a row lock inside the transaction that confirms the order, with a database constraint behind it, so the count on your prep sheet is the count that was sold — a sitting cannot quietly go one over because two bookings landed in the same second.

A forty-cover night is not forty covers at once

Generic ticketing sells a room, and a dining room is not sold that way. Forty seats across a six o'clock and an eight-thirty is two services with two pass timings, two rounds of turning the room and two different last orders, and a platform that only understands one capacity number will happily sell thirty-two people the early sitting. The workaround everybody reaches for is publishing each sitting as its own event, which makes the same dinner look like several to a guest browsing, splits the reporting and multiplies the admin by the number of turns.

What bindro does: Ticketed dining is modelled as timed-slot inventory, which means the sitting is the unit of capacity and the dinner is the thing being sold. One listing carries as many sittings as the room turns, each with its own cover count and its own availability, and a guest picks the time on the same page they pick the menu. The day-of screen shows remaining covers per sitting while the service is running, so the pass knows what is still to come rather than what was sold this morning.

Allergy detail arrives as a forwarded email at four in the afternoon

The most consequential information a ticketed dinner collects usually reaches the kitchen last and worst. A booking platform asks one optional free-text question of the person paying, that person answers on behalf of a table of six, and what the chef receives is a note reading "one nut allergy" with no name attached to it and no idea whether it means an aversion or an ambulance. On a set menu, which is the only kind of menu this trade sells, that answer decides whether a dish can be sent at all, and it needs to arrive per guest and early enough to change the order.

What bindro does: Every guest on the booking is asked in their own name, and the follow-up opens itself when the answer needs one. Dietary requirements and access needs are per-guest fields rather than an order-level note, and a nut allergy, a shellfish allergy or anything declared as other makes a free-text description mandatory before the booking can complete — conditional logic enforced server-side in the same validation the money path runs, not a hint next to a text box. The answers are classed as health data: encrypted, excluded from analytics exports and from AI context absolutely, and anonymised in place twelve months after the dinner. Read the limit in the same breath, because it is a real one: you read those answers back on the guest — their own record, the guests list, your CSV export — and never on the service, so there is no allergy sheet for tonight and you keep your own channel to the kitchen open.

One guest drops out and the whole cover is written off

Somebody is ill, somebody is stuck, somebody booked the wrong Friday. With an ordinary reservation the seat simply empties; with a prepaid one the restaurant is left with a worse problem, because now there is money attached to the disappointment and only two answers available, both bad. Refund it and the food is bought and the seat is empty. Refuse and you have spent the goodwill of somebody who wanted to come, over a set menu they will now describe to their friends as the night they lost their money.

What bindro does: Two mechanisms sit between those answers, and neither needs an account or an app. The guest can hand the seat to somebody else from the signed link in their confirmation email: the new diner gives their own name and answers the dinner's questions themselves — their allergies, not the previous guest's, because health answers are replaced rather than inherited — and the old code stops admitting the moment the handover completes. Or you defer the booking from the orders page and the guest is emailed a credit worth what they paid, good on any future dinner at your restaurant for a year. The credit sits as a liability rather than in your balance, so the money stays in the relationship instead of leaving the building.

The pairing gets sold at the table, if it gets sold at all

The wine is where a ticketed dinner makes its margin and it is almost always the last thing decided. Sell the flight at the table and the sommelier is negotiating with six people who have already looked at the price of the ticket, the pour is being guessed at on the day, and a magnum that would have gone to a table of eight is opened for nobody. It also makes the night impossible to cost in advance: the kitchen knows its covers and the cellar knows nothing until service.

What bindro does: Add-ons are priced items attached to the booking at checkout, each carrying its own stock. A pairing flight per person, a magnum for the table, a corkage upgrade or a signed copy of the menu is chosen and paid for before the guest arrives, priced from your catalogue on the server rather than from anything the buyer's browser sends. Stock moves under the variant's own row lock inside the confirming transaction, so six pairings are sold six times and the seventh guest is told before they pay. Per-person add-ons are one of the three pricing models this vertical publishes, beside flat and tiered seat prices.

Sittings that hold their own cover count

The unit of inventory is the sitting, which is the unit the kitchen actually works in. You publish the dinner once and hang as many sittings off it as the room turns, each with the number of covers you are prepared to plate at that time, and availability is tracked and sold per sitting under a lock rather than against a single room total. What a guest sees is one dinner with times on it; what your reporting sees is one dinner with the money grouped under it.

• Covers are decremented inside the confirming transaction, under a row lock, with a database constraint behind it — the same seat cannot be sold twice.
• A sitting that fills says "Fully committed" and stops selling; there is no waitlist in this vertical, so publish another sitting if you want the overflow.
• Remaining covers per sitting are visible live on the day-of screen while service is running.
• A held seat that is not paid for is released when the hold expires, and the checkout stops rather than charging for covers that are gone.

Questions asked of every guest, not just the buyer

The booking form for ticketed dining arrives already carrying the six fields this trade needs — party size, a phone number, the dietary declaration, its conditional detail box, access requirements and the occasion — and you are not assembling it from a blank form builder. Guest-scoped fields are asked once per cover rather than once per order, which is the difference between knowing that somebody at the table cannot eat shellfish and knowing which chair.

• Conditional fields are enforced on the server in the same validation the payment path uses, so a mandatory allergy description cannot be skipped by a crafted request.
• Dietary and access answers are classified as health data on the field itself: encrypted at rest, excluded from analytics exports, never placed in AI context, anonymised twelve months on.
• The occasion field is an ordinary answer rather than a health one, so a birthday is not buried under the same handling as an allergy.
• They read back where service happens: under each guest's name on the roster, on the allergen sheet for that sitting, which lists every seat including the ones that stated nothing, and in the guest CSV — the sheet and the file owner or manager only, behind a fresh verification, every read recorded.

Gift cards that behave like money you owe

A restaurant gift card on bindro is a liability rather than a discount code, which matters the first time your accountant asks what the balance is. The purchase flow is addressed to the restaurant rather than to one dinner, so somebody can buy a chef table for a birthday without knowing which night the recipient will pick, and the code is emailed to the recipient rather than to the buyer.

• Money from a gift-card sale sits against a gift-card liability account and does not enter your balance until somebody redeems it.
• Redemption is a tender line on the order: at that moment the liability converts into your proceeds and the platform fee, against the dinner that was actually eaten.
• An expired or spent card is refused at checkout with a message on the field, not with a generic failure at the end of the payment.
• Refunding a mixed-tender order puts the gift-card leg back onto the card rather than paying it out in cash.

A door that runs off the name list, and roles that fit a dining room

Check-in for ticketed dining is a name list first and a scanner second, because that is how a maitre d' actually works the door. Front of house opens the roster on a phone, finds the booking and marks the guests in; the QR code in the confirmation email works if you would rather scan it. Both paths run the same replay logic, so first admission wins and a guest who turns up to the wrong sitting is flagged rather than quietly admitted.

• Manual check-in and QR check-in share one code path, so a mixed door cannot double-admit a seat.
• A door login sees a name and whether the booking admits — not what anyone paid, and not anyone else's bookings.
• Permission is checked in the request handler rather than by hiding a button, so knowing the URL of the payouts page gets somebody nothing.
• Check-in needs a connection: offline mode is optional for this vertical and is not enabled, so plan for signal at the host stand.

Sales tax kept apart from your money

Tax on a ticketed dinner is handled as price-exclusive US sales tax, applied server-side in the single money derivation that both the quote and the confirmation read from, itemised on the pay page, and held as a liability rather than mixed into your balance. The figure you are paid out is proceeds — a number you can bank rather than a number you still have to do subtraction on — and a refund reverses the tax tier-wise along with everything else.

• One derivation computes the quote, the charge and the confirmation, so the guest is never shown a total the ledger disagrees with.
• Tax sits in its own account and is never included in a payout figure.
• Bindro does not file returns, is not a tax adviser, and does not do inclusive VAT — that is a separate capability this vertical does not claim.

Selling from your own site, your own list and the phone

Most restaurants running ticketed nights already have the audience; what they lack is somewhere to send it that takes money properly. Every dinner gets a hosted page you can link from an email or a bio, and the same checkout embeds into the site you already run, so a supper club does not have to send its regulars somewhere unfamiliar to buy. Bookings taken over the phone go through the console and down the same money path as the website.

• Promo codes cover the members' night and the friends-of-the-house discount without needing a membership roster, which this vertical does not check against.
• Comped seats consume a cover and admit at the door but write no revenue lines, so a critic's table does not distort your average spend.
• A back-office order keyed by your team uses the same validated form and the same locks as a public booking.
• An order recorded as paid outside the platform has no card charge behind it and therefore cannot be refunded through bindro — money that came in through your terminal goes back out through your terminal.

Who pays the booking fee?

The guest, unless you say otherwise. Every dinner carries its own setting — the guest pays, you absorb it, or you split it — and the fee itself does not change with the choice, only which side of the sale it comes from. On a ten-seat $25.00 dinner that is $16.20 either added to what guests pay or taken out of what you keep.

Because the default is the guest, a restaurant can go from signing up to a sold-out dinner without paying bindro anything up front, at any point, ever. We are paid out of sales that happened or we are not paid.

The word "event" is load-bearing and worth reading twice. The scheduler groups by dinner, admits one only once its LAST session has ended, and pays it once. A dinner sold as a run of dates therefore pays after the final date, not after each one — a season's float is not something an operator should discover halfway through the season.

Bindro never pays before delivery, in any vertical. A pre-event advance is a configuration violation platform-wide rather than a policy someone can be talked out of, because paying out on dinners that have not happened is exactly how a cancellation becomes guests with no refund. "Paid" also means the money moved: a payout only reaches its paid state with a real transfer reference attached, enforced by the database rather than by a status field someone can set.

• One payout per dinner, after its last session ends, one in flight at a time.
• T+2 for this vertical (low risk tier), no reserve.
• Refunds reverse in a fixed order — your proceeds first, then tax, then our fee — so a refund never leaves you charged for a sale that was undone.
• Sales tax, where it applies, is held as a liability rather than mixed into your balance, so the payout figure is proceeds rather than a number you still have to do subtraction on.

The reason this number rather than revenue is that a set menu is bought before it is sold. Food cost is committed days ahead against a cover count, so a sitting running at four fifths is not four fifths of a good night — it is a good night with the margin removed. Prepayment is what turns the figure from an estimate into a fact early enough to act on: by the time you place the order, the covers are sold and the money is taken, and the decision about whether to open the second sitting is being made on a number rather than on a feeling about the weather.

The no-show rate beside it is computed from the two figures the console does hold: seats sold against guests marked in, per sitting, per dinner. It is worth watching even though every absent guest has already paid, because a sitting with four regular no-shows is a sitting whose time is wrong, and because your own service planning is easier when you know that the eight-thirty runs at nine tenths and the six o'clock runs full.

The other two figures this vertical is configured around are both reported, and both say what they counted. The deposit forfeit rate is deposits kept against deposits taken on a plan — an em-dash with a reason while you have taken none, never a zero, because a zero would read as a measurement. The menu-change refund rate counts refunds AMONG THE DINERS WHO WERE TOLD a menu changed, which is why the notice is recorded as a row at the moment it is sent: refunds that merely happened after a menu changed would climb every time an unrelated guest cancelled.

Everything underneath is exportable. Orders and guests come out as CSV behind a fresh verification step, with repeat diners tracked across dinners so lifetime spend and attendance for one address are visible. The guest export carries the dietary and access answers, because they are yours and a pass you cannot staff from your own export is not much of an export — which is exactly why it needs that verification step and why every download is recorded against your name. What health-class data never reaches is the analytics surfaces and the assistant's context: excluded absolutely, in every vertical, with no override.

What the console shows today, without an integration or a spreadsheet:

• Gross, platform fees and refunds per dinner, read from the ledger the payouts reconcile against.
• Seats sold against guests checked in, with a no-show percentage per session.
• Live remaining capacity while the dinner is running, per pool, on the day-of screen.
• This restaurant's own funnel — view → sitting selected → dietary captured → paid → attended — stage by stage with the drop-off between them, and any step the platform cannot see said so rather than shown as a zero.
• Refunds, transfers, turnout, no-shows, add-on attach and repeat buyers, each printed with the two numbers it was divided from.
• Orders and guests as CSV, so anything not on the screen is one export away.

Two more that are worth stating plainly. Sensitive answers are classified on the field rather than by convention, and health data is excluded from analytics exports and from AI context absolutely, with no override in any vertical. And a restaurant's own people see only what their role allows — a door login sees a name and whether the code admits, not what anyone paid — which is checked in the handler rather than by hiding a button.

• Collecting the balance of a payment plan automatically — you can publish a deposit plan and the deposit is taken at checkout, but bindro does not charge the stored card for the rest of it. Off-session charging is armed by a separate switch that is set in no environment, on purpose: a checkout happens with the diner watching and a sweep bills with nobody present. Take the balance the way you take any other payment.
• A second allergy channel — the per-service allergen sheet lists every seat on a sitting with what each guest stated, including the ones who stated nothing, and the guest export carries the same answers. What bindro does not do is chase a guest who left the question blank, or replace the question asked again at the table.
• Replacing your reservation book — there is no table map, no floor plan, no walk-in seating and no cover-flow management. Bindro sells admission to a ticketed service; ordinary reservations are explicitly out of scope for this vertical.
• A waitlist when a sitting is fully committed — a waiting list is not enabled for ticketed dining, so a full sitting is full and the page says so rather than collecting addresses nobody calls back.
• Supper-club memberships and subscriptions — recurring revenue is not attached to a dinner, and payouts settle per delivered event, so the engine could take a monthly payment and have nothing to release it against. It is off on purpose.
• Member and non-member seat prices checked against a roster, and automatic group rates for a table of ten — both are optional for this vertical and neither is enabled.
• Charging a no-show after the night — nobody has their card billed for not turning up. What you can do is keep money already taken: a deposit on a payment plan can be forfeited once the service has been delivered and nobody on the booking checked in, and your published cancellation terms can keep a stated share of a late cancellation automatically. No new charge is ever raised against a card that is not present.
• Check-in with no connection, and a till at the door — offline check-in and counter sales are optional for ticketed dining and are not turned on, so the door needs a signal and a walk-up cannot be sold on the night through bindro.
• VAT and non-US tax — sales tax here is price-exclusive US sales tax; VAT is a separate capability that this vertical does not claim, and onboarding offers the United States.

If one of those is the thing you need, say so — the answer is a capability declared, built and gated properly, or a straight no. It is never a feature flag that collects the request and does nothing.

The instinct to publish each sitting as its own event is worth resisting. It works, and it costs you the two things the model is for: a guest browsing sees three listings for one night and has to work out that they are the same food, and the reporting splits the dinner into pieces that have to be added back together before the night means anything. A dinner with sittings underneath it is one listing, one set of numbers and one payout.

Where a run of nights is concerned the grouping has a cash-flow consequence and it is better known now than in week three. A payout is released per dinner, two days after that dinner's last sitting has ended, so a fortnight of supper clubs published as one dinner with fourteen sittings pays once at the end of the fortnight. Published as fourteen dinners, each pays two days after its own night. Neither is wrong; the second is what you want if the ingredients for Thursday are bought with the money from Tuesday.

On price, the three models this vertical can actually take money with are flat, tiered and per-person add-ons, and the honest use of tiers here is narrow. A chef's counter at one price and the dining room at another is a real tier; an early-bird on a forty-cover supper club mostly discounts the people who were always coming. Verified member pricing and automatic group rates are not enabled for ticketed dining, so a members' night is a dinner with a promo code and a table of ten is ten covers.

• One dinner, one sitting per turn, cover count set by the pass rather than by the floor plan.
• Publish each night separately when you want the money from each night separately.
• Flat, tiered and per-person add-on pricing are what the checkout will honour here.
• Promo codes, not membership checks, are how a regulars' rate is done in this vertical.

The practical shape of that split is simple. Your reservation system owns the nights you are open à la carte, the tables, the walk-ins and the people who ring up. Bindro owns the nights where a fixed number of people eat a fixed menu at a fixed time and have paid for it: the collaboration dinner, the wine maker's table, the twelve seats at the counter on a Monday when the room is otherwise dark.

Nothing about that arrangement requires your guests to notice. The checkout embeds into the site you already run, so the ticketed nights sit on your own events page rather than on somebody else's marketplace, and the hosted page exists for the link you paste into an email or a bio. The confirmation carries the guest's code and a signed link they can use to hand the seat on or refund it under your policy, with no account to create and no application to install.

The thing to plan around is the pass. Bindro does read the dietary and access answers back: the roster prints what each guest stated under their name for anyone with the grant to read guests, the guest CSV carries the same columns, and the dietary answers are also returned on the allergen sheet for that sitting, which lists every seat including the ones that stated nothing. But the sheet is health data about named people, so it asks for a fresh verification every time it is opened and records the read against your name. That is not a thing to be doing between two tables at seven o'clock. Print it before service, alongside whatever pass paperwork you already run, and still ask the question at the table: what bindro has is what somebody typed at booking, which is a record rather than a substitute for the exchange that keeps them safe.

That single invariant is what makes a generous cancellation policy affordable. A guest who cries off two weeks out can be refunded in full without you being out of pocket at any point, because nothing has been released to you yet — and the refund reverses in a fixed order, your proceeds first, then tax, then the platform fee, so you are never left carrying the cost of a sale that was undone. Where your policy allows it the guest can do this themselves from the link in their confirmation, and where it does not, you can still refund or defer from the console.

A cancelled sitting also stops admitting, which sounds obvious and is the failure that ruins the evening when a platform gets it wrong. Nobody arrives at a dark room holding a code that still scans green, and the day-of screen and the door list agree with each other because they read the same state.

On the rare occasion a guest disputes a charge, the chargeback is handled as a money movement in the ledger rather than as an email, and the evidence a card network wants — what was sold, when it was bought, whether the code admitted at the door and when — is exactly what a prepaid ticketed dinner records as a matter of course. The check-in mark on a disputed booking is the strongest artefact in that file and you get it for free by working the door on the roster.

The allergy one carries the most weight, so it is worth being exact. Both halves now exist: asked per guest with mandatory detail where a bare answer would be useless, validated on the money path, held as health data — and returned on a per-service allergen sheet that lists every seat including the silent ones, behind a fresh verification and an audit row. What bindro cannot do is make a guest answer, or notice that the person who typed nothing has a severe allergy. Ask again at the table.

On deposits, the summary a restaurant needs is short. You can publish a plan — the deposit as a share of the price, the number of charges and their spacing, on the seat type — and the deposit is taken at checkout against a stored card. What we do not do is take the rest of it automatically: that switch is set in no environment, because a sweep bills with nobody watching. Part-paid money is held off your balance until the last charge clears, so a payout can never pay you for a dinner somebody is halfway through paying for, and an unclaimed deposit can be forfeited after the night.

The rest are boundaries rather than gaps. There is no waiting list when a sitting fills, so the page says so and you publish another sitting; the door needs a signal, because offline check-in is not enabled here; nobody is billed for not turning up, because bindro has no no-show charge and the card a deposit plan stores is chargeable only for that plan's own parts; and a walk-up cannot be sold at the door through bindro, because a till at the door is not part of this vertical either.