Pay on booking or pay on arrival: what changes

Deciding whether customers pay on booking or pay on arrival is not just a pricing preference. It changes what your website has to build, store and confirm at the point someone commits to a slot. Get the wrong setup and you end up with no-shows, awkward phone calls chasing card details, or a booking form that asks for far more than it needs to.

💳 Pay on booking or pay on arrival: the real difference

Pay on booking means the customer hands over money (in full or as a deposit) the moment they confirm the appointment, room or class. The website has to take that payment there and then, which means a proper checkout, not just a form.

Pay on arrival means the booking is confirmed but no money changes hands until the customer turns up. The website's job is simpler: capture the booking, send a confirmation, and leave payment to happen in person, over the phone, or via an invoice link later.

Neither is universally "better". A dentist filling appointment slots six weeks out has a different no-show risk than a gym running a free trial class. The right choice depends on how much it costs you when someone doesn't show up.

🧾 What changes when you take payment on booking

Taking payment on booking adds real infrastructure to the site, not just a tickbox. You need:

• A payment gateway (Stripe and GoCardless are the two most common for UK small businesses) with fees typically around 1.5% plus 20p per transaction on card payments.
• A clear statement, before the customer enters card details, of what they are paying for: full amount, deposit, or a holding fee.
• A cancellation and refund policy that is visible before payment, not buried in an email afterwards. This matters for consumer law as much as for trust.
• Automatic handling of failed payments, so a declined card doesn't leave you with a "booked" slot that was never actually paid for.
• A receipt or confirmation email that states clearly what has been charged and what happens if the customer cancels.

This is more build work than a basic enquiry form, and it usually means the booking system needs to talk properly to the payment gateway rather than just link out to it. That's typically a few days of setup rather than an afternoon, and it's worth knowing that going in.

🔓 What changes when customers pay on arrival

Pay on arrival is lighter on the website side but heavier on your admin. The site only needs to capture the booking details, confirm the slot, and send a reminder. No checkout, no gateway integration, no PCI concerns.

The trade-off shows up later: no-shows cost you nothing on the website but cost you the slot itself. Some businesses solve this with a card-on-file hold rather than a charge, which is a middle path. The card details are captured at booking (so there's a small integration cost, similar to taking payment) but nothing is charged unless the customer fails to turn up. This needs the same clarity around what "hold" means and when it converts to a charge.

⚖️ Choosing the right model for your business

A few practical questions decide this, more reliably than a general preference for one model over the other:

• What does an empty slot actually cost you? A missed haircut is not the same loss as an empty hotel room on a Saturday night.
• How far in advance do people book? Longer lead times mean more time for a customer to forget, which pushes towards taking a deposit.
• Do your customers expect to pay upfront already? Clinics, driving instructors and serviced accommodation bookers are used to it. Walk-in trades and casual gym classes usually aren't.
• Can you absorb the admin of chasing payment after the fact? Pay on arrival often just moves the work from the website to a phone call.

Many businesses land on a mixed approach: a deposit on booking for anything more than a week out, full payment on arrival for same-day slots. The website needs to support both rules cleanly rather than forcing every customer down one path.

🛠️ What your website needs to support either choice

Whichever model you pick, the booking page itself needs the policy stated plainly, not left to be discovered at checkout or on arrival. That single paragraph, in plain English, near the booking button, prevents most disputes before they start.

At WebCheap, a booking page that only captures details without payment is usually a straightforward addition to a site, often within the standard build. Adding a payment gateway with deposit or hold logic is more involved, closer to a dedicated afternoon or two of setup work, and it's the kind of thing worth pricing properly rather than bolting on as an afterthought. If you're not sure which model suits your business yet, it's worth building the booking flow so the payment step can be switched on later without rebuilding the page from scratch.

The practical takeaway: decide your no-show cost first, then let the website follow that decision, not the other way round.