Deposits, Cancellations and No-Shows: Booking Payment Rules

A cancellation policy on a web page changes nothing until the booking system enforces it. Staff waive fees because checking the rule is awkward, refunds are worked out by hand, and each no-show costs the business a slot it could have sold to someone else.

The way out is to treat the policy as a specification. Booking deposits, refund windows, rescheduling limits and no-show fees can each be reduced to a setting, a status or a scheduled job. The decisions below are in the order a developer will ask about them.

Booking deposits, prepayment or a card on file

There are four common arrangements for what a customer pays when they book. They protect against different things and need different plumbing.

Arrangement	Customer pays at booking	Protects against	The system needs
Pay on arrival	Nothing	Nothing	Reminders and a way to flag repeat no-shows
Deposit	A fixed amount or a share of the price	Casual bookings and late cancellations	Partial payment, a balance due, refund rules for the deposit
Full prepayment	The whole price	No-shows and unpaid balances	Refund rules by time window, credit or voucher handling
Card on file	Nothing, but a card is saved	No-shows, with the least friction at booking	Saved payment method, recorded consent, a later charge that may fail

Pick per service, not for the whole business, and use the lightest arrangement that covers the cost of an empty slot. A short consultation may need nothing, a three-hour procedure with a reserved room deserves a deposit, and a workshop with limited seats is usually paid in full. Ideally the rule can also vary by customer, so a regular with a clean record is not treated like a stranger.

A card hold is not a deposit

Payment gateways can authorize an amount on a card without capturing it. The money is reserved, and you capture it later or release it. That sounds ideal for no-show protection, but authorizations expire. Stripe's documentation on placing a hold on a payment method gives a window of about a week for most online card payments, shorter in some cases, after which the funds are released automatically.

So a hold works for a booking in the next few days and fails for one next month. For anything further out, charge a real deposit, or save the card and charge it only if the policy is triggered. Some systems save the card at booking and place a hold a day or two before the appointment.

Card on file needs consent you can show later

Saving a card means the gateway stores it and gives you a token. Your own database should never hold card numbers. What your database must hold is evidence of what the customer agreed to:

• the exact policy text shown at booking, or a version number that points to it,
• a checkbox the customer ticked, not one ticked for them,
• the date, time and booking reference.

This record matters twice. Card networks have rules for charging a stored card when the customer is not present, and a customer who disputes a no-show fee with their bank is likely to win unless you can show clear agreement. Ask your payment provider what it requires for this kind of charge in your country.

Plan for the charge failing. A card saved weeks ago may have expired, hit its limit or need the cardholder to authenticate with their bank. The system needs a status for "fee owed", an email asking the customer to pay through a link, and a rule for whether they can book again before settling.

Write the cancellation policy as time windows

"Cancellations within 24 hours are non-refundable" reads clearly and is ambiguous as a rule. Twenty-four hours before the start or before the day? In whose time zone? Does the deposit follow the same rule as the balance? A policy a system can apply is a short list of windows:

• More than 48 hours before the start: full refund, including the deposit.
• Between 48 and 24 hours: refund everything except the deposit.
• Less than 24 hours: no refund, or a credit toward a future booking.
• Canceled by the business: full refund, always.

Store these windows as data attached to the service, not as conditions written into code, so the owner can change them without a developer. Measure time from the appointment start in the location's time zone. Keep a copy of the policy on the booking itself at the moment it is made, because changing the rule tomorrow must not change the terms for bookings taken today.

Then decide who may override. Front-desk staff usually need a "waive fee" button with a required reason, and the override should be logged with the user's name. Without that, staff find ways around the system, such as deleting and recreating the booking, and your reports stop meaning anything.

Rescheduling needs its own rule

A customer who moves an appointment still intends to come. A system that treats a move as "cancel and rebook" will either refund and recharge for no reason or apply a cancellation fee to someone it should be keeping.

Settle these points:

• The cutoff. Free rescheduling up to a set number of hours before the start, and after that the cancellation rule applies.
• The limit. How many times a single booking may be moved. Without a limit, a customer inside the no-refund window moves the booking three months out and cancels it from there with a full refund.
• Which policy applies after a move. The simplest safe rule is that refund eligibility is judged against the original appointment time once a booking has been moved inside the late window.
• Price differences. If the new slot costs more or less, charge or refund the difference, or restrict moves to the same service and price.

The deposit and payment record should stay attached to the same booking through every move, with a history of the previous times.

Reminders do what fees cannot

Plenty of missed appointments are simply forgotten. A fee recovers some money afterwards. A reminder can save the slot.

A sequence that suits most appointment businesses is a confirmation straight away with a calendar file attached, a reminder a couple of days ahead while canceling is still free, and a short one on the day. Each message should carry links to confirm, reschedule or cancel without logging in. When a customer cancels through that link, the slot goes back on sale at once, and anyone on a waiting list is offered it.

Rules on consent for SMS vary by country, so collect permission explicitly at booking and check what applies to you. Reminder times belong in settings per service, since a dental check-up and a two-day course need different lead times.

Marking a no-show and charging for it

A no-show is a status, and something has to set it. The usual design gives staff "arrived" and "no-show" buttons on the day's schedule, plus a job that flags unmarked appointments for review after closing time. Avoid charging automatically the minute a grace period ends. Customers arrive late, staff forget to click, and a wrong charge costs more goodwill than the fee is worth. A review queue where a staff member confirms each fee is safer.

Keep a count of no-shows and late cancellations per customer. That count lets the system apply a stricter rule to repeat offenders, such as requiring full prepayment, without penalizing everyone else.

Details to settle before anyone writes code

• When the business cancels, is the refund automatic, and is the customer offered another slot first?
• For group bookings, what happens when three of five people turn up?
• Are refunds returned to the original card, issued as account credit, or the customer's choice?
• Does your payment processor return its own fee when you refund? Many do not, which affects what a "full refund" costs you.
• How are forfeited deposits and no-show fees treated for tax? Ask your accountant, because the answer differs between jurisdictions.
• If bookings can be paid with packages, vouchers or membership credits, what is returned on cancellation?

Configuring a product or building the rules

Many booking plugins and hosted schedulers handle a deposit or full prepayment with one cancellation window. If that is your policy, use one and configure it. Custom logic pays for itself when rules vary by service and customer history, when no-show fees are charged to saved cards, or when refunds must reconcile with an accounting system. That is the kind of work we take on for booking and scheduling systems, often for clinics and wellness practices and coaching and training providers. Payment timing also interacts with slot locking, which we cover in preventing double bookings.

Frequently asked questions

Should the deposit be a fixed amount or a share of the price?

A share of the price scales with the value of the slot, which suits businesses with a wide price range. A fixed amount is easier for customers to understand and for staff to explain. Either works as long as the amount is high enough to make someone think before booking casually.

Can I charge a no-show fee without a card on file?

Only by sending an invoice or payment link afterwards, and there is little you can do if the customer ignores it. If no-show fees are a real part of your policy, collect a deposit or save a card with clear consent at booking time.

Where should the policy be shown to the customer?

On the booking form beside the consent checkbox, in the confirmation email, and in each reminder. Showing it only in the site footer invites disputes, because the customer can reasonably say they never saw it.