Bookitive
Protection

Attendee names

Require one name per ticket — printed on tickets and shown at check-in — plus the backfill action for tickets sold before you turned it on.

Not verified yet

Attendee names make every ticket personal: "Collect one full name per ticket; names are printed on the tickets and shown at check-in." A ticket tied to a named person is far less useful to a reseller and turns your guest list into a real ID manifest.

Turning it on

Under Event settings → Anti-scalping, enable Require attendee names. From then on, checkout asks the buyer for a full name for each ticket in the order — the name prints on the ticket PDF (via the attendee name field) and appears at the door when the ticket is scanned.

Backfilling earlier tickets

Turn it on mid-sale and the tickets already sold have no name yet. The Name them after the buyer action fills the gap: "Every valid ticket without a holder name gets its order's customer name." Tickets that already have a name are left alone, so running it is always safe. It's the pragmatic default — the buyer's name on each of their tickets — which you can refine individually where it matters.

For tickets still unnamed after a mid-sale switch, the door shows the buyer's name when the ticket is scanned — so check-in never hits a blank. Backfilling just makes that the stored value too.

Using names at the door

Named tickets pair naturally with ID checks:

  • The scan verdict shows the holder name; the door compares it to an ID for high-value events.
  • The guest list becomes searchable by the actual attendees, not just buyers — the fallback when a code won't scan.

Where it fits in protection

Names are the identity layer of anti-scalping — they don't stop a ticket from being sold on, but they make it checkable at the door, which is what deters profit resale. Combine with rotating QR delivery (hard to copy), per-customer limits (hard to hoard), and transfer policies (hard to hand off) for defense in depth.

On this page