Checking tickets in without a network

Before the doors: one sync, while there is still signal

The gate is a web page, not an app. An usher signs in with an access code, and the phone downloads the event’s pass list while it has a connection. That list is signed by the platform, and the phone verifies the signature on the device with a public key it downloaded at the same time. It holds no secret that could mint a pass, so a phone that is lost or stolen forges nothing.

Do this at the venue rather than at home. The list the phone holds is a snapshot of the passes that existed when it synced: tickets sold after that are not on it, and a pass that was voided after that still looks valid to a phone that never resyncs. Each sync also carries a version, so a phone working from an out-of-date list is told so the moment it next reaches the server.

At the door: scan, admit, next

The phone checks the pass against the list it has and records the admission locally. No request is made, so the scan costs the same whether the network is up or not.

• A second scan is refused on the device, with the time the pass was already admitted. The phone knows what it has let in.
• A pass from another event is refused, because the list only carries this event’s passes.
• There is a manual search for a phone with a dead battery or a pass on a cracked screen: name, email or order reference, then admit or refuse by hand, with the same record written.

When the signal comes back

The admissions taken offline are queued on the phone, and the queue is replayed to the server. Each queued admission carries an id the phone generated when it scanned, so a batch that is retried after a timeout counts once rather than twice.

Every replayed claim goes through the same admission the online path uses, which is the part that matters: the server is still the one that decides. A pass admitted on another device comes back refused as a duplicate, the check-in window is judged by the server’s clock rather than the phone’s, and the offline claim records that it was taken offline so the event’s numbers can separate the two.

What this means for staffing

Give each door one phone. Two devices working the same door offline each keep their own list of who they let in, so the same pass can be admitted by both, and the second claim is only refused when the queues replay. That is the right behaviour for a platform that will not pretend a device can see another device, but it is the wrong setup for a door: one phone per entrance keeps the duplicate check on the device that needs it.

Check the phones before the queue arrives. Open the gate, confirm the pass list has synced, scan one real pass and watch it appear as admitted. A phone that has lost its storage looks exactly like a phone that has never run, and the gate screen says which, because a browser reclaiming a site’s storage is a silent failure otherwise.

What the numbers look like afterwards

The event’s own screen counts admissions, splits online from offline, and lists the duplicates and refusals with the reason each one was refused. Those figures are derived from the same rows the replay wrote, so a claim that arrived an hour after the doors closed shows up where it belongs rather than in a separate report.

Where to read further

How it works puts the gate in the context of the whole funnel, and help answers the questions that come up at a venue: a pass that will not scan, a duplicate, a phone that died. If you want the reasoning behind the signature rather than the routine, the about page’s short version is that the device verifies with public keys and never holds a signing key.

Other guides

• Pricing a ticket in Lagos

  What a Lagos ticket price has to cover, how the processing fee sits on top of it, and why two ticket types with their own stock sell more than one number.

• Getting into the directory

  What makes an event appear on the directory and its city pages, why an unpublished draft is invisible, and what the city and category hubs need to be indexed.