Medusa.js has native multi-region support built into its core data model. Not a plugin, not a workaround — the platform was designed from v2 onward with the assumption that a store might serve multiple countries with different prices, currencies, tax rules, and shipping options. Here is what that looks like in practice, what it costs to build, and when your business actually needs it.
What Medusa’s Multi-Region Architecture Does
In Medusa, a region is a first-class configuration entity. Each region has its own:
- Currency — USD for US customers, EUR for Germany, GBP for the UK
- Tax rules — US stores might apply state-level sales tax; EU stores handle VAT
- Payment providers — you might offer Klarna in Europe but not the US
- Shipping providers — separate fulfillment rules per geography
- Price lists — product prices set independently per region
When a customer lands on your storefront, the frontend passes a region context to the Medusa API. Every response — product prices, available shipping methods, applicable taxes — reflects that region’s configuration. The customer sees EUR prices with German VAT included; a US customer on the same store sees USD prices with no VAT.
This is not the same as simply showing a currency conversion. The prices are set explicitly per region. A product that costs $99 in the US might be set to €85 in Germany — not auto-converted at today’s exchange rate, but deliberately priced for that market.
Multi-Currency Without Multi-Region: What Most Stores Actually Need
Most stores that think they need multi-region actually need something simpler: multi-currency with a single set of operations. Different prices in different currencies, but the same warehouse, the same checkout flow, and the same tax logic.
Medusa handles this through its pricing module. You can attach multiple price entries to a product — one per currency — and the API returns the appropriate price based on the customer’s currency context. This is less complex than full multi-region configuration and is appropriate when you ship from one location globally.
Full multi-region configuration becomes necessary when your regions have genuinely different operations: separate 3PL partners per continent, EU-specific VAT handling that differs materially from US sales tax, or payment providers that are only available in certain markets (Klarna is EU-dominant; certain BNPL options are US-only).
If your store ships globally from a US warehouse and you just want to show EUR prices to European customers, you do not need the full multi-region setup. You need multi-currency pricing, which is a simpler configuration.
Taxes: Where Multi-Region Complexity Lives
Tax is where most international ecommerce setups get painful — and where Medusa’s multi-region architecture saves genuine development time.
In a single-region setup, you configure one tax provider. In Medusa’s multi-region model, each region has its own tax configuration. EU regions can be configured with VAT-inclusive pricing (the price shown already includes tax — required for consumer-facing EU stores). US regions can be configured for tax-exclusive pricing with state-specific rates applied at checkout.
Medusa integrates with tax calculation services like TaxJar (US sales tax automation) and has built-in handling for EU VAT rules. The region configuration tells Medusa which tax logic to apply for which geography — without requiring custom code for each market.
If you are selling to EU consumers and not handling VAT correctly, the liability exposure is real. The EU VAT One Stop Shop (OSS) scheme simplifies reporting but does not eliminate the requirement to charge the correct VAT rate per country. Medusa’s region architecture makes this configurable without custom development.
Fulfillment: Separate Operations Per Region
The most operationally complex version of multi-region commerce is when you have separate fulfillment partners per geography. A US warehouse handled by ShipStation. An EU warehouse handled by a local 3PL. Different shipping rules, carrier options, and delivery windows per region.
Medusa’s fulfillment module is region-aware. You can assign specific fulfillment providers to specific regions. When a German customer places an order, Medusa routes the fulfillment request to the EU provider. When a US customer orders, it routes to the US provider. This happens at the platform level — not through custom logic you have to write and maintain.
Configuring this correctly adds build time. You need to integrate two fulfillment providers, test the routing logic, and validate that orders from each region land in the right fulfillment queue. That is not a weekend task. But it is significantly cheaper than building the same routing logic from scratch on a platform that does not support it natively.
What a Multi-Region Medusa Build Actually Costs
A single-region Medusa build with a Next.js storefront, standard payment and shipping integration, and a custom checkout flow: $35,000–$65,000.
Adding multi-region support to that build increases cost depending on the scope:
- Multi-currency only (2–3 currencies, single operations): Add $5,000–$10,000 — mostly frontend work (currency switcher, price display) and pricing configuration
- 2–3 full regions with separate tax configurations: Add $10,000–$20,000 — tax provider integration, region-specific checkout logic, testing across regions
- 5+ regions with separate fulfillment per geography: Add $25,000–$50,000 — multiple fulfillment integrations, routing logic, storefront localization (translated content, region-specific landing pages)
The full-scale build — 5+ regions, separate fulfillment, localized storefront, tax compliance per market — runs $80,000–$150,000 depending on the number of integrations and the complexity of the pricing rules.
That sounds like a lot. But compare it to building the same capability on Shopify Plus. Shopify Markets handles multi-currency and some localization, but the tax automation is limited, the fulfillment routing is not natively region-aware, and you are still paying $27,600/year in platform fees plus transaction fees. For a business doing $5M GMV across multiple regions, the Medusa build pays for itself in 2–3 years — while giving you full ownership of the platform.
For a broader look at what headless commerce actually costs against traditional ecommerce alternatives, see our post on headless ecommerce vs traditional.
Language and Storefront Localization
Multi-region commerce often requires localization beyond currency and tax — product descriptions in German, legal pages in French, customer service routing based on geography.
Medusa handles content localization through its CMS integration pattern. Product descriptions, category names, and checkout copy are typically managed through a headless CMS (Contentful, Sanity, Storyblok) with translations per locale, rather than stored directly in Medusa. The storefront fetches the appropriate locale content based on the customer’s region or browser language preference.
This separation of concerns is architecturally clean. Commerce data (prices, inventory, orders) lives in Medusa. Content data (descriptions, marketing copy, legal pages) lives in the CMS. Translation management sits in the CMS, where content teams can work without requiring developer involvement.
Building this CMS integration into a multi-region Medusa storefront adds $8,000–$20,000 to the build cost depending on the number of locales and the complexity of the content model.
When You Actually Need Multi-Region
The honest answer is that most businesses do not need full multi-region configuration until they are consistently generating meaningful GMV from multiple international markets.
You do not need multi-region if: You ship globally from one warehouse, you do not charge VAT, and you are happy to show USD prices to international customers. A single-region Medusa store with multi-currency pricing handles this cleanly.
You need multi-region if: You have EU customers and need to handle VAT correctly. You have a separate EU warehouse and want to route fulfillment by geography. You need to offer different payment methods (Klarna, iDEAL) in specific markets. You need localized pricing that is not just a currency conversion.
You definitely need multi-region if: You are operating a genuine international business with $1M+ GMV across 3+ countries and separate operational infrastructure per region.
The build cost of full multi-region setup is justified when the alternative — a patchwork of Shopify apps and manual VAT handling — is costing you more in errors, compliance risk, and operational overhead than the build itself.
Migrating an Existing Store to Multi-Region Medusa
If you are running an existing store on Shopify or WooCommerce and want to add international markets, the migration path to Medusa is:
- Export product catalog, customer data, and order history from the existing platform
- Build and configure the Medusa backend with multi-region setup
- Build the Next.js storefront with locale detection and region-specific pricing display
- Integrate payment providers per region (Stripe supports multi-currency; regional providers need separate integration)
- Configure tax providers per market
- Test checkout flows per region before going live
- Redirect existing URLs and 301 any indexed blog/product pages
This is a 16–24 week project for a mid-sized store expanding from one region to three. It is not a quick switch — but it is a one-time cost that eliminates the ongoing limitation of a platform that was not designed for international commerce.
See our posts on when to migrate from Shopify to headless and Medusa.js for growing ecommerce for more context on migration timing.
Building Multi-Region Commerce Through Designodin
We build headless commerce builds on Medusa.js as part of our WooCommerce development and custom ecommerce work. Multi-region builds are scoped based on the number of regions, the number of fulfillment integrations, and the complexity of the tax configuration.
Every build comes with documentation for the region configuration so your team can add new markets without requiring developer involvement for the configuration layer. See fixed-price packages to understand how we scope and price these projects.
Frequently Asked Questions
Does Medusa.js handle VAT for EU customers automatically? Medusa supports VAT-inclusive pricing per region and integrates with tax providers for automated rate calculation. You configure tax rules per region, and Medusa applies the correct calculation at checkout. It does not handle VAT registration or filing — you still need an accountant or a service like Avalara or TaxJar for compliance reporting.
Can Medusa serve different currencies without separate regions? Yes. Medusa’s pricing module supports multiple price entries per product per currency. You can show EUR prices to European customers and USD prices to US customers from a single-region setup, as long as you do not need separate tax rules, fulfillment routing, or payment providers per geography.
How does Medusa handle exchange rates for multi-currency? Medusa does not automatically update prices based on live exchange rates. Prices per currency are set explicitly in the Medusa admin — you decide what a product costs in each currency. This gives you control over pricing strategy but requires manual updates when you want to adjust for currency fluctuations.
How many regions can a Medusa store support? There is no hard limit. The data model supports as many regions as you configure. Practical limits are operational: each region requires configuration (tax rules, payment providers, fulfillment setup), and the more regions you have, the more surface area to maintain. Most mid-market stores operate 2–6 regions.
What is the difference between Medusa regions and Shopify Markets? Shopify Markets handles multi-currency display and some localization within Shopify Plus. Medusa’s region model is more granular — separate payment providers, fulfillment rules, and tax configurations per region, all API-accessible and fully customizable. Shopify Markets works within Shopify’s constraints; Medusa’s region model is a blank canvas.
Does multi-region require a separate storefront per region? No. One Next.js storefront can handle all regions by passing the region context to the Medusa API. The storefront detects the customer’s location (via IP geolocation, browser language, or explicit user selection) and uses that to set the region context for all API calls. Separate storefront deployments per region are possible but not necessary.
Can I add regions to an existing Medusa store? Yes. Adding a region to an existing Medusa installation is a configuration task — no code changes required for standard use cases. You configure the new region in the Medusa admin, assign payment providers and shipping options, set prices for products in the new currency, and configure the storefront to detect and display the new region. Complex cases (new fulfillment integrations, custom tax logic) require development work.