A discount code on BrightStar is a real record attached to your event, not a note in a spreadsheet or a phrase circulating in a partner's newsletter. It carries a code, a discount, an optional cap on how many times it can be redeemed, an optional expiry date, and an optional restriction to particular ticket types. Every time someone actually completes a purchase with it, that redemption is counted against the code itself. That's what lets you look back after a kirtan night, a weekend retreat, or a festival gate and know whether a specific partnership or campaign actually sold tickets, instead of guessing from a single discount total buried in your revenue report.
What you can configure
Each code you create on BrightStar carries a small set of independent settings, and you only need to fill in the ones that matter for that particular code:
How codes behave when someone actually uses one
BrightStar normalises every code when it saves, converting it to uppercase and trimming any stray spaces. That matters at a real checkout: a buyer typing a code on their phone in lowercase, or pasting it with a trailing space copied from an email, still gets the discount instead of being told it's invalid over something cosmetic. Two codes with identical text cannot exist on the same event — BrightStar refuses the second one outright rather than quietly creating a duplicate that would behave unpredictably later. When a buyer applies a code, it's validated against the event and the discount is written onto their cart right away, but the code's redemption count only increments once the purchase actually completes. An abandoned checkout, or a code typed in and never paid, doesn't use up one of your allocated redemptions.
How do you see which codes actually worked
Each code carries its own redeemed count, so your reporting shows redemptions per code instead of one combined discount figure for the whole event. That distinction is the difference between knowing you gave away some amount in discounts and knowing exactly which partner, mailing list, or campaign earned them. If you're running several partnerships at once — a teacher promoting to their list, a studio cross-promoting, a sponsor handing out codes at a festival gate — give each one its own code rather than sharing a single code between them. Codes cost nothing to create, and the reporting can only separate what you separated in the first place. The internal label helps here too: it defaults to the code text, but setting it to something descriptive means a set of codes still means something in reporting months later, once the code text alone has stopped being memorable.
When restricting a code to certain ticket types matters
A ticket restriction becomes useful the moment you're running more than one price tier under one event — a kirtan night with a door price and an advance price, or a weekend retreat with a shared room rate and a private room upgrade. Hand a teacher or local studio a code meant to fill general seats, restrict it to that ticket type, and the same code can't accidentally be applied against the private room upgrade or a premium pass. That protects the margin on your higher-priced tiers while you still run an aggressive promotion on the entry-level ones. Leaving the restriction empty is what makes a code apply across the whole event, which is the right choice for a general, sitewide discount that isn't tied to any particular tier.