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.
A running demo of the real thing, open to anyone. It carries its own data, so anything you do in there stays well away from a real customer.
- per ticket, all-in
- 3% + € 0,50 per ticket, all-in
- currencies to sell in
- 10 currencies to sell in
- split at the moment of sale
- 0 split at the moment of sale
- Role
- Product, architecture, build
- Period
- 2026 — now
- Stack
- Laravel Livewire 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 once the organiser has connected their account, and otherwise as a payout written down to be made by hand.
What is in it
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 of the ten currencies on offer, one set of number conventions. Conflating the two is how a platform misstates a price.
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.
Paid only because the payment provider confirmed it
The success page is a page, not a promise. An order is marked paid only when Stripe confirms it directly and signed — never because the buyer's browser happened to land on the right page. A reloaded tab, a closed window or an interrupted return cannot change the outcome.
Dormant until configured
Until the payment details are filled in, buy buttons hide, checkout refuses and the payout screens simply do not exist. That is the intended state of a fresh install rather than a fault — and it makes switching payments on a deliberate act you can check.
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.
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.
The trade-off
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