Event Configuration

Discount Code Engine

Discount types, validation rules, usage limits, and promotional code strategies.

4 min readUpdated 2025-01-12

When you're setting up ticket sales for a retreat, a kirtan evening, or a festival weekend, a discount code is one of the few parts of your event that travels directly into someone's hands — printed on a flyer, mentioned by a teacher, dropped into a newsletter. BrightStar's discount code engine has to decide, in the moment someone types that code in, whether it's valid, how much it's worth, and whether that person has already used up their allowance. Because checkout is the one place where a setup mistake becomes visible right away — a code that won't work at the door, or one that gives away more than intended — the engine relies on fixed, checkable rules rather than a judgment call made under pressure.

What kinds of discounts can you create?

BrightStar supports four discount types, and each one changes the price differently. A percentage discount takes a value from 1 to 100 and multiplies the ticket price by what's left over — 20 percent off a $100 ticket brings it to $80. A fixed amount discount subtracts a set number of cents from the price instead, so $10 off a $100 ticket lands at $90; this is the type to reach for when you want the saving to feel the same no matter which tier someone buys. A free ticket is technically a 100 percent discount: the ticket drops to $0 and checkout bypasses payment entirely, which matters for scholarship seats or teacher comps where you don't want a card form standing between someone and their spot. Buy X Get Y works differently again — it's configured with a buy_quantity and a free_quantity, so a "buy 2, get 1 free" code applies to how many tickets someone adds to their cart rather than to the price of any single ticket.

How BrightStar checks a code before it works

Every code passes through the same ordered checks before it's allowed onto an order: it has to exist and be active, the current time has to fall between its valid_from and valid_until dates, its total usage has to be under its usage_limit, the customer's own use of it has to be under their per_customer_limit, the order has to meet any minimum_order amount, meet any minimum_quantity of tickets, and finally the cart has to contain ticket types the code actually applies to. That order matters because it decides which error message someone sees. A misspelled code returns INVALID_CODE; one run past its date returns EXPIRED; one used up returns LIMIT_REACHED; one a customer has already redeemed returns ALREADY_USED; and one attached to too small an order returns MINIMUM_NOT_MET. Reading the specific error back tells you which setting to loosen, rather than leaving you guessing whether the code is simply broken.

Setting limits, minimums, and time windows

Beyond the discount value itself, a code carries several settings that decide who can use it and when. usage_limit caps the total number of redemptions across everyone who has the code, which protects you if a code meant for a small list ends up shared more widely than intended. per_customer_limit caps how many times one email address can redeem it, which stops a single buyer from applying an early-bird code across every order they place. valid_from and valid_until give the code a start and end date, so a code can be published ahead of time and switch on and off automatically without anyone having to remember to disable it. minimum_order and minimum_quantity set a floor on the size of the order the code can attach to, which is useful when a discount is meant to encourage a group booking or a higher-tier purchase rather than a single low-cost ticket.

Restricting a code to specific tickets

Not every discount is meant for the whole event. Setting applies_to to specific_tickets and listing the relevant ticket_ids restricts a code to only those tiers — for instance, a code meant to fill seats in a single workshop rather than discount general admission across the board. When a code like this is checked at checkout, BrightStar also confirms the cart actually contains one of the applicable ticket types before letting the code through, since a code with nothing eligible to apply to would otherwise sit on an order doing nothing.

If you're working with teachers, guides, or affiliates who each bring their own audience, generate a batch of unique codes through the API rather than handing out one shared code. Giving TEACHER_SARAH and TEACHER_JOHN their own codes means every sale is attributable to the person who brought it in, and you can see how each one performed under Analytics → Discount Report.

What makes a good discount code?

A code is only as useful as it is easy to type correctly and hard to misuse. A few habits keep both true:

  1. 1Make the code descriptive rather than generic — YOGA25 tells someone what it's for; PROMO1 doesn't.
  2. 2Keep codes short, around 8 characters, since most people are typing them on a phone at a checkout screen.
  3. 3Set an expiration date so the code creates urgency instead of circulating indefinitely.
  4. 4Set a per-customer limit so one buyer can't reuse the same code across repeated orders.

Common questions

What types of discount codes can I create on BrightStar?

BrightStar's discount engine supports percentage off (a value from 1 to 100, so 20 percent off a $100 ticket gives $80), fixed amount off (a set amount in cents, so $10 off $100 gives $90), free tickets (a 100 percent discount that produces a $0 ticket and bypasses payment), and buy X get Y, configured with a buy_quantity and a free_quantity.

Read more

Two details sit underneath the arithmetic. The stored type is normalised to lowercase at both validation and apply time, because codes created in an older admin tool were saved with capitalised names and every downstream reader would otherwise have to branch on spelling. And the database enforces the obvious bounds itself rather than trusting the form: a percentage code cannot exceed 100, any code's value must be greater than zero, and the redemption counter cannot go negative. A code that breaks those is rejected at the write, not at checkout.

Can I limit how many times a discount code is used?

Yes. Each BrightStar discount code has a usage_limit for total uses across everyone and a per_customer_limit that caps uses per email address. You can also set valid_from and valid_until dates, a minimum_order value, and a minimum_quantity of tickets before the code applies.

Read more

The limit is checked twice, and the second check is the one that matters. Typing the code runs a read-only validation, but attaching it to a cart calls a database function that locks the coupon row before comparing redemptions against the limit, so two buyers racing for the last redemption cannot both pass. If the limit was reached in between, the second attempt is refused with a distinct limit-reached error rather than quietly applying a discount that cannot be honoured. Leaving the limit unset means unlimited.

Why is my discount code being rejected at checkout?

BrightStar validates a code in a fixed order and returns a specific error for whichever check fails. INVALID_CODE means the code does not exist, EXPIRED means the current time is past valid_until, LIMIT_REACHED means the total usage limit has been hit, ALREADY_USED means that customer has hit their per-customer limit, and MINIMUM_NOT_MET means the order is below the minimum order amount. The code must also be active and the cart must contain ticket types the code applies to.

Read more

One rejection is worth singling out because it is easily misread as the code not existing. If a code is restricted to particular ticket types and none of them are in the cart, BrightStar refuses it up front with a message saying it does not apply to anything in the cart. Without that check the totals calculation would simply produce a discount of zero and the code would appear to apply while saving nothing. Codes are also matched without regard to case and stored uppercased, so typing in lower case is fine.

Can I apply a discount code to only certain ticket types?

Yes. BrightStar discount codes have an applies_to setting of either all or specific_tickets. Choosing specific_tickets lets you list the ticket_ids the code is valid for, so a code can be restricted to, for example, a single workshop tier rather than the whole event.

Read more

The restriction is stored as a list of ticket tier identifiers on the code itself. When the code is applied, checkout resolves those identifiers back into the ticket names and returns them alongside the cart, so the buyer is told which tier the code is for instead of working out for themselves why the total only moved on part of the order. If an identifier no longer resolves to a live ticket type the raw value is shown instead, which is a useful signal that the code points at a tier that has since been removed.

How do I give each affiliate or teacher their own trackable code?

Generate unique codes in bulk through the BrightStar API and give one to each partner, such as TEACHER_SARAH and TEACHER_JOHN, so every sale is attributable. You can review how each code is performing under Analytics, Discount Report.

Read more

The reporting side reads straight off each code's own counters, so the numbers do not depend on anything being tagged at checkout. The discounts report lists times used against the usage limit, the gross revenue on orders that carried the code, and an average order value derived from those two, per code. Because the average is revenue divided by redemptions, a partner whose code produced few but large orders reads very differently from one with many small ones, which is usually the more useful comparison.

What makes a good discount code?

BrightStar recommends descriptive codes over generic ones, so YOGA25 rather than PROMO1, and keeping them to about 8 characters so they are easy to type on a phone. Adding an expiration date creates urgency, and setting a per-customer limit prevents a single buyer from reusing the code repeatedly.

Read more

On timing, each code carries both a start and an expiry, and both are compared against the current moment during validation, with separate messages for a code that has not started yet and one that has passed its expiry. That means a code can be created well in advance and left dormant. It is how an early-bird window is usually set up: publish the code with the rest of the campaign, let the start date open it and the expiry close it, without anyone having to remember to switch it off.

Ready to get started?

Create your first event on EveryEvent Rio de Janeiro — it’s free.