Selling your event in your own currency

If you're running a kirtan night in Toronto, you price it in Canadian dollars. If you're leading a retreat outside Stockholm, you price it in kronor. That match between where an event actually happens and what currency it's sold in isn't just a formality — it's what lets a buyer look at a ticket price and know immediately what it costs them, without doing math in their head. On BrightStar, the currency for an event is set once, on the event itself, and everything downstream follows that single choice: the prices you type into each ticket tier, the total your buyer sees at checkout, the payment Stripe actually processes, and the figures that later show up in your reporting. Nothing about currency lives in more than one place, which is what keeps all of those numbers agreeing with each other.

When you add your venue in the event wizard, BrightStar reads the country attached to it and proposes the currency that goes with that country. Most of the time this is exactly right — a venue in Lisbon means euros, a venue in Tokyo means yen — so you never have to stop and think about it. But BrightStar treats this as a suggestion, not a rule. If your situation is different — you're running an event abroad but selling mainly to a community that pays in your home currency — you can override the proposed currency before you start selling. The important word there is before: this override window closes the moment a ticket sells.

As soon as the first order exists, the currency field stops being editable for the life of that event. This isn't an arbitrary restriction — it's what keeps your ledger honest. If the currency could change mid-sale, you'd end up with some orders recorded in one currency and later orders in another, with no accurate way to add the two together into a single total for reporting. It would also make refunds ambiguous: a buyer who paid in the original currency needs to be refunded in that same currency, not whatever you switched to afterward. Locking the field the moment money moves is what protects both your numbers and your buyers' refunds from becoming a guessing game.

Sometimes one event genuinely has two audiences paying in two different currencies — a retreat marketed to both a domestic and an international community, for example. BrightStar doesn't support splitting a single event listing across currencies, because that's the same ledger problem as changing currency mid-sale, just from a different angle. The way around it is to create a second, separate listing for the same event with its own currency set from the start. Each listing then has its own clean, single-currency ledger, its own checkout totals, and its own reporting — nothing to reconcile between the two after the fact.

Buyers pay in whatever currency the event itself is priced in — there's no automatic conversion happening on BrightStar's side for the person buying the ticket. If your event is priced in Canadian dollars, that's what shows on the checkout page and that's what gets charged. Any conversion from there happens on the buyer's side, through their own bank or card issuer, if their card is denominated in a different currency. That's also why the amount that eventually shows up on a buyer's card statement can look slightly different from the total they saw at checkout — that gap is your buyer's bank applying its own exchange rate and any conversion charge, not anything BrightStar added or changed.

The fee structure itself doesn't change depending on which currency an event is sold in — every event on BrightStar carries a platform fee charged per ticket according to your plan, plus payment processing charged once per order. What does change is the currency those amounts are expressed in: they're calculated and shown in the event's own currency, not converted from US dollars or any other reference currency. So a Stockholm event's fees appear in kronor, in the same krona figures as the rest of that event's totals, keeping every number on one page in one currency.