Three places entry can fail
Getting someone through a gate involves three things working together:
- The attendee’s phone has to show the ticket.
- The scanner has to decide whether the ticket is valid for this event.
- The shared record of check-ins has to tell every scanner which tickets have already been used.
In a connected venue, all three can lean on the internet. A ticket in an email or on a web page may need to load from a server, a scanner app may ask the ticketing platform about each code, and the platform keeps one list of check-ins for every device. When a venue’s network saturates or its uplink fails, each of the three needs its own fallback. How do stadiums cope when phone networks saturate? covers why that happens on busy days.
The attendee’s phone
The simplest fix is on the attendee’s side: have the ticket stored on the phone before arrival. Apple describes the Wallet flow as a user adding a pass to the Wallet app on their device, then holding the device near an NFC reader or scanning a barcode on the pass. Google notes that links to an event ticket work offline when the Google Wallet app is installed.
Wallet tickets come in a few forms, and each puts a different demand on the gate:
- A static barcode that the scanner reads like any printed code.
- A rotating barcode, which Google says changes periodically, typically every minute, with the reader programmed to accept only the most recent one. That limits screenshot sharing, but the reader has to be set up to know which code is current.
- NFC tap, which on Google Wallet uses Smart Tap and needs terminals that support it.
Google also lets an issuer require a screen lock before a pass is shown, to protect the holder’s access to it.
The scanner
A scanner app does more than read a code. Eventbrite’s organizer app, for example, offers three scan behaviours: check attendees in, check them out, or validate only, which shows whether a code is valid for the event without changing anything. In the default mode it shows an error if a code is already checked in or not valid for the event, and staff can search for an attendee and check them in by hand.
To answer those questions with no connection, the scanner needs the answer on the device. There are two ways to do that: download the list of valid tickets before the doors open, or issue tickets that carry the issuer’s signature so the scanner can check them with a stored key. How are tickets checked at a gate with no internet? goes through the signed-ticket approach step by step.
The shared record
The hardest part to keep offline is the record of who is already inside. Eventbrite describes running check-in on several devices at once, with data syncing automatically so that every team member has the current attendee list and duplicate entries are prevented. That sync is what lets the north gate reject a ticket already used at the south gate. Without a connection, each scanner knows only its own scans.
The approaches compare like this:
| Approach | Valid ticket check offline | Repeat scan at the same gate | Repeat scan at another gate |
|---|---|---|---|
| Live lookup on every scan | No | Only while online | Only while online |
| Ticket list downloaded to each scanner | Yes, against the list | Yes | No, until scanners sync |
| Signed tickets checked with a stored key | Yes, by signature | Yes | No, until scanners sync |
| Either of the above, plus local sharing between scanners | Yes | Yes | Yes, for scanners that can reach each other |
Where device-to-device sync fits
The last row is where local software helps. If scanners pass each check-in to the scanners near them, directly over a short-range radio or through a relay device, a ticket used at one gate shows as used at the others within moments, with no internet involved. Gates that cannot reach any other scanner fall back to the downloaded list or signature check, and their records merge when they reconnect.
Two design choices keep it safe. Each check-in needs its own ID, so a record that arrives twice, once directly and once by relay, is counted once (see message deduplication). And the merge rule must never drop a scan, so a ticket admitted at two gates during a gap is visible once the records meet. The article on checking tickets at a gate, linked above, explains both in more depth.
The rest is planning on the ground. Scanners at neighbouring gates need to be within radio range of each other, or have a staff phone between them that can relay. Staff need a clear rule for what a scanner shows when it is working alone, so a gate does not stop admitting people just because it cannot see the others. And the ticketing platform stays the system of record: local sharing narrows the window in which a copied ticket can get in twice, and the platform reconciles everything once the connection returns.