Skip to content
Rascals
Work
Own product 2026 — now

Usher

Ticketing that is honest about the money.

A multi-organiser ticket platform where the fee is stated, the currency belongs to the event, and the receipt never changes after the fact.

per ticket, all-in
3% + € 0,50 per ticket, all-in
currencies on one page
2 currencies on one page
split at the moment of sale
0 split at the moment of sale
Role
Product, architecture, build
Period
2026 — now
Stack
Laravel 13 Livewire 4 Flux UI Stripe Connect Cashier Redis Sail

The problem

Ticketing platforms mostly compete on how well they hide the fee. That works until the night is cancelled and somebody has to give the money back — at which point whoever was paid at the moment of sale has already spent it. The awkward parts of ticketing are all downstream of that one choice, so Usher makes it explicitly and early.

How it works

Every buyer pays into the platform account. Nothing is split at the point of sale, because tickets sell months before the event and whoever holds the money is who refunds it. Each order records both halves — what the buyer paid and what the platform keeps — and a weekly release moves the remainder to the organiser, automatically for a connected Stripe account and as a written-down manual payout for one without.

What is in it

01

Language and money kept apart

Language is the reader's choice; currency belongs to the event and no reader can change it. A Dutch visitor sees € 45,00 next to £ 22,00 — two currencies, one set of number conventions. Conflating the two is how a platform misstates a price.

02

Buy without an account, keep the tickets anyway

Guest checkout is the default path. Register later with the same address, verify it, and the orders that were already paid for appear under your tickets — claimed by proof, not by trust.

03

Paid only because the webhook said so

The success page is a page, not a promise. An order becomes paid on a signed Stripe webhook and nothing else, so a reloaded tab, a closed browser or a lost redirect cannot change the outcome.

04

Dormant until configured

With no Stripe key resolved, buy buttons hide, checkout refuses and the Connect routes 404. That is the intended state of a fresh install rather than a fault — and it makes switching payments on a deliberate, checkable act.

05

Extras are a gate, not an invoice line

Door scanning and PDF tickets are billed per event and paid before the event can go on sale — someone who buys scanning needs it working when the doors open. Once selling, the extras freeze: you cannot bill for what buyers were never told about.

06

A fee set against the market, not picked

3% + € 0,50 per ticket, all-in — 5.0% on a € 25 ticket, against roughly 9% at Eventbrite. Free tickets are never charged. Each event chooses whether the buyer or the organiser carries it, and both routes leave the organiser owed the same amount.

A decision worth explaining

The order stores what it was actually charged in, not a reference to the event's current currency. Reprice the event, move it to another city, change the platform default — the receipt somebody already holds still reads exactly as it did. A record of a payment that can be rewritten by later configuration is not a record.

Something like this on your list?

The projects differ, the way of working does not. Tell me what you are trying to solve.

Taking on new work