Ticket Types & Configuration

Each type is its own database row rather than a field on the event, which is what makes the count open-ended. The values themselves do have bounds: quantity is capped at 999,999 per type, and price is stored in cents with a constraint allowing either exactly zero or at least 50 cents, up to a ceiling of $100,000. The 50 cent floor is why a token price below that is rejected outright — a ticket is either genuinely free or priced at half a dollar or more.

The fee side follows the price automatically. When the platform fee is calculated, any ticket line priced at zero is skipped entirely, so a free ticket carries neither the percentage nor the per-ticket flat amount, and an order whose payable total comes to zero skips payment processing rather than sending a zero-value charge. That holds regardless of the plan the event is on. For donation and sliding-scale setups the practical effect is that the fee tracks whatever each buyer actually chose to pay, ticket by ticket.

Underneath, visibility is a boolean on each ticket row, and the public events API filters its ticket list to rows marked public before the page renders at all. A non-public ticket is not fetched and then hidden in the browser; it is simply never returned. The same flag does other work in the system: add-ons and accommodation room tickets are stored as non-public rows so they stay out of the main ticket list and are surfaced by their own parts of the checkout instead.

There is a second ceiling above the per-ticket one. The event row itself carries a maximum tickets per transaction value, defaulting to 10, which applies across the whole order rather than to a single type, so a buyer cannot get around a per-type limit by spreading the order across several types. Use the per-type maximum for the constraint that belongs to one particular ticket, and the event-level maximum for the constraint you want on the order as a whole.

The hold is a real inventory row, not a countdown running in the browser. Adding to the cart calls a database function that reserves the quantity in the same operation, keyed by an idempotency string built from the cart, the event and the ticket type, so a double tap on Add does not create two reservations. If the reservation cannot be satisfied the item is not added at all, and the error carries the number actually remaining rather than letting someone reach payment on tickets that are already gone.

Because the window is set per ticket type rather than per event, you can stagger tiers on the same event — an early-bird type with its own sale_end closing while a general type's sale_start hasn't opened yet, or the reverse. Once sale_end passes, the ticket stops being purchasable even if quantity_available is still above zero, and before sale_start it isn't purchasable no matter how much inventory sits unsold.

Because each tier is stored independently rather than as part of the event description, you can act on one without disturbing the others: pause a single tier, change its cap, or pull sales reporting for it alone. Each tier also carries its own display order, so the list your buyers see is arranged the way you want rather than in the order you happened to create them.

The absence of a default is deliberate, so BrightStar never quietly restricts a sale you wanted to allow. The consequence is that a tier you meant to ration will not ration itself. If you are running a limited allocation, set the per-order maximum explicitly on that tier. It is separate from the total quantity available: the maximum per order governs one transaction, while the quantity available governs the tier's whole lifetime.

This is why BrightStar does not rely on the sold counts stored alongside the event for blocking a sale — those counts can drift after abandoned carts or test purchases, and treating them as authoritative would either oversell or wrongly refuse a real buyer. The reservation call is the single source of truth on availability, and a held ticket returns to the pool automatically when the buyer's hold lapses without a completed purchase.

The range is enforced at the cart rather than trusted from the buyer's browser, so an amount below your floor or above your ceiling is refused with a message that states the limit, instead of being silently adjusted after the fact. Donation only behaves differently from the others in one important way: leaving the amount blank is valid and the buyer still gets in at no cost, because the donation is genuinely optional rather than a minimum in disguise.

There is a second, wider control: pausing sales for the entire event, which blocks every purchase at the cart with a single message regardless of tier. Neither action is destructive — tickets already sold are untouched and no data is removed. BrightStar also stops accepting new cart additions once the event's end time has passed, so a finished event closes itself without you having to remember.

If you deliberately leave a tier's quantity uncapped, it never sells out and keeps selling until you pause it or the event ends. Selling out is not permanent either: raising the quantity available on the tier brings it straight back into circulation, because availability is calculated from the cap against real sales at the moment of the request rather than from a stored sold-out flag.