Selling internationally on Magento is architecturally straightforward and operationally full of sharp edges. The platform gives you websites, currencies, tax rules and translation systems that compose well - but the details (who sets prices, how rounding works, which VAT applies) decide whether expansion feels smooth or chaotic. Here is the practitioner’s tour.
Currencies
Magento distinguishes three currency concepts per website:
- Base currency: the currency prices are stored and orders are charged in
- Default display currency: what the storefront shows
- Allowed currencies: what customers can switch to, converted at stored rates
Rates sync nightly via a configured service, or you maintain them manually. The crucial decision: display conversion or real pricing? Auto-converted prices produce ugly numbers (£19.99 becomes EUR 23.41) and margin erosion as rates drift. Serious international operations set per-website pricing (a website-level price scope) and price deliberately in each market. That means prices become a website-scope attribute - set it before importing your catalog, because changing price scope later touches every product.
Tax
Tax configuration has three parts that must agree:
- Tax rules mapping product tax classes + customer tax classes + rates
- Rates per country/region (EU VAT per member state, UK 20 percent, US by state)
- Display settings: prices including or excluding tax - and this differs by market convention (B2C EU/UK prices must show VAT-inclusive; US shows tax added at checkout)
EU cross-border B2C adds OSS (One Stop Shop) logic: charge the destination country’s VAT above the threshold. Magento handles rates fine; the merchant’s obligation to register and file is outside the platform. Validate your rule matrix with real test orders to real addresses before launch - tax errors are legally sensitive, not just cosmetic.
Translations
Three mechanisms, in order of preference:
- Language packs (Composer packages like
mageplaza/magento-2-german-language-pack): cover core phrases; install per store view locale - Theme-level CSV dictionaries (
i18n/de_DE.csv): your overrides and custom-module phrases - Inline translation: database-driven, per store view - slow to maintain, avoid for anything but tiny tweaks
Custom modules must wrap strings in __() and ship their own i18n CSVs; hardcoded English in templates is untranslatable forever.
The Gotchas
- Locale != currency: a de_DE view can still price in GBP if the website’s currency is GBP - check the full matrix
- Number formats: 1.299,00 vs 1,299.00 come from the locale, not the currency
- CMS content: blocks and pages are per store view; build a translation workflow (export, translate, import) or content drift is guaranteed
- Hreflang and URLs: each store view gets its own base URL; ensure hreflang tags link language variants for SEO - Magento does not do this well natively, so plan for an extension or theme-level implementation
International expansion on Magento rewards doing the architecture once, properly: websites per market, deliberate pricing, tested tax, managed translations. Skip the deliberation and you will rebuild it in year two, at catalogue scale, in production.