QR tickets without the gate panic.

Roles at a glance

• Owner: /dashboard/owner/tickets/create and /dashboard/owner/tickets — creates events, ticket classes, price and capacity.
• User: /dashboard/user/tickets/buy, /tickets/checkout/[eventId] — buys tickets, keeps them in /dashboard/user/tickets.
• Worker: /dashboard/worker/tickets/scan — scans buyer QR at entry; verified vs. rejected is recorded immediately.

Capacity you can quote correctly

Capacity is not a guess. Each ticket class has quantity, sold, available, checkedIn. The Owner capacity page aggregates tickets, workers, jobs, stock and platform totals so you spot over-selling before it happens.

Buyer ticket lifecycle

1. Buyer checks out — payment status, reference and QR are returned by the backend.
2. Ticket appears in My Tickets with eventId, ticketType (REGULAR / VIP / VVIP) and quantity.
3. At the gate, worker scans the QR. The backend marks fulfilled and prevents re-use of the same ticket code.
4. Audit logs record who scanned, when, and for which event.

Troubleshooting

Scan says “already checked in”

The QR has already been fulfilled. Check the ticket's collectedAt / fulfilled flag in the buyer's ticket detail before re-scanning. Don't override — investigate duplication.

Capacity shows negative available

More tickets were sold than the configured quantity allows. Reduce the ticket class quantity or close sales immediately and correct via the backend admin report before gating.

Buyer can't find ticket

Confirm they purchased while logged in and are viewing /dashboard/user/tickets on the same account. Tickets are bound to customerId, not device.

Internal links

• Barcode inventory guide — same ledger principles for stock.
• How it works — five-step lifecycle.
• About the platform — why audit-ready design matters.