B2B flight booking platform

A B2B travel platform for flight ticketing: travel agencies search availability, book, issue tickets, and settle against their own credit line, on top of supplier inventory.

Delivered for a client in the travel sector. Named details, figures, and outcomes are omitted — no permission to publish them has been given. What follows is the engineering, which is mine to describe.

The problem it solves

A travel agency’s day is a sequence of quotes. A customer asks about a route, the agent checks options across suppliers, quotes a price that includes the agency’s own margin, and books when the customer agrees — by which time the fare may have changed.

Without a system, that runs on supplier portals opened in separate tabs, prices copied into a spreadsheet, margin applied by hand, and issuance done through whichever portal held the booking. It is slow, it is error-prone in a way that costs real money, and nobody can tell you the agency’s exposure at any given moment.

What makes it hard

B2B travel is one of the most unforgiving integration problems in commercial software.

• Supplier inventory is external, slow, and inconsistent. Availability comes from systems you don’t control, with their own latency, their own error semantics, and their own idea of what a fare is. Search has to stay responsive while several of those are queried, and it has to degrade sensibly when one is unavailable rather than failing the whole search.
• Prices expire. A quote is only valid for a window. The system has to know the difference between a price it showed, a price that is still holdable, and a price that must be re-verified before money moves — and it has to explain that difference to an agent mid-conversation with a customer.
• Issuance is the point of no return. Everything before ticket issuance is reversible; issuance is not. That single fact drives the transaction design: the booking state machine, the idempotency of the issue call, and what happens when the supplier times out after committing.
• Money is layered. Supplier fare, agency margin, agency credit limit, and settlement are four separate concerns that all have to reconcile. Agency credit is the constraint that turns this from a booking tool into a financial system: the platform has to know, before authorizing a booking, whether this agency can cover it.

How I approached it

• The booking state machine before any screen. Every feature is a view onto it, so its states and transitions were defined first — including the ugly ones, where the supplier and the platform disagree about what happened.
• One integration boundary per supplier, with a shared internal representation. Suppliers change; the domain model shouldn’t. Adding a supplier is implementing an interface, not editing the search path.
• Idempotency everywhere money is involved. Retries are inevitable when calling external systems over unreliable networks. Double-issuing a ticket is not a bug you fix later.
• Observability from the first slice. With this many external calls, “it’s slow” is useless without knowing which supplier, on which route, at which step. Traces went in with the first feature, not after the first incident.

Where this is relevant to you

Any system that sits between customers and third-party supply — travel, logistics, insurance, wholesale — shares this shape: external inventory you don’t control, prices that expire, a commit step that can’t be undone, and credit or margin layered on top. The techniques transfer even when the industry doesn’t.