A B2B booking system is a closed portal where your partners check availability, book and immediately see their own net price with commission. The industry calls it a b2b booking system or a partner portal: it is not part of your public offer, you get in by logging in, and every account sees its own terms. The goal is one thing - the end of phone calls along the lines of “do you still have two rooms on 14 August and what does that come to for us”. If what you need is a calendar for a guesthouse or a B&B, that is a different topic, covered in the piece on a booking system for a guesthouse.
How a B2B booking system differs from an ordinary store
The difference is fundamental: in a B2C store there is one price for everybody, in a B2B portal the price is a function of the account. Same package, same dates, and three partners see three different amounts, because they have different commissions, volume tiers and payment terms.
On top of that come things B2C does not have at all:
- Registration with approval - an account does not work the moment somebody clicks, only after the company is verified
- Availability that is alive - a slot sold at the supplier has to disappear from your portal before somebody books it a second time
- An option before purchase - in travel it is standard to hold a date for a dozen or so hours rather than take payment instantly
- Periodic settlement - a partner does not pay by card on every booking, but against a credit limit or a deposit
- Documents - booking confirmation, a voucher for the end customer, an invoice for the partner
If that sounds like a description of an ordering panel, it should - technically this is a close relative of a B2B ordering panel for trade customers, except that instead of stock levels it guards a calendar and dates.
What a partner portal has to do - the minimum scope
Version one does not need everything. It needs enough that the partner stops calling. That usually means seven things:
| Feature | What it is for | Priority |
|---|---|---|
| Login and roles (account owner, booking agent) | Everyone sees only their own bookings | Version 1 |
| Search with availability | Dates, headcount, filters | Version 1 |
| Price per account (net + commission) | The whole point of the portal | Version 1 |
| Booking with an option and an expiry time | Holding a slot without payment | Version 1 |
| Booking history and downloadable documents | The end of “please send me that voucher again” | Version 1 |
| Settlements: balance, limit, invoices | Closes the money loop | Version 2 |
| A panel for your own team | Overview, corrections, manual intervention | Version 1 |
Deliberately push to later: a mobile app, multiple languages, currency rates, a report builder. Each of them can push the budget up sharply, and none of them decides whether a partner starts booking on their own.
Where the portal gets real-time availability from
Real-time availability is not magic, it is a regular question to a data source plus honest handling of the moment the source goes quiet. In practice there are three sources:
- Your own database - you keep the calendar and decide the number of slots yourself. Simplest, most reliable, fully under your control.
- The supplier’s API - a tour operator, hotel, carrier or a channel manager exposes an availability and booking query. Your portal is then a middle layer.
- An XML or CSV file from the supplier - refreshed at intervals. Cheap to build, but the data is always slightly stale.
For the last two, three rules are worth not breaking. First, a cache with a short lifetime - you do not query the supplier on every mouse movement, you hold the answer for a few minutes. Second, confirmation right before the write - before a booking becomes a fact, the portal asks the source once more whether the slot is still there. Third, a plan B for a supplier outage - the portal shows “we are checking availability, we will confirm within an hour” and creates a request for your team, instead of serving a blank page. A partner portal is only as stable as the weakest system it plugs into, so failure scenarios get designed from day one.
Commissions and per-account pricing - how to calculate it
A partner’s price is the base price minus their terms, applied in a predetermined order. Without a fixed order the chaos starts: two discounts stack and suddenly you are selling below cost.
The typical models I see with clients:
| Model | How it works | When it fits |
|---|---|---|
| Percentage commission | The partner buys at a set percentage less | The standard in travel |
| Net price list per group | Partners split into tiers, each with its own table | When the differences are large and stable |
| Commission + volume bonus | A base plus a top-up once a threshold is crossed | Loyalty programmes |
| Partner markup | The partner adds their own margin for the end customer | When the partner sells under their own brand |
A practical tip: keep one base price and rules held separately in the system, instead of uploading ten parallel price lists - changing the price of a package should be a single operation. And always show the partner the breakdown: list price, their commission, amount to pay. A portal where the partner does not understand where a number came from generates more phone calls than a spreadsheet in an email.
B2B payments - different from retail
A B2B payment is rarely instant, because a company buying on behalf of its own clients needs flexibility in timing. The realistic variants you can combine in one portal:
- Online prepayment - a fast payment gateway, useful with new partners and small bookings
- Deposit and balance - part on booking, the rest before the travel date, with an automatic reminder
- Credit limit - the partner books up to an approved limit and settles periodically. The portal watches the balance and blocks anything over it
- Deposit account - the partner pays a sum up front and every booking draws it down
When picking a gateway, what counts is not the transaction cost but whether it handles partial refunds and deferred payments. I compared the options separately in the piece on WooCommerce payment gateways; provider commissions change often enough that I always check the current price list at the source before deciding.
Invoices are a separate topic. KSeF, Poland’s mandatory national e-invoicing system, is in force: the largest taxpayers from February 2026, everyone else from April 2026. A portal that issues invoices therefore needs a planned route for the document into accounting and on into KSeF - either through accounting software or through your own API integration. This is not something to bolt on at the end of a project, because it affects what data you collect when a partner registers.
Partner registration and verification
A partner account should come into being in two steps: the partner fills in a form, you approve it. Automatic approval is a straight road to accounts opened by competitors and by retail customers hunting for wholesale prices.
The minimum data: company name, NIP (the Polish VAT and tax ID), address, contact person, phone and work email. It is worth checking the NIP against public registers right away - that is a single query and it filters out a lot of random sign-ups. I covered the whole process, including roles, in more depth in the piece on B2B account verification. Plus two things that are easy to forget: terms of cooperation accepted inside the portal (with the date and version recorded) and multiple users in one company - the agent books, the owner sees everything and manages the limit.
What to build it on
The technology choice depends on how unusual your booking logic is. Three sensible routes:
| Solution | When it works | Risk |
|---|---|---|
| WooCommerce with a B2B layer | The catalogue is simple, dates mean a date and a headcount | Complex availability gets cramped fast |
| Hybrid: WooCommerce plus a custom module | Sales and payments standard, but the booking engine is your own | Needs a proper plan, not the first plugin you find |
| Fully custom system (Laravel) | Many availability sources, complex pricing rules, heavy partner traffic | Higher start-up cost, but predictable growth |
Most often the middle option wins. Woo gives you ready accounts, cart, payments, invoices and an order panel, while the booking layer is built for your logic instead of being bent out of a bike-rental plugin. The date mechanism in Woo itself I walk through in the piece on booking and rentals in WooCommerce.
Off-the-shelf B2B system or a custom booking portal - what to pick for a travel agency
The question I hear most often: does a travel agency with a dozen or so partners need its own portal, or is an off-the-shelf B2B system on a subscription enough? The answer depends on three things: where your availability comes from, how complex your commissions are and how many partners are going to book.
An off-the-shelf B2B system for travel is usually sold as a bundle: an agent portal, a booking engine, credit limits, vouchers under your brand. If you sell one kind of product, the commission is a flat percentage and you have a few dozen partners, a subscription can be the fastest route. You pay for it in two ways: a monthly fee that never goes down, and booking logic that works the way the vendor imagined it. An unusual product, say a group trip with a participant list or a package assembled from several sources, rarely fits.
A custom B2B platform makes sense when the booking portal has to mirror your process rather than the vendor’s: your own availability sources, commissions calculated in several steps, documents in your layout. It costs more at the start, but with a few dozen agents a per-account subscription can outgrow the cost of your own portal, and development moves at your pace. I laid out the differences between the two routes in the piece on off-the-shelf versus custom B2B platforms, and the basics in what a B2B system is.
The middle route I recommend most often is a B2B panel built onto a store: accounts, price lists and payments come from WooCommerce, while the calendar and booking rules are written for you. That is how I build B2B stores and portals on WooCommerce - the partner sees one portal, and you do not pay for features you never use.
How long it takes and where to start
A partner portal in version one is a project measured in weeks, not months, provided the scope is cut honestly. With me these builds run as a fixed-price project, with a written quote after a conversation, billed in stages. Development after launch goes in as further stages or under ongoing maintenance - plans and prices are on the support page. I compared the cost of the different variants in the piece on what a B2B platform costs.
I start with a diagnosis: a conversation about how bookings flow today, what availability sources you have and how many partners are meant to use this. Out of that comes a feature list split into version one and version two, and only then a quote. If it turns out that polishing your existing store is enough rather than building a portal from scratch, I will say so plainly.
Frequently asked questions
What is a b2b booking system? It is a booking system available only to verified partner companies, behind a login. It shows availability, the individual price for that account, and lets them book without contacting your office. The main difference from an ordinary store is that price and terms depend on who is looking.
Can a B2B booking system be built on WordPress and WooCommerce? Yes, as long as the booking logic is not very unusual. Woo handles company accounts, per-group price lists, payments and invoices well, and an availability module can be written on top of it for your specific sales model. With many availability sources and complex pricing rules, a hybrid with a custom engine often makes more sense.
How do you connect the portal to a supplier’s system? Through the supplier’s API if they expose one, or through a scheduled import of a file with the offer and availability. The critical parts are re-checking availability right before the booking is written and having a planned scenario for when the supplier’s system does not respond. Without that, sooner or later you will sell the same slot twice.
How long does a partner portal take to build? The first working version is usually a few weeks, counted from the moment the scope is closed. The biggest influence on the date is not the code but access to supplier data and decisions on your side about commissions and payment terms. That is why I agree scope and schedule in writing before the start, together with the price.
Building an application, a panel or an integration rather than a website? I write B2B systems to order - backends, APIs, client panels, billing modules. Let’s talk about your project.