Client builds the booking
Service, route, format, package, extras and guest details become structured data instead of chat fragments.
Operational objective
The site sells the service, but the backend closes the operational gap. After payment, the system should notify the client and Collins without depending on manual copy-paste.
Flow
Service, route, format, package, extras and guest details become structured data instead of chat fragments.
The Stripe payload already includes guest info, route, package, extras and operator metadata for downstream dispatch.
Only verified `checkout.session.completed` events should trigger confirmations.
Email to client, email to Collins, WhatsApp to client and WhatsApp to Collins all originate from the paid booking payload.
Channels
Booking code, paid status, route, date, pickup time, add-ons, total paid and reply path.
Guest contacts, route, service type, add-ons, notes, pickup timing and operational reference.
Fast reassurance in the channel that most guests actually answer after paying.
The short operational brief that makes the next move instant instead of manual.
Stack
Checkout: Stripe Checkout session endpoint with brand-specific metadata support.
Verification: Stripe webhook signature verification inside Cloudflare Pages Functions.
Email: Resend-ready delivery path for client and owner messages.
WhatsApp: Twilio WhatsApp-ready delivery path for client and owner dispatch.
Idempotency: optional KV-backed notification ledger to avoid duplicate sends.
Implementation order
The remaining production steps are operational, not conceptual: real email identity, real WhatsApp sender, Stripe keys and webhook secret, then one end-to-end payment test with the owner contact values filled in.