A code and a QR, not a count
Each ticket carries a short printable code and its own QR, generated straight from that code, ready to validate on its own regardless of how many others were in the same order.
Orders & Tickets
Every seat gets its own code. Not a headcount.
Buy three seats, get three individually redeemable tickets, each one frozen at the price and policy that applied the moment they were bought. A catalog change next week never reaches back to rewrite a sale that already happened.
- 1 ticket per unit Buy three seats, get three individually redeemable codes, not a quantity of one
- Frozen at purchase Product name, ticket type, price and cancellation policy never change after the sale, even if the catalog does
- Sequential per organization Receipt numbers increment under a row lock, so two orders paid at once never collide
Four pieces of order fulfillment.
Each one covers a different part of turning a paid order into something a customer can actually use.
Everything commercial gets frozen
Product, option, ticket type, price and cancellation policy get copied onto the order the moment it's paid. A price change next week never rewrites what someone already paid for.
External vouchers, tracked separately
A ticket needing a third-party voucher carries its own fulfillment status, independent of whether it's valid for entry, so gate staff always knows whether a code still needs attaching.
A full history, not just a current state
Every status change, issued, void, redeemed, writes an event recording who changed it and from what source: an agent, the system, or a payment webhook.
How it resolves
How a paid order becomes real tickets
Five steps, from the moment payment confirms to the moment a customer holds a code.
- 1
The order gets its receipt number
Right after payment confirms, the organization's counter row locks briefly, increments, and that number gets assigned. Two orders paid at the exact same second still get two distinct, sequential numbers.
- 2
A ticket gets born per unit
Buying three units of the same ticket type creates three separate ticket rows, each with its own position within the order, never one row carrying a quantity field.
- 3
A code gets generated, checked for collisions
A ten-character code, drawn from an alphabet that excludes visually ambiguous characters like 0 and O, gets generated and checked unique within the organization before being assigned.
- 4
The QR gets built from the code alone
The QR encodes exactly the ticket code and nothing else, embedded directly into the confirmation email rather than sent as a separate attachment.
- 5
The email waits for the database to mean it
Confirmation only queues once the paid transaction genuinely commits, so a customer never receives a ticket for an order that, moments later, actually failed.
The API, as it is
A ticket carries its whole story
Position within the order, product, ticket type, date, buyer name and fulfillment status, resolved from the code alone. Price and cost never appear here, on purpose.
GET /api/v1/tickets/lookup
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
{
"ticket_code": "7K3P9QXFH2",
"status": "issued",
"position": 2,
"quantity": 3,
"product_name": "City Food Tour",
"pricing_category_name": "Adult",
"date": "2026-08-14",
"fulfillment_status": "not_required"
}200 Ticket resolved
The detail almost nobody explains
A pending voucher never blocks the door
A ticket still waiting on an external voucher can still be redeemed. Gate staff sees a clear "verify manually" warning instead of a hard block, because an operator can't always control when a third-party code arrives, and refusing entry over a paperwork gap would be the wrong failure mode.
Frequently asked questions
Four. Every unit sold becomes its own ticket, with its own code, its own QR and its own position within the order, so any single one can be validated independently of the rest.
Nothing. The price, the product name, the ticket type and the cancellation policy all get frozen onto the order the moment it gets paid. A later catalog change is invisible to a sale that already closed.
The organization's own counter row gets locked for the brief moment it's read and incremented, so two orders confirming at the exact same instant still receive two distinct, sequential numbers, never a collision.
It carries its own fulfillment status, separate from whether it's valid for entry. Gate staff sees a clear warning to verify it manually until an agent attaches the real code or PDF, but the ticket is never blocked from redemption while that's pending.
No. It only queues after the database transaction that marks the order paid actually commits, closing the gap where an email could go out for a purchase that, a moment later, turns out to have failed.
More bookings. More channels. The same calm.
Tiqory keeps availability, pricing, payments and access working together as your operation grows. Tell us where you are headed; we’ll show you how to get there without starting over.