Display Currency & FX Rates
The Cambridge TCG price guide carries a canonical GBP price for every card. The currency selector on the price guide pages converts that GBP value into one of six display currencies. It is a display transform only. Every transaction on cambridgetcg.com — buy, trade-in, marketplace fill, payout — clears in GBP regardless of the currency you happen to be reading the page in.
The six currencies
The selector covers the platform's real audiences today. Each is ISO 4217.
| Code | Symbol | Name | Decimals | Why |
|---|---|---|---|---|
GBP | £ | Pound Sterling | 2 | Platform canonical. Transactions clear here. |
USD | $ | US Dollar | 2 | TCGplayer upstream; US visitors. |
EUR | € | Euro | 2 | Cardmarket upstream (planned); EU visitors. |
JPY | ¥ | Japanese Yen | 0 | CardRush upstream; Japanese visitors. |
HKD | HK$ | Hong Kong Dollar | 2 | South-East Asia visitors. |
CHF | CHF | Swiss Franc | 2 | Swiss visitors. |
Where the rates come from
We fetch GBP-base mid-market rates from one of two open sources, cached for six hours.
- Primary:
open.er-api.com/v6/latest/GBP— free, no API key, refreshed daily by the upstream. - Fallback:
api.exchangerate.host/latest?base=GBP— used when the primary times out or returns an error. - Final fallback: a static rate table baked into the storefront, refreshed by the developer on platform releases. When this is in play, the surface shows an amber "fallback"pill so visitors aren't misled.
Today the price guide is reading from open.er-api.com, fetched at 2026-05-14T00:02:31.000Z.
The conversion math
For a card priced at p GBP and a target currency c with a rate r(c) expressed as units of c per 1 GBP:
displayValue = p × r(c)
displayString = format(displayValue, locale(c), decimals(c))GBP is the base, so r(GBP) = 1.0 exactly. JPY uses zero decimal places; the other five use two.
Why this is display-only
Three reasons we don't accept transactions in non-GBP currencies:
- Settlement risk.The platform's bank is in GBP. Accepting USD or JPY at the checkout would require us to either hedge the exposure or pass it to the customer with a spread — both of which add complexity without changing the price.
- VAT compliance. UK VAT must be calculated in GBP on the date of supply. Multi-currency checkout would require a second VAT engine.
- Refund symmetry. A refund in a different currency than the original charge creates an FX gain/loss for the customer, which is hostile to the trade-in flow especially.
The display selector exists because readinga price in your own currency is useful — it's the action of converting that we want to keep in one place (the bank).
Machine-readable surface
The rate table is available as JSON at /api/v1/fx-rates with the standard data-pantry envelope (provenance, freshness, source license). Federation clients can pin a particular rate by capturing the JSON response at the moment of computation, since the response includes the source name and fetched_at timestamp.
What we don't do
- We don't price-discriminate by currency. The selector is symmetric — a Japanese visitor sees the same GBP base price as a British visitor, just rendered in JPY.
- We don't add an FX margin to the display rate. Mid-market in, mid-market out. The platform earns its margin on the card price, not the FX.
- We don't cache rates per-user. Everyone reads the same rate table; if your conversion looks off, refresh — the cache is six hours.
Related surfaces
- /methodology/pricing — how the GBP base price itself is computed (upstream JPY → GBP, channel uplift, VAT, margin).
- /methodology/cross-source-pricing — how we compose USD / EUR / JPY signals from multiple upstreams into a single comparable view.
- /api/v1/fx-rates — the machine-readable rate table.
- /prices — the price guide itself, where the selector lives.