1. Issue: turning a purchase into a code
When the issuer confirms your payment, their system does three things. It generates a unique identifier — typically a 128-bit random value rendered as 16 to 32 characters. It stores that identifier in a database alongside the event, the seat, the price, and (sometimes) your name. Finally, it encodes the identifier into a barcode symbol, often together with a cryptographic signature that lets scanners verify the ticket is real without calling home.
The encoding is deterministic: the same payload always produces the same pattern of bars or modules. What makes the ticket unique is the identifier itself, not the way it looks.
2. Deliver: getting the code onto your screen
There are four common delivery channels, and each has different characteristics:
- PDF by email — simple, works offline, printable, and identical every time you open it. The default for most events.
- Wallet pass (Apple Wallet, Google Wallet) — a small package the phone renders itself, with push updates when details change (gate, time, seat).
- Issuer app — a code generated on demand, often refreshed every minute. Required for tickets with rotating codes.
- Printed paper — still issued by transit operators, theatres, and events that cannot assume smartphone ownership.
The barcode is the same in all four cases; the difference is how often it changes and how it reaches the gate.
3. Present: what the scanner actually sees
A scanner does not "read" a barcode the way you read a sentence. It takes a series of photographs and runs a decoding algorithm that looks for the format’s signature pattern: the "finder" squares in the corners of a QR code, the start/stop bars of a Code 128, the central bullseye of an Aztec.
Once the format is recognised, the scanner sizes the code to a pixel grid, reads each cell, and passes the resulting bit stream through the format’s error-correction algorithm. Reed–Solomon correction is what lets a scanner read a QR code through a cracked screen or a folded corner.
In practice this takes 20–80 milliseconds on a modern handheld or phone — the "beep" you hear is the confirmation, not the scan.
4. Validate: the decision to let you in
Decoding the symbol only tells the gate what the ticket ID is; it does not tell the gate whether it is valid. That happens in one of two ways.
- Online validation — the scanner sends the ID to the issuer’s server, which checks that the ticket exists, has not been used, and is for today. The server returns an allow or deny, and marks the ticket as used if admitted.
- Offline validation — before doors, the scanner downloads a signed list of valid ticket IDs. It checks the presented ID against the list locally, and records every admission so duplicates can be detected at sync time. Used at most stadiums and festivals, because venue Wi-Fi cannot be trusted to carry 60,000 scans per hour.
Both approaches rely on the same principle: the barcode is a lookup key, not proof of validity. The rules live in the issuer’s system.
What this means for you
If you understand the four stages, most of the surprising behaviour of barcode tickets stops being surprising:
- A screenshot works because the barcode encodes an identifier, and the identifier is the same in every copy.
- Only one person gets in because the issuer’s system marks the ID as used on the first scan.
- Rotating codes change because the ID is short-lived — the barcode on your screen now is not the one the gate will accept two minutes from now.
- Offline venues are fine because the allow-list was downloaded before doors opened.