B2B travel portal development succeeds or fails on the requirements written before anyone codes. Specify inventory per kind, net rates and agency tiers, agency credit, holds and on-request lines, documents frozen at booking, payments, white-label, languages and currencies, accounting, an agency API, and security. For each one, name the edge case, because the edge cases are where home-built portals lose money.
Whether to build at all is a separate decision, covered in build or buy a white-label portal, and the questions for a vendor's demo are in ten questions to ask a B2B portal vendor. This page is the specification that sits between the two: what you hand over, phase by phase.
How to use this checklist
Each table below has three columns: the requirement, why it matters to a travel business that sells to agencies, and the edge case that breaks a portal built without it. Use it in two ways:
- With a developer: ask them to write, against every row, how it will be built and how they will prove the edge case before you accept the work.
- With a vendor: ask them to show the edge case on screen, on your own contract, not in their demo account.
One rule runs through all of it. Wherever the policy is yours (cancellation terms, release days, credit limits, markups, who may hold), the requirement is a setting you control, not a rule the developer hard-codes. A portal that bakes in one trade practice is a portal you will be asking to change every season.
Phase 1: inventory, one model per kind
Hotels, tours, transfers and packages are different shapes. A single "product with a price" table is how a portal ends up being rebuilt in year two. How each shape is loaded from a real contract is covered in loading contracted travel inventory.
| Requirement | Why it matters | The edge case that breaks it |
|---|---|---|
| Hotels as room type × rate plan × season, priced per occupancy, with child age bands | Hotel contracts are written that way; a nightly rate cannot hold them | A "Christmas peak" inside "high season": two seasons cover the night and the system picks the wrong one. Specify that the most specific season wins |
| Allotment per night, release days, stop-sale | You sell rooms you hold, and give them back on the date the contract says | Release judged on the server's clock rather than the hotel's, so rooms go back a day early or a day late |
| Tours with options, time slots, operating days and a booking cut-off | Agents book a departure, not a product | A cut-off judged in your office's time zone for a tour in another one; a date override that opens a weekday the tour does not run |
| Transfers per vehicle or per seat, priced per trip, per kilometre or per hour | Ground transport is priced all three ways | Route ends typed as free text, so a search from a hotel cannot find the route that serves it |
| Packages assembled from your own rooms and routes | A package should follow its parts | A package price that does not move when a component's season changes |
| A publish gate | Half-loaded products should not be on sale | A product published with no rate next month: the agent sees "available" and the checkout fails |
Phase 2: pricing, agencies and credit
| Requirement | Why it matters | The edge case that breaks it |
|---|---|---|
| One stored net rate; each agency's price derived from it by its tier | One rate sheet, many audiences | The tier is applied in two places, so the search card and the checkout disagree |
| Tier rules by product, destination, market or travel dates, most specific wins | Your best partner in one market is not your best everywhere | Two rules match one booking and both are applied |
| Product visibility per agency or tier | Some contracts are for named partners only | The hidden product is still reachable by its address or through the API |
| Net and commission agencies side by side | Some partners buy net, some earn commission | Commission worked out on a different gross from the one the agency was quoted |
| An account per agency: prepaid, a credit limit or none, days to pay, on hold | Credit is a decision per agency | Two agents of one agency spend the last of the credit in the same second, because the check and the charge are separate steps |
| Payment reports with proof, confirmed once | Much B2B money still arrives by bank transfer | Two clerks confirm the same transfer and the agency is credited twice |
| Registration and approval of new agencies | You vet before you trade | An applicant can book before anyone has checked their licence |
The pricing vocabulary is set out in net rates, markup and agent tiers; the vetting side in sub-agent registration and approval.
Phase 3: booking, holds, requests and changes
| Requirement | Why it matters | The edge case that breaks it |
|---|---|---|
| Availability taken inside the booking's own transaction, under a lock | Allotment is finite | Two agents take the last room at the same second; "we check availability first" is the race, not the fix |
| A cart that books all or nothing | Agents sell a hotel, a tour and a transfer together | Line two fails after line one has been charged |
| Holds with a deadline you set, per rate plan, tour or transfer | Agents need time to collect from their client | A hold whose deadline outlives the booking cut-off: a place reserved that nobody can confirm |
| On request per product, option, rate plan or route | Some lines you confirm by hand | A request charged at once and refunded on decline: two money movements where none was needed |
| Amendments re-priced through the same path as a new booking | Dates and names change | The preview promises one figure and the change charges another |
| Cancellation from the policy frozen at booking, previewed first | Terms change between seasons | The policy is edited after the sale and the cancellation charges the new terms |
Phase 4: documents, payments and white-label
| Requirement | Why it matters | The edge case that breaks it |
|---|---|---|
| Vouchers rendered from the booking's frozen snapshot, numbered and versioned | A voucher is a commitment | A voucher reprinted next year shows this year's policy |
| The audience decides the money: supplier copy no price, trade copy net, traveller copy retail | Three readers, three prices | The supplier copy prints your selling price |
| A QR on each document that a hotel desk can check | Front desks receive forged and cancelled vouchers | The check page shows prices and phone numbers to anyone who scans it |
| Agency money recorded, card payments on your own provider | You are the merchant of record | The platform sits in the money path, with its own settlement delay |
| Your brand on the portal, sign-in page, emails, documents and webhook headers | Agents must never meet the platform underneath | Confirmation emails arrive from the vendor's address |
Phase 5: languages, currencies, reports and accounting
| Requirement | Why it matters | The edge case that breaks it |
|---|---|---|
| Interface and emails in the agent's language; your product text stays as you typed it | Agencies are worldwide | A machine-translated hotel name on a voucher the hotel cannot match |
| Each agency buys in one currency; the rate frozen on every booking | Partners budget in their own money | A cancellation refunded at today's rate rather than the rate the sale froze |
| Amounts in each currency's own digits | Some currencies carry no decimals | "1,500,000.00" on a rupiah voucher |
| Several business entities on one account, each with its own number series | Many groups trade through more than one company | Two offices share one invoice series and create gaps |
| An accounting export of balanced vouchers per entity and currency | Your accountant should not re-key bookings | Cancellations exported as nothing, so revenue is overstated |
| Closed periods | Filed months must not move | A refund dated into a month already filed with the tax office |
What the accounting side needs in detail is in travel agency accounting software.
Phase 6: API, security and data
| Requirement | Why it matters | The edge case that breaks it |
|---|---|---|
| An agency booking API through the same booking path as the portal | Large agencies book from their own systems | The API prices on its own, so an agency sees one price on screen and another by machine |
| Test keys that cannot book | Integrations need rehearsal | Test bookings that consume real allotment |
| Idempotent writes | Networks time out | A retry after a timeout books twice |
| Signed booking webhooks with retries | The agency's system must hear about changes | An unsigned webhook anyone can forge |
| Roles and rights; nobody grants a right they do not hold | Accounts staff and reservations staff need different screens | One shared admin login for the whole office |
| Two-factor authentication and an activity log | People who move money must be accountable | A credit limit raised with no record of who raised it |
| Erasing a person without deleting money records | Privacy law and accounting law both apply | Deleting a sub-agent deletes their bookings |
The API is covered in the B2B travel API for agencies.
A worked example: one booking that tests nine rows
The figures are illustrative. Your books are in euros. Agency K buys in US dollars on a tier that adds 10%, with a credit limit of 5,000 USD, of which 4,000 is used. You hold an allotment of 10 rooms a night at one hotel.
- An agent of Agency K holds 2 rooms for 3 nights at a net of 100 EUR per room per night: 600 EUR, 660 EUR at the tier, 726 USD at a selling rate of 1.10. The available credit is checked; nothing is charged. (Tiers, currency, holds.)
- The agent confirms before the deadline. 726 USD is charged inside the booking; 274 USD of credit remains. (Agency account.)
- A minute later a colleague at Agency K tries to book a 300 USD transfer. It is refused and nothing it touched is kept; had the two bookings arrived in the same second, the lock would still have let only one through. (Credit check inside the transaction.)
- You change the hotel's cancellation terms for next season. The booking keeps the terms it was sold on. (Frozen policy.)
- Two days before arrival, the agency cancels one room. Its share is 363 USD; say the frozen terms keep one night, 121 USD. The preview says 242 USD back to the account, and the cancellation does exactly that, at the rate of 1.10. (Preview equals result, frozen rate.)
- The month's export carries a sales invoice to Agency K for the stay, then a credit note for the cancelled room and the kept night on your cancellation-fees ledger, each line also in euros at the rate the sale froze. (Accounting.)
If a candidate system cannot walk through those six steps with your own contract loaded, the requirement is not met, however the demo looked.
What a ready platform already answers
Here is where iTravel's Portal stands against this list today. It holds hotels by room type, rate plan and season with per-night allotment and release days; tours with options, slots, operating days and a cut-off in the product's own time zone; transfers per trip, per kilometre or per hour; and, once you switch them on, packages built from your own units. It prices through one engine per kind, applies the agency's tier once, and charges the agency's account inside the booking, refusing what the account cannot carry. Holds and on-request lines follow the hours you set, and nothing is charged until they are confirmed.
Vouchers render from the booking's snapshot, the supplier copy carries no price, and each document carries a QR a hotel can check. Agencies can buy in their own currency at a frozen rate; the accounting export writes Tally Prime, Xero and QuickBooks Online files and a journal per business entity and currency; closed periods are locked. The agency booking API is switched on per agency, with test keys that roll back. Two-factor authentication, roles and an activity log are in place, and mail can leave from your own mail server once you connect it.
Two things to know before you assume: Portal sells the inventory you contract and load yourself, not a third-party hotel feed, and packages are booked in the portal, not through the agency API.
