Get the formatter
createFormatter() resolves to a standard
Intl.NumberFormat
set up for the store. format(), formatToParts() and formatRange() all work as usual.
Adaptive currency
If the merchant has turned on adaptive currency, shoppers see prices in their own currency. The formatter is how that reaches your storefront: it converts as it formats. The shopper’s currency comes from their browser’s language and region, so a US store’s29.99 shows in dollars for most US
shoppers and in pounds for one whose browser is set to British English.
That’s why the rules are strict:
- Pass amounts exactly as the API gives them.
costand every other price in store data is in the store’s currency,store.currencyCode. Don’t convert or round them first. - Format every price with it. A price printed any other way -
"$" + cost, orcost.toFixed(2)- is in the wrong currency for those shoppers, while the checkout they reach is in the right one. - Never hardcode a currency symbol, not even as a placeholder while the formatter loads. On an
adaptive-currency store, a
$placeholder is the wrong currency, and it’s the first thing shoppers see.
Examples
A price range
A cart total
Add up amounts in the store’s currency, then format the total once:Styling part of a price
formatToParts() splits a price so you can style the pieces - here, a smaller currency symbol:
Loading and caching
The SDK caches the formatter, so callcreateFormatter() wherever you need it - every call after the
first resolves straight away. init() starts preparing it in the background too.
If you keep your own copy, keep only a formatter the call actually returned:
Next
Products
Variants, stock and volume pricing
Basket
The cart, and rendering it with prices