Think about the moment right before someone buys a ticket to a kirtan, a weekend retreat, or a sound healing circle. They've just found the event, they're deciding whether to bring a friend, and they are not thinking about setting up a login. If BrightStar required an account before checkout, that hesitation would be the last thing many buyers do — the most casual, spontaneous buyers would drop off first, and those are often exactly the people a conscious-gathering event is trying to reach. So on BrightStar, a buyer can add tickets, apply a discount code, and pay by card without ever registering. The cart itself is built to allow a purchase with no user account attached to it — it only needs an email address, and that email is where the ticket is delivered.
What's actually sitting in a cart before someone pays
A cart is not just one ticket waiting for one payment. It's a small holding area that can carry several things at once:
Why ticket holds expire instead of lasting forever
A hold that never expired would be indistinguishable from a sale that never happened: the stock sits locked while your event shows as sold out to everyone still browsing. That's the problem BrightStar's expiry solves. Picture a busy festival gate, or a retreat that's down to its last few beds — someone adds a ticket, gets pulled away, and never comes back to pay. Without an expiry, those seats would stay reserved and unsellable indefinitely. With it, the hold lapses on its own and the tickets return to the pool, available to the next buyer, with no one needing to notice or intervene. It's also why overselling isn't just unlikely on BrightStar but structurally hard to do — availability is decided by the reservation itself, not by a running count that could be out of date by the time someone checks out.
What happens when someone pays
Checkout requires an email address and won't proceed without one, because that address is how the ticket actually reaches the buyer — there's no account to fall back on. Payment itself runs through Stripe by card. The important part happens after the card is charged: the order isn't created by the buyer's browser, it's created on BrightStar's server only once the payment confirmation arrives back from Stripe. That sequencing matters at the exact moment things tend to go wrong — a buyer closing their laptop mid-redirect, or losing signal right after paying, doesn't cost them the ticket they already paid for. The reverse problem is handled too: repeated attempts at the same purchase are made idempotent from the event, the buyer's email, and the tickets chosen, so an impatient double-click on the pay button doesn't turn into a double charge.
What fees show up in the total
What a buyer pays is built from a few distinct pieces: