How it works, from listing to the gate
Six steps between an idea and a door that moves. Steps one to four are yours and your buyer's; steps five and six are where the product earns its keep.
1. Create the event
A title, a venue, a date and the ticket types you want to sell. Each ticket type carries its own price and its own stock, so an early bird, a standard price and a free guest list are three rows rather than three events. Venue addresses are looked up, so the map and the Plus Code on the pass come from the address rather than from typing. A free ticket is a price of zero, and it skips the payment step entirely.
If the room has seats, you lay it out once: sections, rows and individual seats, or whole tables if the room is sold that way. A buyer then picks from the seats you opened. An event with no seat map sells by quantity, and an event with one can still allocate a seat automatically when the buyer does not choose, which is what happens to every pass sold at the door.
Nothing is public yet. A draft can sit for as long as you need, and it can be edited after it is published too.
2. Publish, and share one link
Publishing gives the event its own page: poster, venue, date, the ticket types on sale and your own accent colour. Share that link anywhere. If you list the event as public it also joins the directory, where buyers search by city, date, category and price.
The directory also has a Featured strip above the list. It is not a ranking and it is not for sale: somebody at Tickus chooses an event and gives it a run of a set number of days, after which it stops being featured by itself. A published, listed event is the only thing that can be chosen.
3. A buyer picks a ticket and pays
The buyer needs no account and installs nothing: they give a name and an email per attendee, pick a quantity or a seat, and pay. Payment happens on OPay's checkout, and card details never reach Tickus. The order page shows the ticket price and the processing fee as separate lines before the payment button.
If you issued a discount code, the buyer enters it before paying and the page shows the reduced total, priced by the server rather than by the browser.
When a ticket type sells out, a buyer can leave an email instead. If a ticket comes back (a refund, a released hold, a transfer nobody accepted), it is held for the first person in that queue for a short window and then offered to the next one.
Not every sale has to happen online. Door sales are a per-event switch, off unless you turn them on, and once they are on anyone working the gate can record a cash or transfer sale from the same screen that scans. The sale is an ordinary order: the buyer gets a pass and a receipt, the money is credited like any other sale, and it appears in the same books. It carries no processing fee, because nobody processed a card.
4. Every attendee gets their own pass
When the payment settles, each attendee is emailed their own QR pass, with the event, the venue, the doors time and a Plus Code. One pass per attendee rather than one per order is what makes the gate able to tell five friends apart, and what makes handing a ticket to somebody else an explicit handover instead of a forwarded email.
- A pass can be handed on. The holder offers it to an email address and the recipient accepts from their own link, within a week and before the event starts. Nothing moves until they accept, so an offer nobody takes leaves the ticket with the person who bought it. Transfers are free.
- Some events use a live code. Where an event is set up with a rotating code, the code changes on a timer, so a screenshot is worthless. Those emails link to the live pass instead of printing a picture of it.
- The order and the pass add to a calendar. Both offer a calendar file with the venue and the doors time, so the event lands where the rest of the evening is.
- You can reach the room. Sending an announcement emails everyone holding a paid ticket for one event, and the dashboard shows what was delivered and what failed, with a retry. It is not a mailing list: it is one message to the people already coming.
5. The gate opens before the doors do
You give each usher an access code, and they open the gate in a browser on their own phone. With a signal, the phone downloads the event's pass list, signed by the platform, and verifies it on the device with a public key. It holds no secret that could forge a pass, so a stolen phone forges nothing.
- Scanning works with no network. The phone checks the pass against the list it already has and records the admission locally.
- A second scan is refused. The phone knows what it has already admitted, and says when and by whom the pass went through.
- Admitting opens and closes with a window. The gate starts accepting passes when the event's check-in window opens (the doors time by default, earlier if you open it early) and stops at the end of the event. A scan outside it is refused rather than quietly counted.
- The room's guest list is the first screen. Every live pass on a paid order, with its buyer, order reference and seat. Search by attendee, buyer, pass code or order reference, so a dead phone or a forgotten printout is still a person with a name.
6. What was taken offline is settled when the signal returns
The admissions queued on the phone are replayed to the server, each with an id the phone generated, so a batch that is sent twice counts once. The server applies the same one-admission rule it would have applied online: a pass is admitted once, and a claim that arrives for one already admitted comes back refused. The offline guide covers the staffing decisions this implies.
More than one person
An account can stay with one login or add two kinds of staff. A manager can build and publish events, see attendees, send announcements and manage gate staff, and cannot see the money at all. An accountant can see balances, ledger, statements, payouts and refunds, and cannot publish or delete an event. Neither can invite the other; that stays with the account owner. Without a change, everybody keeps the single login they have always had.
And the money
Ticket sales settle into your wallet as orders are paid, and a payout goes to your own bank account. A withdrawal is confirmed with your password or an authenticator code. Ticket money becomes withdrawable a few days after the event ends, not when it is sold, so a cancellation can still refund every buyer. Refunds and cancellations are paid the same way, from the event's own balance: refunds and cancellations explains the claim link and the 90-day window for a cancelled event. Pricing explains the fee.
A finished month can be downloaded as a statement from the wallet: every payout, fee, refund and reserve in order, generated from the ledger rather than added up again, signed when the deployment holds a signing key and marked unsigned when it does not. Door sales and online sales appear in the same file.
See it from either side
Create an organizer account to build a draft, or browse the directory to see what a published event looks like to a buyer.