Mobile Age Verification for Stadiums and Venues

Three conditions define age verification at a venue, and they all arrive at the same moment.

The three conditions

Peak concentration. Concourse alcohol sales cluster into short, intense windows — doors, intermission, and the period before the event ends. Average throughput is irrelevant; the peak is the whole design problem.

A saturated network. A full venue has tens of thousands of phones competing for Wi-Fi and cellular capacity. Any verification design that needs a server round trip per check will start timing out precisely when the queue is longest.

A large temporary workforce. Concessions are frequently staffed by part-time or event-day workers, often working few events per season. Any check that requires interpretation — of a hologram, of an unfamiliar state format, of an out-of-state card — will produce inconsistent decisions across dozens of stands on the same night.

Every design decision worth making here follows from those three.

What the conditions imply

The check must be local. In the ISO/IEC 18013-5 device-retrieval model, the phone hands data directly to the reader over NFC and BLE, and the trust material the reader validates against is loaded ahead of time rather than fetched per check. That is what allows verification to work when the network does not.

Treat “does a check require a network round trip?” as a disqualifying question. If the answer is yes, the product does not fit a venue, whatever else it does well.

Reporting must queue, not drop. Records generated during the outage need to survive it, and delivery after reconnection must not inflate the counts. That requires a durable local queue with explicit bounds, a stable identity per record, and idempotent processing when it finally arrives. Ask what happens when the queue fills — silently discarding the oldest records turns an operational problem into an invisible data problem.

The interface must be trainable in minutes. Three outcomes and three actions. If it takes longer than that to teach, it will not survive event-day staffing.

The privacy angle, specific to venues

Venues already accumulate a great deal of attendee data through ticketing and access control. Age verification does not need to add to it, and a well-designed mobile ID check does not: the business gets counts, not attendees.

There is a second, less obvious reason this matters. Many venues host age-restricted and all-ages events in the same building on consecutive days. A design that produces no attendee-level records avoids the awkward position of holding age-related data about people who attended a family event.

What to measure in an evaluation

Run the evaluation at a real event, not a quiet weekday. Nothing else tests the conditions above.

Peak-window throughput, measured at a stand during the busiest fifteen minutes, against the same stand’s current process.

Mobile-ID share, which will vary considerably by event type. A concert crowd and a family matinee are different populations.

Behaviour under network saturation. Do not simulate this — a full venue does it for you. Confirm that checks continued and that post-event counts are correct rather than inflated.

Consistency across stands. The same patron profile should produce the same outcome at every point of sale in the building. Inconsistency across stands is a training or design problem, and event-day is when it shows.

Staff feedback after the event, from people who worked one shift. That is the realistic training-retention test.

Deployment notes

Device count scales with points of sale, not with the venue. A large concourse is a real hardware footprint. Scope it honestly before a rollout rather than discovering it during one.

Charging is a logistics problem. Devices need to be distributed, charged, and collected each event. Build that into operations planning, not as an afterthought.

Premium areas differ from general concourse. Slower, more conversational service changes what “good” looks like; evaluate them separately.

Expect a mixed line indefinitely. Mobile ID handles a growing share; your existing procedure handles the rest, at the same stand, with the same staff.

How LaurelID fits a venue

Laurel’s own product.

Verification is entirely local — a saturated or failed network delays reporting rather than stopping checks. Completed outcomes enter a bounded durable on-device outbox (5,000 rows, 8 MiB, 28 days) and drain when connectivity returns, with at-least-once delivery, stable event identity, and idempotent server processing. The result is correct aggregate counts after the event rather than counts inflated by the reconnection.

Queue pressure or expiry is visible and quarantined rather than silently evicting an accepted record.

Staff training is three outcomes and three actions, which is the design constraint event staffing imposes. Reporting is per-location aggregates with rows below a minimum group size of three suppressed, so no attendee-level record exists at any point.

More on the mechanics at offline reliability, and the vertical page at stadiums and venues.

Sources

1. ISO/IEC 18013-5:2021 — Mobile driving licence (mDL) application — ISO
2. In-person acceptance of digital credentials — Google
3. mDL Digital Trust Service — For Relying Parties — AAMVA