# Selling into several markets

Sell into several markets with one order per purchase_country, currency and locale — Kustom doesn't convert between them. Includes every supported locale and its fallback.

An order is bound to one `purchase_country`, one `purchase_currency` and one `locale`, and
**Kustom does not convert currencies**. Selling into a second market therefore means
either a second order or a change to the open one — there's no setting that makes one
order serve two markets.

## Core countries

Kustom Checkout reaches well over two hundred countries. A smaller set are *core*
countries, which have their own currency and support Kustom Credit, local low-risk payment
methods and cards:

| Country | `purchase_country` | Currency |
|---|---|---|
| Sweden | `SE` | SEK |
| Norway | `NO` | NOK |
| Denmark | `DK` | DKK |
| Finland | `FI` | EUR |
| Germany | `DE` | EUR |
| Austria | `AT` | EUR |
| Netherlands | `NL` | EUR |
| Belgium | `BE` | EUR |
| France | `FR` | EUR |
| Spain | `ES` | EUR |
| Poland | `PL` | PLN |
| Switzerland | `CH` | CHF |
| Great Britain | `GB` | GBP |
| United States | `US` | USD |

Each country and currency pair you intend to sell in has to be on your contract — ask your
account manager to add it. Shipping and billing countries are allowlisted per merchant,
and Kustom may restrict further on risk grounds, including orders that would breach EU
sanctions or that carry fraud or money-laundering signals.

## Supported languages and locales

`locale` is set on Create order and Update order, and it controls language only. It has no
effect on purchase country or currency, which `purchase_country` and `purchase_currency` set
separately:

```json
{
  "purchase_country": "GB",
  "purchase_currency": "GBP",
  "locale": "en-GB"
}
```

Fourteen languages, and twenty-one regional variants on top of them. Send the most specific
code that fits your market: a variant is a separate translation, not a formatting tweak, so
`fr-BE` is written for Belgium and `fr-CA` for Canada rather than both being French with a
different date format.

| Language | Base | Regional variants |
| --- | --- | --- |
| Czech | `cs` | — |
| Danish | `da` | — |
| Dutch | `nl` | `nl-BE` |
| English | `en` | `en-AT`, `en-AU`, `en-BE`, `en-CA`, `en-DE`, `en-DK`, `en-FI`, `en-FR`, `en-GB`, `en-IE`, `en-NL`, `en-NO`, `en-SE`, `en-US` |
| Finnish | `fi` | — |
| French | `fr` | `fr-BE`, `fr-CA`, `fr-CH` |
| German | `de` | `de-CH` |
| Greek | `el` | — |
| Italian | `it` | — |
| Norwegian Bokmål | `nb` | — |
| Polish | `pl` | — |
| Portuguese | `pt` | — |
| Spanish | `es` | `es-US` |
| Swedish | `sv` | `sv-FI` |

English carries the most variants because it's what a market gets when its own language
isn't the customer's: `en-DE` is English for a German checkout, not a second German.

Three things that are easy to get wrong:

- **`no` and `no-NO` are remapped to `nb` and `nb-NO`.** Both work. You don't need to
  translate Norwegian codes yourself.
- **The fallback is English specifically**, not the market's language. A locale Kustom
  doesn't carry — `zh-CN`, say — renders an English checkout in a Chinese market.
- **A variant falls back to its base language**, so `sv-SE` renders `sv` and `fr-GB` renders
  `fr`. This is why the absence of a code from the table is rarely visible: something
  reasonable still renders.

The API can't catch a mistake here. `locale` is validated for shape only — two letters, or
two letters and a region — so anything well-formed is accepted and the wrong language is
chosen silently. Pick from this table rather than passing through whatever your storefront
happens to hold.

## One site per market

A `.co.uk` domain, a `.de` domain, and so on. Allow a single shipping country on the
order, set `purchase_country` to that market and use the `address_update` callback to
keep shipping options and prices right as the address is filled in.

This is the simpler shape: the market is decided before the checkout opens, so it can't
change underneath you.

## One site for every market

Allow all your supported shipping countries on the order and set `purchase_country` to
your best guess of where the customer is.

Then you **must** handle the `country_change` callback — updating the currency and the
language to match the new country — as well as `address_update`. Without it, a customer who
changes country is left with the wrong currency, which is a broken purchase rather than a
cosmetic fault.

## Related

- [Server-side callbacks](/checkout/callbacks/) — `address_update` and `country_change` in full
- [Checkout options](/checkout/checkout-options/) — the rest of the order's configuration
- [External payment methods](/checkout/external-payment-methods/) — methods Kustom doesn't process, limited to the markets you list