Multi-Currency Pricing for Your Store: Display, Exchange Rates, Tax, and Payment
1. Three Technical Mistakes in Multi-Currency Display
Mistake one: converting prices on the storefront by calling an exchange rate API in real time with JavaScript. The price a buyer sees when the page loads reflects the rate at that moment, but by the time they add the item to the cart, fill in their address, and reach checkout, the rate has moved and the checkout price no longer matches the displayed price. On B2C sites this pushes up chargebacks; on B2B sites buyers abandon the cart and go straight to an inquiry.
Mistake two: displaying multiple currencies without localizing tax. EU buyers expect to see tax-inclusive prices (MwSt. inkl.), while US buyers expect to see pre-tax prices plus an estimated sales tax. If you show EU users a pre-tax price, they assume another 20% is coming and leave. Mistake three: forcing online payment onto a B2B inquiry-based site. B2B orders are usually large, require a quote, and need payment terms, which online payment channels cannot handle; forcing it in only raises the risk of chargebacks. For a discussion of pricing strategy, see Pricing for Overseas Markets: From Cost-Plus to Value-Based Pricing.
| Technical Mistake | What actually happens | The right way |
|---|---|---|
| Real-time rate conversion via storefront JS | Displayed and checkout prices differ by over 1% | Pull rates daily in one batch, same rates front and back |
| Switching currency but not tax | EU buyers assume another 20% in tax | Show tax-inclusive or pre-tax prices by destination country |
| Forcing online payment on a B2B site | High chargeback risk on large orders | Display multiple currencies only, take inquiries and quotes |
| Using the merchant’s spot rate | 3% to 5% above the central bank rate | Use the central bank mid-rate plus a 1% to 2% buffer |
| No manual currency switcher | VPN users see the wrong currency | Add a currency selector in the footer, default by IP |
2. How Often to Update Rates: Once a Day, Not in Real Time
For multi-currency display, a B2B store should update exchange rates once a day, pulling them in a batch at 00:00 UTC and caching them in the database for the whole day. Do not call an exchange rate API in real time on the front end. There are three reasons: first, real-time calls add page load delay and hurt Core Web Vitals metrics; second, exchange rate APIs have call limits, so real-time calls are expensive; third, real-time conversion makes the displayed price and the checkout price drift apart.
Three recommended exchange rate sources: the European Central Bank daily reference rate (free and stable), the XE API (free tier is enough for a small site), and Open Exchange Rates (1,000 calls per month on the free plan). Add a 1% to 2% merchant buffer to the cached rate, because the rate your payment provider actually settles at runs slightly higher than the ECB mid-market rate. For managing exchange rate risk in B2B quotes, see Exchange Rate Risk Management. This article covers front-end display only.
| Exchange Rate Options | Update frequency | Use cases | Cost |
|---|---|---|---|
| ECB Reference Rate | Once a day | B2B sites focused on Europe | Free |
| XE API | Once a day | Multi-currency B2B sites | Free tier is enough for a small site |
| Open Exchange Rates | Every hour | High-volume B2C sites | 1,000 calls per month on the free plan |
| Stripe Auto Conversion | Real time at payment | Small B2C orders paid by card | Stripe settles in the card’s currency |
3. Tax Calculation: By Destination Country, Not Warehouse Location
The core rule for tax calculation is that it follows the destination country, not the warehouse location. When a German buyer purchases your goods, whether you ship direct from China or from an EU warehouse, your German storefront must show prices including 19% MwSt. When a US buyer purchases, show prices before tax and add sales tax at checkout based on their state’s rate. This rule is called the destination principle, and both EU VAT rules and US sales tax rules follow it.
Example: an industrial sensor exporter whose site shows prices in USD before tax by default. A German buyer opens the page and sees a sensor priced at $100. He assumes 19% German VAT will be added and does the math as $119. If the site doesn’t localize taxes, he’ll see the price as unclear and send an inquiry asking “including VAT?” The right approach: when a German IP visits, switch automatically to the EUR price including tax and show “€109.90 inkl. MwSt”; when a US IP visits, show “$99.00 + sales tax”. For inquiry form reliability, see Inquiry Form Reliability.
| Region | Price Display | Tax Handling | Typical Rate |
|---|---|---|---|
| EU (Germany) | EUR price incl. tax | MwSt included, nothing added | 19% (standard) / 7% (reduced) |
| EU (France) | EUR price incl. tax | TVA included | 20% |
| United States | USD price before tax | Sales tax added at checkout by state | 0% to 10%, varies by state |
| UK | GBP price incl. tax | VAT included | 20% |
| Japan | JPY price incl. tax | Consumption tax included | 10% |
4. Payment Settlement: Charge in Your Main Currency, Pay Out in the Card’s Currency
Multi-currency pricing and payment settlement are two different things. Pricing layer: show prices in the buyer’s local currency on the front end so they know what they’re paying. Settlement layer: as the seller, you still ultimately receive your main currency (usually USD or CNY). The payment provider handles the currency conversion in between, so don’t build your own conversion logic into the site.
Recommended setup: buyers see prices in EUR including tax, choose Stripe at checkout, and Stripe charges their card in the card’s currency (a euro card is charged in euros, a dollar card in dollars at the current exchange rate). At settlement, Stripe converts the funds into your primary currency and deposits them in your bank account. This way you only maintain one set of prices in your primary currency: the storefront display relies on a cached exchange rate, and settlement is handled by the payment provider. Don’t build your own currency conversion logic into your site’s backend — it’s costly to maintain and easy to get wrong. For payment provider options and fee comparisons, see Inquiry Form Reliability the payment articles on this site.
| Stage | Currency | Rate source | What to watch for |
|---|---|---|---|
| Storefront display | Buyer’s local currency | Central bank rate, cached daily | Plus a 1% to 2% merchant buffer |
| Add to cart | Buyer’s local currency | Same as storefront cache | Locked for the session, no drift |
| Checkout charge | Cardholder’s local currency | Stripe/PayPal live rate | Tell buyers they’ll be charged at this rate |
| Seller settlement | Primary currency (USD/CNY) | Payment provider settlement rate | 1% to 3% lost to conversion on arrival |
5. Multi-currency strategy for B2B inquiry-based sites
Multi-currency strategy is completely different for B2B sites and B2C ecommerce sites. B2B orders are large (usually thousands to hundreds of thousands of dollars), require quotes, payment terms, and volume-based tiered pricing — scenarios online payment providers can’t handle. So multi-currency on a B2B site does just one thing: show buyers prices in a currency they know, reduce friction in the conversation, and guide them to send an inquiry.
How it works in practice: switch the display currency automatically by IP, add a manual currency selector at the bottom (USD/EUR/GBP/JPY/AUD), convert prices using a daily cached rate, and label the displayed price with “Reference price, final quote in USD”. Add a “Preferred currency” dropdown to the inquiry form so buyers can choose the currency they want to be quoted in. For delivery commitments and quoting standards, see Delivery Commitment.
| Site type | Multi-currency approach | Payment method | Rate updates |
|---|---|---|---|
| B2C ecommerce site | Display and checkout, end to end | Stripe/PayPal online payment | Hourly or daily |
| B2B inquiry site | Display only, no checkout | Drive inquiries, paid by T/T | Once a day |
| Hybrid site | Retail SKUs paid online, large orders by inquiry | Routed automatically by order value | Once a day |
FAQ
How much difference between the storefront price and the checkout price is normal?
How often should exchange rates update?
How should EU VAT be displayed on the site?
Should a B2B site accept online payments?
How does multi-currency settlement differ between Stripe and PayPal?
Should I add a merchant buffer to the exchange rate cache, and how much?
Final thoughts
The technical core of multi-currency pricing isn’t currency conversion — it’s consistency: the price on the front end, the price in the cart, and the price at checkout must all use the same set of exchange rates. Real-time conversion looks advanced, but in practice it leaves price drift to the buyer, which ends up showing up as refunds and abandoned carts.
Three steps to launch: First, pull the central bank rate once a day on a schedule and cache it in your database. Second, display tax-inclusive or pre-tax prices based on the destination country — tax-inclusive for the EU, pre-tax for the US. Third, on a B2B site, show multi-currency prices without settling in them and steer buyers to inquiries; on a B2C site, settle through Stripe in the card’s currency and don’t write your own conversion logic.
One line worth remembering: multi-currency pricing isn’t about getting your site to convert currencies for you — it’s about letting buyers see a price that won’t change, in the currency they know.