Online booking checkout (what your customers see)

Once a client has picked a time on your booking page, everything that follows — holding the slot, collecting details, taking payment, and confirming — runs on autopilot. This page walks you through exactly what your customer experiences, step by step, so you understand the flow well enough to support them and to make sense of a payment in your books. Every stage is shaped by settings you already control, and we call those out as we go.

The slot is held with a countdown

The moment a client reserves a slot it goes into their cart and a hold is placed on it in the backend, so nobody else can take it while they finish. A slim timer bar appears with a live countdown and the exact time the hold runs out. How long they get is your organisation's reservation timeout setting — 15 minutes by default, and the same value drives both the on-screen timer and the backend hold, so they always agree.

If the timer reaches zero before checkout is complete, the hold is released automatically: the cart is emptied, the freed slot reappears in the calendar for the next person, and the client is sent back to the start with a short "reservation expired" message. There is nothing for you to clean up — an abandoned cart never leaves a slot stuck. The same thing happens if a client leaves a stale tab open and comes back much later.

While the hold is live, the client can add gift vouchers, other products, or a wallet top-up to the same cart, and apply a voucher code or their existing account credit against the total. Whether those extras appear at all is decided by your modules and by the per-session Show vouchers / Show products switches.

Signing in with email and a one-time code

Before anyone can reach the checkout form they must identify themselves. When the client taps Checkout, a sign-in dialog asks for their email address, then sends a one-time code to that inbox (the code length is a tenant setting). They enter the code to verify, and only then does the flow let them continue — the checkout page is guarded, so a client who somehow lands there without signing in is bounced straight back to the cart. This is also what links the booking to the right client record: a returning customer's saved details and available credit are recognised, and a brand-new email quietly creates a new client for you.

Filling in the checkout details

The checkout form asks for the fields you chose. Critically, the client is asked for the combined set of fields from everything in the cart — the checkout fields configured on each booked session, plus those on any product in the cart, plus your organisation's tenant-wide fields — merged together and de-duplicated. So a client booking a treatment that asks for "Allergies" and also buying a voucher that asks for "Recipient name" sees a single form containing both. See Fields for how those selections are made.

A returning client's form is pre-filled from their profile; a guest's entries are remembered on their device in case they come back. One rule is enforced automatically: when there is an amount to pay, the billing address (street, postcode, city) becomes required even if you did not mark those fields required — Swiss receipts need it, and the backend insists on it too. Free or fully credit-covered bookings skip that. If you use a consent or terms field, it appears as a scroll-to-read agreement rather than a plain input, and a client who has already signed it is never asked twice.

Review, then pay — or confirm instantly

Most clients next see an order summary: their details, the booked items, the price breakdown with any voucher, credit and VAT lines, and a final total. (The order summary is skipped only when Express booking is on, or when there is nothing left to pay — see the next section.)

What the confirm button does depends on the total:

• Nothing left to pay — the whole amount is covered by account credit and/or a voucher (or the booking is free). The button shows a checkmark icon (its accessible label is "Confirm Booking"), and tapping it books everything immediately, with no payment provider involved. Behind the scenes the order is activated on the spot, credit and voucher balances are drawn down, and the client goes straight to the confirmation page.
• An amount is due — the button reads proceed to payment, and the client is redirected out to the payment provider to pay.

The payment step and how it reconciles

When money is owed, the checkout submit reaches the backend, which records a pending Payment row against the order and opens a session with your organisation's configured payment provider. You choose that provider under your organisation's Payments module settings. Select Saferpay — it is the only payment provider wired to checkout in this release. The dropdown also lists Stripe, Datatrans, Wallee / PostFinance and Adyen, but these are not yet connected; choosing one will stop payments from completing. The client is redirected to that provider's hosted page to enter card details. Nothing is booked yet at this point — the order sits in a Created state waiting on the outcome.

After paying, the provider redirects the client back to a confirmation URL carrying the order id and an outcome of success, fail, or abort. Here is the important part for reconciliation: that outcome word in the URL is only a hint — it is never trusted. On return, the app asks the backend to complete the payment, and the backend asks the payment provider directly what really happened. Only if the provider reports the transaction as Captured (the money actually taken) does the order get activated: the slot flips from held to a real booking, the payment is stamped as captured, the order is marked paid, and a receipt is produced. A client who tampered with the URL cannot fake a confirmation, and one whose card genuinely failed cannot be shown a false success.

Because a network hiccup or a closed browser tab can interrupt that redirect, there are two safety nets that make the order and the payment converge on their own:

• Provider webhooks. The payment provider independently notifies the backend of Authorised and Captured events. If a notification arrives while the order is still pending, it is logged for follow-up.
• A reconciliation worker. A background job periodically checks every still-pending payment against the provider. If the provider has the money but the order never finished (the classic "paid, then closed the tab" case), the worker recovers it — activating the booking automatically. If the provider reports no transaction and enough time has passed, the abandoned payment is safely cleared so the client can retry. Drift is written to your operations log, escalating in severity the longer it stays unresolved.

The practical upshot for you: the money and the booking are reconciled from the payment provider's record, not from what the browser did. A charged card will end up as a confirmed booking even if the customer's screen never showed it, and an uncharged one will never become a phantom booking. A failed or aborted payment leaves the order untouched and lets the client retry back through the payment provider (up to a configured attempt limit).

The confirmation page and receipt

On success the client lands on your confirmation page — your confirmation image, a thank-you, and a tidy list of every session (with its date, time and any per-session confirmation message) and every product they bought. A receipt PDF is generated for paid orders, and any purchased gift voucher gets its own code and PDF, all prepared just after the booking is activated. The cart is cleared, and reloading the confirmation later simply returns the client to the calendar rather than re-triggering anything.

Paid checkout requires the Booking and Payments (Orders) modules; vouchers, wallet credit and the "add a product" prompts each depend on their own module being enabled for your organisation.