A booking system needs an authoritative rule for availability and a durable reservation state. A calendar display cannot by itself prevent conflicting bookings. Payment, staff assignment and cancellation must be coordinated without treating a browser response as final confirmation.
Choose the availability owner
In a hypothetical appointment service, a slot may depend on a staff member, location and resource. Define which system owns each constraint. External calendar events can affect availability, but the integration's sync delay must be understood rather than described as instant.
| State | Meaning | Next action |
|---|---|---|
| Held | Capacity temporarily reserved | Expire or proceed to confirmation |
| Payment pending | Payment outcome unresolved | Reconcile with the provider |
| Confirmed | Business conditions satisfied | Send confirmation and staff assignment |
| Canceled | Reservation no longer active | Apply refund and release rules |
Confirm payment through the backend
Stripe webhook delivery explains signature verification and duplicate or out-of-order Stripe events. Keep the booking linked to the payment operation. Repeated notifications must not send repeated confirmations or create extra appointments.
Make cancellation a complete workflow
Specify deadlines, refund rules, resource release and staff notification. If a refund fails, distinguish canceled booking from completed refund. Users need an accurate status rather than a generic success message.
What must be tested?
Two users requesting the last slot, hold expiry, delayed payment, calendar failure and repeated cancellation. Check time zones and daylight-saving transitions for the actual service locations. Use only authorized test accounts and payment test modes during acceptance.
For custom software, prepare availability constraints and a sale-to-cancellation example. Those rules determine scope more accurately than requesting “a booking calendar with payments”.