Building TicketWave: ticketing that disappears behind the venue's brand

TicketWave is a white-label ticketing, bookings and ordering platform. It is a separate product line of TicketWave HQ Ltd, the company VerySEOly is also a trading name of, and it was built by the same founder. VerySEOly does not sell, resell or bundle it, and nothing on this page is an offer: if you want bookings, ordering or ticketing on your own site, we connect the system you already use, or help you choose one.

This write-up is here for the engineering: what the platform does, why it was built that way, and the disciplines that carry over into the sites we build.

The problem: venues run three subscriptions and rent their own customers

A venue that takes bookings, sells tickets, and handles orders usually ends up paying three separate SaaS vendors, each with its own monthly fee, its own branded checkout, and its own claim on the customer relationship. The booking page says the booking company’s name. The ticket page says the ticketing company’s name. Every quiet month still costs the same fixed subscription. The venue does the trading; the platforms own the audience.

TicketWave was built to invert that.

The positioning, expressed as infrastructure

TicketWave’s own headline reads: “Ticketing that disappears behind your brand.”

That is not metaphor. The platform serves its booking widget on the venue’s own domain (book.yourpractice.co.uk, order.yourrestaurant.com), with the venue’s colours, fonts and terms of service. The venue’s customers never see a TicketWave brand. The infrastructure is white-label first, and the brand is anti-marketplace by design.

The approach: three modules, one platform

Most ticketing, booking, and ordering competitors specialise, and specialising is what forces a venue into stacked subscriptions:

• Eventbrite owns events ticketing but has nothing for restaurant orders
• OpenTable owns bookings but has nothing for ticketed events
• Deliveroo owns food orders but has nothing for either of the above
• Fresha / Booksy own salon bookings but charge monthly subscriptions and own the customer relationship

TicketWave is one platform with three modules:

• Ticketed events, single events, recurring series, multi-event accounts and free tickets
• Service bookings, staff calendars, services with durations and prices, deposits, automated SMS reminders, opening-hours rules
• Curated takeaway / ordering, menus with modifiers, kitchen tickets and courier integration

A salon takes bookings and sells a class series. A restaurant takes table bookings and orders for delivery. The platform handles both from one account, without the venue running two systems side by side.

What was built: the technical posture

The platform is where the white-label promise is either kept or broken at the infrastructure layer. Five decisions carry most of the weight.

Next.js on Vercel London (lhr1). The runtime is region-pinned to London, and the app ships the modern isolation triad, COEP: credentialless, COOP, and CORP. Those are the headers a team sets when it is taking cross-origin security and embedding seriously, not just accepting framework defaults, and they matter directly here because the widget is designed to be embedded on other people’s domains.

5-locale i18n at the platform layer. en, es, pt, el, and fr, with locale negotiation handled via cookie and request header rather than bolted on per page. The five-locale set points at the markets the platform is built for, Mediterranean tourism across Ibiza, Barcelona, Lisbon, Athens, and Marseille, so every venue page can serve the correct language by default instead of pinning a customer to English.

Stripe Connect for vendor payouts. Each venue connects its own Stripe account at onboarding, so settlement runs 2–3 working days direct to the venue’s own bank, with no platform holding-account and no escrow week in between. Promoter and affiliate tracking is built into the same flow rather than sitting on top of it: an affiliate link signs a Stripe Connect commission split automatically at checkout, so the money splits itself without a manual reconciliation step.

Offline QR scanning. Door staff at a busy event can scan tickets without an internet connection. The scanner caches the guest list locally and reconciles when it reconnects, which is the difference between a queue that keeps moving and a queue that stalls the moment the venue Wi-Fi drops. It is the kind of real-world operations detail that only gets built when someone has actually stood on a door.

Custom-domain routing. Each venue gets its own subdomain or apex, with DNS configured by the venue, so the booking flow looks like it lives on the venue’s own infrastructure. Combined with the isolation headers and the venue’s own Stripe account, the trust signal compounds: the URL, the branding, and the bank account the customer pays are all the venue’s own.

What carries over to the sites we build

None of this is something VerySEOly sells. What carries over is the discipline:

1. Embedding chosen by the job. An API-rendered page where search matters, an interactive component where the interface has to stay live, a sandboxed iframe where isolation is cheap insurance. It is the same judgement we use when we connect a client’s own booking, ordering or stock system to their site.
2. Security headers set on purpose. Cross-origin isolation and a strict Content Security Policy, chosen and documented rather than left at framework defaults.
3. Region pinning. Rendering from London, so a UK business’s site and its visitors’ data stay close to home.

The outcome

A platform that keeps its white-label promise at the infrastructure layer rather than in its marketing: the address in the browser, the branding on the page and the bank account the customer pays are all the venue’s own. That is the standard we hold our own client builds to, whatever system they connect to.