> ## Documentation Index
> Fetch the complete documentation index at: https://docs.stigg.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Serving countries that pay in EUR

## 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](/documentation/price-localization/price-localization-no-code-configuration) or [programmatically](/documentation/price-localization/price-localization-codebase-integration) - 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 TypeScript theme={null}
const EUROZONE_COUNTRY_CODES = new Set([
  "AT", "BE", "BG", "HR", "CY", "EE", "FI", "FR", "DE", "GR",
  "IE", "IT", "LV", "LT", "LU", "MT", "NL", "PT", "SK", "SI", "ES",
]);

function resolveBillingCountryCode(actualCountryCode: string): string {
  if (EUROZONE_COUNTRY_CODES.has(actualCountryCode)) {
    return "EU";
  }

  return actualCountryCode;
}
```

<Note>
  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.
</Note>

## 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](/documentation/price-localization/price-localization-no-code-configuration#at-the-customer-level) show `EU` rather 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](/documentation/price-localization/price-localization).
* **Differentiating a specific country later.** If you later want to charge a different price in one eurozone country, stop mapping that country to `EU` and [add a dedicated localized price](/documentation/price-localization/price-localization-no-code-configuration) 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 single `EU` price, two operational constraints apply.

<Warning>
  Dropping a redundant per-country price is not a no-op for anyone already subscribed to it - see below before you remove any per-country price with live subscriptions.
</Warning>

### 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](/api-and-sdks/api-reference/mutations/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 new `EU` 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 example `DE`) 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.

## Reference: eurozone country codes

| Country     | ISO-3166-1 code |
| ----------- | --------------- |
| Austria     | AT              |
| Belgium     | BE              |
| Bulgaria    | BG              |
| Croatia     | HR              |
| Cyprus      | CY              |
| Estonia     | EE              |
| Finland     | FI              |
| France      | FR              |
| Germany     | DE              |
| Greece      | GR              |
| Ireland     | IE              |
| Italy       | IT              |
| Latvia      | LV              |
| Lithuania   | LT              |
| Luxembourg  | LU              |
| Malta       | MT              |
| Netherlands | NL              |
| Portugal    | PT              |
| Slovakia    | SK              |
| Slovenia    | SI              |
| Spain       | ES              |


## Related topics

- [Price localization overview](/documentation/price-localization/price-localization.md)
- [No-code configuration in the Stigg app](/documentation/price-localization/price-localization-no-code-configuration.md)
- [Implementing price localization on your public website and application](/documentation/price-localization/price-localization-codebase-integration.md)