How B2B Travel Buyers Book: Wallets, Credit and Net Rate Settlement

If you have only ever built consumer checkouts, the first time you watch a trade buyer work is disorienting. They do not browse. They do not compare. They have a client on the phone, they need eight seats on the 14th, and they need to know in the next ninety seconds whether they can promise it.

Everything about a B2B booking flow follows from that. Speed over discovery, certainty over persuasion, and a payment model that does not involve typing card details while someone waits.

Why not just take a card?

Several reasons, all of them practical.

• Volume. A partner making four hundred bookings a month does not want four hundred card transactions to reconcile, and their finance team will refuse.
• Fees. Card fees on a thin wholesale margin can consume a meaningful share of it.
• Authority. The person making the booking is often not the person authorised to spend, so a card in hand is the exception.
• Cross-border. International card payments decline at rates that would be unacceptable when a client is waiting.
• Refunds. Reversing a card payment takes days. Crediting a wallet takes no time at all.

So wholesale settles differently, and there are two models that work.

The prefunded wallet

The partner transfers funds up front. The balance sits in their account. Bookings draw against it.

This is the default for new partners because it carries no credit risk, and it is genuinely better for the buyer too: no per-booking payment step, instant refunds, and a running balance they can see.

The mechanics that make it work are worth getting right.

Hold, then capture

When a booking is reserved, funds are held rather than spent. The balance is unchanged, but the held amount increases and the available amount falls. If the reservation expires, the hold is released and nothing ever moved.

Only on confirmation does the hold become a debit. This mirrors exactly how the inventory hold works, which is the point: money and seats move together or not at all.

One currency, converted on the way in

A partner in Stockholm wants to fund in euros. A partner in Dubai wants dirhams. Holding a separate balance per currency means every refund raises the question of which pot it goes back to, and every FX movement creates an unrealised gain nobody asked for.

Convert on the way in, bank one currency, and record what they actually sent alongside the rate used. The partner sees both, the ledger stays simple .

Every movement is a ledger line

Top-up, hold, release, purchase, refund, adjustment. Each one writes an immutable row carrying the resulting balance. Never update a balance without writing the line that explains it.

This sounds like bookkeeping pedantry until the first time a partner disputes a figure. With a ledger it takes two minutes. Without one it takes a week and you will probably concede.

Credit terms

Established partners will eventually ask for credit, and the request is reasonable. They are bringing volume and they do not want working capital tied up in a float.

Credit is the same wallet with a negative floor. The partner can spend past zero, down to an agreed limit, and settles on terms. The implementation detail that matters is that the limit is checked at hold time, not at confirm time, so a partner cannot hold their way past their ceiling.

What trade buyers need to see

Beyond the money, there is a set of things a trade partner needs before they will put real volume through you. Most platforms get about half of them.

1. Net rates, clearly labelled as net, separate from any retail or recommended price.
2. A recommended selling price, so their agents do not have to calculate one.
3. A minimum selling price, so they know the floor they agreed to.
4. Real availability, not a request form. A trade buyer will not sell what they cannot confirm.
5. Cancellation terms as structured data, not prose, so their system can display the deadline.
6. Their own reference on every booking, so it reconciles against their system rather than yours.
7. A booking list they can filter and export.
8. A sandbox with test credentials, so their developer can integrate without spending money.

Number six is underrated. A partner reference field that flows through from booking to voucher to invoice is the difference between a partner who reconciles automatically and a partner whose finance team hates you.

The booking flow itself

Put together, a trade booking looks like this.

1. Search availability for a product, option and date range. Net prices come back in the same response.
2. Reserve. Seats are held, funds are held, an expiry is set, the booking is on hold.
3. The partner confirms with their client and takes their own payment, on their own terms.
4. Confirm. Funds are captured, seats committed, vouchers issued immediately.
5. If the client cancels, cancel through the API. The refund ladder is applied and the wallet is credited the same second.

Step two and three are what the whole design exists for. The partner gets a guaranteed price and a guaranteed seat while they are still on the phone, and if the client says no, nothing happened. No refund, no reversal, no reconciliation.

Refunds without pain

The refund advantage of a wallet is large enough to be a selling point on its own.

A card refund is a reversal: days to settle, possibly non-refunded fees, a statement line the client has to be told about. A wallet refund is a credit line in a ledger, available for the partner's next booking within the same second.

Apply the cancellation terms that were captured when the booking was made, not the terms currently configured. Suppliers change their policies, and a booking made under a 100 per cent refund window must keep that window even if the policy tightened afterwards. Storing the applicable terms on the booking is the only reliable way to honour that.