Door check-in on BrightStar runs entirely in a phone's web browser. There is no app to install, no store account to create, and nothing for a volunteer to set up beyond opening a link and allowing the camera. That matters at the door of a kirtan, or at a retreat check-in table where the last thing anyone wants is a queue building while someone hunts for a password or waits on an app store download to finish. The scanner opens on the event you picked, shows how many of your active tickets have already come through, and starts reading QR codes right away.
Decoding happens on the phone itself. Each frame the camera captures is read locally, and only the ticket reference it contains is sent on to BrightStar to be validated — nothing else about the image ever leaves the device. That local decoding step is what keeps the loop fast enough to hold a line together, since the phone is never waiting on a full image upload before it knows whether to admit someone.
What happens when you scan a code
Every scan runs through the same fixed sequence, and stops at the first thing that fails. Knowing the order helps explain why a particular scan comes back the way it does.
- 1The camera frame is read on the device and the ticket reference is extracted.
- 2The reference is sent to BrightStar together with the event you are scanning for.
- 3BrightStar confirms you are allowed to scan that event, and refuses the request outright if not.
- 4A rotating QR code is checked against the codes on issue: an unknown one is rejected, one already used is rejected, and an expired one comes back asking the attendee to refresh their ticket.
- 5The ticket itself is then checked: it must exist, it must belong to this event and not another, and it must still be active rather than refunded or voided.
- 6If the ticket already carries a check-in time, it comes back as already checked in, along with the time of the first scan.
- 7Only if every check passes does BrightStar stamp the check-in time onto that individual ticket, and the guest's name and ticket type come back to the screen.
Why do rejected scans show a reason instead of a blank error
A refusal at the door is never a blank error. The scanner shows the specific reason — already checked in, ticket is for a different event, ticket is refunded, QR code expired — so the person at the table knows what to say to the guest rather than having to flag down an organizer mid-line. That distinction matters most at a festival gate or a multi-session retreat, where a handful of different refusal reasons could otherwise look identical and leave a volunteer guessing what to do next.
The result card can clear itself after three seconds, after five seconds, or wait to be dismissed by hand, whichever suits the pace of your line. A quiet kirtan door might want the card to linger long enough for a volunteer to read a name aloud, while a fast festival gate wants it gone before the next guest arrives. A short buzz on a valid scan and a different pattern on a rejection means the operator can keep their eyes on the guest instead of the screen. Where the phone supports it, the torch can be switched on from inside the scanner for a dim entrance after sunset, and the front and rear cameras can be swapped mid-event.
How do you check someone in without a working code
Some guests arrive with a dead battery, a printed page that will not read, or a ticket sitting in someone else's inbox because a friend bought it for them. None of that should mean turning someone away at a retreat check-in table they traveled hours to reach. The attendee list inside the scanner is searchable, and tapping a guest's name checks them in directly, without a code ever being read.
A manual check-in is recorded as manual rather than as a scan, so afterwards you can see how many people came through the camera and how many were let in by hand — useful if you're trying to understand where a door slowed down. The checks applied are the same ones the camera path runs: a ticket for a different event or a ticket that is not active is refused here too, and a guest who is already checked in simply comes back with the time they were first admitted, rather than being let through twice.
What information does a check-in record
On the ticket Check-in time: stamped on the individual purchased ticket, which is the authoritative record Method: whether it was a camera scan or a manual check-in Device: which scanner made the check-in
Counts Source: the number of active tickets carrying a check-in time, per event Scope: refunded and voided tickets are excluded from both the total and the scanned count
Event list Shown: the events the signed-in user or paired device is allowed to scan Hidden: events that ended more than 24 hours ago