Ticketing

Ticketing combines a separate ticket catalogue with a hosted shop, checkout, order access, refunds, and admission scanning. Ticket products are not managed in the ordinary Products catalogue.

Test and live mode

The mode switch in the Ticketing header changes between two operational worlds. The selected mode is stored as ?mode=test or ?mode=live, remains active across Ticketing pages, and is preserved in links to records such as orders. Test is used when the parameter is absent.

Products and shop settings are shared, but inventory pools, promotions, partner budgets, concessions, orders, refund policies, reports, credentials, and Stripe payments belong to the selected mode. Test mode displays a banner and uses separate inventory, orders, and Stripe test payments; none of them reach real buyers. An event guest list follows the storefront's current mode.

The Tickets tab on an event does not have a separate switch. It shows availability for the mode currently served by the storefront and labels that mode beside the figures.

Ticket usage and allowances

• A paid admission issued in live mode counts toward the Workspace's Tickets sold allowance. A group ticket counts each issued credential; a pass or entitlement counts once per sold unit, not once per later redemption.
• Free orders, guest-list and RSVP admissions, imports, vouchers, reissues, and exchange replacements do not count. A refund or cancellation after a paid ticket was issued does not reverse its usage.
• Paid tickets issued in test mode appear separately for visibility but are never billed. Review the included amount, enforcement, estimated overage, and monthly additional charges under Workspace Settings -> Usage.

Shop settings

Open Ticketing → Settings to configure the hosted shop.

• Enable the storefront and choose its unique URL slug.
• Set the ISO currency, currency exponent, and how long checkout holds inventory. The hold can be between 30 minutes and 24 hours.
• Store the current terms and privacy version identifiers. Buyers must accept the versions shown during checkout.
• Publish a versioned refund policy. Orders keep the policy version that applied at purchase, so later edits do not change their eligibility.
• Configure webhook subscriptions for order.paid, ticket.issued, ticket.checked_in, refund.completed, event.cancelled, event.postponed, and ticket.exchanged.

To use a custom domain, save a subdomain and copy the CNAME and, when shown, ownership TXT records into its DNS. The settings page shows whether the connection is pending, verified, or failed, along with the last provider result, and offers a manual recheck. Pending domains are checked every 15 minutes and verified domains every six hours; a temporary provider error does not take a verified domain offline. Only a verified domain routes to the shop. A hostname cannot also belong to another ticket shop or an Einblick Site.

Products and inventory

The general Products page creates passes or punch cards, vouchers, fees, and donations. Admission tickets are created from the Tickets tab of the event they admit.

Pricing can be fixed, free, or buyer-chosen. A fixed price can have up to eight dated online price steps: the base price applies before the first step, then the most recently started step wins. A separate door price can be set; when left empty, the current online price applies at the door. For buyer-chosen prices, the storefront enforces the configured minimum, maximum, and step. Product settings also define maximum quantity per order and, where applicable, inventory pools, credentials, capacity, credits, and validity. These terms are copied into the purchased order item rather than changing with later catalogue edits.

Create and activate inventory pools before selling capacity-limited products. A child pool can also consume a parent pool, so a purchase must fit both the product allocation and its shared parent capacity.

Existing products can be edited and activated or archived. A product can be permanently deleted only while nothing durable refers to it. Once it has been used by an order, cart, credential, voucher, hold, registration, promotion, or another business record, archive it instead so its history remains intact.

Selling tickets for an event

An event type with tickets or mixed admission gives its events a Tickets tab. Create an admission product there for:

• the whole event
• one specific slot
• a repeating slot role

Set its price, capacity, seats consumed per ticket, maximum quantity per order, and optional parent pool. Capacity can be unlimited. A group ticket consumes the configured number of seats and issues one credential for each seat.

The tab reports capacity, sold, held, and available units. It combines tickets owned by the event or its slots with tickets inherited from the festival, event type, or slot role. Inherited products are read-only there and link to the source where they must be edited.

For a capacity pool, Reserved seats can protect units for the guest list, partners, or a named concession. Those units are hidden from normal storefront availability, consumed by their channel first, and can return to general sale at an optional release time. A buyer using that concession can still draw from its reserved seats when ordinary storefront availability is sold out. If a complimentary issue exceeds its channel allotment, staff see a warning before it consumes general inventory.

Guest lists

Ticketed events have a Guest List tab, and a festival's Guest List combines its events in one operational view. Add one guest or a bulk list with a name, optional email, and additional guests.

• A name-only entry uses no ticket inventory. Door staff find it by name or email and admit the recorded party manually.
• A complimentary ticket selects an admission product, reserves the required units, emails the guest when an address is present, and issues scannable passes. Guest-list allotment is used before general inventory.
• Before admission, staff can edit an entry, resend its ticket, upgrade a name-only guest to ticketed admission, or remove it. Completed admissions protect the affected entry and inventory from incompatible changes.

Partner budgets

Ticketing → Partner budgets controls complimentary inventory for sponsors, agencies, and other partners. A budget can be measured in ticket units or money and scoped to the whole Workspace, one festival, or selected events. Optional rules restrict products, validity, event and request totals, booking cutoff, and whether unnamed guests are allowed.

Staff can issue tickets on the partner's behalf or send a reusable private portal link. The link can be rotated or revoked; in the portal, the partner reserves and cancels tickets for eligible future published events and sees the remaining budget. Every issue, cancellation, and adjustment remains in the budget ledger.

Concessions and cards

Open Concessions & cards. Start with a built-in partner-card or pass preset, or create a blank rule. The page also contains promotion codes plus concessions applied per ticket. A concession can reduce a percent or amount, use a presale price, or make admission free. Rules can limit products, events, a festival or day, weekdays, validity, quantities, buyers, and total, per-event, or per-card-number usage; proof and card-reference fields can be required.

Choose whether a concession is available online, at the door, or both. Online pricing can discount immediately or charge full price and record the refund due after proof is checked at the door. Scanner staff can verify proof, record an override and refund, and update door-only tallies. The localized door sheet can be printed or downloaded as a PDF for offline operations, and unused fully free concession seats can optionally return to sale after the event starts.

Promotion codes can reduce a percentage or fixed amount and can be limited by validity dates, minimum quantity, eligible products, total uses, and uses per buyer. The rule remains editable. A promotion can be paused and resumed, but archiving it is final. Its individual codes show their suffix and use count and can be archived or reactivated separately.

Storefront and checkout

The hosted shop is available at /tickets/:storefrontSlug. It uses the Workspace name, full logo matched to the current light or dark background, brand color, and branding preference, and keeps the cart available throughout the shop.

The shop leads with published public events that currently have sellable tickets. A shop with one event opens it immediately; a shop with several events shows event cards leading to /tickets/:storefrontSlug/event/:eventId. Event pages include the public image, description, time, venue, schedule, and all applicable event-, slot-, role-, type-, and festival-scoped tickets. Published unlisted events stay out of discovery but can open through a known event link. Products not attached to a listed event remain available under the general offers.

• Visitors can switch the storefront language with ?locale=en, ?locale=de, or ?locale=cs.
• Fixed-price cards show the effective online price and the next scheduled change when applicable. A concession is added to an individual ticket line, including any required proof reference and a door-refund notice.
• The cart is saved in the visitor's browser. Checkout collects buyer details, promotion or voucher codes, and acceptance of the current legal versions.
• A buyer-chosen product requires an allowed amount before it can be added to the cart.
• A voucher is validated before checkout. The cart shows its available balance, applies up to the order total by default, and lets the buyer choose a smaller positive amount. It then shows the remaining balance and any amount still due.
• A free order completes without a payment redirect. Paid checkout redirects to Stripe.
• Capacity is held during checkout. An expired hold cannot be completed as a late payment that oversells inventory.

Orders and buyer access

Staff can search recent orders, open a shareable order detail, and start an eligible refund there. The selected test or live mode is preserved in the order link.

After checkout, the buyer opens the order through a private claim token. Treat this token like a password: it grants access to payment and fulfillment status, QR credentials, remaining admissions, and voucher balances.

From the order page, the buyer can:

• rotate the claim token, which invalidates the previous access link
• replace a lost credential, which invalidates the old QR code
• request an eligible refund under the policy version stored with the order

The current self-service refund flow is for the whole eligible order. Eligibility can require unused inventory, a cutoff time, and no completed admission. Restored unused units return to inventory when the policy allows it.

Reports and operational status

Users with Ticket Fulfillment read access can review a 7-, 30-, or 90-day period in the selected mode. The overview includes orders, paid orders, tickets, gross sales, recent order lines, payments, and credentials. It also flags dead-letter webhooks, stale holds, paid but unfulfilled orders, failed deliveries, and failed refunds.

Event check-in

Event types with registration or ticket sales show a Check-in tab. Use it to create event gates, rename their display names, remove gates, and approve or revoke scanner devices. Renaming keeps the gate code. Removing a gate preserves historical scans and sessions while making its former code available again. Gate and device management follows the Admission permissions; scanners do not need event-edit access to admit visitors.

An enrolled mobile scanner operates for one event and gate within a time-limited session. A scan can be accepted, repeated, outside its target or validity window, refunded or revoked, out of uses, or require verification. Revoking a device invalidates its active scanner access immediately.

Door staff can also find guest-list entries by name or email and admit name-only parties. Concession tickets display the proof and refund action; the result records verification, an authorized override, any refund due, and door usage.

Offline scanning uses a signed, device-authorized manifest with a validity window. Scans synchronize later, and authoritative conflicts remain available for supervisor review.

Ticketing API

Custom storefronts use the commerce API under /api/v2/commerce/: storefront, catalogue, cart/{id}, commands/{name}, and orders/{id}, with @einblick/sdk/commerce as the typed client. These routes accept External Site or native app credentials, require a storefront from the same Workspace, and enforce the External Site's configured browser origins.

See Workspace Integrations for API-key and browser-origin setup, and Events for the event-side staffing, ticket, invitation, and reservation workflows.