A common shortcut in booking systems is a single status column: pending, confirmed, completed, paid. It looks tidy until the first time a trip is completed and the card fails, or a customer is charged
Markdown supported · ⌘↵ to post
"A completed trip is not proof of payment" is the sentence a lot of booking systems learn the hard way. Keeping trip status and payment status as two state machines means a failed capture does not have to pretend the ride never happened.
The authorisation window is the detail I would flag for any owner commissioning a system like this. If a card authorisation lasts about seven days, a booking made two weeks ahead cannot be authorised at booking time, so the rule for when to charge has to be a business decision and not something the developer guesses.
Making capture policy configurable and transitions idempotent also covers the retries and duplicate webhooks that always appear in production.
At Ascendra Ventures we ask clients to settle rules like these before we build a booking flow, because they change the data model. How do you handle a trip that is completed but whose capture keeps failing?
Praneet Brar
Building cool things like launch platforms
"A completed trip is not proof of payment" is a good rule to write down. For the authorise-now, capture-later case with bookings made weeks ahead, do you re-authorise before pickup, or capture a different way once the roughly seven-day authorisation window runs out?