Systems I build
B2B travel booking system
A B2B travel booking system is the platform a travel agency works inside: it searches availability across the suppliers the agency has contracts with, applies the agency's own margin, holds and books, issues tickets, and settles the result against that agency's credit line. What makes it a financial system rather than a search tool is the layer underneath — fares that expire between the quote and the payment, an issuance step that cannot be undone, and a credit limit the platform has to check before it authorizes anything. I have built one of these, from the booking state machine through supplier integration to reconciliation.
A booking and ticketing platform for travel agencies — supplier search, expiring fares, irreversible issuance, agency credit, and margin, in one system.
Who needs a B2B travel booking system?
You need a B2B travel booking system when your agency’s day is a sequence of quotes and the quoting happens across supplier portals in separate browser tabs. A customer asks about a route, someone checks options across suppliers, copies prices into a spreadsheet, applies margin by hand, and issues through whichever portal held the booking. It is slow, it is error-prone in a way that costs money directly, and nobody can state the agency’s exposure at any given moment.
This page is for:
- A travel agency that has outgrown supplier portals and manual quoting.
- A consolidator or wholesaler selling to sub-agencies, where agency credit, margin, and settlement are the actual product.
- A travel business with a system already in place whose problems are underneath the features — fare validity, issuance failures, or reconciliation that only balances after someone spends a day on it.
The same shape appears outside travel. Any system sitting between customers and third-party supply — logistics, insurance, wholesale — has external inventory it does not control, prices that expire, a commit step that cannot be undone, and credit or margin layered on top. If that describes your system, this page is about your problem even though the industry is different.
What does a booking and ticketing platform include?
A booking and ticketing platform covers the full lifecycle: business analysis and product planning, architecture and system design, development and delivery, cloud deployment and scaling, and App Store releases where there is a mobile surface. For this kind of platform specifically, the substance is:
- The booking state machine — every state and transition, including the ones where the supplier and the platform disagree about what happened.
- Multi-supplier search with a shared internal representation, staying responsive under external latency and degrading sensibly when a supplier is unavailable.
- Fare validity handling — the difference between a price shown, a price still holdable, and a price that must be re-verified before money moves, represented in the model and explained in the interface.
- Margin rules — how the agency’s margin is defined, applied, and overridden, as configuration rather than code.
- Ticket issuance, treated as the point of no return: idempotent calls, explicit handling of the timeout-after-commit case, and reconciliation against the supplier.
- Agency credit and exposure — limits checked before authorization, balances maintained, and total exposure visible rather than derived at month end.
- Settlement and reconciliation across supplier fare, margin, credit, and payment.
- Observability across every external call, so a slow search is a question with an answer.
- Back-office tooling for the corrections, cancellations, and exceptions that will happen in week one.
How does a booking platform build run?
On a booking platform the state machine comes before any screen. Every feature in a platform like this is a view onto that state machine, so its states and transitions get defined first — including the ugly ones — and agreed with the business before anything is built on top of them.
Then:
- Business analysis and product planning — which suppliers you hold contracts with, how margin is set, how credit is granted and settled, and what today’s manual process actually does, including the parts nobody has written down.
- Architecture and system design — the state machine, one integration boundary per supplier, the money model, and the idempotency guarantees around every irreversible step.
- Development and delivery — a modular monolith by default, with search, booking, issuance, credit, and settlement as separate modules behind clear interfaces.
- Cloud deployment and scaling — environments plus tracing from the first slice, because external-call latency is the dominant performance question here.
- App Store releases where agents work from a phone.
The reason this works is not travel-domain trivia. It is that fare validity, credit limits, margin, and settlement are business rules first and code second. A developer handed a feature list will build the feature list correctly and still produce a system that authorizes a booking an agency cannot cover, because that question was never asked. Understanding the technical system and the business it has to serve is exactly what stops that happening — and on this kind of platform, it is the difference between a booking tool and a system the finance side can trust.
Questions about this work
How is a B2B booking system different from a consumer booking site?
A consumer site sells a seat to a person who pays for it immediately. A B2B system sells through agencies, which changes three things structurally. Margin is the agency's, applied on top of the supplier fare and configurable rather than fixed. Payment is usually credit rather than a card, so the platform has to know whether an agency can cover a booking before it authorizes one. And the platform owner carries exposure across every agency at once, which has to be visible at any moment rather than reconstructed at month end. That is why this is a financial system with a search interface on it, not the reverse.
What happens when a fare expires while the customer is still deciding?
The system has to distinguish three things that look identical on screen: a price it showed, a price that is still holdable, and a price that must be re-verified before money moves. Treating them as one number is where agencies lose real money. The harder half is the interface: an agent is mid-conversation with a customer, so the difference has to be explained in a way that is usable at that moment, not buried in a status field. Fare validity is designed into the booking state machine rather than handled as an error case.
What happens if a supplier times out after it has already issued the ticket?
This is the case the whole transaction design exists for. Everything before issuance is reversible and issuance is not, so the issue call is idempotent, the booking state machine has explicit states for "the supplier and we disagree about what happened", and reconciliation against the supplier is part of the system rather than a manual cleanup task. Retries are normal traffic when you are calling external systems over unreliable networks. Double-issuing a ticket is not a bug you fix in the next release.
Can more suppliers be added later, or is the first one baked in?
Added later, if it is built correctly the first time. Each supplier gets one integration boundary translating into a shared internal representation, so the domain model does not change shape when a supplier does. Adding a supplier is then implementing an interface, not editing the search path. Suppliers change their APIs, their error semantics, and occasionally their idea of what a fare is; the point of that boundary is that those changes stay contained.
How does the system handle agency credit limits?
Credit is checked before a booking is authorized, not reconciled afterwards, which is the decision that turns a booking tool into a financial system. Supplier fare, agency margin, agency credit limit, and settlement are four separate concerns that all have to reconcile with each other, and the platform has to be able to state an agency's exposure — and the total across agencies — at any moment. Settlement rules are business rules: they get agreed with you explicitly and modelled, rather than inferred from how the previous spreadsheet behaved.
What happens to a search when one supplier is slow or down?
It degrades rather than fails. Search stays responsive while several external systems with their own latency and their own error semantics are queried, and an unavailable supplier removes its own results instead of failing the whole search. Making that behaviour diagnosable needs observability from the first slice of the build: with this many external calls, "it is slow" tells you nothing without knowing which supplier, on which route, at which step. Traces go in with the first feature, not after the first incident.
B2B travel booking system — tell me what you're working with.
Start a conversation