Security & privacy
Payments and cards
BookingSimple never touches card numbers, security codes or expiry dates. Stripe collects them in its own secure frame on the booking page, so our pages, our database and our logs never see them.
Where the card number goes
BookingSimple's pages, database and logs: never
Every patient charge is made on the clinic's own Stripe account. Funds settle with the clinic, not with us, and refunds come from the clinic's balance. BookingSimple takes 0% commission.
We never put patient names, emails, phone numbers, treatment names or clinical details in Stripe's metadata. It holds only neutral references: the appointment, the payment and the clinic's web address. The patient's name and email go on Stripe's customer record, a standard Stripe field with its own protections.
Stripe is the source of truth for every payment, refund and no-show charge. Its messages to us are signed, and we check every signature. A repeated or replayed message never charges or refunds twice, and never moves an appointment backwards.
A no-show charge is only possible when the patient ticks a consent box at booking and saves their card with Stripe, passing their bank's 3-D Secure check if the bank asks for one. We keep a copy of the wording they saw, when they agreed and, where available, their IP address and browser.
Patient data
BookingSimple runs on AWS in London (eu-west-2). Some providers we rely on, such as Cloudflare, Stripe, Resend (which sends from Ireland and keeps email records in the US) and Sentry (EU region), process data outside that server, as our privacy notice explains. We design with UK GDPR in mind. Patient data is never sold. It is shared only with the providers listed in our privacy notice, such as Stripe for payments and our email delivery provider for booking emails.
Every clinic's data sits behind a boundary tied to its own web address. Staff at one clinic can't see another clinic's patients or appointments, even with a forged request. We test this on every release.
The database is backed up every night, and each backup is checked before it is kept. We keep the last 14 nightly backups, and the founder is alerted if one fails. Webhook delivery failures, 5xx errors and payment-side anomalies also alert the founder, not the clinic. We want to know first.
We use Sentry in its EU region to catch errors. Reports are stripped of request bodies, user identity and message text before they leave our server.
Owners and admins can anonymise a patient on request. Their name, email, phone and notes are removed and their links stop working, while payment and audit records are kept. It can't be done while the patient has a future booking.
Booking pages set no advertising or analytics cookies. They use a security cookie, and when the card step loads, Stripe may set its own fraud-prevention cookies. This website sets none.
We're happy to walk through the architecture, how Stripe's messages are checked, our backups and the activity log with anyone who wants the depth.