Clinics, schools, consultancies and training providers don’t sell boxes. They sell an hour of someone’s time or a seat on a course, and that changes how you should take payments on your website.
You may need a deposit to hold a slot, a full fee before a course fills, or a way for clients to pay an invoice once the work is done. A standard online store handles few of those well. This guide compares the options that do, and shows how to keep card details off your website.
The short answer
Most service businesses need one or two of these:
- Payment links for one-off amounts, sent by email or chat or placed behind a button.
- A booking system that takes deposits, when payment must be tied to a date, time and person.
- A simple checkout for fixed-price services such as course places or packages.
- Online invoice payment, so clients can pay a specific invoice from a link.
Whichever you choose, card details should be typed only into the payment provider’s hosted page or embedded fields, never your own forms. Show the price and cancellation terms before anyone pays, and mark a booking as paid only when the provider confirms the payment.
Four ways to take payments on your website
Payment links
You create a link in the provider’s dashboard for a set amount and send it, or place it behind a “Pay now” button. It suits anyone who agrees the price in conversation first, such as a consultancy taking a retainer, and set-up takes minutes.
The catch: a link knows nothing about your calendar. Someone matches each payment to a client by hand, and a forwarded or reused link can be paid twice.
A booking system that takes deposits
Scheduling software, hosted or as a plugin, shows real availability and connects to a payment provider. The customer picks a time, pays a deposit or the full fee, and the slot is theirs. Good tools also handle reminders, rescheduling and refunds within your rules.
The catch: you inherit the tool’s limits, so check it handles your real rules (deposits per service, staff hours, buffers) before committing. Hotels have extra needs such as rate plans and channel managers, covered in hotel direct booking websites.
A simple checkout for fixed-price services
When a service has a fixed price but no calendar (a course place, an assessment package, a gift voucher), a short checkout works well. On WordPress that’s usually a form with a payment step, or a lightweight commerce plugin set up for a handful of services.
The catch: it can quietly grow into a store you have to maintain. If you sell physical products too, the decisions in e-commerce website design apply.
Online invoice payment
For work billed after delivery, many invoicing and accounting tools can add a “Pay now” link to each invoice, opening the provider’s checkout with the amount and reference filled in.
The catch: generic “pay invoice online” pages, where clients type the invoice number and amount themselves, produce typos and payments nobody can match. A link per invoice avoids that and, when the tools are connected, marks the invoice paid automatically.
Payment links vs checkout vs bookings
| At a glance | Payment links | Booking with deposit | Simple checkout | Invoice payment |
|---|---|---|---|---|
| Best for | Prices agreed in conversation | Appointments | Places and packages | Work billed afterwards |
| Knows availability | No | Yes | Capacity only | No |
| Matching to records | By hand | Automatic | Automatic | Automatic |
| Refunds | In the dashboard | Within booking rules | Plugin or dashboard | Dashboard, plus a credit note |
Choosing a payment gateway for your website
In practice, choosing a “payment gateway” means choosing a provider that runs the checkout and pays out to your bank. Availability varies by country, but providers fall into three broad types:
- Online payment platforms, quick to sign up to, with hosted checkouts, payment links and plugins for common tools.
- Your bank’s merchant services, which can suit higher volumes but often mean more paperwork and fewer ready-made website connections.
- Payments built into software you already use. Many booking and invoicing tools support only a short list of providers.
It often works best to choose the booking or invoicing tool first, then compare the providers it supports.
Fees and terms to check
Compare providers using your own booking values, not the headline rate.
Where card data lives, and why it shouldn’t be your website
The key technical decision is where the customer types their card number. There are two safe answers.
Hosted payment pages. The customer pays on the provider’s domain, then returns to your site, which never touches the card.
Embedded payment fields. The card fields sit in your page but are served by the provider in a secure frame, so the numbers go straight to them.
Avoid any set-up where card numbers pass through your own server or forms. That puts your website in the card-handling chain, with far heavier obligations.
Outsourcing isn’t the whole story
PCI DSS, the card industry’s data security standard, applies to every business that accepts card payments, even when a provider handles the card details. A hosted page or embedded fields keeps your part as small as it can be.
Your website still matters. Attackers who get into a site can inject a fake card form or point the “Pay now” button at a copycat page. Keep the CMS and plugins updated, and keep third-party scripts on the pages leading to payment to a minimum. The WordPress security guide covers the rest.
Check it yourself. Go through your own payment flow. On a hosted page, the address bar shows the provider’s domain at the card fields. If the fields sit on your own page, ask whoever built it: are these the provider’s embedded fields, and does a card number ever reach our server, even briefly? You want yes, then no.
Design the payment step so people feel safe paying
Put the price and terms before the form
State the full price, the deposit, when the balance is due and the cancellation terms in plain sentences on the booking page, with the currency and whether tax is included. A “Terms and conditions” link beside the button isn’t enough; few people open it.
Keep the form short, and don’t ask twice
Ask only what the appointment needs, and carry the name and email from booking into payment instead of asking again. WCAG 2.2, the W3C’s accessibility standard, addresses this directly in its Redundant Entry success criterion (3.3.7). Web form design covers fields, labels and error messages.
Let the provider’s checkout do its job
A provider’s checkout usually handles saved cards, phone wallets and errors already, and people recognise it. Add your logo and colours, but don’t restyle it beyond recognition. In the UK and the European Economic Area, for example, strong customer authentication rules mean many online card payments need an extra check with the customer’s bank (usually 3-D Secure), which good providers handle inside the checkout. Much of checkout optimisation applies to a one-item booking too.
Confirm clearly, and plan for declines
The confirmation page and email should cover what was booked, with whom, when and where, what was paid and what’s left, and how to reschedule, with a calendar invite. On a multilingual site, the payment step and emails should follow the language the customer chose. When a card is declined, say so plainly, keep the slot held briefly and offer another method.
Set deposit, cancellation and refund rules first
Most payment problems are policy problems. Decide these first, keep each to one sentence, and use the same wording on the booking page, checkout and confirmation email.
- Deposit or full payment. A deposit suits appointments where no-shows are the main risk; full payment suits courses with limited places.
- Refundable or credit. A deposit that turns into credit for another booking often feels fairer than one simply lost, and gives customers less reason to dispute the charge.
- Cancellation window. How late can someone cancel or reschedule and keep their money?
- No-shows. Keep the deposit, or charge a saved card? The provider stores the card, and customers must clearly agree to that charge when they book.
- Your own cancellations. A prompt, full refund.
Some providers let you hold an amount on a card instead of taking a deposit, but holds expire, often after about a week for online payments, so they suit bookings a few days ahead, not weeks. Consumer law on cancelling services bought online varies by country, so check what applies where your customers are.
Connect payments to bookings and accounting
Confirm bookings from the provider’s notification
When a payment succeeds, fails or is refunded, the provider can send a message straight to your website’s server, called a webhook. Mark a booking paid only when that arrives and its signature checks out; people sometimes close the tab before the thank-you page loads. Hold the slot while someone pays, and release it automatically if they don’t finish, so nobody is double-booked.
Carry one reference through every system
Put the booking or invoice number in the payment’s reference, so the provider’s dashboard, booking system and accounts point to the same record. Keep sensitive detail out: “Appointment 1042”, not a treatment name. Set a statement name customers will recognise, because an unfamiliar charge is an easy one to dispute.
Reconcile payouts and measure bookings
Payouts usually arrive in batches with fees already deducted, so connect the provider to your accounting software to split each into payments, fees and refunds. Check which receipts or tax invoices you must issue; a provider’s receipt isn’t always enough.
Then record a confirmed, paid booking as a key event in Google Analytics, triggered by the confirmation rather than the button, with no names or emails in the data. GA4 conversion tracking explains how, and website integrations explained shows how bookings, payments, CRM and accounting fit together.
Security and privacy checklist
Frequently asked questions
Am I responsible for PCI DSS if my payment provider handles the cards?
Yes, but the burden is much lighter. When card details are only ever entered on the provider’s hosted page or embedded fields, you usually qualify for the simplest level of validation, and some providers handle the paperwork for you. Your provider or acquiring bank confirms what applies.
Can customers pay in their own currency?
Many providers can charge in several currencies and pay you in yours. Check who bears the conversion cost, and how foreign-currency refunds work, before switching it on.
How do I test payments before going live?
Use the provider’s test mode, which accepts published test card numbers and moves no real money. Try a successful payment, a decline, a refund and a cancellation, and check each updates the booking, the emails and your records.
What to do next
Payments work best when the rules, the tool and the pages are planned together:
- Find where getting paid hurts: chasing invoices, no-shows, or matching transfers to bookings.
- Write your deposit, cancellation and refund rules.
- Choose the lightest option that fixes it, then a provider it supports.
- Build the pages around the provider’s checkout.
- Test every path, go live, and track paid bookings.
If you’re planning a new website, raise bookings and payments in the first conversation: they are far easier to design in than to bolt on. Our guide to website integrations explains how a site connects to the booking and payment tools behind it, and a free website audit shows how easily visitors can reach you and book today.