A booking system that never says our name
izBooking is the platform a travel business sells on when it wants the booking, the price and the confirmation email to come from one place — and wants all of it to carry its own brand rather than ours. It runs more than a thousand merchant sites today.
What izBooking actually is
izBooking is a booking platform for travel businesses: tours, transfers, day activities and packages. It holds your products, your departure dates, your prices and your remaining places, it takes the money, and it sends the confirmation. Everything a guest touches carries your name.
The problem it exists for is not that operators cannot take bookings. They can — by email, by phone, by a form that lands in an inbox, by a spreadsheet a manager keeps open all day. The problem is that each of those places holds its own version of how many seats are left, and none of them tells the others when one changes.
So a request sits unanswered for six hours because it arrived on a Saturday, an agent quotes last season's price because that is the sheet they have, and two people sell the same cabin on the same boat. Every one of those is the same fault: no single number is true, so a human has to be the reconciliation layer.
izBooking is not a website with a calendar on it. It is the place where availability and price are decided, so the website, the agent, the phone and the OTA listing all read the same figure instead of arguing.
What running under your brand means
White-label is a word used loosely, so here is what it means in practice. Your guest books on your domain. The pages carry your logo, your colours and your language. The confirmation email arrives from your address. The line on the guest's card statement is your merchant name, because the payment account is yours, not a pooled one we own.
There is no izBooking badge in the footer and no point in the flow where the guest learns there is a supplier behind you. That matters commercially: a guest who realises mid-checkout that they have been handed to a third party often stops and looks for a better price.
- Your domain, your brand, your confirmation email and your merchant descriptor.
- Your customer records belong to you, not to a marketplace that also sells to them.
- Multiple languages and currencies on one product, so it does not have to be duplicated per market.
- Your own commercial rules — deposits, options, child pricing, seasonal rates.
How a booking moves through it
The interesting part of a booking engine is not the screens. It is what happens in the seconds when two people want the same place, and what happens when the money step fails. That behaviour is the product.
- A guest picks a date and an option. The system answers from live availability, not from a page that was cached this morning.
- The place is held while the guest fills in details and pays. A hold is a promise you make to one guest at the cost of every other guest looking at the same date.
- Payment is attempted. This step fails most often, usually for reasons outside your software: a bank declining a foreign card, a 3-D Secure screen the guest closed.
- On success, the place is committed, the confirmation goes out, and every channel reading from the same stock is decremented.
- On failure or abandonment, the hold expires and the place returns to sale. If it did not, a week of failed checkouts would quietly sell out your season.
How long a hold lasts is a commercial decision, not a technical one. Short holds return places to sale quickly and lose guests who were still typing. Long holds show a full boat that is not full. We ask you for that number and explain what each answer costs, rather than picking it quietly.
The same applies to cancellation. One that reverses the booking but not the stock is worse than no automation at all, because now the wrong number looks authoritative.
Living with a channel manager and the OTAs
Almost nobody we work with sells only direct, and nobody should. The point of a direct platform is not to leave the marketplaces; it is to stop paying commission on the guests who were already coming to you. So izBooking sits alongside a channel manager and your OTA listings rather than replacing your whole stack.
That requires agreement on one question: which system is allowed to be wrong. One place decides stock, and everything else accepts it, including when the answer is unwelcome.
| What can go wrong | What has to be true to avoid it |
|---|---|
| The same seat sold direct and on an OTA | One system owns remaining stock; the others subscribe to it |
| A stale price pushed back over a new one | The direction of price updates is decided per product, not per person |
| A cancellation that never reaches the channel | Failed pushes are queued and retried, and visible when they keep failing |
| Availability that drifts over a season | A reconciliation you can run and read, not a claim that drift cannot happen |
If your channel work is the actual problem rather than the booking engine, that is a separate piece of work, described on the booking integration page. Our team has been working inside Bokun for years, starting with our own inbound business, which is why the failure cases above are written from memory.
The 2026 platform, and the rule we do not break
During 2026 izBooking is being rebuilt on a new white-label platform written in Next.js. This is a rebuild of the merchant-facing stack rather than a new coat of paint, and seven sites are in the first migration batch.
The rule we hold ourselves to is the reason it is taking as long as it is: the new platform has to pass an acceptance gate before a single live site moves onto it. Not in parallel. Not partially, with a promise to finish the checklist during the migration. The gate closes first, then sites move.
- No site is moved in order to prove that the platform is ready.
- Sites move in controlled batches, so a fault is found on a few sites rather than on a thousand.
- If you are on izBooking today, nothing about your site changes on a date we choose without telling you first.
Because you will find out anyway, and because how a supplier handles its own platform change is the best available evidence of how it will handle yours.
Getting your data out
A booking platform holds the two assets your business is actually made of: your product catalogue and your customer list. Any supplier who makes those hard to retrieve is using that difficulty as a retention strategy, and you should assume they know it.
Bookings, guests, products and prices are exportable in standard formats, and the export obligation is written into the contract rather than offered as a favour when the relationship is ending. We have migrated businesses onto izBooking from other platforms, and we do not build an exit we would not want to be on.
Who should not use izBooking
- You sell one product on fixed dates a few times a year. A form and a calendar invite will serve you better than a platform with a subscription attached.
- Your business has not decided internally who owns product and pricing. Software will freeze that argument in place rather than settle it.
- You need to be live in under two weeks and you need card payments. The bank and gateway approvals will not be finished in that window, whoever you hire.
- You want a booking engine mainly so the website looks more serious, and nothing behind the screen is going to change. The screen is not the broken part.
Tell us what you sell and what you run on
Send the products, the channels you sell through today and where bookings currently arrive. You get a written answer about whether izBooking fits, including the case where it does not.
What travel operators ask us most
Do our guests ever see the name izBooking?
No. The booking pages sit on your domain, the confirmation comes from your address and the payment descriptor is your merchant name.
The only people who see the platform name are your own staff, in the admin screens they log into.
Can izBooking work with the website we already have?
Usually yes, and it is often the cheapest useful step. The booking layer can be connected to an existing site as long as that site can be edited at template level.
If it sits on a locked platform that does not allow that, we will say so rather than sell a workaround that breaks at the next update.
What happens to bookings taken while the payment gateway is down?
The request is recorded before any external call is made, so a gateway outage loses the payment attempt but not the enquiry. Someone on your side can follow up with a payment link.
The design principle is the same everywhere in our systems: write the record first, then talk to the outside world.
How does pricing work for izBooking?
It is a subscription plus the payment processing costs charged by your gateway, not a commission on every booking you take.
Ranges and what moves them are on the pricing page, and the number that applies to you is confirmed in writing before work starts.
Are you migrating existing merchants to the new platform automatically?
No. Sites move in batches, after the new platform has passed its acceptance gate, and the merchants involved are told before their site is scheduled.
Seven sites are in the first batch. Nobody is moved in order to test the platform.
Read next
Tell us what you are trying to run
What you sell, what you use today, and what is breaking. You get a written answer with an approach and a price range - not a brochure.