Retail age checks are a different problem from door checks. They happen mid-transaction, they are performed by someone who is also handling payment, and the customer is usually already committed to the purchase. Speed matters, but so does something operators think about less often: what the check leaves behind.
The scan log problem
Barcode scanning is the standard technology upgrade in this category, and it is worth being precise about what it does. The two-dimensional barcode on a driver’s licence encodes the full record — name, address, birth date, document number, and more — as one block. A scanner reads all of it, because there is no partial read. The software then compares a birth date to a threshold and decides what to keep.
In practice, systems keep more than anyone intended, for longer than anyone remembers, in a database whose ownership is unclear. For a multi-store operator, this compounds: which stores retained what, under which software version, with which franchisee configuration, is a question most chains cannot answer quickly.
The compliance requirement, meanwhile, was narrow: establish that the customer is old enough. Everything else is risk absorbed for no return.
What mobile ID does differently
A mobile ID is a set of independently verifiable elements, and the credential includes issuer-signed age attestations. A verifier can request the age attestation alone.
The difference is the ordering. Scanning is collect everything, then decide what to keep. A single-element mobile ID request is decide what to ask for, then collect only that. The first requires trusting a retention policy across every store and every software version. The second removes the question.
What this looks like at a register
The check stays at the counter. The cashier holds the verifier; the customer taps their phone. Nothing changes hands, and the phone does not leave the customer.
One outcome, one action. Verified proceeds to payment. Under 21 refuses per policy. Cannot verify falls back to your normal manual check — which is also what happens for every customer without a mobile ID, so staff are not learning a new exception.
Reporting rolls up by store. A district manager sees volume and outcome mix per store and per day. They do not see a customer, because there is no customer record underneath.
Honest limitations for this category
Most customers still present a card. Mobile ID share will be a minority for years. This is an additional path, not a replacement.
It is a standalone check, not a POS interlock. If your compliance posture requires the transaction to be hard-blocked by the age result, that is an integration conversation. Do not assume it from a vendor’s website — including this one.
Age thresholds are per-attestation. A verifier built for age_over_21 cannot answer a different threshold. If you sell products gated at multiple ages, establish that early.
Your jurisdictions may not be covered. Which states issue mobile IDs, which wallets carry them, and which combinations a given vendor has validated are three separate facts. Check all three against the stores you actually operate.
What a multi-store evaluation should measure
Mobile-ID share by store. It will vary more between locations than operators expect — demographics and proximity to a participating state’s population drive it.
Seconds added or removed at the register, measured at a busy hour rather than an average.
Cannot-verify rate and its causes, decomposed. An undiagnosed rate is not actionable.
What your current scanning stack actually stores, per store, today. Run this in parallel. The answer is frequently the finding that decides the project.
Behaviour during a store network outage. Retail Wi-Fi fails. A check that stops when the network does has failed the relevant test.
Deployment notes
One verifier per staffed lane, or a shared unit for low-volume stores where the lane count exceeds the age-gated transaction rate.
A charging position at the lane, not in a back office.
Write the fallback down and put it where staff can see it. The cannot verify outcome needs an obvious next step, or it becomes a hesitation in front of a queue.
Brief loss-prevention and compliance teams early. The absence of a scan log is a change to their evidence model, and it is better discussed in week one than at an audit.
How LaurelID fits retail
Laurel’s own product.
A handheld verifier at the register. The entire request is one element — age_over_21, with retention declined — so no name, address, birth date, or document number ever reaches the platform. There is no scan log because there is nothing to log: outcomes are stored as aggregate counters per location and day, with rows below a minimum group size of three suppressed.
Verification is local, so a store network outage delays reporting rather than stopping checks. There is no POS integration today, and we would rather say so here than discover it during your rollout.
Checked-in owner-attested evidence records Apple Wallet and Google Wallet physical interoperability on Elo M51. Current physical-evidence, trust-binding, promotion, and production status are derived from the reviewed registry on supported mobile IDs. See the liquor retail page for the deployment context.
Sources
- ISO/IEC 18013-5:2021 — Mobile driving licence (mDL) application — ISO
- Mobile Driver License Digital Trust Service — AAMVA
- Supported attributes for credentials in Google Wallet — Google
How to read this article
Statements about standards, wallets, and issuing authorities are drawn from the primary sources listed above. Statements about what LaurelID does are ours, and are marked as such in the text. Nothing here is legal advice, and wallet or jurisdiction availability changes — check the source before relying on a detail.