Overview
The euro (EUR) is the shared currency of the eurozone - 21 EU member states (as of 2026). A common requirement is to offer a single EUR price to customers across all of these countries, rather than a different price per country. Stigg supports this with a synthetic country code,EU, representing the European Union - ISO-3166-1 exceptionally reserves EU for this purpose, so it’s a fully valid billingCountryCode value. It also gets its own EU flag in the Stigg app. Add one localized price under EU - via no-code configuration or programmatically - and every customer you resolve to EU gets that price, instead of you having to add and maintain the same price once per eurozone country.
How matching works
Stigg has no built-in concept of “the eurozone,” or of any other country grouping - it doesn’t know that Germany (DE) is a member state, and it doesn’t map DE to EU for you. Matching a billingCountryCode to a localized price is an exact string comparison against the country code configured on that price row, nothing more. A request with DE will never match a price row configured for EU, and a request with EU will never match one configured for DE.
This means the country-to-region mapping is entirely your application’s responsibility. Maintain your own list of eurozone country codes, and when you resolve a customer’s actual country (via GeoIP, billing address, or an onboarding preference), map it to EU before passing it as billingCountryCode - on every call that accepts it: the Paywall, Checkout, and CustomerPortal widgets, and the provisionSubscription and previewSubscription APIs.
TypeScript
Countries that use the euro unilaterally (Andorra, Monaco, San Marino, Vatican City) or de facto (Kosovo, Montenegro) are not eurozone member states. Add their country codes to the mapping only if you intend to serve them the same EUR price.
Returning customers can resolve to EU without you sending it
Stigg has a fallback for customers you don’t explicitly resolve:resolveCustomerBillingCountryCode maps a customer’s billingCurrency back to a country code, by finding a price row configured in that currency. Once an EU price row exists in EUR, this lookup can return EU for a customer whose billing currency is already EUR - which is why a returning EUR customer keeps seeing their EUR price even when a caller omits billingCountryCode.
This fallback is currency-driven, not region-aware - it only applies to customers who already have a billing currency (i.e. an existing paid subscription), and it only resolves to EU because a price in that exact currency happens to be configured with that code. It isn’t a substitute for resolving and passing billingCountryCode explicitly for new or anonymous visitors, per the previous section.
Things to keep in mind
- Customer-facing country in the Stigg app. Once a subscription is provisioned, the customer’s payment details show
EUrather than the customer’s actual country. If you rely on this field for reporting, resolve the customer’s real country from your own systems instead. - Existing subscriptions don’t reprice automatically. As with any localized price, a change to the customer’s resolved country only affects new subscriptions - it doesn’t reprice an active one. See price localization overview.
- Differentiating a specific country later. If you later want to charge a different price in one eurozone country, stop mapping that country to
EUand add a dedicated localized price for it directly.
Consolidating existing per-country prices into one EU price
If you’re already serving the eurozone with a separate localized price per country and want to replace them with a singleEU price, two operational constraints apply.
Consolidation isn’t available in the dashboard
A price row’s delete control is disabled once it has live subscriptions, and that stays disabled even in a new draft - you can’t work around it by editing a draft version. To consolidate prices that already have subscribers, use Set Package Pricing instead. It replaces a plan or add-on’s entire pricing set in one atomic call, so include every price you want to keep - the default price, any other localized prices, and the newEU price - not just the ones you’re changing.
Existing subscribers don’t move onto the consolidated price by themselves
Consolidating prices doesn’t change what country an existing subscriber resolves to. A subscriber who still resolves to their original country (for exampleDE) will find no price row there once you’ve removed it, and will fall through to your product’s default price - which is very likely a different currency than what they were being billed before. This happens silently: there’s no error, just a currency change on their next invoice.
To avoid surprising existing subscribers, publish the consolidated EU price for new customers only, and either leave existing per-country prices in place for their current subscribers or explicitly re-point those subscriptions to EU yourself.