Building Blue Canoe · 19 of 19
A Payment Is Not a Booking
What the next booking core has to establish before money and capacity can become a confirmed booking.
From a customer's point of view, booking ought to be straightforward. Choose something, pay for it and receive confirmation.
The software does not get to treat those steps as one event.
Capacity belongs to our system. Payment evidence comes from another system. The customer sees a third part of the journey in their browser. Each can reach a different point before a connection fails or a response arrives late.
The next booking core has made us deal explicitly with what happens between those steps.
The order is a business rule
It is tempting to give every booking the same sequence: hold a place, take payment, confirm it.
That is one model, not a universal rule.
In the revised design for TMS, the accepted sequence is to authorise payment, allocate capacity and then capture payment. Opening checkout does not itself reserve a place. Verified capture is required before the sale becomes confirmed.
Authorisation and capture are deliberately separate here. Permission to take money is not evidence that the money has been taken, just as an available place shown on a page is not evidence that it has been allocated to this customer.
Other explicitly selected policies can use a pre-payment hold. The important change is that the policy has a name and a defined sequence, rather than being an accidental consequence of whichever page happens to run first.
Uncertainty needs a state of its own
The awkward case is not always a clear rejection. Sometimes the system cannot yet establish whether an operation succeeded.
Repeating an action blindly may duplicate work. Assuming it failed may discard a real payment. Assuming it succeeded may promise capacity the system no longer has.
The accepted model therefore makes recovery explicit. It gives an indeterminate outcome a fixed deadline and starts reconciliation immediately. That deadline is a limit on uncertainty, not an intended delay for every customer.
It also defines the uncomfortable case where capture is confirmed after the allocation has expired. That becomes paid-but-unallocated work to resolve. It does not silently recreate a booking and hope capacity is still available.
Naming the state does not make it desirable. It makes it visible and gives the implementation something precise to handle.
Evidence has limits
By the September development records, we had moved beyond a diagram. The revised model and application work had been exercised against a real PostgreSQL database, including contention, rollback, restart and restricted-permission cases.
That is useful evidence. It is not proof of the complete customer journey.
The browser, payment-provider integration and end-to-end behaviour have their own boundaries to cross. This article describes a developing replacement, not a new platform already taking production bookings.
Confirmation is a promise
The customer should not have to think about any of this. They should receive a clear answer and a booking the business can fulfil.
Keeping that experience simple requires us to preserve distinctions internally. Chosen, allocated, authorised, paid and confirmed are related states, not interchangeable words.
A payment is not a booking. The job of the booking core is to bring the necessary facts together before telling somebody that it is.