Booking Deposits, Balance Dates and Cancellations

A good booking payment workflow answers four questions without making the guest call the office:

What do I need to pay now?
What will I need to pay later?
When is the balance due?
What happens if I change or cancel the booking?

It should answer the same questions for the team too.

The aim is not to collect the largest possible deposit or create the strictest possible cancellation policy. It is to protect the booking, give the guest a clear commitment and make the next action obvious at every stage.

For most campsites, holiday parks and glamping businesses, the calmer workflow is the one with:

One clearly defined amount due at booking.
One balance due date that matches the booking lead time.
A small number of useful reminders.
A visible route for failed or late payments.
Cancellation terms that are clear, proportionate and applied consistently.
A human decision when the normal policy does not fit the situation.

This guide explains how to design that workflow. It is operational guidance, not legal advice or a cancellation-policy template. Your terms should reflect your business, booking channels and circumstances, and should be reviewed by a suitably qualified adviser where necessary.

Start with the operating decision, not the percentage

Operators often begin with a question such as:

Should we take a 20% deposit or a 30% deposit?

That number matters, but it is not the first decision.

Start by deciding what the payment is meant to do.

A deposit may be intended to:

Confirm that the guest is making a real commitment.
Cover costs incurred soon after the booking.
Reduce the exposure created by holding popular inventory.
Give the guest a manageable first payment.
Reduce the amount that remains to be collected later.

Those aims can conflict.

A very small payment may create weak commitment and a large balance-collection job. A very large payment may make the booking harder to complete and create a bigger refund or cancellation issue later.

The right amount depends on the booking value, how far ahead guests book, the likelihood that cancelled dates can be resold, the costs created by the reservation and what guests reasonably expect in that market.

Do not copy a nearby park's percentage without understanding the rest of its workflow. The same deposit can behave very differently when one operator takes the balance 14 days before arrival and another takes it 12 weeks before.

The five decisions behind a booking payment workflow

A complete workflow needs five connected decisions:

The amount due at booking.
The date the remaining balance becomes due.
The reminders sent before that date.
The response when payment is late or fails.
The financial outcome if the booking is changed or cancelled.

Design them together. If each decision is made separately, guests can receive inconsistent messages and staff end up repairing the gaps by hand.

1. Decide what is due at booking

The first payment normally takes one of three forms.

A fixed deposit

The guest pays the same amount for each booking, such as £50.

This is simple to explain and easy for the team to recognise. It can become less suitable when booking values vary widely. A fixed amount may be significant for a short touring stay but negligible for a two-week lodge booking.

A percentage deposit

The guest pays a stated share of the booking value.

This scales with the reservation and can create a more consistent level of commitment. The actual amount can be less predictable for the guest until the booking total is known, so show both the percentage and the amount before payment.

Payment in full

The guest pays the complete price when booking.

This can make sense for lower-value stays, last-minute bookings or reservations made after the normal balance date. It removes the later collection step, but the cancellation and refund terms still need to be clear.

Some operators need more than one rule. For example:

A normal deposit when the arrival date is more than six weeks away.
Payment in full when arrival is within six weeks.
A separately reviewed schedule for group or long-stay bookings.

That is still a simple policy if the guest can understand which rule applies and the system can apply it consistently.

2. Choose a balance date that matches the lead time

The balance date should create enough time to identify a problem, contact the guest and decide what happens before arrival.

It should not be chosen simply because another operator uses it.

Consider:

How far ahead guests normally book.
When you incur costs for the stay.
How quickly cancelled inventory could realistically be resold.
Whether the booking includes higher-cost extras or third-party services.
How many overdue balances the team can reasonably handle.
Whether a later date would create a large payment close to the guest's stay.

A calendar rule is usually easier to run than an informal one. For example:

The remaining balance is due 42 days before arrival.

That rule produces a date from information already held in the booking.

It also needs a short-lead rule:

If the booking is made within 42 days of arrival, the full amount is due when the booking is made.

Without that second line, the system and team have to decide what to do with every last-minute booking.

The number of days in these examples is illustrative, not a recommendation. Test your own rule against real booking patterns.

3. Use reminders to clarify, not chase

A useful reminder tells the guest:

Which booking the message concerns.
The outstanding amount.
The due date.
How to pay.
How to get help if the amount or booking is wrong.

It should not make the guest search through an old confirmation to reconstruct the payment position.

A simple sequence might include:

A confirmation message showing the deposit paid, remaining balance and due date.
A reminder before the due date.
A message on or shortly after the due date if the balance remains unpaid.
A staff task when the booking needs review.

More reminders are not automatically better. A sequence that continues after payment, cancellation or an agreed exception makes the business look disorganised.

Each message needs a stopping condition. The reminder should stop when:

The payment is recorded.
The booking is cancelled.
A staff member pauses the workflow.
A different payment arrangement is agreed.
The booking moves into a state that requires manual review.

The booking-system automation framework explains how to separate the routine path from exceptions that need a person.

4. Define what happens when payment is late

"Balance overdue" is a status, not a complete procedure.

Decide what the team should do next.

A practical overdue route may be:

Confirm that the payment has not already been received through another route.
Check that the balance and due date are correct.
Send the agreed overdue message.
Create a task for a named role or person.
Record any contact or alternative arrangement.
Apply the booking terms only after the required checks and communication.

The workflow should not automatically treat every late payment as a cancellation.

A card may have failed. The guest may have paid by bank transfer. A member of staff may have agreed an extension. The booking total may have changed. The guest may be disputing a charge.

Software can identify the overdue booking and assemble the payment history. A person should handle the point where incomplete information or a material exception changes the right outcome.

5. Connect the cancellation terms to likely loss

A cancellation policy is not just a table of dates and charges. It is the financial logic that connects a cancelled booking to what the business may genuinely lose.

Current Competition and Markets Authority guidance says consumer contract terms need to be fair and transparent. It warns against automatically keeping large advance payments or applying excessive cancellation charges without considering actual loss and reasonable steps to reduce that loss, such as reselling the service.

The CMA's guide to writing fair contracts and its updated unfair contract terms guidance are useful starting points. They are not substitutes for advice on your own terms.

This has an important operational consequence:

The cancellation workflow needs a record of what was paid, when the guest cancelled, what the terms said, what inventory became available again and what decision was made.

A simple percentage table cannot do all of that by itself.

Design the cancellation route as a workflow

When a guest asks to cancel, the team should not have to improvise the process from an inbox.

Use a consistent route.

Step 1: Confirm the request

Record:

The date and time of the request.
Who made it.
The booking concerned.
The intended cancellation or change.
The reason, if the guest chooses to provide one.
The communication channel.

Do not leave the booking active simply because the financial outcome has not yet been decided. Give it a clear review state so availability, guest communication and staff tasks do not continue as if nothing happened.

Step 2: Establish the booking position

Bring together:

Arrival and departure dates.
Accommodation or pitch.
Total booking value.
Deposit and other payments received.
Extras or third-party services.
The cancellation terms accepted when the booking was made.
Previous changes or exceptions.
Any amount already refunded.

This should come from one booking record wherever possible.

Step 3: Apply the relevant rule

The normal policy may depend on the time between cancellation and arrival.

For example, an operator might distinguish between:

A cancellation well before the balance date.
A cancellation after the balance date but with meaningful resale time.
A late cancellation close to arrival.
A no-show.
A cancellation initiated by the operator.

The categories should be clear enough that two trained team members reach the same starting answer.

Avoid wording that suggests the business can always retain every payment regardless of the reason, service provided or loss. The CMA's consumer cancellation guidance explains that cancellation charges should be reasonable and linked to direct loss, with reasonable steps taken to reduce that loss.

Step 4: Identify the exception

The normal route may not fit when:

The operator cannot provide the booked stay.
A material part of the booking was described incorrectly.
The guest disputes the payment or terms.
A significant accessibility or vulnerability issue is involved.
A group or negotiated booking has its own agreed schedule.
The booking has been moved previously.
The dates are resold and the policy requires a different calculation.
The situation needs legal or specialist review.

The system should make the policy outcome visible without forcing staff to apply it blindly.

Step 5: Record and communicate the outcome

The guest should receive a clear written summary showing:

That the booking has been cancelled or changed.
The effective date.
What will happen to the accommodation or pitch.
The amount being retained, charged, credited or refunded.
How that amount was determined.
The expected refund route and timing, where applicable.
How to raise a question.

The internal record should also show who approved any exception.

That protects the guest, the team and the operator when the booking is reviewed later.

A worked payment-workflow example

Consider a fictional glamping booking with these details:

Booking value: £600.
Booking date: 1 February.
Arrival date: 1 August.
Deposit at booking: 20%, equal to £120.
Balance due: 42 days before arrival.
Remaining balance: £480.

The dates and percentages are examples only.

At booking

The guest sees:

Total stay price: £600.
Pay now: £120.
Remaining balance: £480.
Balance due date: 20 June.
A clear link to the booking and cancellation terms.

After payment, the confirmation repeats the same figures.

The team sees a confirmed booking with the deposit recorded and the next payment date already set.

Before the balance date

The system checks whether the £480 balance is still outstanding.

If it is, the guest receives a reminder with the amount, date and payment route. If the balance has already been recorded, nothing is sent.

When the payment succeeds

The booking moves to paid in full. The payment history shows both transactions. Future balance reminders stop.

When the payment does not arrive

The booking becomes an overdue-balance task. It does not disappear and it is not silently cancelled.

A team member checks the record, contacts the guest and records the outcome.

When the guest cancels

The team records the request, reviews the accepted terms and calculates the normal starting outcome. If the case involves a dispute, an operator cancellation, resale or another exception, it leaves the automatic route for a person to review.

The important point is not the chosen 20% or 42 days. It is that each state has:

A trigger.
A visible amount.
A next action.
A stopping condition.
An exception owner.

What the guest should see before paying

Payment clarity begins before the card form.

Before committing, the guest should be able to see:

The complete price that can reasonably be calculated.
Any unavoidable booking fees, taxes or charges.
The amount due now.
The amount due later.
The balance due date.
The main cancellation and amendment conditions.
Which optional extras they have selected.
Whether any amount will be paid locally.

Current CMA price-transparency guidance says the total price should normally include unavoidable mandatory charges. Where a total cannot yet be calculated, the customer should receive the information needed to calculate it.

This is a useful booking-journey test even apart from compliance:

Could a guest take one screenshot before paying and understand the whole financial commitment?

If not, the payment page may be technically complete but commercially unclear.

Use the direct-booking website audit to review the wider route from availability search to confirmation.

What the team should see after payment

The booking office needs a payment position, not just a list of transactions.

For each booking, staff should be able to see:

Total booking value.
Payments received.
Remaining balance.
Balance due date.
Payment status.
Payment history.
Refunds or credits.
Failed or disputed payments.
Reminder status.
Agreed exceptions.
The next action and its owner.

If those facts live across a booking diary, payment dashboard, spreadsheet and email inbox, even a good policy will create avoidable work.

The Keydesk deposits and payments workflow is designed to keep the amount paid, balance and due date with the reservation. Keydesk currently describes Stripe for online card payments, payment history, visible balances and scheduled reminders.

It does not currently claim that every balance is automatically charged from a saved card. Refund handling, chargebacks, accounting reconciliation and alternative payment gateways should be confirmed with the Keydesk team during early access.

A 15-minute payment-workflow audit

Take one normal future booking and answer these questions.

At the point of booking

Is the complete price clear?
Is the amount due now shown in pounds, not just as a percentage?
Is the later balance visible?
Is the exact due date shown?
Can the guest find the cancellation terms before paying?
Are mandatory charges included at the appropriate point?

In the booking record

Can the team see every payment against the reservation?
Is the remaining balance calculated correctly?
Is the due date visible?
Is there one clear payment status?
Can staff identify who owns an exception?

In the reminder sequence

Does each message show the booking, amount and due date?
Does it contain a usable payment route?
Does the sequence stop after payment or cancellation?
Can staff pause it?
Does an overdue balance create a clear task?

In the cancellation route

Is the original accepted policy available?
Is the cancellation request dated and recorded?
Can staff see the payments and booking value together?
Is any exception and approval recorded?
Does the guest receive a written explanation of the outcome?

Every "no" is a workflow gap. Prioritise the gaps that can create an incorrect charge, an unnecessary guest contact or uncertainty about whether the booking is secure.

Get one practical operator idea each week

The Operator Brief turns one accommodation workflow, commercial decision or software question into something you can use.

Join The Operator Brief for practical notes written for independent campsites, holiday parks and glamping operators. Joining the newsletter does not add you to the Keydesk early-access waitlist.

The calmest policy is the one the workflow can actually run

A payment policy can look polished in the terms and conditions while failing in day-to-day operations.

The test is whether the booking moves cleanly through these states:

Deposit required → deposit paid → balance scheduled → balance reminder → paid in full

And whether it can leave that normal path safely:

Payment failed → balance overdue → booking changed → cancellation requested → manual review

The policy defines what should happen. The booking system should keep the amounts, dates, messages and status aligned. The team should own the decisions that depend on context.

When those responsibilities are clear, deposits stop being isolated card transactions. They become part of a reliable booking workflow that both the guest and operator can follow.

See how Keydesk handles deposits and balances

Keydesk is being built for campsites, holiday parks, touring parks and glamping operators that want the payment position to remain connected to the reservation.

Explore deposits and online payments in Keydesk, including deposits or payment in full, Stripe card payments, payment history, visible balances, due dates and scheduled reminders.

Deposits, balance dates and cancellations: designing a calmer payment workflow