📐 Diagram of the real flow, from the code in this repo

How a booking works

The full path of one booking — from picking an open slot to confirmed payment — exactly as implemented in the controllers and webhook.

Customer System / staff

Picks a service

Sees a list of the business's active bookable services.

BookingController@index

Picks an open time slot

Slots are generated for business hours (9am–5pm) and already-booked ones are removed — computed on the fly, never cached.

BookingController@create — availableSlots()

Overlap check

On submit, the server runs a real SQL check for whether the slot is already taken — prevents double-booking even from two simultaneous attempts.

Booking::scopeOverlapping()

Booking created as "pending"

Saved to the database with a pending status, and a Stripe Checkout session is created for payment.

StripeCheckoutService::createSessionForBooking()

Pays via Stripe Checkout

The customer is redirected to Stripe's own secure payment page.

Webhook confirms payment

Stripe notifies the server directly (not through the customer's browser) — the request's signature is verified before the booking is marked paid.

StripeWebhookController@handle

Sees the confirmation

A page with the booking's details — service, time, status.

BookingController@confirmation

Staff manage it from the dashboard

A staff-only view (behind login + admin check) lists all bookings and allows changing status — e.g. to "completed" after the appointment.

Admin\DashboardController

    Technical details
    Double-booking is technically impossible — the check happens at the database level (WHERE starts_at < ? AND ends_at > ?), not only in the frontend.
The webhook route explicitly excludes CSRF protection (Stripe isn't a logged-in browser) and instead verifies the cryptographically signed Stripe-Signature header.
A cancelled booking frees up the slot again — it's excluded from the overlap check.

  