Purchase limits

Every ticket can have two optional purchase limits:

• Max per order — how many of this ticket can sit in a single cart
• Max per customer — how many can be bought across all orders by the same checkout email

You set them per ticket, independently. A high-demand discount tier can be capped at 1 per customer while your general-admission ticket stays uncapped.

When to use them

• Discount or community links: you share a hidden 50%-off ticket with your subscriber list, and you want every subscriber to have a fair shot — cap at 1–2 per customer
• VIP / scarce tiers: limit one super-fan from claiming all the premium seats
• Anti-scalping: combine with hidden ticket links for tight control over high-demand drops
• Family / chaperone rules: cap kids tickets at 4 per order so adults must also book a chaperone seat

If neither cap is set (the default), the ticket sells without restriction.

How to set it

In the admin dashboard, edit any ticket and look for two fields just below the stock setting:

Field	Effect
Max per order	Cart-level cap. The shop quantity selector won’t let buyers add more than this.
Max per customer	Cross-order cap, keyed by checkout email. Counted across all of this customer’s purchases of this ticket.

Both accept positive integers. Leave blank for no limit. You can set one without the other.

The in-app AI assistant also knows about these fields — “Cap the early-bird at 2 per customer” sets it. “Remove the limit on early-bird” clears it.

What counts toward the limit

Usetix counts the same way for both caps:

• Paid orders: count
• Reserved orders (someone mid-checkout, before payment): count
• Cancelled, refunded, expired-reservation orders: don’t count — the buyer can purchase again

Limits are per-ticket-type, not per-event. A buyer hitting their cap on the “VIP Friday” ticket can still buy “Early Bird Friday” on the same event, since those are separate tickets with separate limits.

For group tickets, the cap counts purchases, not seats. A “2 for €50” group ticket with max_per_customer = 1 lets a buyer claim one bundle (2 attendees), not 1 seat.

What the buyer sees

When a cap is hit:

• Cart-level (max per order): the shop’s + button stops at the cap, and the server rejects any submission that exceeds it with an inline error: “You can only purchase up to N of TICKET per order.”
• Customer-level (max per customer): the buyer fills in their email, hits Pay, and sees an inline error in the checkout: “You’ve reached the limit of N TICKET per customer.” No payment is taken.

The error renders as a persistent banner above the payment buttons, not a flash toast — buyers have time to read it. Same UX for Stripe and PayPal.

Edge cases

• Lowering a cap retroactively: safe. Existing orders stay valid; the customer simply can’t buy more until cancellations free up slots.
• Conflicting caps (max_per_order higher than max_per_customer): the lower cap wins at runtime. We don’t validate this combination — you may have intentional reasons.
• Refunded orders freeing up the cap: yes, immediately. A refunded purchase doesn’t count, so the buyer can purchase again.
• Two simultaneous attempts by the same email: the per-customer cap is enforced inside a transaction, but a thin race window exists between count and commit. In practice the rare overshoot is by 1 ticket, accepted as a soft business rule.

See also

• Event capacity — total seat cap across all ticket types
• Webhooks — subscribe to order.paid to track usage from your own systems