Booking & payment policies

Policies are the rules and terms attached to a booking. They all live on the Settings → Policies → General panel:

• Booking policies - the free-text terms guests see (dress code, house rules, what happens if they’re late).
• Payment policies - reusable rules for deposits, refunds and whether guests can change or cancel.
• Deposit policies and Reservation confirmation policies - reusable rules that automatically chase, and then cancel or release, a reservation the guest hasn’t paid for or confirmed in time.

Booking policies

On the General panel you set your default booking policies - plain-text terms shown to guests at the point of booking. There’s a separate policy for each flow:

Policy	Applies to
Tables	Table reservations.
Guest list	Guest-list entries.
Events	Event bookings.

Keep these clear and specific - arrival windows, dress code, minimum spend expectations, and what happens if the party changes size. They appear to guests before they confirm.

Payment policies

On the same General panel you build payment policies. Unlike the free-text booking policies, these are reusable - you name a policy once and attach it to access profiles, shifts and events wherever the same terms apply.

Each payment policy sets these things:

Setting	Options	What it means
Deposit	Hold / Capture	How the deposit is taken. Hold authorises the minimum spend on the guest’s card at booking and only charges it if needed. Capture charges the card for the minimum spend at checkout.
Refunds	None / Full / Partial %	If money is captured, how much is refundable - nothing, all of it, or a set percentage.
Modify / cancel	Any time / Never / Up to cutoff	Whether the guest can change or cancel their booking themselves, and until when. Up to cutoff ties changes to the booking window cutoff.
No-show deposits	Capture / Release	What happens to a live hold when the guest is marked a no-show. Capture (the default) charges it - a no-show forfeits the deposit.
Unconfirmed deposits	Release / Capture	What happens to a live hold when a booking is auto-cancelled for not being confirmed in time. Release (the default) returns it to the guest.

Whether a booking takes a deposit at all is set by the linked price list, not the payment policy: a deposit applies only when the price list gives the table a positive per-cover rate. A table with no price list (or a zero rate) takes no deposit, whether or not a payment policy is attached. A payment policy has no “no deposit” option - every payment policy either holds or captures. If an access profile or rule doesn’t pick one, it falls back to the venue’s Default payment policy - every venue has one, and it can’t be deleted, only edited to the terms you want.

The deposit amount itself also comes from the price list (per cover), not the policy - the policy only decides how the deposit is taken and how refunds and changes are handled.

Note

A deposit Hold authorises funds without taking them, then captures or releases them later; Capture charges the card at checkout. Your team can also capture or release a live hold from the reservations floor. The full lifecycle is covered in Deposits & card holds.

Tip

What the guest actually sees. Sidedoor never calls a hold a deposit to the guest. A Hold policy shows the guest Minimum hold £X: nothing is charged, it’s released when they arrive, and it’s only charged (as a No-show charge) if they don’t turn up or cancel late. A Capture policy shows Deposit £X: charged straight away and taken off their bill, with refundable or non-refundable wording from the Refunds setting above. When no deposit applies, they see Payment: None needed.

Deposit and confirmation policies

The General panel also holds two more reusable, named policy types that automatically chase a reservation and then act if the guest doesn’t respond. Like payment policies, you build each one once and attach it to a table access profile.

• Deposit policies - for reservations that ask for a deposit, this auto-cancels the booking if the deposit is still unpaid, warning the guest first with a fresh payment link (the reminder is always sent). Cancel unpaid deposits sets when that happens:

  • A set time before the reservation - the default.
  • A set time after the deposit is requested - for example, pay within 24 hours of the request or the table is released. The countdown starts when the deposit is requested, and re-sending the link restarts it. If that time would land on or after the reservation itself, it’s skipped - no-show handling takes over instead.
  • Both, whichever comes first - for example, within 24 hours of the request, and in any case by 48 hours before.

  The Warn the guest reminder is timed off whichever cut-off is in play: before the reservation for the first option, or before the cancellation itself for the other two - and it must always be the shorter of the two.

• Reservation confirmation policies - this asks the guest to actively confirm their reservation with a one-tap link. Turn on auto-release and it automatically releases the table if they haven’t confirmed by your deadline; leave it off and it only asks the guest to confirm, so your team decides what happens if they don’t.

Note

The Unconfirmed deposits setting on a payment policy (above) only takes effect when a confirmation policy is also attached to the same access profile. Without a confirmation policy, nothing marks a booking unconfirmed, so that hold is never auto-released.

Tip

Copy from another venue on this panel shares your payment policies and default booking terms with another venue in one action, so a group can keep them consistent. Deposit policies and confirmation policies are set up per venue.

Putting policies to work

1. Write your default booking policies for tables, guest list and events.
2. Build the payment policies you need - for example Weekend hold, no refund or Event deposit, 50% refund up to cutoff. To take no deposit on a table, leave its price list off (or set a zero per-cover rate) - a payment policy only sets how a deposit is taken, not whether one applies.
3. Attach a payment policy (and, for tables, a price list) to the relevant access profile or shift. Add a deposit or confirmation policy to the table access profile if you want unpaid or unconfirmed reservations chased automatically.

See Deposits & card holds for how holds behave end to end.