Working a club door with no signal: wristbands, scans and the age check

How does scanning work in a basement with no reception?

The device takes a signed manifest of the night before the doors open and then stops needing the network entirely. Validation is local and does no input or output at all, which is what makes it fast enough for a queue: the answer comes from the device, not from a request that may not complete.

Afterwards the shift log uploads. Replaying it twice is safe — the second upload counts as duplicates rather than as a second set of admissions — and this vertical requires the offline path rather than treating it as a fallback, because for a rented basement the offline case IS the case.

Wristbands or QR codes at the front?

Either, and interchangeably at the same scanner. You bind a wristband uid to a guest and the door admits that band exactly as it admits the ticket QR. Only a keyed hash of the uid is stored, so a leaked database is not a box of working wristbands.

Wristband is the primary mode configured for club nights for a practical reason: a band on a wrist survives four hours of a dance floor, and a phone screen at twenty percent battery does not. If a ticket is handed on to somebody else, any wristband bound to it is cleared in the same transaction as the transfer — a band that still worked would be a second live credential for one place.

What does the age check on the door actually do?

Two separate things, and it is worth being exact about which is which. At checkout, the booker confirms they are eighteen or over and gives a date of birth, and an under-age date is refused on the money path before any payment — an unparseable date is refused too, because a rule that garbage bypasses is not a rule.

At the door, your operator confirms explicitly that ID was checked, and only then is the admission recorded, with that confirmation stored against the scan and the operator who made it. The flag is per scan rather than per order on purpose: one person can buy four tickets, and recording ID verified against the order would assert something about three people nobody looked at.

What bindro does not do: scan or store identity documents, call a third-party age verification service, or claim to have verified anybody on your behalf. On an 18+ licensed night the check is yours and so is the licence. A platform that pretended otherwise would be worse than one that says where the responsibility sits.

What happens with double scans, guest list and re-entry?

A second scan of the same credential at the same session is reported as a duplicate, not a fresh admission, and a ticket scanned on two devices at once surfaces in a conflict queue in the console for you to review after the night. First scan wins by timestamp when the logs come back together.

Guest list is complimentary tickets issued from the console. They admit like any other ticket and they consume a place in the pool — a guest list that did not would be how a room ends up over its licensed capacity at one in the morning.

Re-entry is not something bindro authorises: this vertical is configured as single entry, so stepping out and coming back is a door policy handled with the wristband on the wrist. Decide it before the night and tell the front of house, because the scanner will call the second scan a duplicate either way.

Can I sell to walk-ups at the door?

On a card, yes — the till takes on-site payment on the operator device and the sale goes down the same money path as an online one. In cash, no, and that is a deliberate refusal rather than a missing feature: a cash sale typed into bindro would credit your balance for money the platform never held and then transfer it to you at payout, paying you twice for one ticket.

Merch and drinks can be recorded at the same till for your bar spend numbers, but those takings stay with you and never enter the platform ledger for the same reason. What you get is an auditable record of the night, not a second pot of money to be paid out.