bindro.

winery guide

Age verification for winery tastings: what the booking refuses and what your staff must still do

Reviewed: 2026-08-09

bindro refuses an under-21 booking on the money path: the booker's date of birth is evaluated inside the confirm transaction, and an unparseable date is refused too. Everything else is a declaration. Your door still checks physical ID for every guest, and the console will not admit anybody until an operator confirms it was checked — which is what makes the record worth having.

What does bindro refuse before payment?

One thing, properly: a booker under 21. The date of birth is a required field on the booking, and the rule attached to it is evaluated on the money path inside the confirm transaction rather than in the browser. An under-age booker sees an error anchored to the field, no order is created and no payment is taken. A date the system cannot parse is refused as well, because a rule that garbage bypasses is not a rule.

That is a real gate and it is worth knowing exactly how far it reaches: it is about the person making the booking, not about every guest in the party. The 21-and-over confirmation covering the rest is a declaration the booker makes, which is blocking — the order cannot complete without it — and which is evidence of nothing more than that they ticked it.

What does the door still have to do?

Check physical ID for every person tasting, exactly as you would if the booking had been taken on the telephone. The compliance requirement in this vertical says so in as many words: the sale is not the age check. What bindro adds is that it will not let the check be skipped quietly — on the console check-in page every taster carries an "ID checked" confirmation, and the admission is refused without it.

One nuance that matters if you build your own scanning: a scan sent through the door API records whether ID was checked and does not refuse when the flag is missing. The guarantee lives in the console door. If your staff admit people from the console, admitted and ID-seen are the same act; if you script against the API, that is your discipline to keep.

  • Check ID for every guest, not only the booker.
  • Admit from the console check-in page so the confirmation cannot be skipped.
  • The confirmation is recorded against the scan, with the time and the device.
  • The API records the flag but does not enforce it — do not build the guarantee there.

What happens if a guest turns up without ID?

They can be refused, and the software will not refund them automatically. That is the correct behaviour — an unused seat that was refused entry is a commercial decision, not a mechanical one — but it means your refusal policy has to be written down and visible before the booking is made rather than argued about at the door.

Say it on the booking page and say it again in the confirmation. The registration form already tells the booker that photo ID is checked on arrival and that guests under age will be refused entry without a refund; make sure the words your staff use at the door match the words on the page they agreed to. Refunding anyway is one action if you decide to, and the seat does not return to sale afterwards.

Where is the age evidence recorded?

In two places, and they answer different questions. The declarations — the 21-and-over confirmation and the alcohol compliance box — are recorded against the order at the moment of purchase, and the compliance record is kept for two years. The ID confirmation is recorded against the admission: this attendee, this session, this device, this time, ID seen.

The booker's date of birth is personal data and is treated as such — encrypted, redacted from logs, and anonymised by the retention sweep after the visitor's last session, on the attendee record. Answers stored at order scope are not cleared by that sweep, so if a licensing inspection or an internal policy needs a defined retention period for those, that is a decision to make deliberately rather than one the product makes for you.

What should I take away?

  • The booker's age is a real gate: refused inside the confirm transaction, with no order and no charge.
  • Everything about the rest of the party is a declaration — the door is the check.
  • The console refuses to admit anybody until the operator confirms ID was checked.
  • The door API records the ID flag but does not enforce it; keep the guarantee in the console.
  • A guest refused for want of ID is not refunded automatically — publish your policy before they book.

Reviewed: 2026-08-09

Run your tastings on bindro

Nothing to pay until you sell. 2.5% + $0.99 per paid seat; free tastings cost nothing.

Start selling — free