QR code tickets, done properly

QR codes carried roughly every ticket in the UK by 2026 — and they're routinely implemented badly. The gap between a smooth 400-person door and a queue meltdown is a handful of technical choices made weeks earlier.

How a QR ticket actually works

The code encodes a ticket reference (ideally a signed token, not a raw ID) that the scanner app validates against the guest list and marks as used. Everything that matters operationally follows from one question: what happens when the same code appears twice?

• Static QR: the code never changes — screenshots work forever, so first-scan-wins is your only defence.
• Rotating QR: the code refreshes (15–60s) in the app — screenshots die on their own; this is DICE's and the majors' anti-fraud backbone.
• Signed offline QR: cryptographically verifiable without connectivity — the difference between a door that survives a basement with no signal and one that doesn't.

The four door-day failure modes

1. No signal: demand offline mode with local sync — venues are Faraday cages with bars attached.
2. One scanner for 300 people: real throughput is 6–10 scans/minute/device including fumbling; staff accordingly (a 400-person doors-at-7 needs 3+ devices).
3. Brightness and cracked screens: torch-assisted scanning and a manual lookup fallback (name search) rescue ~5% of entries.
4. Duplicate chaos: when a code scans as 'already used', the protocol is calm name-lookup — the legitimate holder is usually the one standing there.

Wallet integration

Apple/Google Wallet passes cut door friction measurably — the ticket surfaces on lock screens by time and location, brightness auto-boosts, and phones-on-airplane-mode still display it. See our guides to Apple Wallet and Google Wallet tickets.

What to ask any platform

• Offline scanning with multi-device sync? Free scanner app on staff phones, or hardware rental?
• Rotating or static codes? Signed payloads?
• Live entry dashboard and re-entry handling?
• Manual check-in fallback by name/order?