Restaurant deposits can reduce the financial impact of no-shows and late cancellations, but the payment setup needs to work properly with the venue's booking system, payment gateway, merchant account and EPOS.
For some restaurants, taking a simple deposit at the point of booking is enough.
Other venues may need:
- card details securely captured at reservation;
- a tokenised card-on-file arrangement;
- pre-authorisation;
- full prepayment;
- different deposit rules for large parties;
- cancellation or no-show charges;
- automated refunds;
- private dining or event payments;
- booking-system integration;
- EPOS integration; and
- clear reconciliation between advance payments and the final restaurant bill.
The right structure depends on how the restaurant takes bookings and how the payment is eventually applied.
For the wider restaurant payment setup, see our Restaurant Payment Processing guide .
Restaurant deposits are really a payment-workflow decision
The question is not only:
“Should we charge £10 or £20 per person?”
It is also:
- When is the customer's card charged?
- Is money actually taken or merely authorised?
- Is the payment credited to the final bill?
- Can it be refunded automatically?
- Who stores the payment token?
- Can the booking system trigger a no-show charge?
- Does the payment appear correctly in the EPOS?
- How is it reconciled by finance?
For restaurants using integrated booking technology, the deposit policy and payment architecture should therefore be designed together.
Why do restaurants take booking deposits?
A booked table has a commercial value.
If a customer does not arrive, particularly during a busy service, the venue may not have enough time to resell that table.
The financial impact can be greater for:
- fine-dining restaurants;
- small venues with limited covers;
- Friday and Saturday evening bookings;
- large groups;
- private dining;
- set-menu restaurants;
- special events;
- Christmas bookings;
- Mother's Day or Valentine's Day;
- chef's table experiences; and
- restaurants that order or prepare specifically for a booking.
A deposit can give the customer a stronger commitment to the booking while also providing the restaurant with some protection if the reservation is cancelled.
Restaurant deposit vs card guarantee vs pre-authorisation
These arrangements are not necessarily the same.
Booking deposit
A deposit normally means the restaurant actually takes a payment when the customer books.
For example:
6 guests × £20 deposit = £120 paid at reservation
The £120 might later be deducted from the restaurant bill, refunded under specified circumstances or retained where the restaurant is contractually entitled to do so.
Full prepayment
The customer pays the entire price before attending.
This can be suitable for:
- tasting menus;
- ticketed dining experiences;
- private dining;
- events;
- special menus; or
- other fixed-price experiences.
Card guarantee or card-on-file
The customer's card is securely captured during the booking process without necessarily taking the full payment immediately.
The payment provider can instead store a secure payment token that may be used later where the merchant's payment setup and agreed customer terms support the transaction.
The restaurant should not simply store raw card details itself.
Pre-authorisation
A pre-authorisation can reserve funds on the customer's card without immediately completing the payment.
Visa documentation specifically identifies restaurants as one of the merchant types that may use pre-authorisation where the final transaction amount is not known at the beginning.
Pre-authorisations are time-limited and need to be managed correctly by the payment provider.
Should every restaurant take a deposit?
No.
A neighbourhood café taking mostly walk-ins may have little need for deposits.
A destination restaurant with limited seating and £100+ average spend per customer may have a much stronger commercial case.
Consider:
- average customer spend;
- historic no-show rate;
- average party size;
- table availability;
- whether cancelled tables can normally be resold;
- day of the week;
- seasonality;
- food-preparation costs;
- booking lead time;
- private dining;
- special events; and
- customer expectations.
The policy does not necessarily need to be identical for every booking.
Different deposit rules for different restaurant bookings
Some restaurants use a tiered policy rather than requiring a deposit from every customer.
For example:
- no deposit for tables of two;
- deposit for six or more guests;
- deposit for Friday and Saturday evenings;
- full prepayment for tasting menus;
- higher deposit for private dining;
- prepayment for special events; or
- card guarantee for standard bookings.
A capable booking and payment system can make these rules easier to automate.
Using SevenRooms for restaurant deposits and booking payments
SevenRooms is an example of a hospitality platform where reservations and payments can be connected.
Depending on the restaurant's setup, payment functionality can support workflows such as:
- taking deposits during booking;
- full prepayment;
- secure card capture;
- tokenised payment credentials;
- cancellation and no-show charges;
- refunds;
- guest payment history;
- reporting; and
- integration with wider hospitality systems.
Restaurants using or considering the platform should read our SevenRooms Payment Integration guide .
The payment provider should be assessed alongside the booking platform rather than chosen independently and connected afterwards.
Restaurant booking systems and payment providers
The restaurant's booking software can determine which payment providers and gateways are practical.
The payment journey might look like:
Customer → Booking Platform → Payment Gateway → Acquirer → Merchant Account
The booking platform may need to:
- request a deposit;
- securely capture card details;
- store a reusable token;
- apply the correct cancellation policy;
- trigger a later transaction;
- process a refund;
- identify the guest;
- pass payment information to the restaurant systems; and
- support finance reconciliation.
Our Payment Providers for Booking Systems guide explains the wider relationship between booking software and payment infrastructure.
What happens to the deposit when the customer eats at the restaurant?
This needs to be decided before implementing the system.
A restaurant might:
- deduct the deposit automatically from the final bill;
- manually apply it within the EPOS;
- refund the deposit and take the entire bill separately;
- treat the deposit as an advance payment against the meal; or
- use a different process for prepaid experiences.
The simplest customer journey is not always the simplest accounting journey.
For example, if deposits are taken through the booking platform but the final restaurant bill is taken through a separate EPOS/payment provider, finance may need to reconcile two different payment streams.
Restaurant deposits and EPOS integration
This becomes particularly important for groups and larger restaurants.
Ideally the restaurant wants to avoid staff having to check one system for the booking deposit and another for the final bill.
The payment architecture may therefore need to connect:
Booking System → Deposit → Guest Record → EPOS → Final Bill → Settlement → Reconciliation
Questions to ask include:
- Does the deposit appear against the reservation?
- Can the EPOS see the deposit?
- Can staff apply it to the correct table?
- Can deposits be split across several guests?
- Can part of a deposit be refunded?
- What happens when the booking changes size?
- Can the deposit move to another reservation date?
- How are vouchers or gift cards handled?
- How does finance identify the final settlement?
Restaurants reviewing the wider technology stack can also see our Hospitality EPOS guide .
Can a restaurant keep a deposit if the customer cancels?
Restaurants should not assume that describing a deposit as “non-refundable” automatically makes it fair in every circumstance.
UK Competition and Markets Authority guidance states that deposit, advance-payment and cancellation terms must be fair.
Where a customer cancels, the business should generally only seek to recover losses that genuinely result from that cancellation and should take reasonable steps to reduce those losses where possible.
A restaurant should therefore make its policy clear before the customer books, including:
- the amount being charged;
- whether it is a deposit or full prepayment;
- when the customer can cancel without charge;
- when some or all of the deposit may be retained;
- what happens if the restaurant cancels;
- how refunds are handled;
- what happens if party size changes; and
- the rules applying to no-shows.
Businesses should obtain legal advice where necessary when drafting their cancellation terms.
How much should a restaurant deposit be?
There is no universal percentage or fixed amount that suits every restaurant.
The amount should make commercial sense for the particular booking.
Consider:
- expected spend per guest;
- party size;
- likelihood of reselling the table;
- food purchased or prepared specifically for the booking;
- staffing;
- room or table capacity;
- event costs;
- booking lead time; and
- the restaurant's genuine potential loss.
The CMA's guidance indicates that non-refundable deposits should generally represent only a small proportion of the total price and that cancellation charges should reflect a genuine estimate of direct loss.
What if the restaurant manages to refill the table?
This is relevant when considering whether a cancellation charge is fair.
Consumer-law guidance expects businesses to take reasonable steps to reduce losses after a cancellation.
If a restaurant successfully fills the cancelled table with another customer, the financial loss may be different from a situation where the table remained empty throughout service.
Restaurants should ensure their cancellation terms and operational process take this into account where relevant.
No-show charges and card-on-file payments
Some restaurants prefer not to take money when the reservation is made.
Instead, the customer provides a payment card as a booking guarantee.
If the customer attends, no separate booking charge may be required.
If the customer does not attend or cancels outside the restaurant's agreed policy, an authorised charge may potentially be submitted under the provider's supported card-on-file framework and the restaurant's agreed terms.
This arrangement should be implemented through a payment provider capable of handling stored credentials correctly.
Do not store a customer's CVV for later no-show charges
PCI DSS rules prohibit merchants and service providers from retaining the card verification code after the transaction for which it was collected has been authorised.
That remains the case even if the customer gives permission.
Restaurants wanting to retain a payment credential should therefore use an appropriate tokenised card-on-file arrangement through their payment provider rather than attempting to store complete card-security information themselves.
The gateway or acquirer should explain how subsequent transactions need to be submitted within the relevant card-scheme framework.
Restaurant deposit vs pre-authorisation
A deposit and pre-authorisation solve different problems.
A deposit: money is actually collected from the customer.
A pre-authorisation: an amount is authorised and temporarily reserved on the customer's card, with capture taking place later where appropriate.
Visa Acceptance documentation specifically lists restaurant transactions as a use case for pre-authorisation.
This may be useful where the final amount is not known when the initial authorisation takes place.
However, authorisation periods and processing requirements vary.
The restaurant should therefore confirm with its payment provider:
- whether pre-authorisation is supported;
- how long the authorisation remains valid;
- how it is captured;
- how unused authorisations are reversed;
- whether incremental authorisation is available;
- how Strong Customer Authentication applies; and
- what fees apply.
Large groups and private dining
Large parties create a different risk profile from a normal table booking.
The restaurant may have:
- reserved a significant proportion of available covers;
- provided a private room;
- ordered specific food or drink;
- scheduled additional staff;
- agreed a set menu;
- turned away other customers; or
- incurred event-specific costs.
The payment workflow might therefore involve:
- initial deposit;
- second-stage advance payment;
- final balance;
- pre-order payments;
- customer-specific payment links;
- split payments;
- corporate cards; and
- in-person settlement on the day.
A normal consumer restaurant checkout may not be the best payment structure for this type of booking.
Deposits for Christmas, Valentine's Day and special events
Special-event bookings can justify a different payment policy from ordinary service.
A venue may decide to use:
- higher deposits;
- full menu prepayment;
- fixed cancellation deadlines;
- ticket-style payments;
- scheduled balance collection; or
- different rules for large groups.
The customer should be shown the relevant payment and cancellation terms clearly before completing the booking.
Need restaurant payments to work with your booking or EPOS system?
Tell us which booking platform and EPOS system you use, how you want to collect deposits or booking guarantees and how the final restaurant payment is processed.
Merchant Advice Service can help you understand the payment requirement before identifying providers that may be suitable.
Find suitable payment providers
Refunding restaurant deposits
The refund process should be considered before the restaurant launches a deposit policy.
Operational questions include:
- Can staff refund directly from the booking platform?
- Does the refund need to be processed through the gateway?
- Can a partial refund be issued?
- Can the deposit be transferred to a new booking?
- How long do refunds normally take?
- What happens if the customer's original card has expired?
- How does the refund appear in reporting?
- Which staff have authority to issue refunds?
For a restaurant group, refund permissions and reporting may need to be controlled at site level.
Restaurant deposit chargebacks
A deposit or no-show payment can still be disputed by the cardholder.
The restaurant should retain evidence such as:
- booking confirmation;
- the amount authorised or paid;
- the cancellation terms shown to the customer;
- customer acceptance of those terms;
- booking date and time;
- cancellation records;
- communications with the customer;
- refund records; and
- evidence of the payment transaction.
A clear policy can reduce misunderstandings, but it does not eliminate chargeback risk.
Deposits across multiple restaurant locations
Restaurant groups need to decide how booking payments are structured across venues.
Questions can include:
- Does every venue use the same merchant account?
- Does each location have its own MID?
- Does each site settle into a separate bank account?
- Are deposits reported by venue?
- Can bookings be transferred between restaurants?
- Who controls refunds?
- Are cancellation policies consistent across the group?
- Can head office reconcile payments centrally?
This can become particularly important for restaurant groups using one central booking platform across many locations.
Reconciliation: the part restaurants often overlook
A deposit can create two separate financial events:
1. Deposit collected before the visit
2. Remaining bill paid in the restaurant
The venue then needs to ensure the two payments are correctly associated with:
- the reservation;
- the guest;
- the correct restaurant location;
- the final bill;
- the correct settlement batch;
- refunds;
- chargebacks; and
- the general ledger.
Manual reconciliation may be manageable for a single restaurant taking a handful of deposits each week.
It becomes a very different problem for a group taking thousands of advance payments across many venues.
Our Payment Reconciliation guide looks at this in more detail.
Should restaurant deposits integrate with the wider payment system?
Ideally, yes — particularly where deposit volume is significant.
A connected hospitality payment environment may involve:
Website / Booking Platform → Gateway → Merchant Account → Reservation → EPOS → Card Terminal → Settlement → Finance
The more disconnected those systems are, the more likely staff will need to:
- re-enter data;
- manually check deposits;
- manually reconcile payments;
- issue refunds across several systems;
- investigate missing payments; or
- correct customer bills.
Our Integrated Payments guide explains how payment providers can connect with wider business software.
What should restaurants compare between payment providers?
If deposits and booking payments are important to the business, do not compare providers purely on the headline card rate.
Check:
- booking-system compatibility;
- SevenRooms or other required integrations;
- tokenisation;
- card-on-file support;
- pre-authorisation;
- merchant-initiated transactions where required;
- Strong Customer Authentication;
- refund functionality;
- payment-link functionality;
- EPOS integration;
- multi-site support;
- settlement;
- reporting;
- reconciliation;
- chargeback support;
- international cards; and
- total processing cost.
The lowest transaction rate can be poor value if it breaks the restaurant's booking or EPOS workflow.
Questions to answer before introducing restaurant deposits
- Which bookings require a deposit?
- How much will be charged?
- Is it a payment, card guarantee or pre-authorisation?
- When can customers cancel?
- When is the deposit refundable?
- How will no-shows be handled?
- Does the booking system support the required payment workflow?
- Does the payment provider support the booking platform?
- How will the deposit be credited against the restaurant bill?
- How will refunds work?
- How will disputes be evidenced?
- How will deposits be reconciled?
- Does the policy differ for groups or events?
- How will multiple restaurant locations be managed?
Review the whole restaurant payment journey
A booking deposit is only one part of the payment setup.
For restaurants using booking platforms, EPOS, card terminals and online payments, the provider needs to fit the complete customer and operational journey.
Merchant Advice Service can help you understand those requirements before identifying payment providers that may be suitable.
Get personalised payment recommendations Restaurant payment guide
Sources & References
- Competition and Markets Authority / GOV.UK – Cancelling Goods or Services – guidance on fair deposits, cancellation charges and recovering genuine losses.
- Competition and Markets Authority – Deposits, Advance Payments & Cancellation Charges – business guidance on deposits, advance payments and fair cancellation terms.
- PCI Security Standards Council – Card Verification Codes and Card-on-File Payments – PCI DSS guidance confirming that card verification codes cannot be retained after authorisation for future card-on-file transactions.
- Visa Acceptance Solutions – Pre-Authorisation – technical guidance on pre-authorisation, including restaurant transaction use cases.
- Merchant Advice Service – SevenRooms Payment Integration – guidance on booking deposits, secure card capture, tokenisation and hospitality payment integration.
- Merchant Advice Service – Restaurant Payment Processing – wider guide to restaurant merchant accounts, terminals, EPOS and payment processing.
- Merchant Advice Service – Hospitality EPOS – guidance on EPOS, booking systems, deposits, terminals and connected hospitality payments.
- Merchant Advice Service – Editorial & Research Policies
Editorial & Commercial Disclosure
This guide provides general information about restaurant deposits, booking payments, card-on-file arrangements, payment integration and merchant services.
Deposit and cancellation policies should be fair, clearly communicated and appropriate to the restaurant's actual circumstances. Consumer-law requirements depend on the contractual arrangement and individual facts.
Merchant Advice Service does not provide legal advice and does not determine whether an individual restaurant's cancellation or deposit terms are legally enforceable.
Payment functionality including tokenisation, card-on-file transactions, pre-authorisation and later charges depends on the relevant gateway, acquirer, booking platform and card-scheme requirements.
MAS is an independent payments information and provider-matching service. MAS may receive a referral fee or commission from some payment providers where a business proceeds following an introduction. Commercial relationships do not determine the factual information or provider-selection principles contained within this guide.
Information is provided for general guidance and should not be treated as legal, regulatory or technical implementation advice.
