Selling internationally sounds simple until you actually do it. Accept payments in euros, show prices in yen, ship to Canada. In practice, multi currency ecommerce touches every layer of your stack: your product catalog, your pricing engine, your checkout flow, your payment processor, your invoicing system, your accounting, and your tax compliance. Getting any one of these wrong creates problems that range from annoying (prices displaying as $14.7832) to catastrophic (charging the wrong amount or violating tax law in a foreign jurisdiction).
We have built ecommerce systems that process transactions across 15+ currencies and ship to 40+ countries. This post covers the architectural decisions that matter, the technical pitfalls that are not obvious until you hit them, and the practical patterns we use on projects we ship.
Currency Is Not Just a Display Problem
The most common mistake teams make is treating multi currency as a frontend formatting issue. They store all prices in USD, convert at display time using a cached exchange rate, and charge in USD regardless. This "works" in the loosest sense, but it creates real problems.
Exchange rate exposure. If you display a price in EUR on a product page but charge in USD at checkout, the customer's actual charge depends on their bank's exchange rate, which is different from yours. The price they saw and the price they paid will not match. This generates support tickets, chargebacks, and lost trust.
Rounding errors. Currency conversion produces fractional amounts. Different currencies have different decimal rules. USD and EUR use 2 decimal places. JPY uses 0. BHD uses 3. If your system assumes 2 decimal places everywhere, you will either overcharge Japanese customers by rounding up or display incorrect prices for Bahraini customers.
Legal requirements. Many jurisdictions require that the price displayed is the price charged, in the customer's local currency. The EU's consumer protection regulations are explicit about this. Displaying in one currency and charging in another can violate these rules.
The correct approach is to store and charge in the customer's currency. This means your data model, your pricing engine, and your payment processing all need to be currency aware from the ground up.
Data Model for Multi Currency
Your product catalog needs to support multiple price points per product. The simplest model is a price table with columns for product ID, currency code, and amount. Each product has one row per supported currency. This gives you full control over pricing in each market, letting you set psychologically appealing price points ($49.99 in USD, 49.99 EUR, 5,980 JPY) rather than awkward conversion artifacts.
For currencies you do not want to manage manually, implement a fallback conversion from a base currency using exchange rates. Your pricing resolution logic becomes: check for an explicit price in the requested currency; if none exists, convert from the base currency using the current rate. This hybrid approach lets you hand tune prices in your major markets while still supporting the long tail.
Store amounts as integers in the smallest currency unit. USD amounts in cents, JPY amounts in yen (since JPY has no subunits), EUR amounts in cents. This eliminates floating point errors entirely. Your database column is a bigint, your application logic operates on integers, and you only format to decimal at the display layer. We wrote about this pattern and other schema decisions in our database schema design guide.
Exchange rates need a history table. Store every rate update with a timestamp. When you need to reconstruct what a customer was charged and why, the current rate is useless. You need the rate that was active at the moment of the transaction. Pull rates from a reliable source (European Central Bank, Open Exchange Rates, or your payment processor's rates) and update at least daily.
Payment Processing Across Currencies
Your payment processor is the linchpin of multi currency support. Not all processors handle all currencies equally. Stripe supports 135+ currencies for card payments but settles in a smaller set. PayPal has its own supported currency list with different limitations. Local payment methods (iDEAL in the Netherlands, PIX in Brazil, Alipay in China) only work in their respective currencies.
Presentment currency vs settlement currency. The presentment currency is what the customer sees and pays. The settlement currency is what lands in your bank account. Most businesses present in multiple currencies but settle in one or two. Your payment processor handles the conversion between presentment and settlement, but they take a margin on it (typically 1% to 2%). Factor this into your pricing.
Multi currency with Stripe is well documented but has nuances. Each PaymentIntent specifies a currency and you cannot change it after creation. If a customer switches currency during checkout, you need a new PaymentIntent.
Local payment methods are often necessary for meaningful conversion rates. Credit card penetration varies dramatically by country. In the Netherlands, over 60% of online payments use iDEAL. In Germany, direct bank transfers are preferred. In Brazil, PIX and boleto dominate. Supporting these methods requires per market integration, which adds complexity but can double your conversion rate. Our payment processing guide covers the integration patterns for major processors.
Tax Compliance
International tax compliance is the part of multi currency that keeps finance teams up at night. The core challenges:
VAT in the EU. If you sell digital goods to EU consumers, you must charge VAT at the rate of the customer's country. VAT rates vary from 17% (Luxembourg) to 27% (Hungary). You need to determine the customer's country, apply the correct rate, collect the tax, and remit it. The EU's One Stop Shop (OSS) simplifies remittance but does not eliminate the complexity of rate calculation.
Sales tax in the US. Over 12,000 tax jurisdictions, each with different rates and rules. If you have nexus in a state, you must collect and remit sales tax there. Economic nexus thresholds (typically $100,000 in sales or 200 transactions) mean even purely online businesses trigger obligations in multiple states.
GST, HST, and other regimes. Canada, Australia, India, and many other countries have their own goods and services tax systems with unique rules.
Our strong recommendation: use a tax calculation service like TaxJar, Avalara, or Stripe Tax rather than implementing tax logic yourself. These services maintain rate databases, handle jurisdiction lookups, and provide the audit trails needed for compliance. One API call per transaction saves you from maintaining tax rules across dozens of jurisdictions.
Localization Beyond Currency
Multi currency is one dimension of internationalization. A truly international ecommerce system also handles:
Locale specific formatting. The number 1,234.56 in the US is 1.234,56 in Germany and 1 234,56 in France. Your display layer needs locale aware number formatting. JavaScript's Intl.NumberFormat handles this, but only if you pass the correct locale through your rendering pipeline.
Address formats. Shipping addresses vary dramatically by country. US addresses have a ZIP code. UK addresses have a postcode. Japanese addresses are ordered differently (prefecture, city, neighborhood, then building). Your address form and validation need to adapt per country.
Shipping cost calculation. International shipping costs depend on origin, destination, weight, dimensions, and carrier. Your shipping cost engine needs carrier integrations for your target markets and must account for duties and import taxes. DDP (delivered duty paid) vs DDU (delivered duty unpaid) affects customer experience: DDP means no surprise charges at delivery, but you bear the cost of calculating duties upfront.
Language. Translating your storefront is an entire discipline. At minimum, ensure your currency and pricing layer does not make language assumptions. Price formatting, date formatting, and legal text all need localization.
Architecture Recommendations
Based on our experience shipping international ecommerce systems, here are the decisions we recommend.
Currency is a first class concept, not an afterthought. Every financial entity (price, discount, tax, shipping cost, order total, refund) carries a currency code alongside the amount. No implicit currencies anywhere.
Prices resolve through a pricing service, not inline calculation. The service takes a product ID and a currency, returns the correct price, and handles the fallback logic internally. The rest of your application never does currency math.
Exchange rates update automatically via a scheduled job with manual override capability. Store rate history. Use the rate active at transaction time for all calculations.
Tax calculation is delegated to a third party service. Do not maintain tax rate tables yourself. The regulatory landscape changes too frequently and the compliance risk is too high.
Getting international ecommerce right requires coordinated work across your full stack, from database schema to checkout UI to financial reconciliation. If you are evaluating whether to build a custom ecommerce platform or extend Shopify, multi currency requirements often tip the decision toward custom because the degree of control you need over pricing, tax, and payment flows exceeds what most platforms offer out of the box.
If you are expanding internationally and need an ecommerce architecture that handles multi currency natively, reach out to our team and we will help you plan the implementation.