Selling Add-Ons at Checkout

Some things aren't the reason someone buys a ticket, but they matter the moment the ticket is bought. A parking spot for the festival gate, a camping pitch on the retreat grounds, a meal plan for a weekend of practice, a shuttle seat, a shirt. BrightStar lets you offer these as add-ons at the point where the decision is easiest to make — right after a buyer has chosen their ticket and before they pay — rather than hoping they notice a follow-up email days before the gathering. An add-on rides along with the purchase already underway instead of asking the buyer to go hunting for a separate item on your event page.

An add-on lives in your system as a ticket, but one flagged so it never appears in the ticket list buyers see on your event page. That distinction matters at a retreat check-in or a kirtan door: your main selector stays focused on the actual ways in to the gathering — general admission, a supporter tier, a scholarship spot — instead of growing cluttered with parking passes and shirt sizes. The add-on surfaces instead as its own card during checkout, once a buyer has already committed to a ticket and is moving through payment. That's a different moment than browsing the event page, and it's the moment when saying yes to a meal plan or a camping pitch is easiest, because the buyer is already in the frame of mind to add to an order rather than start one. Each add-on also carries its own quantity and its own maximum per order, tracked separately from ticket stock, and its price stands on its own — a meal plan can cost the same no matter which ticket tier someone bought, because the two are priced independently rather than tied together.

An add-on doesn't have to be decided in that first checkout pass. If a buyer books their retreat ticket in March and only realizes in June that they'll need parking for the weekend, they can come back to their existing order and add it then. That later purchase attaches to the same order the original ticket belongs to — it doesn't create a second, unrelated purchase floating apart from the first. For you, that matters at the door: your list still shows one buyer with one set of entitlements, ticket and parking pass together, rather than two records you have to manually match up. It also keeps your reporting coherent, because the add-on revenue is tied to the order it belongs to rather than sitting as an orphaned transaction you have to reconcile by hand later.

It can look like a contradiction: an add-on is marked non-public, the same flag that normally keeps a retired or held-back ticket off sale entirely, yet buyers can still purchase it at checkout. The two behave differently on purpose. Non-public keeps an item off the ticket selector on your event page — that part is the same whether it's a hidden ticket tier or an add-on. But where a hidden ticket tier is also blocked from purchase, an add-on is not; it's excluded from that block specifically so it can stay invisible on the page while remaining buyable once a buyer reaches checkout. That's what lets you offer parking or a meal plan without either one ever cluttering the list a buyer sees while they're just deciding which ticket to buy.