Designing Event QR Check-in That Works When the Venue's Wi-Fi Doesn't
Every event organiser discovers the same thing at the gate: the venue Wi-Fi that worked fine during setup becomes unreliable the moment a crowd arrives. Two hundred people walking in at the same time, all of them downloading the event app, streaming stories, and running GPS in their pockets, collapses the same access point that held up fine during the sound check. The result is a queue, frustrated staff, and a check-in process that grinds down to manual clipboard verification — which is what the ticket QR was supposed to replace.
This article covers the system design decisions that prevent that from happening. It uses Boni Event Ticketing as the worked example, but the patterns apply broadly to anyone building or evaluating event check-in infrastructure.
The Real Problem at the Gate
Gate check-in sounds simple: scan a QR, confirm it is valid, let the person in. The difficulty is that "confirm it is valid" carries hidden assumptions.
In a fully connected world, the scanner calls a central server, the server checks whether the ticket exists and has not already been used, and it responds with a green or red light. That round-trip takes perhaps 300 milliseconds and works perfectly — until it doesn't. When connectivity drops, every scan attempt hangs while the app waits for a response that isn't coming, or fails immediately with a network error, leaving the operator with no good option: hold the queue or let people through unchecked.
A robust check-in system must handle three separate concerns simultaneously:
- Tamper resistance — can you trust that the ticket in front of you is genuine without calling home to verify it?
- Double-scan prevention — even if the ticket is genuine, has it already been used?
- Offline tolerance — what happens when the connection is flaky, and how do you stay consistent once it returns?
These three concerns require different design decisions, and they interact with each other in ways that matter at scale.
What a Good Ticket QR Encodes
A QR code is just a payload — what it encodes determines how much trust you can place in a scan without a server call.
The weakest approach is a plain ticket ID. If the scanner has connectivity, it looks the ticket up; if not, it cannot validate anything. A stronger approach embeds enough signed data in the QR itself so that the scanning device can verify authenticity locally, without needing to phone home for every scan.
The illustrative payload shape below is not the live Boni Event Ticketing specification. It is included to show the design pattern; readers should consult current Boni documentation for the actual format.
// Illustrative only — not the live spec
{
"tid": "EVT-20260810-A4F2",
"eid": "boni-event-7291",
"issued_at": 1754918400,
"expires_at": 1754962800,
"holder_name": "REDACTED AT PRINT",
"category": "general-admission",
"sig": "<base64-hmac-or-ecdsa-signature>"
}
The critical field is sig. The issuing system signs the payload using a private key. The scanning device holds the corresponding public key (or a shared secret, if using HMAC). When a ticket is presented, the scanner checks the signature without making any network call. A valid signature means the ticket was genuinely issued by the ticketing system; no amount of editing the payload fields will produce a valid signature without the key.
This solves tamper resistance entirely offline. But it does not solve double-scan prevention, because the signature tells you nothing about whether the ticket has already been scanned somewhere else.
Validation and Double-Scan Prevention
Double-scan (or "passback" — one person scanning in, handing the phone back to a friend who scans the same QR) is the gate problem that cannot be solved by cryptography alone. You need shared state: a record of which tickets have already been admitted.
In a connected environment, that state lives on a central server. Every scan writes a record; every subsequent scan for the same ticket ID reads that record and returns a rejection. The server is the single source of truth.
The design challenge is that you cannot afford to make every scan block on a server round-trip when connectivity is unreliable. There are two established patterns for handling this:
Online-first with graceful degradation. The scanner attempts a server call for every scan. If the call succeeds within a short timeout (say, 1–2 seconds), the server's answer is authoritative. If the call times out or fails, the device falls back to local validation — signature check only — and queues the scan record for later sync. This means that during outages, the system accepts any cryptographically valid ticket, which introduces a window for passback. For most events, this is an acceptable trade-off; the alternative is turning people away at the gate.
Pre-loaded ticket set with local state. Before the event, the scanning device downloads the full set of valid ticket IDs (or a compact representation such as a Bloom filter). Scans are validated and recorded locally. Scanned IDs are synced to the server whenever connectivity is available. This approach closes the passback window even during outages, at the cost of requiring a pre-event sync and managing the local dataset on each device.
For a multi-gate event — a festival with four entrances simultaneously processing scans — local state on each device diverges until the devices sync. A ticket holder could, in theory, pass through gate 1, hand their phone back, and have a second person enter at gate 4 before gate 1's scans propagate to gate 4. Reducing this window requires more frequent sync intervals and, for high-stakes events, a mesh-sync approach where gate devices replicate to each other directly over the local network rather than waiting for internet connectivity.
Boni Event Ticketing implements QR-based gate check-in with double-scan detection. The exact synchronisation strategy across gates is a configuration and deployment detail; organisers running multi-gate events should discuss their venue setup during onboarding.
Offline-Tolerant Design and Later Sync
"Offline tolerance" is not a binary property. It exists on a spectrum depending on how much local state the scanning device carries and how aggressively it syncs.
The minimum viable offline posture is: the device can validate a ticket's authenticity (signature check) without connectivity, and every scan is durably written to local storage so that no admission record is lost if the device loses power or the app crashes. When connectivity returns, the local queue flushes to the server in order.
A stronger posture adds the pre-loaded ticket set so the device can also reject invalid tickets (not just confirm valid ones) during outages. This is more complex to build and to operate — the ticket set must be kept current, and revocations (refunds, cancelled orders) must propagate to devices before they go offline.
The practical guidance for organisers is straightforward: ensure your scanning devices complete a sync with the server before gates open. A device that has checked in with the server in the last five minutes before doors open is carrying current state. A device that has not synced since the morning of a multi-day event may be working from stale data. Build a pre-gate-open sync check into your operations checklist, the same way you check that the audio feed is live before letting the audience in.
Capacity Reconciliation
Ticket check-in is also an inventory problem. If an event has a capacity of 500, the gate system must prevent more than 500 people from being admitted regardless of how many valid tickets were sold (overselling) or how many devices are scanning in parallel.
Reconciliation means comparing the count of scans — from all devices, after sync — against the ticket inventory. Discrepancies fall into three categories:
- Scans with no matching ticket (fraudulent or corrupted QR, handled by signature rejection at the device).
- Valid tickets that were scanned more than once (passback events, flagged by the double-scan check).
- Valid tickets that were scanned on a device that has not yet synced (the in-flight window during outages).
After the event, the server-side reconciliation report tells the organiser exactly how many admissions were recorded, how many tickets were unused, and whether any anomalies occurred. This is the source of truth for post-event capacity compliance and for any disputes.
Boni Event Ticketing provides admission tracking through the organiser dashboard. Anomaly reporting specifics depend on the event configuration; organisers can review admission counts in real time as synced scans arrive.
Current Status
Boni Event Ticketing is live and actively used for events in India. Free events are fully supported end to end, including QR ticket generation, attendee communication, and gate check-in. For paid events, payment processing runs through Razorpay; standard Razorpay payment-gateway fees apply. Boni does not mark these up, but we are not quoting exact rates here because payment pricing changes — reach out for current details.
The gate check-in capability described in this article — QR-based scanning with offline-tolerant validation and double-scan detection — is a real feature, not a roadmap item.
Getting Started
If you are planning an event and want gate check-in that does not fall apart when the venue internet does, the design patterns above are a useful starting framework. Boni Event Ticketing is built around these principles and handles the infrastructure so your team can focus on running the event rather than debugging scanners.
Visit boni.one to learn more or get in touch about your next event.
Originally published on the Boni blog.