Club Night & Promoter Ticketing

The vertical decides the vocabulary, the questions asked at checkout, the inventory model, the door, the payout terms and the theme. This page says "ticket" and "event" because that is what a promoter says; a config whose primary call to action is generic ticketing wording fails validation rather than shipping.

The on-sale lasts four minutes and the price ladder has to survive it

A night that announces well sells its cheap tickets faster than anyone can watch a dashboard. If early release is a price you edit rather than a pool you set, the promoter is the mechanism: somebody has to be awake, notice the count, and change the number before too many go at the wrong price. Get it wrong by ninety seconds on a three-hundred-capacity room and the difference is real money, and the guests who paid each price can no longer be told apart afterwards.

What bindro does: Each release wave is its own ticket tier with its own price, its own selling window and its own pool. When the early pool is gone the rung closes and the next one opens on its own; a hold against a closed rung is refused server-side rather than hidden in the page. Nobody has to be awake for it, and the price a guest actually paid stays readable on their order forever, which is what makes wave-by-wave reporting possible at all.

Half the room is on somebody else's guest list and the licence is the venue's

Three DJs, an agency, the venue and the promoter all add names, usually by message, usually on the day. None of those lists knows what the others have promised, and the ticket count says the room is fine. The number that matters is bodies through the door against a licensed capacity, and it is discovered at one in the morning by a door supervisor who is entirely right to stop letting people in.

What bindro does: A comp is issued from the console, lands on the same manifest as a sale and consumes a place in the same pool. A guest list that does not draw down capacity is the whole bug, so here it draws down capacity. Guest-list ratio is one of the three numbers this vertical is scored on, and remaining places are live on the day-of screen while the door is running rather than reconstructed the next day.

A guest who cannot come has exactly one option, and it is a tout

Somebody buys four tickets, two friends drop out, and the platform offers them nothing. What happens next is a resale listing at double face value, a screenshot of a QR code sold twice, or two people at the door with the same ticket and a promoter arbitrating a fraud they had no part in. Every one of those costs the night goodwill it did not budget for, and the guest who got scammed blames the party, not the tout.

What bindro does: A guest hands the ticket to a named person from their own confirmation link — holding the link is the authorisation, so nobody makes an account. The new holder gives their own details and answers the same age questions, a fresh credential is issued, and the old QR and any bound wristband stop working in the same transaction. Bindro runs no resale marketplace and does not pretend to; what it offers is a free, traceable handover that undercuts a tout by definition.

The room is a basement and the door tool is a website

Railway arches, basements and warehouses are where this music happens and none of them has a signal. A scanner that needs a connection turns the busiest twenty minutes of the night into a queue in February while somebody reads names off a phone that is still loading — and a queue outside a residential street at midnight is how a venue loses the room for everyone.

What bindro does: The door device pulls a signed manifest before doors, validates every scan locally with no network calls at all, and uploads its shift log afterwards. First scan wins by timestamp, a re-uploaded log counts as duplicates rather than double admissions, and a credential scanned on two devices at once lands in a conflict queue in the console instead of being silently resolved. Wristbands and ticket QRs are interchangeable at the scan, because a band on a wrist survives a dance floor and a phone screen does not.

Splitting the door happens in a group chat at four in the morning

The headliner is on a door split, the venue takes a percentage, and the promoter takes what is left after the fees nobody agreed on in advance. The arithmetic gets done tired, from a ticket count rather than from settled money, and each share gets rounded on its own — so the parts do not add up to the whole and somebody is quietly short. Doing it again next month with a different headliner is how a promoter gets a reputation they cannot see.

What bindro does: Recipients and shares are configured once as basis points totalling 10000, and the engine allocates largest-remainder, so leftover cents go to the biggest fractional claim and the parts total the payout exactly rather than approximately. The split is frozen onto the night's payout and shown by name. What bindro does not do is send each party their share: it holds bank details only for you, so it gives you the arithmetic and the record and you make the transfers.

You rent the venue, so the platform ends up owning your audience

A promoter without a building is a name and a mailing list, and a discovery platform that sits between the two is renting you your own crowd. The listing outranks your own page for your own night, the buyer relationship belongs to the platform, and the day you want to announce somewhere else you find that the list you built is not a list you can take with you.

What bindro does: Every night has one canonical share address, indexable in its own right, with a generated card sized for an unfurl — the address for the bio link, and the same checkout however a guest arrives at it. Buyers and their checkout answers export in full whenever you want them, behind a one-time code, with no export fee and no notice period. Referral source, release wave and transferred-versus-original buyer are reportable segments, so the list you leave with is the list you actually built.

The 18+ box was ticked three weeks ago by whoever paid

On a licensed night the age policy is the licence, and generic ticketing can only ask. It cannot refuse the sale, it cannot tell the door what was asked, and the tick sits on the order rather than on the person drinking — who, on a booking of four, is very often not the person who paid. That leaves the venue holding an attestation with nothing behind it on the one night a licensing officer walks in.

What bindro does: Two controls doing two different jobs. The booker confirms every guest is 18 or over and separately gives their own date of birth, which is enforced where the money moves — an under-18 booker is refused rather than sold to and sorted out later, and an unparseable date is refused too, because a rule that garbage bypasses is not a rule. The door operator then confirms explicitly that physical ID was checked before a scan is recorded, against the scan and the operator rather than against the order.

Release waves that are pools, not prices you edit in a hurry

A club night is fixed-pool inventory and a wave is a rung on the price ladder: its own price, its own on-sale window, its own capacity. Flat, tiered and early-bird pricing all resolve for this vertical, so a three-wave night is a configuration rather than a plan you have to execute live.

• Early release closes when its pool is gone and the next rung opens on its own — no edit, no alarm set for 9am.
• A hold against a closed rung is refused server-side, not hidden in the page, so a stale tab cannot buy at last week's price.
• The price paid stays on the order, which is what makes "how did wave two do" a question with an answer.
• No waitlist when the last wave goes: that capability is not declared for club nights, so the off-sale page says off sale rather than collecting emails nobody will call back.

Named transfer instead of a resale market

The most-searched thing in this scene is resale, and the honest answer is that bindro has no marketplace — the capability is undeclared because it is unbuilt, and a listing page that does not exist is not a roadmap item on this page. What exists is the part that removes the reason to use a tout: a free handover to a named person, with the credential rotated so the old one dies the instant the new one is issued.

• The transfer link is in the guest's own confirmation email; holding it is the authorisation, so there is no account to create.
• The new holder answers the same age questions, so a handover cannot launder an 18+ night.
• The old QR and any wristband bound to it stop working in the same transaction as the new issue — there is no window where both scan.
• Transfer volume is a reportable number, and transferred-versus-original buyer is a segment, so you can see how much of the room is second-hand.

A wristband door that works with no bars of signal

Offline check-in is a requirement of this vertical rather than an upgrade, so it is in the data model instead of bolted on. Wristband is the primary mode configured for club nights and a band binds to a guest, admitting exactly as their ticket QR does; only a keyed hash of the band uid is stored, so a copy of the database is not a stack of working wristbands.

• The device holds a signed manifest and validates locally — no network call in the scan path at all.
• A second scan of the same credential reads as a duplicate, and the visit is counted once however often it is scanned.
• Re-entry is therefore a door policy and a wristband, not something bindro authorises: this vertical is configured with re-entry off and the scanner will not say otherwise.
• Manual look-up by name is there for the band that took a drink, and it writes the same check-in record as a scan.

Splits worked to the cent, and stated honestly about the last step

Shares are basis points totalling 10000 and the allocation is largest-remainder, which is the difference between three shares that add up to the payout and three shares that add up to a cent less than it. Database triggers hold both halves of that invariant — shares total 10000, allocations total the payout — so a split cannot be saved in a state where the arithmetic does not close.

• A worked night: 300 tickets at $15.00 grosses $4,500.00, pays $411.00 in platform fees at 2.5% + $0.99 each, and nets $4,089.00.
• Club nights are medium risk, so 12% — $490.68 — is held as reserve and $3,598.32 releases two days after the last set.
• Split 50/30/20 that is $1,799.16 to the headliner, $1,079.50 to the venue and $719.66 to you; the parts total $3,598.32 exactly.
• Bindro holds bank details for you and nobody else, so a split settles to no third party until you send it — and the console says so rather than reporting a transfer that did not happen.

One link in a bio, one checkout behind it

Promotion for a club night is a story, a flyer post and a link. That link is a public share address that is canonical and indexable in its own right, typed as a music event for search engines, with a generated card image and a from-price read off the event rather than typed into a caption that goes stale.

• One address per night, used in the bio, the story, the flyer and the listing — every route lands in the same checkout, not a second copy of it.
• Embed the same checkout in a site you already run, if you have one; it is the identical money path.
• Referral source is a reportable segment, so "the story" and "the flyer" stop being a guess.
• A guest checks out with a phone number and a one-time code — no account to make at the moment they are most likely to leave.

The door till, the merch table and the bar on one device

Walk-ups, a T-shirt and a drink can all be rung up on the operator device, and it is worth being exact about which of those is platform money. A walk-up ticket is: it draws down the same pool as an online sale, lands on the same order table and the same ledger, and is why the room count stays true. Merch and bar takings are recorded for the night's numbers and stay yours — they never enter the platform ledger or a payout.

• Card on the operator device only. Cash ticket sales are deliberately not recorded, because crediting the platform for money it never held would pay you for the same ticket twice.
• Bar spend per head is a KPI this vertical is scored on, which is what the till record is for.
• Sales tax, where it applies, is held as a liability rather than mixed into your balance. It can be added on top or carved out of a tax-inclusive price; bindro registers nobody for VAT and files no returns.
• Keep walk-up sales on one device: an offline room count is only as fresh as its last sync, and two devices selling at once will not see each other until both are back.

Comps, refunds, roles and a residency that builds once

The controls a promoter reaches for in the week either side of a night, all of them yours rather than a support ticket.

• A residency is a recurring series with a session per date: one event to maintain, each date with its own door and its own payout two days after it ends.
• Comp a place for the DJ's plus-ones or the venue: it consumes inventory, scans normally, and writes no revenue lines.
• Refund from the console yourself — proceeds reverse first, then tax, then our fee, so the ledger is never left unbalanced.
• Promo codes for a mailing list or a residency regular; a door login sees a name and whether the code admits, not what anyone paid.

Who pays the booking fee?

The guest, unless you say otherwise. Every event carries its own setting — the guest pays, you absorb it, or you split it — and the fee itself does not change with the choice, only which side of the sale it comes from. On a ten-ticket $25.00 event that is $16.20 either added to what guests pay or taken out of what you keep.

Because the default is the guest, a promoter can go from signing up to a sold-out event without paying bindro anything up front, at any point, ever. We are paid out of sales that happened or we are not paid.

The word "event" is load-bearing and worth reading twice. The scheduler groups by event, admits one only once its LAST session has ended, and pays it once. An event sold as a run of dates therefore pays after the final date, not after each one — a season's float is not something an operator should discover halfway through the season.

Bindro never pays before delivery, in any vertical. A pre-event advance is a configuration violation platform-wide rather than a policy someone can be talked out of, because paying out on events that have not happened is exactly how a cancellation becomes guests with no refund. "Paid" also means the money moved: a payout only reaches its paid state with a real transfer reference attached, enforced by the database rather than by a status field someone can set.

• One payout per event, after its last session ends, one in flight at a time.
• T+2 for this vertical (medium risk tier), with 12% held as reserve and released later.
• Refunds reverse in a fixed order — your proceeds first, then tax, then our fee — so a refund never leaves you charged for a sale that was undone.
• Sales tax, where it applies, is held as a liability rather than mixed into your balance, so the payout figure is proceeds rather than a number you still have to do subtraction on.

The three numbers underneath it are transfer volume, guest-list ratio and door conversion. Guest-list ratio is the one that quietly decides the night: every comp is a place that cannot be sold, and a room where a fifth of the capacity went out as names is a room that has to sell out to break even. Transfer volume tells you how much of the audience is second-hand and worth marketing to differently; door conversion — advance against walk-up — tells you whether the on-sale did the work or the flyer did.

The console computes the headline figure per delivered night and prints the arithmetic under it, and the arithmetic says what it is: gross per show, not net after splits. Subtracting the splits is still yours, and everything you need is beside it — gross, platform fees and refunds per night out of the ledger the payout reconciles against; the frozen split allocation by name; tickets sold against guests scanned with a no-show percentage; and the whole buyer list as CSV. The numbers going into it are settled money rather than a ticket count.

What the console shows today, without an integration or a spreadsheet:

• Gross, platform fees and refunds per event, read from the ledger the payouts reconcile against.
• Tickets sold against guests checked in, with a no-show percentage per session.
• Live remaining capacity while the event is running, per pool, on the day-of screen.
• This promoter's own funnel — view → checkout → paid → scanned — stage by stage with the drop-off between them, and any step the platform cannot see said so rather than shown as a zero.
• Refunds, transfers, turnout, no-shows, add-on attach and repeat buyers, each printed with the two numbers it was divided from.
• Orders and guests as CSV, so anything not on the screen is one export away.

Two more that are worth stating plainly. Sensitive answers are classified on the field rather than by convention, and health data is excluded from analytics exports and from AI context absolutely, with no override in any vertical. And a promoter's own people see only what their role allows — a door login sees a name and whether the code admits, not what anyone paid — which is checked in the handler rather than by hiding a button.

• A resale marketplace — not offered for club nights, because it is not built. A guest who cannot come hands the ticket on by name; there is no face-value exchange and no listing page.
• A waitlist when a night goes off sale — a waiting list is not enabled here, so the off-sale page carries no join form and a sold-out night is sold out.
• Cash taken at the door — the door till charges a card on the operator device. Cash ticket sales are deliberately not recorded, because crediting the platform for money it never held would pay you for the same ticket twice at payout.
• Bar and merch takings as platform money — a till sale is recorded for the night numbers, but on-site takings stay with the promoter and never enter the platform ledger or a payout.
• Re-entry — a credential admits once per session and a second scan is reported as a duplicate, so smoking-area re-admission is a wristband and door-policy matter rather than something bindro authorises.
• Season passes, residency memberships, gift cards and donation add-ons — configured as optional for club promoters and not resolved, so each one is a refusal rather than a half-working feature.
• Running your door outside the United States — host onboarding offers one country today, so a UK or EU promoter cannot yet sign up. Tax-inclusive pricing itself now works per night, but bindro registers nobody for VAT and files no returns.
• Sending a DJ or a venue their share directly — bindro works out every party's cut, freezes it onto the night's payout and shows it by name, but it holds no bank details for anyone except you. A split night therefore settles to nobody until you send it, and the console says so rather than reporting a transfer that did not happen.
• Booking the artists — bindro sells the night and works the door. Contracts, riders, advances and agency paperwork are not modelled anywhere in it.

If one of those is the thing you need, say so — the answer is a capability declared, built and gated properly, or a straight no. It is never a feature flag that collects the request and does nothing.

Announce first and sell second. A stated on-sale time concentrates demand into a moment you have staffed rather than a trickle you have to keep watching, and the median lead time this vertical is modelled on is eighteen days — a planning horizon rather than a rule. Build the waves before the announcement, not during the on-sale: the whole point of a rung is that nobody has to touch it while it is selling.

On the night, the two door jobs stay separate and both get done. The scan answers "is this credential admitted"; the ID check answers "is this person 18", and only one of those has a licence attached to it. Walk-ups go through the door till on one device so the room count stays true, comps are already on the manifest, and the device needs no signal for any of it.

The morning after is settled money rather than a ticket count. Gross, fees and refunds per night come out of the ledger the payout reconciles against; the split is frozen and shown by name; the buyer list exports in full. Then the payout: one per event, two days after its last session has ended, and never before — paying out on a night that has not happened is precisely how a cancelled lineup becomes guests with no refund.

• Build all the waves before you announce; set wave one's on-sale to a stated time roughly eighteen days out.
• Issue comps from the console so the guest list draws down the same capacity as sales.
• Two people at the door: one scans, one checks ID. Walk-up sales stay on one device.
• Read guest-list ratio, transfer volume and door conversion; export the buyer list; send the DJ and the venue their frozen shares.

The distinction worth holding is between distribution and infrastructure. A discovery platform gives you a listing in front of people who have never heard of you, and charges for it in fees and in owning the relationship. Bindro is the other half: the waves, the door, the splits, the export. Pointing a listing at your own night and also selling from your bio link is not a contradiction, and the numbers stay comparable because referral source is a segment.

Be specific about what you would be giving up before you move anything. Bindro has no resale exchange, no waitlist, no season pass or membership, no gift cards, and no cash door. Each of those is a refusal rather than a half-working feature, listed on this page above rather than discovered in month two, and each comparison page names where the other tool is genuinely stronger — a comparison with no such section is an advert and you would be right not to believe the rest of it.

This vertical is written for a scene that is mostly European, which makes the gap worth stating in the largest type available rather than in a footnote. Everything else on this page is true — the waves, the transfer, the offline wristband door, the splits — and none of it helps if you cannot connect a payout account or price a ticket the way your tax authority requires.

If you run US nights and European ones, the honest position is that the US ones can move today and the others cannot. Nothing about the platform degrades gracefully into a currency it does not support: it is one country at onboarding, and a capability that is not declared is refused at the call rather than approximated.

The checkout already asks the two things this vertical needs and no more: the 18+ confirmation for every guest, and the booker's own date of birth with the bound enforced on the money path. One compliance requirement — the alcohol age check — is attached to the vertical rather than to a checkbox somebody has to remember, and it is collected before checkout rather than chased afterwards.

The page you are reading says "night", "ticket", "guest" and "promoter" because a promoter does, and the primary call to action reads "Grab a ticket" rather than the generic ticketing wording, because a config whose copy pack reads like a generic checkout fails validation instead of shipping. That is the shortest available explanation of what this platform is for: the vertical decides the vocabulary, the questions, the inventory model, the door, the payout terms and the theme, and the engine refuses anything the vertical has not declared.