Skip to main content
Each store sets its own currency, and every product and pricing response includes the currency it is expressed in — so displaying money is a matter of formatting the amount with the symbol that came back alongside it, without a separate currency call.

Where currency lives

Currency travels with the priced data, on every catalog and pricing response. This is the primary source for rendering a price: Both display_currency and currency_symbol are selectable via sparse fieldsets — request just them with fields=...,display_currency,currency_symbol to keep a grid lean. So a storefront renders the right price and symbol straight from the catalog read it was already making — no extra round trip.
Store information lists what the store is configured for — it’s reference metadata, not the per-response source of truth. client.system.getStoreInfo (single store) / client.marketplace.getMarketplaceInfo (marketplace) return:
Use store info to know which currencies a store supports (e.g. to render a currency switcher); use the display_currency/currency_symbol on each priced response to actually render prices.

Single-currency store

Multi-currency store

Prices are returned in default_currency. When features.multi_currency is true, you can offer a currency switcher built from store.currencies and convert amounts for display.

Marketplace

On a marketplace deployment the storefront currency is marketplace-wide — it’s the operator’s single default, so the whole aggregated catalog renders in one currency (you do not get a different currency per merchant). Every product still carries display_currency/currency_symbol inline, so you format the same way; they just resolve to the marketplace’s currency across all merchants. client.marketplace.getMarketplaceInfo reports the marketplace’s default_currency, and getMarketplaceInfo({ storeId }) returns a single merchant’s store info. (Each merchant still sets its own prices; the operator sets the currency they’re shown in.)
If default_currency is ever absent for a store, fall back to the first entry of store.currencies.

Currency is validated server-side at payment

The currency a payment is charged in is decided by Galactic Core, not by the caller. When you initialize a payment, any currency you pass is treated as a request that is validated against the store’s enabled currencies — the same set store.currencies reports:
  • A currency the store supports is accepted (this is what a multi-currency storefront’s currency switcher relies on).
  • A currency the store does not support is rejected with 400 unsupported_currency, listing the currencies that are allowed — so a mismatched or unexpected currency can never be charged.
  • Omit currency and the store’s default is used.
On a marketplace deployment this resolves to the operator’s single marketplace currency, and a checkout that requests a different currency is rejected the same way. In every case the amount and the currency the shopper is charged are the server’s decision, and the currency returned on the priced response being checked out is always in the accepted set.
Server-side validation makes a pre-check unnecessary. Reading store.currencies — or the display_currency on each priced response — is what lets a UI offer only currencies that will be accepted in the first place.