Age & Sale-Eligibility Verification
For age-restricted sales of alcohol, tobacco, or pharmaceuticals, prove only that a customer meets the age and eligibility to sell — without disclosing their birth date or ID document — at the point of sale or online, so you can meet age-verification obligations without retaining unnecessary personal data.
For age-restricted sales teams
Verify age without taking a birth date or ID at every check — removing the storage that turns into a leakage surface.
-
Retail, convenience, and e-commerce handling age-restricted goods
-
Unmanned stores, vending, self-checkout where in-person checks are hard
-
Teams needing an evidence trail for age-verification obligations
Hand over the source, or just the facts?
Nothing changes on the floor. Everything changes for the receiver.
① Your team just saves, as always.
- The usual action
- Enter the record, hit save
- On save
- a proof is attached (one API call behind the scenes)
- The document
- never sent
② They just open a link.
- Proven fact
- meets the age / eligibility to purchase
- date of birth and ID documents
- not shown
- Login / keys
- not needed
- The document stays private — the record itself is never sent or disclosed.
- Independent verification — the receiver just opens a link. No account, no keys.
- Edits are detected — even a one-character edit fails verification.
Pass only a proof that the customer "meets the age/eligibility to sell to." The birth date and ID are not disclosed. From issuer-signed attributes (public ID or eKYC), only predicate satisfaction (e.g. "20+") is shown. Stores, e-commerce, and auditors verify without seeing the contents.
(A lawful age-verification process is assumed; issuer and retention design are handled separately.)
Why the usual methods fall short.
Only work that needs all three at once — pass without exposing, independent verification, tamper-evidence — is Lemma's domain.
| Method | Pass without exposing | Independent verification | Tamper-evident | What happens |
|---|---|---|---|---|
| Access control / permissions | △ | ✗ | ✗ | “Someone inside could have edited it” remains possible |
| Masking / redacted copies | △ | ✗ | ✗ | Redaction work grows; the original is still unproven |
| Encrypt and store / send | ✓ | ✗ | ✗ | To verify, the receiver needs it disclosed after all |
| Lemma (ZK proof)the only one with all 3 | ✓ | ✓ | ✓ | The receiver just opens a link |
How it works — and how to start.
We help design disclosure scope and retention, run the PoC, and support production.
Start with a 30-minute call.
Tell us the one path with the heaviest ID-storage burden, in the first 30 minutes. No disclosure of sensitive data required.
Find the case that matches your industry and problem
Browse all 36 use cases →TRY LEMMA
Run it yourself.
No sales call needed — start hands-on with Lemma's products.