One appointment, followed end to end
This guide is a commissioning checklist. It does not compare booking tools or recommend providers. It lists the decisions to settle and the failure cases to test when you commission a booking app that has to work with the calendar, payment account and message channels you already use.
Integration problems are easier to see in a real flow than in a feature list. Take one illustrative booking at a small salon: a customer books a 90-minute colour appointment with a stylist called Ana for Thursday at 2 pm, pays a deposit, gets a reminder, then needs to move it.
- The app reads Ana's availability, including her personal calendar, and shows Thursday 2 pm as open.
- The customer picks the slot. The app holds it while the customer pays.
- The card processor takes the deposit and tells the app the payment succeeded.
- The app confirms the booking, writes it to Ana's calendar and sends a confirmation email.
- The day before, the app sends a push reminder and an email.
- The customer cancels inside the free window. The app refunds the deposit and frees the slot.
Every numbered step touches an outside system. The sections below show how each step can go wrong and what the app should do about it.
Calendar conflicts
Ana added a dentist appointment to her phone calendar at 1:50 pm. If the app syncs her calendar every 15 minutes, it can show Thursday 2 pm as free for a few minutes after it stopped being free. Two-way sync narrows that gap but never closes it completely, and it adds permission screens and token refreshes for each staff member.
| Failure | What the customer sees | What the app should do |
|---|---|---|
| External event added after the last sync | A slot that looks open | Re-check the calendar at the moment of booking, before taking payment |
| Two customers pick the same slot | Both reach checkout | Hold the slot for the first person for a few minutes and release it if payment is abandoned |
| Staff calendar connection expires | Nothing, until a double booking happens | Alert the owner and the staff member, and fall back to app-only availability |
| Daylight saving or time zone change | Appointment shown an hour off | Store times in one standard form and display them in the customer's and the shop's local time |
Decide early which calendar is the source of truth. For most small businesses the app should own bookings and push them out to staff calendars, reading those calendars only to block busy time.
Deposits and payment edge cases
The payment processor and the app are two systems that must agree. The processor reports results through a webhook, a message it sends to your server, and that message can arrive late, twice or not at all.
- Payment succeeds but the booking fails to save: the app must either complete the booking from the webhook or refund automatically, and log it for staff.
- The bank asks for extra authentication and the customer closes the app: the slot hold expires and no booking is made.
- The webhook arrives twice: the app must recognise the duplicate and not create two bookings.
- The customer disputes the charge later: staff need the booking record, the policy shown at checkout and the payment reference in one place.
Appointments are services used outside the app, so Apple's App Review Guidelines (section 3.1.3(e)) direct those payments to methods other than in-app purchase, such as card entry or Apple Pay. If the same app also sells digital subscriptions, those generally need the stores' in-app purchase systems. Check the current Apple and Google rules for your markets during scoping.
Sources: [S8]: Apple Developer, App Review (opens in a new tab)
Cancellations, reschedules and no-shows
Cancellation is where business policy becomes code. The app needs your exact rules: how many hours before counts as free, whether a late cancellation keeps the deposit, whether a reschedule counts as a cancellation, and what happens when the salon cancels.
| Scenario | Typical rule to decide | Systems involved |
|---|---|---|
| Customer cancels inside the free window | Full deposit refund | Payments, calendar, email |
| Customer cancels late | Deposit kept, or partly refunded | Payments, email |
| Customer reschedules | Deposit moves to the new booking | Calendar, payments record |
| Salon cancels | Full refund and an apology message | Payments, calendar, push and email |
| Customer does not show | Staff marks a no-show; deposit kept | Admin, payments record |
Show the policy at checkout and in the confirmation email, in the same words the app uses to decide refunds.
When reminders fail
Reminders reduce no-shows only when they arrive. Each channel fails differently: push depends on the customer allowing notifications, email can land in spam, and SMS can be blocked or the customer may have opted out. The worst failure is a reminder for an appointment that was already cancelled.
- Cancel or update scheduled reminders whenever a booking changes.
- Fall back to email when push permission is off.
- Record each send and its delivery status so staff can check before calling a customer.
- Send at the right local time, and avoid the middle of the night for early-morning bookings.
- Include a reschedule link so a customer who cannot come frees the slot.
The commissioning checklist
Use this to brief a developer or review a quote
- Which calendar is the source of truth, and is sync one-way or two-way?
- How long is a slot held during checkout?
- What does staff see when a calendar connection breaks?
- Which payment processor, and is the merchant account in the business owner's name?
- What happens when a payment succeeds but the booking does not save?
- Are duplicate payment webhooks handled?
- Are cancellation, late cancellation, reschedule and no-show rules written down?
- Which reminder channels, at what times, with what fallback?
- Are reminders cancelled when a booking changes?
- Can staff see a log of payments, refunds and reminders for each booking?
- How are time zones and daylight saving handled?
- Which test cases cover each failure above?
Acceptance tests to run before you sign off the build
- Book a slot, then add a clashing event to the staff calendar and try to book the same slot again.
- Open checkout on two phones for the same slot and pay on both.
- Abandon a payment at the bank's authentication step and confirm the slot is released.
- Cancel inside and outside the free window and check each refund against the written policy.
- Reschedule a booking and confirm the old reminder is not sent.
- Turn off push permission and confirm the email fallback arrives.
- Disconnect a staff calendar and confirm the owner is alerted.
A quote that names these items is easier to trust than one that lists "calendar integration" as a single line. Our booking app cost guide shows how each integration changes the scope, and the app brief template gives you a format for writing it all down.
Getting integrations scoped
Bring the checklist answers you already know and mark the ones you do not. During discovery we turn them into user flows, a screen list and a test plan, and each integration appears in the written scope as its own line. See the booking app service page for a typical first version, or send your workflow for a quote.
Frequently asked questions
What integrations does a booking app need?
Usually a calendar, a payment processor for deposits and at least one reminder channel. Some businesses also need a customer database, accounting tool or point-of-sale system.
How do booking apps prevent double bookings?
By re-checking availability at the moment of booking, holding the slot during payment and treating one calendar as the source of truth.
Is two-way calendar sync worth it?
It helps when staff keep personal events in their own calendars, but it adds permission flows and failure cases. Many small businesses start with one-way export plus busy-time blocking.
Which reminder channel reduces no-shows best?
It depends on your customers. Push and email are the cheapest to run; SMS adds a per-message cost through your provider and is often read more reliably.
Who should own the payment account?
You should. The merchant account stays in your business's name, and the app connects to it.
Sources
- [S8] Apple Developer, App Review
- Apple Developer, App Review Guidelines
Written and reviewed by the DFY Games team. Published ; facts checked . Prices and store rules change: check the linked sources before you rely on a figure.