How We Connected Online Payments and Instant Booking for a Riyadh Clinic

This is the first monthly build log. Each month I will take one real system I built or run, and explain the decisions behind it in plain language. No client numbers, no screenshots of private tools. Just what we built, why, and what a business owner should ask for.

This month: how Avant Clinics, a dermatology, aesthetics and laser clinic in Ar Rabi, Riyadh, started taking online payments and instant bookings on its own website.

The problem

A clinic website usually does two jobs badly. It shows offers the visitor cannot pay for, and it has a "book now" button that really means "send us a message and wait."

Avant wanted two things:

• Visitors should be able to buy a package or an offer online, with Mada or Apple Pay, and gift it to someone else.
• Visitors should be able to pick a real time with a real doctor, and have that appointment exist in the clinic's own system, not in an inbox.

Both sound simple. Both have the same trap: the moment money or a doctor's calendar is involved, "mostly works" is not good enough. A payment marked paid when it was not, or two patients booked into one slot, costs more trust than the feature earns.

Real payments have been live since August 2026, through Moyasar. Instant booking runs on the doctor pages and writes into Nixpend, the clinic management system the team already uses every day.

Three decisions did most of the work.

Decision 1: the signed webhook is the only source of truth for "paid"

When a visitor pays, two things can tell the website the payment went through. The visitor's browser coming back from the payment page, and a message the payment provider sends directly to our server, called a webhook.

The browser is not reliable. People close the tab, lose signal, or hit back. And anything the browser says can be faked.

So the rule is simple: only the webhook can confirm an order. The browser return only shows a "we are confirming your payment" page.

The webhook itself is treated with suspicion too:

• It must carry the correct secret, checked in a way that does not leak timing hints.
• The same event arriving twice is recognised and ignored, so a retry never confirms an order twice.
• The whole confirmation happens in one database transaction. Either everything is recorded, or nothing is.
• If the amount or currency does not match the order, the order is never confirmed. It waits for a human.

Once an order is paid, it issues a voucher. Gift orders issue an unbound voucher with a claim link. The person receiving the gift opens the link and binds it to their own name and phone number in one step, so two people cannot claim the same gift. If something goes wrong, reception can find and reissue a voucher from a staff page. Every paid order also queues an invoice request that the team closes once the invoice is issued in the clinic system.

Bookings do not take a deposit. Payments apply to packages and offers only, which keeps the booking flow short.

Decision 2: never double-book, even if it means "we will call you"

Instant booking lives on each doctor page. The visitor sees open slots for the next 14 days, in Riyadh time, pulled from the clinic system. They pick one, type their name, mobile number and sex, and give consent.

What happens next is where the care goes:

1. The server checks the slot again, fresh, at the moment of booking. A slot that was open a minute ago might not be now.
2. The patient is matched to an existing record in Nixpend, or registered if they are new.
3. Exactly one appointment is created in Nixpend.
4. A mirror row is written for reception, and the team gets a notification with no personal data in it.

The hard part is step 3 when the clinic system is slow.

If a request to create the appointment times out, we do not know whether it succeeded. Many systems would simply try again. But the clinic system does not offer a way to say "this is the same request as before" (what engineers call an idempotency key). Retrying could create a second appointment for the same patient.

So timeouts are never retried. The visitor sees a clear message that the clinic will call them, and reception gets a flag to confirm the booking by phone.

That is a deliberate trade. A small number of visitors get a phone call instead of an instant confirmation. In exchange, no doctor ever finds the same patient booked twice, and no slot gets taken by a ghost.

Decision 3: one reception queue, no matter how people book

Not every visitor wants to pick a slot. Some prefer to fill a form. Some prefer to ask a question first.

So there are three ways in:

• Instant booking on doctor pages, described above.
• A booking form with name, mobile, service, preferred date and time, and consent. The team confirms within 24 hours.
• An AI chat assistant on the site (Chatbase). If the visitor wants to book, it asks for explicit consent inside the chat before sending anything.

All three land in the same place: one reception board in the CMS, where every request shows up with its source. Reception does not check three inboxes. The front desk works one queue, with access limited by role.

For visitors who prefer WhatsApp, the coordinator team is one tap away as a fallback.

Hosting and compliance

Patient data is sensitive, and Saudi Arabia's Personal Data Protection Law (PDPL) cares where it lives. Every part of the platform runs in Google Cloud's Dammam region: the website and its APIs, the CMS, the database and the background worker that sends notifications. Private invoice files sit in their own private storage, separate from public media.

Compliance is not left to whoever edits the site that day. It is enforced by the database and the code:

• Service pages cannot go live without a Ministry of Health ad approval.
• Devices are gated on their SFDA clearance.
• Doctor titles come from a closed list that matches their licence, in correct Arabic grammar.
• Every form asks for explicit consent.
• Analytics, notifications and URLs carry no personal data.

If a rule matters, a person should not have to remember it.

For more on where Saudi data should live, read the guide to Saudi hosting compliance for founders.

What a clinic owner should ask their developer

You do not need to read code to protect your clinic. Ask these questions before you launch payments or online booking:

1. What marks an order as paid? If the answer is "the customer returns to the site," push back. It should be a signed message from the payment provider.
2. What happens if the payment provider sends the same message twice?
3. What happens if the amount paid does not match the order?
4. When someone books online, is the slot checked again at the moment they confirm?
5. If the clinic system is slow or down, what does the patient see, and could they end up booked twice?
6. Does every booking path (form, chat, instant booking, WhatsApp) end in one queue my team can see?
7. Where is patient data stored, and is it inside the Kingdom?
8. Which healthcare rules are enforced by the system, and which depend on someone remembering?
9. Do our analytics or notifications contain patient names or phone numbers?

A good developer will answer each one in a sentence. A vague answer is your signal to slow down.

What's next

Next month's build log will look at another live system. If you run a clinic and want the same setup, the full picture is in the case study, and the clinic systems page explains how we would approach yours.

Related reading

• Case study: Avant Clinics' website, booking, payments and CEO dashboard
• Clinic website, online booking and payments in Saudi Arabia
• AI for Clinics in Saudi Arabia: Intake, Follow-up, Compliance, and Trust