How do pay-in-full bookings work?

Charge the full price when customers book — per person or per booking — on What guests pay; set the amount, days and times and dates, and see how refunds and changes work.

Pay-in-full is a third payment mode alongside "no payment" and "deposit": customers pay the full price by card when they book online, instead of a smaller deposit — per person, or one price for the whole booking. It suits tasting menus, big nights and other prepaid services. Set it up in the Pay in full section of Settings → Payments and deposits → What guests pay.

It's Available on Pro plan and above, needs Stripe connected (connecting is owner-only), and only Owners and Admins can open the page. The money goes straight to your own Stripe account — ResoFlow charges no platform fee on pay-in-full bookings (Stripe's normal processing fee still applies).

Switching it on

• Go to Settings → Payments and deposits → What guests pay and find the Pay in full section.
• Switch on Require full payment. A pop-up explains that customers will pay the full price when they book and that a payment and refund clause is added to the terms they agree to — click Turn on.
• Set the amount, and whether it's Per person (the default — charged for every guest, e.g. 4 guests × £30 = £120) or Per booking (one price for the whole booking, whatever the party size, e.g. £120 for the table). The row is called Amount per person or Amount per booking to match. The page warns you if it's left at £0.
• Set the Minimum party size — full payment is only required for parties this size or larger (set it to 1 to charge on every booking). Below the threshold, your normal deposit settings (if any) apply instead.
• Click Save changes.

One payment per booking: "Pay in full beats a deposit; a deposit beats a card to hold." (Only dishes paid for while booking come before it.) Where pay-in-full applies it takes priority — the same booking is never also asked for a deposit or to save a card for no-show protection. If you also offer pre-orders, a party that chooses its dishes while booking pays for them instead of a full payment; a party that books without choosing dishes pays in full, and that payment counts towards the dishes they choose later, so nobody pays twice.

Where it applies: online — your booking page and website widget. When a booking your team adds needs a full payment, you're offered a payment link to send. Walk-ins and the waitlist are never asked to pay.

Different amounts for bigger parties

Switch on Tiered amounts by party size to charge different prices by party-size range (e.g. parties of 2 → £30pp, parties of 6+ → £25pp) — they follow your per person or per booking choice. Tiered rules override the standard amount, and a party size no rule covers pays nothing — the page warns you about gaps and overlaps from your Minimum party size upwards (where ranges overlap, the first matching rule wins). The Minimum party size still gates everything: sizes below it never pay in full, whatever the tiers say.

Only on certain days, times or dates

• When it applies — in Pay in full: when it applies, under Day and time rules, click Add day/time rule to restrict full payment to specific days and times (e.g. weekend evenings). When any rule is set, full payment is only required at those times; outside the rules, your normal deposit settings (if any) apply instead. The page spells out the model: "Require full payment" applies every day; day and time rules restrict it; special dates always apply — even when the switch is off. (Deposits and pre-orders follow exactly the same model.)
• Dates of their own — a date like New Year's Eve gets its own full payment on Settings → Bookings → Special dates: open the date and set its Pay in full to Custom, with its own price (following your per person or per booking choice) and, if you like, a party size it starts from. Pay in full: dates of their own then lists them under Special pay-in-full dates, with a link there. A date's own full payment applies even if "Require full payment" is switched off, and it overrides your deposit settings on that date.

Refunds and cancellations

Pay-in-full refunds follow the same cancellation policy as deposits — one policy for all booking payments, set in Cancellations and refunds on the same page (the Refunds and cancellations row in the Pay in full section links there). The one exception: when a party paying in full per person gets smaller, the difference is always refunded, whatever the policy. If the booking is moved, the refund deadline counts back from whichever is earlier — the time that was paid for or the new time — so a move can never stretch it; the page says so beside Refunds and cancellations. See When do customers get their deposit back? — everything there (the deadline, full/partial/no-refund choices, and the staff Refund/Retain dialog) applies to pay-in-full bookings too, with the dialog wording saying "payment" instead of "deposit". A clear refund window (full or partial refund up to a deadline) is strongly recommended over "No refunds" — blanket non-refundable advance payments sit badly with UK consumer-protection guidance and invite card disputes.

If a customer doesn't turn up, you keep the payment — that's the point of prepayment. The no-show fee never applies to a paid-in-full booking, and the "deposit retained" email to the customer says "payment" instead.

What the customer sees

The booking page tells the customer up front — "This booking is paid in full when you book — £X per person" (or "£X for the booking") — and the payment step is headed Full Payment with a Total to Pay amount (Apple Pay and Google Pay work too). Their confirmation shows Paid in Full, and the manage-booking page shows a Paid in Full badge. On your side, a paid-in-full booking's money chip on the Bookings list, Home and the customer profile reads PAID £X — so you can tell it from an ordinary deposit's plain £X at a glance. If you've entered your VAT number on Settings → Payouts and Stripe, the confirmation email also shows the VAT included in the meal payment (at the standard 20% rate) and your VAT number, so it doubles as a simple VAT receipt — venues without a VAT number set never show VAT, and deposits never do.

When the party size changes

Customers changing their own booking online are settled automatically at the booking's own per-person price: reducing the party refunds the difference to the customer automatically, and increasing it takes an online top-up payment before the increase is confirmed (if the table is really gone in the meantime, the top-up is refunded automatically). Nothing settles automatically once the party has been seated. A booking paid per booking moves no money when its party changes — the payment was for the booking as a whole.

When your team resizes a paid-in-full booking, no money ever moves automatically — a note appears telling you what to do: refund the difference from the booking's payment section, or send a payment link for the extra amount.

Loyalty

If you run a spend-based loyalty scheme, you can let full prepayments earn points like event tickets do — the Paid-in-full bookings earn points toggle is on the More options step of the loyalty scheme set-up (Loyalty page → Edit scheme) and it's off by default. A customer's own online prepayment earns when they signed in on the booking page (the quick email code — a device that's already signed in needs no code); a paid-in-full booking your team adds with the customer's email typed in earns without any sign-in. See How do I set up a loyalty scheme?

Related: How do I take booking deposits? · When do customers get their deposit back? · How do payment links work? · How do I sell extras with bookings?