bindro.

haunt guide

The gate on closing weekend: wristbands, no signal and two scan points

Reviewed: 2026-08-09

Sync the manifest before doors and the gate stops needing the network: scans validate locally, append to a device log and reconcile when signal returns. Wristbands bind to entries and scan interchangeably with codes. Two things are honestly yours rather than ours — preventing a double scan across two offline gates, and enforcing single entry, which nothing in the engine refuses.

What does the gate actually check?

A credential, and whether it belongs to the session in front of it. Every entry mints one credential at purchase; the gate resolves either the code from the buyer’s email or a wristband bound to that entry, interchangeably, so a haunt can band its regulars and scan phones for everybody else without running two systems.

Only a keyed hash of the 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. A stolen database of yours does not produce working entries.

How do wristbands get attached to entries?

Each band is bound to an attendee through the platform’s own API, which is how haunts handling thousands of bands do it in batches at the start of a season rather than one at a time at the gate. After binding, the band admits exactly where the entry did.

Worth stating plainly: a band is a credential, not an identity. It carries no name, proves no age, and if it is cut off and handed over the fence it works for whoever is holding it. That is a rope-and-staff problem, and every ticketing system has it.

What happens when the signal dies in the middle of a field?

Nothing, if you synced. Before doors, the device pulls a SIGNED manifest of the credentials valid for that session. Scans then validate locally against it with no network at all, and each one appends to a local log carrying the device’s id and a monotonic sequence number. When signal comes back the log replays and the server reconciles it.

Two design decisions are worth trusting because they were paid for: a re-uploaded log applies once rather than twice, and a single poisoned record — an attendee removed by retention after the manifest synced, say — no longer rolls back the hundreds of good scans around it. One bad row must not cost a night’s attendance.

The device is authoritative for the duration of the shift. That is the whole model, and it is why this cannot be retrofitted onto a system that assumed the network: what the door is allowed to believe changes.

What if two scan points scan the same band?

It is recorded, flagged and put in a conflict queue for you to read — not prevented. This is the stated limitation of any offline door and we would rather you learn it here than at midnight: two devices with no connection to each other cannot agree in real time about who has already come in.

When the logs reconcile, the earlier scan by timestamp wins and the later one is the conflict — decided by when the scan happened, not by which device happened to upload first. Conflicts are surfaced, never silently resolved, because a resolved conflict is a decision made about a real person who was standing in front of a real member of your staff.

If double entry would genuinely cost you money, the operational answer is one scan point, or two that share a connection. The software will not pretend otherwise.

Does a band stop working once someone has gone in?

No. Haunted attractions are configured as single-entry, and it is honest to say that this is a statement of your policy rather than a lock: nothing in the engine refuses a second scan. What it does instead is record it and flag it as a conflict — whichever gate reads the band, including the one that admitted them — and tell that gate the band has already been used to get in.

So re-entry is decided by a person on your door under your published rule. If that matters to you — and at a haunt with a bar next door it usually does — put the rule on your own page, brief the gate, and treat the conflict queue as evidence after the fact rather than enforcement during.

Who is allowed to scan, and what do they see?

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. Roles decide that: door staff scan, a manager builds the show, finance sees the money, a volunteer sees the least of all.

Rostering somebody for tonight does not grant them anything. The rota is a plan and the role is the authority, kept separate deliberately so that a seven o’clock staffing swap cannot quietly widen who is able to refund an order at eight.

What should I take away?

  • Sync the signed manifest before doors; after that the gate needs no network at all.
  • Bands and codes admit interchangeably, and only keyed hashes are stored.
  • Cross-device double scans are detected and queued, never prevented — that is what offline costs.
  • Single entry is your door policy: nothing refuses a second scan.
  • A shift is not a permission; roles are.

Reviewed: 2026-08-09

Run your nights on bindro

Nothing to pay until you sell. 2.5% + $0.99 per paid entry; free nights cost nothing.

Start selling — free