Entrance and check-in guide
The door needs a workflow, not just a QR code.
A QR code is only the visible part of event entry. The useful system is the decision behind it: who may scan, what happens after the first valid check-in, how repeated codes are shown and how guest lists, tables and rewards stay separate at the door.
The short answer
How should QR check-in work at an event?
Give entrance staff event-scoped access, scan each ticket or entitlement once, show repeated scans clearly and keep live counts visible for the event manager. Manual lookup should exist, but it must be rate-limited and tied to the same event.
The first valid scan should win
A ticket should not admit two people because two devices scanned it almost together. The check-in action has to decide once, record the time and show any later scanner that the code was already used.
Separate tickets, tables and guest lists
A table code, a named guest entry and a paid ticket are different promises. Staff should choose the right mode and see a clear result instead of trying to decode everything from one spreadsheet.
Keep the scanner useful in bright and dark settings
Nightclubs, beach entries and daytime venues need different visibility. A scanner interface should work one-handed, offer strong contrast and keep recent results easy to read without exposing unnecessary buyer details.
Prepare a controlled fallback
Real offline entry is risky when tickets can change. A safer release-one fallback is a short-lived emergency list with audit trail and later reconciliation, plus manual codes for cases where the camera fails.
Entrance and check-in guide
QR entry is reliable only when the scan decision is clear
The visible QR code is less important than the system response. Staff need to know whether a code is valid, already used, blocked, refunded or attached to another kind of entitlement before the guest reaches the bottleneck.
This guide treats scanning as an operational page rather than a technical feature list. It links mobile usability, manual fallback, live counts and permission boundaries to the visitor's real entrance experience.
In this guide
Four controls before sales open
A launch is ready when responsibility, inventory, communication and entry all have an owner.
| Control | What to confirm | Risk avoided |
|---|---|---|
| Seller | Legal seller, Stripe account and refund contact | Unclear payment and support responsibility. |
| Inventory | Capacity, ticket types, holds and price phases | Overselling or contradictory offers. |
| People and place | Venue, line-up invitations and team roles | Wrong ownership or excessive permissions. |
| Door and changes | Scanner rehearsal, support and cancellation plan | Queues and improvised decisions under pressure. |
In this guide
Three realistic organizer situations
These examples show why the event workflow must remain clear even when one person has several roles.
A DJ organizes their own headline night
The DJ uses one login but sets up both an artist profile and an organizer area. They add themselves to the line-up, remain the legal seller and can invite other artists without gaining access to those artists’ profiles.
A club hosts an external promoter
The location team keeps control of permanent place information. The promoter creates the event, accepts sales responsibility and uses the existing venue. Guests see both entities and know who handles the paid booking.
A sold event needs a major change
The organizer records the new date or place, informs guests and opens the applicable refund path. Tickets and reports follow the documented event state instead of being altered through informal messages or an untracked spreadsheet.
E-E-A-T
How this operational guide was prepared
The guidance follows the product's implemented path from organizer verification and event setup to ticket inventory, connected payments, ticket issue, entrance and refunds. It distinguishes what the platform controls from what remains the organizer's legal and operational responsibility.
Payment statements are checked against Stripe's public Connect documentation. Product workflows are checked against the platform's implemented behavior. This is operational product guidance, not legal or tax advice; country activation still requires professional legal and tax approval.
The guide images are generated editorial illustrations. They help explain the setting but never replace real venue or event information.
Reviewed on 15 August 2026
Primary product and payment sources
The payment model is described with links to Stripe's current first-party documentation.
Send us the page and the detail that should be checked. We review corrections instead of silently changing factual claims.
Send a correction