Print it, scan it, and know it has not already walked in

Staff at the gate can scan a ticket QR with their phone camera in the browser, or paste the code manually, and the server redeems the ticket and reports valid, already-scanned, cancelled, wrong-event or not-recognized.

Requires a live network connection — every scan is a server call, there is no offline mode. Camera scanning uses the browser's native BarcodeDetector (Chromium and iOS 17+ Safari per the source comment); other browsers fall back to manual entry. Restricted to SUPER_ADMIN / PLATFORM_SUPPORT / LEAGUE_ADMIN plus GATE_AGENT on the scanner route, and a gate agent can only scan a match they hold an active gate assignment for.

A ticket that has already been scanned is reported as already scanned with its entry time, a cancelled ticket is reported as cancelled, and a genuine ticket presented at the wrong fixture is rejected as being for a different match.

The redeem step uses a guarded update; the source notes a racing double-scan is resolved by the atomic guard so only one entry is admitted, but this is described as acceptable for gate use rather than a formal uniqueness guarantee.

An admin can mint a batch of physical admission tickets for one ticket type and print a sheet of QR cards, each carrying an HMAC-signed token that the gate scanner verifies cryptographically before any database lookup.

Batch size is capped per request in the schema. Reserved-seating ticket types cannot be printed in bulk. Printing is the browser's print dialog on a generated sheet — there is no ticket-stock or thermal-printer integration. Rotating the HMAC signing secret invalidates every already-printed ticket unless the old value is left in the secret's `previous` slot, which the scanner still accepts.

Every issued ticket carries a unique unguessable token that is rendered as a QR code the holder shows on their phone, reachable from the order page without signing in.

The order page is reached by possession of the order id / ticket token; there is no email or SMS delivery of tickets in the codebase.

For a free ticket type, an anonymous fan can claim tickets from the public event page and the tickets are issued immediately as scannable QR codes on their device.

Only the free path completes end to end without payment configuration; a priced ticket cannot be paid for online in the current production deployment.

Staff can record an at-the-door sale in the box-office panel, which creates an already-paid order on a BOX_OFFICE channel, issues the tickets and posts the sale to the ledger.

Admin/ticketing-operator authorization plus the Ticketing entitlement are required. The money itself is collected outside the product; the app records the sale.

Orders set aside for collection appear in a will-call list for the match, and marking one picked up stamps the pickup time and redeems that order's tickets.

Admin-only, behind the Ticketing entitlement.

Admins can open a per-match admission view showing tickets sold, how many have scanned in, how many are still outstanding, a per-ticket-type split and the most recent scans.

Read-only, admin-only, entitlement-gated; the figures refresh when the page is loaded or refetched rather than being pushed to the browser.

Admins can define named gates and stations for a fixture and assign gate agents to them; an agent can scan only for a match they are actively assigned to, and each scan is logged against the lane they were placed at.

Admin authorization to configure; the agent scanner requires the GATE_AGENT role or an admin role.

Organizers can create ticket types for a fixture with a name, description, price, currency and optional capacity, and move each one between draft, on-sale and closed.

Requires the Ticketing module to be enabled for the organization (self-serve, free, but restricted to LEAGUE_ADMIN / SUPER_ADMIN / PLATFORM_SUPPORT). Ticket-type admin endpoints 403 when the module is off.

Organizers can create, edit and delete discount codes for an event, buyers can preview a code before checkout, and a redemption limit is claimed atomically so a capped code cannot be over-redeemed by concurrent buyers.

Codes are scoped to a single event. The discount applies to the ticket subtotal only, never to an added donation.

A ticket type can be put in presale so it is only purchasable by a buyer who supplies the matching access code, and the code is re-validated on the server for every order.

A single shared code per ticket type, not per-buyer codes.

Organizers can define seating sections for a fixture, buyers see seat availability on the public page, and a reserved-seating purchase claims specific seats inside the same transaction that creates the order so two buyers cannot take the same seat.

Seat holds on an unpaid order are temporary and are released on cancellation or expiry. Seat-level inventory applies only to reserved-seating ticket types; general-admission capacity is not held while an unpaid order is outstanding.

An organization that only wants to sell tickets can create a ticketed event from an opponent and a date and manage it from a dedicated tickets dashboard, without setting up scoring or league structure first.

Restricted to LEAGUE_ADMIN / SUPER_ADMIN / PLATFORM_SUPPORT and requires the Ticketing module to be enabled.

Organizations get a ticketing insights view with totals for tickets sold, gross sales, net after the platform fee, tickets redeemed, sold-out event count, sell-through percentage, a per-event breakdown and a daily sales series for the last thirty days.

Scoped to the signed-in user's own organization from their token, entitlement-gated, and the sales series window is fixed at thirty days in code.

The product contains a complete Stripe Checkout integration for paid ticket orders, including an idempotency key per order and webhook-confirmed fulfilment, which activates once live Stripe keys are supplied.

DORMANT in the live deployment. The Stripe secret still holds placeholder values, so getStripe() returns null and createTicketCheckout returns mode OFFLINE. The live production endpoint GET /public/payment-config currently returns {"card":false,"paypal":false}, and a paid order is instead created PENDING_PAYMENT with a message telling the buyer the organizer will follow up to collect payment before the tickets are issued.