Offline ticket scanning at the gate: signed codes, refunds, re-entry

Offline ticket scanning works when each code can prove itself. While it has signal, the gate phone loads the day's ticket list and the venue's public key. After that it checks every QR's signature, day and state on the phone itself, and queues each scan to send later. What it cannot know offline is a refund made since its last update: that gap is the risk you plan for.

Why gates lose signal

Gates sit in the worst places for a connection: stone entrance halls, basements, huts at the edge of a car park, piers, hillsides. The signal that worked during set-up falls over at 10:00, when the whole queue is on its phones at once. Venue Wi-Fi drops when a router restarts.

A gate that must ask a server about every ticket stops whenever that happens, at the worst moment. A gate that can decide on its own keeps admitting people and catches up afterwards. The question is not whether you will be offline, but what the gate can still prove when you are.

What a code must carry to be checked offline

A lookup code is a reference that means nothing on its own: the gate has to find it in a list. Offline it works only if the phone already holds a list containing it, so a ticket bought after the list was loaded is unknown.

A signed code carries its own proof. The ticketing system signs the ticket's facts with a private key that never leaves the server; the gate holds only the matching public key, which can check a signature but cannot make one. A forged or edited code fails. A ticket bought five minutes ago, after the phone last updated, still passes.

The signed part should hold the ticket's identity, the venue, the day and time it is for, and the guest type, so the steward knows to check a child's age. It should not hold a name, an email or anything else personal, because a QR is shown to strangers in a queue.

In iTravel Attractions, ticketing software for attractions, each ticket's QR is signed with Ed25519 by its venue's own key and carries the ticket's id, the venue, the day, the entry time and the guest type, with no name and no email. A ticket in a combo that is used at a second venue is signed by that venue, so its own gate accepts it (combo tickets across attractions). Every ticket also has a printed code of 12 characters for typing, read leniently: an O for a 0, an I or L for a 1, spaces and dashes ignored.

What the phone loads before the doors open

A signed code proves a ticket is genuine. It cannot prove the ticket is still valid, or that nobody has used it already. For that the phone needs the day.

In Attractions, a gate phone takes a snapshot of the venue's day: every ticket for today with its printed code, guest type, entry time and state (issued, used, cancelled or moved), when and at which gate it was first let in, whether the guest is inside now, the guest type's ages, the venue's public keys and its re-entry rule. There is no email in it; a named ticket carries only a short form of the name and the last four characters of the ID to check. The phone keeps the snapshot and its queue of scans in its own storage, so a page reloaded offline loses nothing.

Every ticket scan is decided on the phone from that list and answered in words: valid, already used (when, and at which gate), wrong day (and which day it is for), not for this venue, cancelled, moved, unknown, or check the age for a concession. A valid ticket whose booking has more tickets to come in today offers to let the rest in with one tap, except any ticket that still needs a check of its own, such as a waiver to sign. A member's card is checked offline from its own signed code and a short list of the cards that may not come in today (memberships and annual passes).

The list is for the venue's today. A phone loads the new day by itself the next time it reaches the server, so the last check before opening is simple: has each gate phone been online since the day began?

Refunded, moved and cancelled tickets while offline

Online, an Attractions gate phone asks every 30 seconds for what has changed: cancellations, moves, new sales and other gates' admissions. A booking cancelled at the desk reaches every connected phone within half a minute, and from then on its tickets answer "cancelled".

Offline, the phone knows only what it knew at its last update. A ticket cancelled since then still has a genuine signature and is still "issued" in the phone's list, so it passes. The gap is exactly as long as the outage.

When the phone reconnects, the server decides every scan again. A ticket let in after it was cancelled or moved is recorded as cancelled or moved, never as used, and the scan appears in that order's history with the gate that scanned it. You learn about it afterwards; you do not prevent it.

Ways to keep the gap small:

• Keep gate phones online wherever you can, on their own connection rather than one shared router.
• Make today's cancellations and moves before the doors open where you can.
• If one happens during an outage, tell the gate by radio.

Re-entry and exits

A guest who steps out to the car park and comes back is either a re-entry or a second use of the same ticket. Your policy decides which.

In Attractions, re-entry is a switch on the venue's page, off unless you turn it on. Each gate phone has an Entry and an Exit setting. A guest scanned out comes back in as a re-entry where you allow it; without an exit scan, a second entry answers "already used". Someone leaving is let out whatever day their ticket is for: an exit is recorded, never refused. The phone shows "inside now": the server's last figure plus what this phone has scanned and not yet sent.

Exit scanning costs a person at the way out. It earns its place where you need an accurate inside count against a building limit (timed entry slots and capacity).

Several gates at once

While both are online, two phones at two entrances know their own admissions at once and each other's within 30 seconds. A screenshot shared between two people is caught: the second scan, at either gate, answers "already used", with the time and the gate.

Offline, the two phones cannot see each other, and the same ticket can be let in once at each. When they sync, the first entry to reach the server is the entry and the second is recorded as already used; both scans sit in the order's history. At points inside the venue where a ticket includes a set number of uses, such as a ride or a show, two phones offline can between them allow one use too many: it is kept, marked as beyond what the ticket includes, and shown on Today.

That rule matters more than it looks: an entry that already happened is never refused when it syncs. Refusing it would not undo it, only make the records untrue.

When the phone reconnects

• The queue goes up in batches. Each scan carries its own id, so a batch sent twice after a timeout changes nothing.
• The server decides each scan again from the ticket's real state, as above.
• The phone merges what changed meanwhile, and another gate's entry or exit replaces its own memory of that ticket unless it still has a scan of it to send.
• A new day loads by itself.
• A phone that was switched off is told to forget what it holds at that contact.

Registered gate phones in Attractions are paired by name with a one-time link that lasts 30 minutes and then use their own long token, so nobody's password sits on a phone at the gate. A lost phone is switched off in one click. A registered phone checks in every 30 seconds, and its gate page opens with no network once it has been seen online. Today lists any gate phone that has synced today but has been silent for 20 minutes.

A busy morning, offline for half an hour

Say a venue sells 600 tickets for the morning and runs two gate phones, Gate 1 and Gate 2. The mobile signal drops at 09:40 and comes back at 10:10.

In half an hour offline, two problems got through, both on record with the gate and the time, and neither stopped the queue. An offline gate does not need to be perfect. It needs to be fast, honest about its gap and complete in its records. Money taken at the desk meanwhile is a question for the box office cash-up.

Checklist for the devices and the staff

The devices:

• Pair each gate phone by name, one per gate, and give each a charger at its post.
• Open every gate phone online before the doors open, so it holds today's list.
• Check that each phone's browser can scan QR codes with its camera; where it cannot, staff type the printed code.
• Keep a spare phone paired, and switch off a lost one at once.
• Decide re-entry, and switch it on only if you mean it.
• Where the inside count matters, staff an exit scan.

The staff:

• Learn one sentence for each answer: valid, already used, wrong day, not for this venue, cancelled, moved, unknown, check age.
• During an outage, keep scanning. Waving people through leaves no record at all.
• Offline, ask for the QR rather than typing a code: a ticket sold since the last update is in no list.
• Radio the gate about any cancellation for today made during an outage.
• Watch Today for silent phones, and after a long outage read the order history of any ticket you were unsure about.