Deposits and prepaid experiences

TableStack can protect your capacity two ways: by taking a deposit or card hold on large parties, and by selling ticketed experiences that are prepaid per cover. Both run through your restaurant's own Stripe account, so the money goes straight to you.

Deposits run on your own Stripe

Deposits and holds are charged with your venue's own Stripe keys — the funds route to the restaurant, not to a platform account, and there's no separate Connect onboarding to complete. Each venue configures its own Stripe credentials. Deposits are a Pro-plan feature (trials included).

Large-party deposit policy

Each venue sets its own deposit policy, which decides when a card is asked for and how much:

• Mode — off (no deposits), charge (take an upfront deposit), or hold (keep a card on file to charge only on a no-show).
• Minimum party size — the policy only kicks in at or above this size (large parties, typically). Smaller bookings skip it entirely.
• Per-cover amount — the deposit is this amount times the number of covers. In hold mode, the same per-cover figure is the no-show fee.
• Refund window — cancellations made at least this many hours out are refunded; later cancellations forfeit.

A booking triggers the policy only when it's switched on, Stripe keys are present, the amount is above zero, and the party is big enough. When it applies, the booking page collects a card through Stripe's secure payment form, and the reservation is marked pending on the deposit until Stripe reports the money is in.

Charge vs. hold

In charge mode the guest pays a real deposit up front. In hold mode no money moves at booking — a card is saved, and you only charge the per-cover fee if the party no-shows. Choose based on how firm you want the commitment to be.

Ticketed prepaid experiences

An experience is a ticketed event — a prix-fixe night, a wine dinner, a holiday menu — offered on your public booking page within a date window, capped to a number of covers per day, and prepaid per cover.

A priced experience behaves like selling a ticket, so the confirmation rule is stricter than a normal booking:

1. A guest books the experience for their party.
2. The reservation is held Pending — it is not honored yet.
3. The guest prepays (price per cover times the party size) through Stripe.
4. Once Stripe confirms the payment, the reservation confirms itself and the confirmation email goes out.

Leaving it Pending until the money clears is deliberate: it prevents someone from booking a fixed-price seat, abandoning the card step, and walking away with a free honored ticket. Your venue's manual-confirmation setting doesn't apply here — there's nothing to vet once a paid seat is sold.

Experiences are also capacity-capped: a booking is refused if it would push that day past the experience's cover limit.

Abandoned and stuck payments

Not every diner finishes the card step in one sitting. A background sweep re-checks pending deposits against Stripe: a guest who paid but never returned to the confirmation page gets their deposit marked secured (and, for an experience, their booking confirmed), while a checkout abandoned for good is expired so it stops counting as capacity held in flight. This keeps your book honest without anyone chasing it by hand.

What this affects

• Booking confirmation — a priced experience or a card hold can keep a booking Pending until payment clears, changing when (and whether) the guest gets a confirmation. See the booking flow.
• Capacity — an experience caps covers per day, and a pending deposit holds the slot until it's secured or expired. This feeds availability.
• Guest history — a forfeited deposit or no-show fee is tied to the guest record.

What affects this

• Your venue's deposit policy (mode, minimum party, per-cover amount, refund window) and its Stripe keys.
• Your Pro-plan status — deposits are a Pro feature.
• Each experience's price, date window, and daily cover cap.