Haunted Attraction 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 "entry" and "night" because that is what a haunt says; a config whose primary call to action is generic ticketing wording fails validation rather than shipping.

The queue is what people remember, and nothing on a ticket page shortens it

A haunt is limited by throughput, not by capacity. The barn holds whatever the fire officer says, but the show only works when groups go in at the rate your actors can reset, and the gap between those two numbers is the line down the road. Sell a night rather than a time and everybody arrives when the flyer said doors open: four hundred people in a dark car park at eight o’clock, a scare queue with no scares in it, and a first-timer at the back who waited ninety minutes for eleven minutes of maze. That is the visit they describe afterwards. The cost is not the evening you can measure — it is the neighbour who complains about the cars, the family who leave before they reach the door, and the write-up that talks about the wait instead of the show.

What bindro does: Every night is published as a grid of slots and each slot is a session holding its own inventory pool per ticket type, so an entry bought for 9:00pm can only take 9:00pm stock. The arithmetic that keeps your line moving is enforced by the thing that takes the money rather than by somebody with a clicker at the gate, and it refuses the sale that would push a slot past its capacity — inventory moves only under a row lock inside the confirming transaction, with a database constraint behind it, so two brave souls cannot take the last place in the same second. You also get a number no haunt had before: how many people are due in the next twenty minutes, live on the day-of screen while the night is running.

The Saturday before Halloween is worth three wet Tuesdays and your page has one price

Demand across a haunt’s season is not flat, it is a spike with a fortnight of shoulder either side. The last weekend before Halloween sells itself at any price you dare print; the first Thursday in October needs a reason to exist at all. Operators know this and still charge one number, because the alternative on a generic ticket page is editing the price as the season warms up — which means the early-bird buyers and the peak-night buyers are the same product bought at different times, with no record of which was which. Then somebody who paid the October price stands next to somebody who paid the August price in the same queue, asks why, and the honest answer is that the page changed. An early-bird release that was meant to be two hundred entries turns out to have been however many were sold before somebody remembered to edit it.

What bindro does: Peak pricing here is separate ticket types with their own prices, their own sale windows and their own stock — first release, general, the last-Saturday price — rather than a number you keep editing. Each rung carries an opens-at and a closes-at, and the gate is on the money path rather than in the page: a brave soul who left the early-bird page open for a week and finally clicks buy is refused with nothing charged and no order created. Because each rung keeps its own pool, an early-bird allocation is genuinely finite. Because prices are captured on the order line at purchase, what somebody paid in August is still readable in November after the ladder has moved on three times, which is exactly what you need when the two people in that queue email you about it.

Fast passes sold on trust, and a door team arguing about who paid extra

The fast pass is the highest-margin thing a haunt sells and usually the worst-run. It gets sold as a different coloured band bought in bulk, or as cash at the gate, or as a note in an email thread — and nothing anywhere caps how many exist. Sell too many and the fast lane becomes the queue, which is worse than not offering it, because now the people who paid a premium are the people complaining. Sell them at the gate for cash and you have a float, a tin and a reconciliation at one in the morning with a tired volunteer. And when it is not written down anywhere, the argument at the rope is between your staff and somebody who says they paid, with no way to settle it.

What bindro does: A fast pass is published as its own ticket type at its own price with its own stock in each slot it applies to, which is the shape that protects the night: the pool is what stops you selling more priority than the queue can absorb, and twenty on a Saturday and none on a wet Tuesday is a stock decision rather than a second price list. The alternative shape is an add-on bought alongside an ordinary entry, priced from the catalogue with its own stock and charged in the same basket — the right fit when the pass is really a band upgrade. Either way it is a credential your gate can scan, not a claim, and the honest limit is stated on this page rather than discovered on the night: bindro sells the pass and never orders your line.

Closing weekend: one bar of signal, two scan points, three hundred people in the dark

Haunts happen where phones do not work — a farm track, a walled yard, a field that was a field on Thursday — and the busiest ninety minutes of your year is exactly when the tethered laptop at the gate loses its connection. What happens next is always the same: somebody decides that holding up three hundred people in the cold is worse than not checking, and the gate starts waving people in. The night still runs. What you have lost is any idea of who came, which is the number the whole season is measured on, and any ability to say no to the four people at the back with a screenshot of somebody else’s code.

What bindro does: The door stops needing the network before doors open. The device syncs a signed manifest of the credentials valid for that session, validates every scan locally against it with no connectivity at all, and appends each scan to its own log with a device id and a sequence number; when signal returns the log replays and the server reconciles it, a re-uploaded log applies once rather than twice, and one poisoned row does not roll back the hundreds of good scans around it. Wristbands and emailed codes admit interchangeably, and a brave soul whose phone died in the queue can be found by name instead. The stated limitation is the one connectivity buys: two scan points that cannot talk to each other cannot prevent the same band being used twice, so the earlier scan wins by timestamp and the later one is queued as a conflict for you to read — detection rather than prevention, said here rather than at midnight.

A fourteen-year-old at the gate holding an entry somebody bought for them

The age limit is on the poster and it is enforced by whoever is standing at the rope at half past nine on a Saturday. By then the money is taken, the group has driven twenty minutes, the parent is in the car park, and the argument is about a refund rather than about the rule. The same evening produces the other version of this: somebody who did not know the show involves strobes, a confined space and actors who come close, discovering it eight minutes in. Both are the same failure — a decision that belonged at the moment of paying was left to a member of your staff with a torch, and neither the warning nor the age limit exists anywhere in the record afterwards.

What bindro does: The half that can be enforced is enforced before payment. The booker’s own date of birth is checked against this vertical’s minimum inside the transaction that would otherwise take the money, so an under-age booker is refused before a payment intent exists — and a date that will not parse is refused too, because a rule that garbage bypasses is not a rule. The intensity, strobe and medical warning is a required box on every booking, checked on the same money path, so nobody buys an entry to your show without being told at the moment of paying what it involves. The rest is honest attestation and we say so: a required tick-box in which the booker confirms the whole party meets the limit, no ID verified by anybody, and no prompt asking your scanner to confirm they saw one. Publish the age, staff the rope, and both the acknowledgement and who made it are on the order afterwards.

Six weeks of trade, twelve months of software, and a cash box you should not be running

A haunt opens for perhaps fourteen nights and then the barn goes back to being a barn. Venue platforms are priced for the year-round attraction they were built for, so a seasonal operator pays through February for a system nobody logs into, and a charity haunt raising money for the air ambulance pays it out of the gate. Underneath that sits the other cost nobody counts: the walk-up trade. Cash at the gate needs a float, a tin, somebody trustworthy, a night deposit and an hour of reconciliation while the actors are getting out of make-up — and the card reader, if there is one, belongs to a different company and its takings appear in a different report a week later.

What bindro does: Publishing costs nothing and there is no monthly charge: 2.5% + $0.99 on a paid order, nothing at all on a free night, and you choose per night who bears it — you absorb it, the brave soul pays it, or you split it — with the fee itself unchanged either way. Walk-ups are real sales through the real checkout on your own device, by card: the sale takes a hold in the real slot, derives its price the same way, moves the same inventory and issues a credential that scans like any other. There is deliberately no cash button, because crediting your balance for money the platform never held would pay you the same money twice at payout — so cash stays entirely outside bindro, and the honest alternative is sending the walk-up to the booking page on their own phone while they are still in line. The merch till records your masks and hoodies at the price they actually sold for, and those takings are already yours: recorded so your numbers are complete, never routed through a payout.

A season of nights, generated rather than typed

You describe the grid instead of the dates — the nights you open and the times you admit — and bindro generates a session per slot, each with its own inventory pool per ticket type, in one transaction so a half-created season is not a state that exists. Thursday to Sunday through October with entries every twenty minutes from seven until eleven is a few minutes of setup rather than an evening of it.

• Each generated slot carries its own capacity, so a smaller mid-week layout is a number on that date rather than a note to remember.
• Live remaining stock is shown per slot while a buyer is reading the page, so a slot that fills while somebody hesitates updates in front of them instead of failing at payment.
• Sold out reads exactly as your vertical says it — no souls left — and stops there: this vertical has no waiting list, and nobody is emailed when an entry is refunded.
• A refunded entry stays counted against its slot. Raise that slot’s capacity by one if you want to resell it, deliberately, rather than having it quietly reopen.

A price ladder the checkout enforces, not the page

Every rung is its own ticket type with its own price, its own opens-at and closes-at and its own pool. The page hides a rung outside its window; the money path refuses it, which is the difference between a price list and a price rule. Nothing about a stale browser tab, a shared link or a cached page can buy at a price you have closed.

• First release, general admission and a peak-night price coexist rather than replacing each other, and each keeps its own finite allocation.
• A closed rung refuses with nothing charged and no order created — not a payment to reverse afterwards.
• Prices are captured on the order line at purchase, so what somebody paid in August is still readable in November.
• Promo codes cover the community night, the local radio code and the scare-actor discount without a second price list, with redemption caps enforced in the database rather than by hope.

Fast passes as finite stock, and add-ons in the same basket

Priority is sold as inventory, in one of two shapes, and both are capped. As its own ticket type it has its own price and its own stock in every slot it applies to; as an add-on it is a catalogue item with its own stock, priced from the catalogue rather than from the form and charged alongside the entry in one payment. Which you choose depends on whether your fast pass is an admission or an upgrade.

• Stock per slot is the cap that keeps a fast lane fast — twenty on a Saturday, none on a Tuesday, no second price list.
• Add-ons cover the things a haunt actually sells alongside an entry: a photo, a band upgrade, a t-shirt collected at the gate.
• The client never names a price. Amounts in a request body are rejected by name and every value is re-read under a row lock inside the confirming transaction.
• What bindro does not do, in either shape, is run the queue: nothing calls the next group or holds a virtual place, and your door team decides who walks in when.

Season passes, with their real cost in capacity stated

A season pass is a ticket type flagged as a pass. It is bought through the same checkout, carries the same single credential, refunds the same way and admits its holder at every session of the event it was sold under. Two consequences decide whether it suits you, and both are published here rather than found in week three.

• A pass does not consume a seat at each night it covers. Its own pool caps how many passes exist; if your slot capacity has to include pass holders, you subtract them yourself.
• A pass admits only at sessions of its own event, which collides directly with publishing your season as weekly events to be paid weekly.
• It is the strongest thing you can sell to the people who come whatever the weather, and the best defence against a forecast emptying a night.

A gate that works with no signal, on bands or on codes

Sync the signed manifest before doors and the device is authoritative for the shift: scans validate locally, append to a device log with a monotonic sequence number, and reconcile when signal returns. Only a keyed hash of a credential is ever stored — the raw value lives in the buyer’s email and nowhere else — and the same is true of a band’s identifier, so a stolen copy of your data does not produce working entries.

• Wristbands bind to entries through the platform’s own API, in batches at the start of a season rather than one at a time at the rope.
• A band and an emailed code admit identically, so you can band the regulars and scan phones for everybody else without running two systems.
• Cross-device double scans are recorded, flagged and queued rather than prevented — the earlier scan wins by timestamp, and nothing is silently resolved about a real person standing in front of a real member of your staff.
• Manual check-in by name is there for the phone that died in the queue, and every check-in is attributed to whoever made it.

Walk-up sales by card and a merch till, on the devices you already have

The day-of page carries the walk-up sale form beside the live counts, and a walk-up is a real sale: a hold in the real slot, continued through the same checkout as a purchase made three weeks earlier, with the same price derivation and a credential that scans like any other. The till sells your masks and hoodies at the price they actually went for, recorded against whoever sold them.

• Card only, on your own device. Cash-recorded ticket sales are deliberately not implemented: crediting your balance for money bindro never held would pay you twice.
• Till takings never enter the platform ledger and are never paid out to you, because they are already yours — they are recorded so your numbers are complete.
• The till is gated to merchandise on this vertical. An item marked food or drink is refused on both the catalogue and the sale, so your concessions run on whatever they run on today.
• Back-office orders cover the sponsor, the local paper and the group who paid you by bank transfer, with the payment recorded as taken outside the platform.

Refunds, tax and comps that keep the season’s numbers honest

The money rules are the same for every haunt and none of them are negotiable, which is the point: a brave soul refunds themselves in full from the link in their confirmation email right up to the moment their slot starts, and after that the decision is yours alone from the console. Plan around that floor rather than against it — it cannot be switched off, and a forecast can empty a night before you have decided anything.

• Refunds reverse in a fixed order — your proceeds first, then tax, then the platform fee — so a refund never leaves you charged for a sale that was undone.
• A chargeback debits you in full, because that is what a chargeback is, and it is idempotent on the provider’s reference so a replayed notification cannot debit twice.
• Sales tax, if you set a rate, is added on top of your published price, itemised at checkout, kept out of the fee base and posted to a tax account rather than to your balance — so collected tax is not part of what gets paid out.
• Comps for sponsors, volunteers and the people who lent you the barn consume real inventory and scan normally, but write no revenue lines at all, so they never flatter what the season took.

Forty volunteers, six roles, and a rota that grants nothing

A haunt runs on people who are there for four nights, and the authority they need is the least possible. Door staff see a name and an admit-or-refuse and nothing else — not what was paid, not the buyer’s details, not the rest of the order — and that is checked in the handler rather than by hiding a button.

• Roles cover an owner, finance, a manager, door staff, volunteers and read-only, and the console renders only what a role may do.
• Rostering somebody for tonight grants them nothing. The rota is a plan and the role is the authority, kept apart so a seven o’clock staffing swap cannot widen who can refund an order at eight.
• Tonight’s rota sits on the same day-of screen as the live counts and the walk-up form, because that is the screen somebody is actually holding.
• Exports are behind a step-up prompt and every one of them is audited.

What you are left holding after closing night

The season ends and the useful part begins: gross, platform fees and refunds per event, read from the same ledger the payouts reconcile against rather than summed from a status column, so the figure in the report and the money that reached your account are the same arithmetic. Underneath it, the rows.

• Orders and attendees export as CSV whenever you want them — no export fee, no notice period, and nothing to leave, because there is no contract.
• One buyer’s history spans every night they have ever come: their orders, their paid lifetime spend and whether they actually turned up.
• One post-event email per paid order, sent only to buyers who opted in at checkout and only after the event has been delivered, never twice for the same order.
• Buyer identities anonymise automatically two years after that person’s last night with you. Answers belonging to the ORDER — access requirements and the booker’s date of birth here — stay on the order, which is worth knowing before you rely on the sweep.

Who pays the booking fee?

The brave soul, unless you say otherwise. Every night carries its own setting — the brave soul 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-entry $25.00 night that is $16.20 either added to what brave souls pay or taken out of what you keep.

Because the default is the brave soul, a haunt can go from signing up to a sold-out night 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 night, admits one only once its LAST session has ended, and pays it once. A night 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 nights that have not happened is exactly how a cancellation becomes brave souls 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 night, after its last session ends, one in flight at a time.
• T+2 for this vertical (low risk tier), no reserve.
• 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 reason for the split is structural and worth understanding before you publish, because it changes what you can see. Money in this platform is reported per EVENT: gross, fees and refunds group where the payout groups. Attendance is reported per SESSION: sold against checked in, with a no-show percentage per slot. So if you publish each week as its own event you can read revenue per week off the reports directly, and if you publish the whole of October as one event the money reports give you one figure for the season and per-night revenue comes from the exported order lines instead. Same data either way; different amount of arithmetic.

The three numbers beside the headline are the ones this vertical is actually run on, and here is exactly where each comes from. Peak-night sell-out is visible without any work at all — sold against capacity per slot, live on the day-of screen while the night is running and readable afterwards. Fast-pass attach rate is a count of the orders carrying the fast-pass tier against all orders on that night: the rows are in the orders export, the ratio is not computed for you. Throughput per hour comes from the check-in records, which carry the time of every scan; nothing charts it, and if it is the number you manage the show by, it is a pivot table rather than a screen.

What no report can tell you is your cost per night, so the metric only becomes the metric once the actors, the make-up, the generator and the insurance sit beside it. What bindro undertakes is narrower and checkable: the income side is derived from the ledger rather than from a balance column, comps are counted separately instead of vanishing into a zero, and every row underneath exports.

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

• Gross, platform fees and refunds per night, read from the ledger the payouts reconcile against.
• Entries sold against brave souls checked in, with a no-show percentage per session.
• Live remaining capacity while the night is running, per pool, on the day-of screen.
• This haunt's own funnel — view → date selected → slot selected → 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 brave souls 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 haunt'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.

• bindro does not manage your queue. A fast pass is a tier you publish at its own price with its own stock, and selling one is the whole of what the platform does about it — nothing orders the line, calls the next group or holds a place in a virtual queue. Who walks in when is your door team’s job, exactly as it was before.
• bindro does not stop a wristband being used twice. Haunts are configured for single entry, but nothing in the engine refuses a second scan: it is recorded and flagged as a conflict for you to read afterwards, whichever scan point makes it, and the screen says the band has already been used to get in. Turning people back at the exit is a rope-and-staff problem, not a software one, and two offline devices cannot agree in real time without signal.
• bindro does not check anybody’s ID and, for haunts, does not even ask the person scanning to say they checked one. The age rule that is enforced is the booker’s own date of birth, refused before payment; every other age claim on the order is a tick-box the booker made about their party. The photo ID at the gate is yours.
• No waiting list. When a slot is gone the page says "No souls left" and stops — nobody joins a list, nobody is emailed when an entry is refunded, and a refunded entry does not go back on sale by itself. If you want to resell it, raise that slot’s capacity by one.
• No transfers and no name changes. A brave soul who cannot come on Friday cannot hand their entry to a friend or move it to Saturday: this vertical resolves neither ticket transfer nor deferral, and there is no credit note to issue. The only lever is money out — a refund.
• No gift cards or vouchers. A haunt cannot sell "entry for two, use it any night" as stored value on bindro, because gift cards sit in this vertical’s optional list and are therefore refused by the engine. A season pass is the nearest real thing, and it is a ticket type, not a balance.
• No donation box and no charity receipts. Charity haunts raise money on the gate price itself: this vertical does not resolve the donation add-on, so there is no "add a donation" control at checkout, and nothing issues a tax receipt for a gift. The definition of this vertical includes charity haunts; the giving tools do not come with it.
• No group rate and no roster. "Number of brave souls" is a question whose answer is stored and shown to you — it does not price anything and it does not set how many entries you bought. Twelve entries cost twelve times one entry, and each one is its own credential to be handed to its own brave soul.
• No food and drink till. The merch till sells your masks and hoodies; an item marked food or drink is refused on both the catalogue and the sale, because this vertical declares merch only. Your concessions run on whatever you use today.
• Money taken at the till never enters the platform ledger and is never paid out to you — it is already yours. Merch sales and walk-up card sales at the door are recorded so your numbers are complete, and cash-recorded ticket sales are deliberately not implemented at all: crediting your balance for money bindro never held would pay you for it twice.
• bindro does not pay out mid-season. One event gets exactly one payout, scheduled only once its last session has ended and released two days later. A whole October published as a single event therefore pays once, after closing night — publish shorter events if you need the money sooner, and read the pricing guide before you decide, because a season pass only admits at sessions of the event it was sold under.
• bindro cannot enforce your refund policy. Every brave soul can refund themselves in full from the link in their confirmation email, right up to the moment their slot starts — there is no notice window to configure and no fee to withhold. After the slot has started the decision is yours alone, from the console.

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.

Published as five weekly events, the same October pays five times, each two days after that weekend ends. Nothing else about the two setups differs: the same slots, the same prices, the same door, the same fee. Haunts sit in the low risk tier so no reserve is withheld either way, and nothing is ever released before delivery — that is a platform-wide invariant rather than a policy someone can be talked out of, because paying out on nights that have not happened is exactly how a cancellation becomes somebody else’s unrefunded ticket.

The collision is the season pass. A pass admits only at sessions of the event it was sold under, so a pass sold against one weekly event admits at that weekend and nowhere else. If you want a pass that covers the run, the run has to be one event — and then you wait for the money. Most haunts should take the weekly structure and sell a season pass only if it is genuinely a product their audience asks for. A haunt with a loyal following and enough float to reach November can do the opposite, knowingly. What no haunt should do is find out in November.

Two smaller consequences follow from the same choice and are easy to miss. Financial reporting groups by event, so weekly events give you weekly revenue without a spreadsheet. And the post-event email — one per paid, opted-in order — is triggered when an event has been delivered, so weekly events mean a follow-up that arrives while the visit is still fresh rather than one that arrives after Halloween for everybody at once.

• One event, one payout, released two days after that event’s final session. No partial releases and no advances.
• Weekly events pay weekly; a season-long event pays once, after closing night.
• A season pass cannot span separate events — pick the pass or the cash flow, deliberately.
• Low risk tier: no reserve withheld on this vertical.
• Reports and the post-event email both group by event, so the structure decides what you can read and when a buyer hears from you.

The queue is the clearest example. Nothing in the platform orders a line, calls the next group, or tells a fast-pass holder when to come back. A fast pass is stock you sell with a price and a cap; what it is worth is decided entirely by how your door team honours it. Slots give you the arithmetic — how many people may arrive in each twenty minutes — and staffing turns that arithmetic into a moving line.

Re-entry is the one most often misread, so it is stated plainly. This vertical is configured for single entry, and nothing in the engine refuses a second scan: it is recorded and flagged as a conflict for you to read afterwards, whichever scan point makes it, and that gate is told the band has already been used to get in. A band does not stop working when its wearer walks out to the car, but re-admitting them costs you a flagged row every time. So publish your own rule, brief the gate, and treat the conflict queue as evidence after the fact rather than enforcement during.

The warning is the same shape. It blocks the sale, and it carries whatever words you wrote: how loud, how dark, how close the actors get, whether they make contact. Keeping that accurate is the most useful thing you will do for the people about to hand you money, and no platform can do it on your behalf.

• Yours: the queue, re-entry, ID at the gate, the intensity wording, the weather call, the concessions, and what happens to somebody turned away.
• Ours: the price, the inventory, the credential, the money, the ledger, and refusing anything the configuration does not allow.
• Publish your rules on your own page. Bindro collects the acknowledgement; the promise is made by a haunt, not by a platform.

For a haunt the class that matters is access requirements: a step-free route, seating, an assistance animal, a quiet space. Those are health-classed, which means they never appear in an analytics export and never reach an assistant, and they are visible to you because you are the person who has to arrange the ramp. Nothing summarises them, nothing flags them and nothing tells your gate that the couple arriving at nine need the step-free route — read them before the night, and if a requirement is essential, expect the brave soul to contact you as well.

Retention runs on its own schedule rather than on your memory. Buyer identities anonymise automatically two years after that person’s last night with you, and health answers sooner. The limit worth stating: the sweep anonymises attendee identities, while answers belonging to the ORDER — access requirements and the booker’s date of birth, on this vertical — stay on the order.

The rest is deliberately dull. Exports are CSV behind a step-up prompt and every one is audited, nothing a buyer types is ever treated as an instruction to a machine, and a brave soul reaches their own order from the link in their confirmation email rather than by making an account.

So a charity haunt on bindro raises money on the gate price itself, which is how most of them raise it anyway. Everything that makes a volunteer-run haunt work is here: costs that only exist when you sell something, a fee you can pass to the buyer so the cause keeps the gate, promo codes for a community night, and comps that consume real inventory while writing no revenue lines — so the free places you gave away are counted as places and never flatter the takings.

What you will have to do elsewhere is the gift. If a supporter wants to add ten dollars at checkout, bindro has no box for it; if they want a receipt for a donation, nothing here issues one. Those are refused by the engine rather than half-built, which is deliberate — a donation control that took money without producing a receipt would be worse for a charity than not having one. Take gifts on whatever you already use, and let the haunt be the haunt.

For a committee rather than an operator: there is no contract, no notice period, and the fee, the payout rule and the exit are all on this page rather than in a proposal.