How QR Ticket Validation Works: Valid, Duplicate, Expired and Invalid Tickets

How QR Ticket Validation Works: Valid, Duplicate, Expired and Invalid

A scanner that reads a QR pattern has done almost nothing useful. What an entry team needs from a scan is an outcome and a next action: admit this person, turn this person away for a stated reason, or call a supervisor. Everything below is about getting to that reliably at a noisy gate, including when the network does not work.

Where this fits, stated once

Nox-Tickets is the dedicated ticket and gate deployment form of NoxOrigin. Events & Ticketing is not in the current NoxOrigin application and is not included in any NoxOrigin plan, so this form is available as a scoped dedicated or white-label deployment, quoted separately. Nothing on this page is a plan feature you can turn on. The rest of the article is about the operating problem, which is worth solving whether or not you ever talk to us — see also QR ticket scanning software and Nox-Tickets.

The five outcomes, and why they must be separate

Most entry problems are not "scanning failed". They are five different situations that need five different responses, and the single most common design mistake in ticketing software is collapsing them into one red screen. An operator who cannot tell "you already used this" from "this is the wrong gate" either waves people through or turns away paying customers, and both errors are invisible until reconciliation.

• Valid — accepted for the current event or access group. Admit.
• Duplicate — already used, subject to the event's re-entry policy. This is the one outcome that needs a policy, not a check: re-entry for a re-entrant ride, a multi-entry pass, a staff or VIP entry, or a genuine second attempt at the same gate are four different answers.
• Expired — outside its permitted date or time window. Common with multi-day passes and early-bird tiers, and a frequent source of queue friction if the boundary is not visible.
• Invalid or revoked — the code cannot be accepted: unknown, forged, or cancelled after issue.
• Wrong group — genuine ticket, wrong gate, ride, or zone. This one is worth separating specifically, because the fix is redirection, not refusal, and a system that reports it as "invalid" sends a paying customer to a supervisor for no reason.

Keeping these distinct is also what makes post-event reporting worth having. Rejections grouped by reason, gate, and time are the only evidence you get about which of the five is actually costing you queue.

The operator, the device, and the override

Assign each approved device to a gate or access group before doors open, and give each operator only the permissions their assignment needs. When a legitimate exception appears, the correct path is a supervisor override with a recorded reason — not making every operator an unrestricted override user, which is the same as having no control at all.

Feedback has to work in the environment, not in the demo. The reason must be legible on screen and distinguishable by ear over gate noise. Test lighting, battery, device handover between shifts, and — this is the one people skip — how long it actually takes to get a supervisor to the gate. A 90-second escalation turns a correct rejection into a queue.

Offline is an operating condition, not an exception

Connectivity failure at a venue is a matter of when, not whether. A device can validate against ticket data it already holds, queue the scan locally, and synchronise when it reconnects, and that is a reasonable design. The consequences are what need deciding in advance, because they are not solvable at the gate:

• Stale revocations. A ticket cancelled while the device was offline will still validate. You need an agreed answer for the customer standing there, not a policy discovered later.
• Two gates, one ticket. If the same ticket is scanned at two gates before either device reconnects, you will have two admissions and one ticket. Decide which wins, or accept that a supervisor resolves it manually.
• Replay is not reconciliation. Queued scans syncing successfully tells you nothing about whether the outcome was correct. Pending-sync visibility and a conflict list are what you actually operate from.

Run the drill before the event, not during it: register the devices, verify ticket-data freshness, force a disconnect, queue scans, reconnect, replay, and confirm the pending count and conflict list match what you expect. The offline ticket scanner guide covers the connectivity boundary in more detail.

Scan exceptions: the small list that recurs

A short list covers most real exceptions, and it is worth writing your answers down before the event rather than inventing them at the gate:

• Photographed or screenshot code replayed at a second gate.
• Same ticket presented by two people in a group booking.
• Staff, organiser, or guest-list entry that has no ticket at all.
• Damaged or defaced code that will not scan.
• Ticket bought at the gate itself, minutes before entry, not yet in the device's data.
• A customer who genuinely bought twice — a duplicate purchase, not a duplicate use.

Each of these has a different correct answer and a different person who can give it. Anything not on the list is a supervisor decision by default.

After the event

Compare valid scans against tickets issued, replacements, no-shows, and counter sales. Review rejections by reason, gate, device, and time. The record that makes this possible contains the operator, the device, the outcome, and the timestamp for every scan — which is also the record that settles a dispute with a customer three weeks later. Without it, an event's reconciliation is a spreadsheet reconstruction from memory.

Gate checklist

• Devices registered and approved for the right gate or group.
• Operators have individual accounts and scanner permissions limited to their assignment.
• Valid, duplicate, expired, invalid and wrong-group outcomes are understood by everyone on the gate.
• Re-entry policy is written down, not assumed.
• Override rules and supervisor escalation are agreed, with a realistic response time.
• Visual and audio feedback tested in the actual venue.
• Offline queue, reconnect, replay, and conflict handling drilled before doors open.
• Post-event report reconciles scans with issued tickets and exceptions.