Offer relevant storefront defaults
Suggest a country and currency from the visitor's connection to reduce friction before checkout, without treating IP-derived location as evidence for tax, shipping, or billing decisions that need to be correct.
Display currency versus billing currency
Use geo.currency to prefill a storefront's displayed currency and price formatting on first load. Treat it strictly as a display default: the amount actually charged still has to come from your payment processor, which resolves currency and rate from the payment method itself, not from an IP address.
A region selector, not a location lock
Show the suggested country and let the shopper change it. Don't gate catalog visibility, pricing tiers, or checkout access solely on an IP-derived country — a VPN, corporate proxy, or traveling shopper can resolve somewhere they don't actually want to shop from.
Tentative shipping messages
City and region fields support an approximate message like "usually ships in 3–5 days to your region," not a guaranteed delivery date or shipping cost. Confirm the actual address and shipping quote during checkout, where the shopper supplies it directly.
Example: suggest currency, recalculate at checkout
On page load, call GET /v1/geo from the storefront's own JavaScript, read country and currency, and prefill the currency selector and displayed prices. At checkout, discard the IP-derived currency and use whatever your payment processor resolves from the shopper's payment method and billing address instead.
What this doesn't guarantee
Current fields don't calculate exchange rates, sales tax, or VAT, and don't establish a purchaser's billing residency — the tax field itself returns a null rate for US addresses precisely because destination-based US sales tax can't be resolved from country/region alone. Use a dedicated tax engine and your payment processor for anything that has to be correct at checkout.