Ticketing that disappears behind your brand

TicketWave HQ is the platform UK Web Marketing is wholly owned by. Same company number (17143167), same Pudsey registered office, same architectural disciplines. This case study is different from most in this set because the subject is our own parent: we own both sides of the work, so we can be exact about how the transactional platform is built and how it connects to the websites we deliver for UK SMBs.

This one covers the platform itself, what it does, why it exists, and how it integrates.

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 single-sentence positioning

The H1 reads: “Ticketing that disappears behind your brand.”

That is not metaphor. The platform serves the booking widget on a custom domain (book.yourpractice.co.uk, order.yourrestaurant.com), with your colours, your fonts, your terms of service. 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, sold separately:

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

A salon takes bookings and sells a class series. A restaurant takes table bookings and orders for delivery. The platform handles both without forcing the venue to run two SaaS subscriptions, and both modules bill on the same commission-only basis rather than a fixed monthly charge per module.

The commission ladder: pay in proportion to what you earn

No monthly fee on any module. Pricing is commission-only, on a sliding scale:

• 4%, entry rate, applies until monthly transaction volume crosses the first threshold
• 2.5%, mid-tier as volume grows
• 1.5%, high-volume floor for established venues

Free tickets carry zero commission. Charity events and free RSVPs cost the organiser nothing.

The contrast against Fresha (~£25–60/month per practitioner) and Booksy (similar tiered pricing) is sharp: a busy salon hits a fixed subscription cost regardless of revenue, whereas a TicketWave salon pays in proportion to what it earns and never owes anything in a quiet month.

What we 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 or by UK Web Marketing on its behalf, 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.

How this connects to the UK Web Marketing tier ladder

The TicketWave HQ modules are not bundled into any UK Web Marketing tier. They are sold direct by TicketWave HQ at TicketWave’s published rates. UK Web Marketing builds the website; TicketWave HQ builds the booking / ordering / ticketing layer; the customer signs two subscriptions because the work is genuinely separate.

What UK Web Marketing handles is the integration, and we match the embedding pattern to the job rather than defaulting to one iframe for everything. The four /integrations/{bookings,ordering,stock,ticketing} spoke pages on the agency site walk three patterns:

• API plus Astro-rendered HTML, our choice where SEO matters most, used for ordering and stock catalogues. The page server-fetches data from TicketWave and renders it as native HTML, so it looks indistinguishable from hand-coded content and search engines can read it.
• Web-component widget, used for bookings, where the calendar UI needs to stay interactive without a full page reload.
• Sandboxed iframe, used for ticketing, where the UI iterates fastest and hard isolation is cheap insurance.

In all three the customer never leaves the venue’s domain, which is the whole point: the integration keeps the same white-label promise the platform makes on its own.

The outcome: a clean two-company split, billed transparently

Being owned by a platform parent is not filler trivia, it is a pedigree signal. A web design agency that also runs the booking platform its clients integrate with knows what the integration surface should look like, because it owns both sides of it. The two-company model exists because the work splits cleanly along ownership lines: the agency owns the marketing site, the platform owns the transactional layer, and both bill direct.

That structural honesty is the case study point. If you want the website plus the booking module, we will build the site, TicketWave will run the bookings, the bills come from two companies, and the maths is transparent rather than buried in one bundled invoice. Get in touch, the same company stands behind both sides.