Show prices in local currency without breaking your pricing

A switcher that divides your USD price by today's rate and prints a euro sign is display conversion. The customer still pays in USD. Their bank does the real conversion at its own rate, adds a foreign-transaction or cross-border fee, and the statement shows a number you never quoted. That mismatch generates support tickets and disputes more reliably than it generates lost sales, because the shopper feels quietly overcharged after the fact. Charging in the shopper's currency is a different arrangement: your processor has to support that presentment currency, and you have to decide the settlement question — which currency lands in your bank account, and who absorbs the spread. Stripe, PayPal and Adyen each publish their own conversion margins and cross-border card fees. Read those before promising local pricing, because the fee structure usually decides whether real multi-currency charging is worth the operational weight.

A live rate turns 1,299 into 1,287.43, and that number tells the shopper the price was produced by a machine rather than chosen by a merchant. Price endings carry meaning — the retail pricing literature on 9-endings, including Anderson and Simester's field experiments on price endings, treats them as signals shoppers actually read — and an arbitrary decimal reads as no signal at all. Conversion also destroys price architecture: bundles stop looking like bundles, a deliberate 50-unit gap between tiers becomes a 48.61 gap, and the shape of your range dissolves. Manual price rules per market almost always convert better. You decide the product is 1,299 at home, 1,399 in one market and 1,199 in another, based on local willingness to pay, shipping cost and who else sells there. Rates then only matter at settlement, where they belong.

• Round to each market's local convention, not to the exchange rate
• Keep the gaps between tiers intentional in every currency
• Set a floor price per market so a rate move cannot cross it
• Re-price on a schedule you control, not on every rate refresh

Geolocation from an IP address is a guess. It is wrong for VPNs, corporate networks, travellers, expats and anyone buying a gift for another country, and when it is wrong it is loudly wrong: the shopper sees the wrong currency, usually alongside the wrong tax and shipping story. The pattern that holds up is to guess once, present the guess as a suggestion rather than a verdict, keep the switcher visible without hunting for it, and then remember what the shopper picked. Remembering matters more than guessing. Someone who switched to GBP and lands on GBP next visit reads the store as competent; someone who has to switch again on every page leaves. Store the choice as a preference, keep it out of the URL, and never let a fresh IP lookup silently overrule an explicit selection.

• Treat IP location as a suggestion, never as a decision
• Put the switcher where it is seen, not in the footer
• Persist the explicit choice and stop guessing after it
• Show currency and delivery destination together, not separately

The moment a price depends on who is looking, full-page caching gets complicated. A cached HTML page holds exactly one currency: serve it to everyone and a share of your shoppers see the wrong number; vary the cache on a currency cookie and you multiply every cached page by the number of markets, which quietly wrecks hit rate on a large catalogue. Most plugins resolve this by rendering prices at request time, which is precisely the path that makes WooCommerce feel slow under load. This is where a storefront rebuild genuinely helps rather than merely sounding modern. A Next.js storefront can serve the shell, layout, copy and imagery from the CDN for everybody, then resolve only the price-bearing parts per visitor against WooCommerce — so price, stock and tax stay correct while the page still arrives fast.

Currency is only half of what a new market changes. Consumer-facing prices in the EU and the UK are expected to be shown inclusive of VAT, Australia expects GST-inclusive pricing, and the US convention is the opposite: a shelf price plus destination-based sales tax added at checkout. So the same product may need to read 99 inclusive in one market and 99 plus tax in another, and no exchange rate can express that. B2B adds another layer, where a validated VAT number can move the same order to a zero-rated, tax-exclusive display — the sort of thing worth planning deliberately if you sell to business buyers. The tax engine itself stays where it is: WooCommerce and your tax plugin keep calculating, and the storefront's job is to display the result the way each market expects to read it.

WooCommerce remains the system of record. Products and their per-market price rules, stock, coupons, tax rates and classes, orders, refunds and reporting all stay in WordPress, and the people who run the store keep the admin they already know. What changes is the customer-facing layer: how the price is chosen, formatted, cached and displayed, and how the currency preference travels with the shopper into the cart. Refunds deserve an explicit decision here, because they are usually issued weeks after the charge at a different rate. If you charged in the shopper's currency and settle in yours, a later refund can cost you more or less than you received; if the sale was display-only, the shopper's bank converts back at its own rate and they receive less than they paid, then email you about it. Pick a policy — normally refund the original amount in the original currency — and make sure whoever processes refunds in the admin follows it.

• Stays in WooCommerce: products, stock, coupons, tax rules, orders
• Stays in WooCommerce: refunds, reporting and your existing gateways
• Changes: price selection, formatting, caching and the switcher
• Changes: how the chosen currency follows the shopper to checkout

The common self-inflicted wound is spawning a URL per currency — a /eur/ path or a ?currency=EUR parameter — and letting search engines crawl all of them. You then have several addresses for one product with near-identical content, crawl budget spent on duplicates, and no clear canonical for the page you actually want ranking. Currency is a visitor preference; language and region are content. Language and country variants are what hreflang and separate URLs exist for, and a currency swap on the same English page is not one of those. Keep one canonical URL per product, resolve currency from the stored preference rather than the path, and if a parameter must exist for sharing, make sure it is not indexable. The same discipline that keeps a technical SEO setup clean during a redesign applies here.

For a lot of stores the honest recommendation is: install a well-maintained multi-currency plugin, set manual prices per market, check the tax display, and stop. If you sell in two or three currencies, run a few hundred products and your pages are already fast, a storefront rebuild is not the cheaper fix and we will say so. The picture changes when caching and per-visitor pricing start fighting each other, when many markets multiplied by a large catalogue makes request-time pricing slow, when your team is maintaining price rules by hand across markets, or when compliant tax-inclusive display per market has become a real requirement rather than a nice idea. Engagements here start at $1,999 and are scoped from what your store actually does — see pricing, or describe the setup and markets in a short scoping note and we will tell you which side of that line you are on.