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: authenticate the payment notification before marking "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: do not blindly retry an uncertain booking

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 integration used for this build did 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. Visitors affected by an uncertain result get reception review instead of an instant confirmation. It avoids creating a second appointment through a blind retry. It does not establish that all duplicate bookings or scheduling conflicts are impossible; reception still needs to reconcile the clinic record.

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

The core application described in this build 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.

That describes the components we host. It does not establish the location of every third-party processor. Moyasar, Nixpend, Chatbase and notification services need their own review of data flows, retention, subprocessors and applicable requirements. Hosting the core application in Saudi Arabia does not by itself establish PDPL or healthcare compliance.

The implementation includes database and code checks that support the clinic's publishing process:

• 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.

These checks help staff apply the publishing rules consistently. The clinic still owns the accuracy of approval and licence records, the permissions granted to providers, and the appropriate professional and legal review. A field or database constraint is not an independent compliance certificate.

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. Ask how the server authenticates the provider notification, checks the amount and currency, and handles duplicate events. This build checks a configured shared secret; providers may support different verification mechanisms.
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. Do the website's booking paths reach one queue, and how are WhatsApp requests added or reconciled by staff?
7. Where does patient data pass and remain, including third-party processors, logs, files and backups? Which requirements apply to each flow?
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