# Selling to agents and travellers from one inventory

> Running a trade portal and a consumer website on two systems means two allotments, two price lists and the same room sold twice. How one engine serves both, what each buyer sees, and how to price your website without undercutting your own agents.

*Source: https://itravel.cloud/blog/sell-b2b-and-b2c-from-one-inventory · published Nov 1, 2026 · topic: Running a portal*

You can sell to agents and travellers from one inventory if both channels book through the same engine: one allotment, taken under one lock, so a room sold on your website is gone for your agents that second. The price you store stays the trade net rate. A public price exists only once you set a retail markup for that kind of product, and the net is never published.

## What goes wrong when the website is a second system

Most operators who sell direct started with a separate website beside the agent portal. It works until the two disagree, and they disagree in predictable ways.

- **Two allotments.** Somebody moves ten rooms to the website for the season and forgets to move them back. The last room sells on both sides the same afternoon.
- **Two price lists.** A season changes on the portal and not on the website, and the public price ends up below what your agents pay.
- **Two sets of terms.** The website still shows last year's cancellation policy.
- **Two places to reconcile** at every month end.

None of these is a software bug. They are what happens when one product lives in two places.

In iTravel the website and the portal share one placement path. A sub-agent and a member of the public buy through the same pricing engines, from the same allotment, under the same lock; only the buyer, the price and the way they pay differ. So a room cannot be sold twice across the two channels, and a rate you change reaches both at once. It is the path behind the [one-cart booking engine](/b2b-travel-booking-engine) your agents already use.

## One stored price, five audiences

Be precise about the words, because "net" is used two ways in this trade.

- **Your cost** is what you pay the hotel, the tour operator or the transport company.
- **Your net rate** is the trade price you store on the product: what an agent with no tier pays you.
- **An agent's price** is your net adjusted by that agency's price tier: a discount for your best partners, a markup for newer ones.
- **The public price** is your net plus a retail markup you set for your [own travel website](/travel-website-builder).

Two things follow. The retail markup works on your net, not on any agent's tier price, so the gap between the public price and each tier is a number you choose. And changing the website markup changes the website only: what agents pay in the portal is untouched. The vocabulary is set out in [net rates, markup and agent tiers](/blog/net-rates-markup-and-agent-tiers).

Each person sees only their own part of that ladder:

| Who | What they see |
|---|---|
| You and your team | Cost, net, the tiers and markups you set, the margin |
| An agent | Their own price, never which tier they are on or how it was made |
| The agent's client | Whatever the agent quotes, from the agent's own markup |
| A traveller on your website | The public price |
| The supplier | No price on their copy |

Documents follow the same rule: a supplier copy carries no price, a trade copy the net, a traveller copy the retail price. With no retail markup set, the traveller copy carries no price rather than the net.

## How a public price is made, and when there is none

You set the retail markup in your website settings: one for hotels, one for tours, one for transfers, and a default for anything without its own. Each is a percentage or a flat amount per booking. A transfer and a five-night stay rarely carry the same margin, which is why it is set per kind of product.

The rules around it are strict on purpose:

1. **No markup, no price.** A product type without a markup shows "ask us for a price" and an enquiry form, never the net. Public prices cannot be switched on until a default markup exists, and the shop refuses a sale rather than fall back to the trade rate.
2. **Rounding goes up.** A public price that rounded down would sell below the margin you asked for. In currencies the public reads without decimals, such as the rupiah, the price rounds up to the whole unit, so the page, the basket and the charge show the same number.
3. **The markup is frozen on the sale.** A traveller who later changes their own booking is re-priced at the markup they bought at, not today's.

## What the website will not sell

One engine also means the website inherits your rules rather than going round them.

- **Lines you confirm yourself.** If a tour, a transfer route or a hotel rate plan is sold on request, the website does not sell it instantly: the visitor is told the operator confirms each booking and is offered an enquiry, and hotel pages leave rate plans on request out. Agents can still request it in the portal. Which lines deserve that is covered in [on request vs instant confirmation](/blog/on-request-vs-instant-confirmation).
- **Anything the portal would refuse.** The website shows published, sellable products only, so no shelf can advertise something the portal itself would not sell.
- **Packages, as an instant sale.** A package appears with its programme and next departures, and is sold by enquiry. Agents book packages in the portal.
- **Unpaid baskets for ever.** A website order holds real seats and rooms while the traveller pays, for the minutes you set (at least five), and is released through the normal cancellation path if the money never arrives.

## Channel conflict: pricing your website without undercutting your agents

This is the real decision, and it is yours. A partner who quotes a client and then watches that client find a lower price on your website will stop quoting you. Equally, you are entitled to sell to the public, especially in markets your agents never reach.

| Approach | How you set it | The trade-off |
|---|---|---|
| Protect the trade | Retail markup above your dearest tier plus what agents typically add | Agents are rarely undercut; your website wins less on price |
| Parity | Retail markup close to what agents typically charge | Fair to both; you need to know what agents add |
| Sell where agents are not | Price the website for your direct market | Simple; agents in that market will notice |
| Commission partners at your public price | Commission basis set to your website price | The agency is quoted your public price and earns commission on it |

The last row is a setting. For agencies you pay commission rather than sell to at net, you choose their gross: their tier price, your website price, or their tier price grossed up by the commission rate. The website basis needs a percentage markup for that product type; a type with a flat markup keeps the tier price, and the setting says so rather than choosing for you.

Agents, in turn, set their own client price. An agency's admin can add its own markup, as a percentage or a flat amount per person or per booking, and round it up to a whole number. It is private to the agency, nothing on your side reads it, and it never changes what you charge them.

## A worked example: one tour at net 40

Say you sell a half-day tour. The numbers are illustrative.

- Your cost from the operator: 30 per adult. Your net rate: 40.
- Tiers: A at minus 5%, B with no adjustment, C at plus 10%.
- Website markup for tours: 30%.
- Every agency adds 20% for its clients and rounds up to a whole unit.

| Buyer | Pays you | Their client pays | Your margin |
|---|---|---|---|
| Tier A agency | 38 | 46 (45.60 rounded up) | 8 |
| Tier B agency | 40 | 48 | 10 |
| Tier C agency | 44 | 53 (52.80 rounded up) | 14 |
| Traveller on your website | 52 | (none) | 22 |

Read it from each seat. The tier B agent's screen says *you pay 40, client pays 48, you earn 8*, and nothing about tiers or your cost. A tier B client who checks your website finds you 4 dearer; a tier C client finds you 1 cheaper than their own agent, exactly the undercut agents complain about. At a 40% website markup (56) your site sits above every agency's client price here. Whether that is the right place is your decision.

Now change one thing: a flat website markup of 12 per booking instead of 30%. A single traveller still pays 52. A party of four adults pays 160 + 12 = 172, which is 43 each: below the 44 your tier C agency pays you before adding anything. A flat amount per booking shrinks per person as the party grows; a percentage keeps the gap proportional. Both are legitimate. Test a large party against whichever you choose.

## Whose account the traveller pays into

The traveller pays you, through your own payment provider: your Stripe, Razorpay, PayPal or Flutterwave account, or bank transfer and pay on arrival. A rail is offered only after a live check of your credentials, and only if it can take your currency. You are the merchant of record; the money never passes through iTravel.

Agents keep paying as they do today: each booking is charged to their agency account inside the same transaction, from a prepaid balance or within the credit limit you set (see [agent credit and prepaid wallets](/blog/agent-credit-and-prepaid-wallets)). Website sales are charged to no agency account.

For a deposit now and the balance later, switch website deposits on and write the rule per kind of product or per product: a percentage or a fixed amount, the balance due the number of days before travel you choose, up to six payments in all. An overdue balance is shown to your desk; nothing is cancelled automatically.

iTravel's own per-booking service charge on a website sale is debited from your platform wallet once the traveller's money arrives, never taken out of the payment, and is not refunded if the booking is later cancelled.

## What to set up before you open the website shop

The shop opens only when five things are true: your plan includes selling to the public, your website is on, you have switched the shop on, a retail markup exists, and a payment rail has passed its check. Until then the [white-label portal](/white-label-travel-portal) sells to agents exactly as before. Then:

- **Write your public price policy** per product type, measured against your dearest tier plus what agents typically add.
- **Set a default retail markup**, then one each for hotels, tours and transfers where the margin differs.
- **Choose percentage or flat** for each, and price a party of four against a flat markup.
- **Mark what you confirm yourself as on request**, so the website asks instead of selling.
- **Decide how long an unpaid order may hold inventory**, and connect your own payment provider.
- **Write the booking terms and cancellation policy** the checkout shows.
- **Decide the commission basis** for agencies you pay commission to.
- **Tell your agents first** where the website's prices sit against theirs. They will find out either way.
- **Buy one product as a traveller**, cancel it, and read every email and document it produces.