Sell 300 tickets and someone will forward a screenshot of theirs to a friend. Ticket fraud at small and mid-size events is almost never a forged code; it is the same legitimate code turning up twice. Once you know what is actually inside a ticket QR code, the defenses, and the ones you can skip, become obvious.
What is actually in the code
For most ticketing systems, the code contains one thing: an ID. A long random string that keys to a database record holding the buyer, the ticket type, and a status field. The code itself proves nothing, and that is deliberate. Any phone can decode any QR code, so nothing secret can ride inside it. All the security lives server-side, in the lookup. A longer or denser-looking code is not a more secure one; what matters is what the server does when that ID arrives.
The variant is a signed payload: the ticket data plus a cryptographic signature, so a scanner app holding the matching public key can verify authenticity with no network at all. Venues with cellular dead zones use this. The signature proves "we issued this"; it cannot prove "this has not been used yet", which still requires shared state. Most events run on the plain-ID model, and it is what general-purpose platforms implement.
The half-second after the scan
Validation is a short, strict sequence:
- The scanner decodes the QR code and extracts the ticket ID.
- It queries the server, or a locally synced copy of the ticket list.
- The server checks the ticket exists and matches this event and date.
- It checks the status: if already used, the screen goes red and shows when and at which gate the first scan happened.
- If valid, it marks the ticket used and shows green. This final write is the entire security model.
Everything an organizer cares about (line speed, double entries, offline behavior) lives in steps 2 and 5.
Two gates, one ticket: the race condition
Picture gate A and gate B scanning copies of the same code within the same second. Both run the status check, both see "unused", both admit. The fix is server-side: the status check and the mark-used write must happen as one atomic operation, not as a read followed by a write. Well-built systems do this, and it is a fair question to put to any ticketing vendor directly.
Offline mode reopens the hole. If gates cache the ticket list and sync every few minutes, a duplicated code can pass at two different doors inside one sync window. The mitigations are operational, not cryptographic: run a single entrance when attendance allows, assign ticket types to specific gates, and treat the residual risk as what it is, a handful of possible double entries rather than a systemic failure.
Screenshots are the threat model
A valid ticket ID is a long random string, and guessing one is not a realistic attack, so forgery against server-validated tickets is effectively off the table. The realistic problem is duplication: a buyer shares a screenshot with friends, or resells the same PDF to three people. Every copy is equally real. First scan wins, and the person refused at the door is sometimes the legitimate buyer, which turns a fraud problem into a refund-desk argument.
Large venues counter this with rotating barcodes: the official app regenerates the code every 15 seconds or so from a rotating secret (Ticketmaster's SafeTix is the best-known example), so a screenshot goes stale before its owner reaches the gate. The cost is heavy. Attendees need the app, an account, battery, and usually a connection, and transfers only work inside the platform. At a 20,000-seat arena that trade is worth it; at a 200-person conference it is friction with no payoff. For where duplication ranks against other QR abuse, see the QR code security overview.
What a small event actually needs
Under roughly 500 attendees, the honest answer is a check-in list and any phone. Generate a unique code per ticket, resolve each scan to an attendee record, mark arrivals. A modern phone camera reads a code off another phone's screen in about a second, so dedicated scanner hardware solves a throughput problem you do not have. QRolling's event QR code generator covers the hosted event page, and bulk generation on the paid tier produces the per-ticket codes; a spreadsheet can be the check-in list if the team stays small. Keep a printed attendee list at the door as backup; when a battery dies or the venue WiFi drops, paper still works.
The door itself (staffing, line flow, WiFi fallbacks, what greeters say when a scan fails) is its own discipline, and we cover it in event check-in with QR codes, published alongside this post.
Refunds and transfers must void the old code
A refund is not complete until the server flips that ticket's status to void; the buyer still has the PDF, and it should scan red from that moment on. Transfers work the same way: issue a fresh ID to the recipient and void the original, otherwise a transfer quietly creates two working copies. This is also the quiet argument against fully offline signed tickets: revoking one means pushing a void-list to every gate, so refundable and transferable tickets effectively demand an online lookup or tight sync intervals.
Before doors open at your next event, run the two-phone test: take one real ticket, screenshot it, and try to check in from both phones. If both show green, you have found the conversation to have with your ticketing setup while it still costs nothing.
