Shopify Markets vs Multi-Store vs Custom i18n: Architecting Global Headless Commerce (2026)
Going global on Shopify Plus is not one decision, it is a fork with three branches. You can run every market from a single store with Shopify Markets, stand up a separate store per region, or build a custom internationalization layer that treats Shopify as one of several backends. Each puts currency, tax, inventory, and catalog truth in a different place, and each fails differently as you add markets. We compare the three on where truth lives, what the integration costs, and the migration path when you outgrow the option you started with.
Shopify Markets vs Multi-Store vs Custom i18n: Architecting Global Headless Commerce (2026)
The first international order looks trivial. Someone in another country buys, you ship, everyone is happy. The second market is where the architecture decision arrives, because now you have two currencies, two tax regimes, possibly two catalogs and price lists, and a question you cannot defer: where does the truth about all of that live. On a headless Shopify Plus stack there are three answers, and choosing among them is one of the highest leverage calls in the build. Get it right and adding a market is a configuration change. Get it wrong and every new country is a migration.
The three options are Shopify Markets running every region from a single store, a multi-store model with a separate Shopify store per region, and a custom internationalization layer where your own services own currency, catalog, and routing and treat Shopify as a fulfillment and checkout backend. They are not just different amounts of work. They put the source of truth in different systems, which changes how tax is calculated, how inventory is shared, and how much of the logic sits in Shopify versus in your code.
The Core Question: Where Truth Lives
Every internationalization decision reduces to who owns the answer to four questions: what price does this customer see, in what currency; what tax applies; what inventory is available to them; and what catalog and content do they get. The three models answer those from different places.
| Concern | Shopify Markets (single store) | Multi-store (store per region) | Custom i18n layer |
|---|---|---|---|
| Currency and pricing | Shopify Markets price lists | Each store owns its prices | Your pricing service |
| Tax calculation | Shopify plus tax app | Per store tax config | Your tax integration |
| Inventory truth | One shared pool | Split or duplicated per store | Your inventory service or ERP |
| Catalog and content | One catalog, market overrides | Independent catalogs | Your catalog, Shopify as sink |
| Operational overhead | Lowest | Highest | Middle, front loaded |
| Ceiling before it breaks | Divergent markets | Cross store inventory | Nothing, you own it all |
Read the table top to bottom for any column and you get that model's philosophy. Markets keeps everything in one store and layers regional overrides on top. Multi-store duplicates the store and lets each one diverge freely. The custom layer pulls truth out of Shopify entirely and leaves Shopify holding checkout and fulfillment. Each is coherent. The mistake is mixing them without deciding which owns each concern.
Shopify Markets: One Store, Regional Overrides
Markets is the native answer and the right default for most brands. You keep a single store, single catalog, and single inventory pool, and you attach per market price lists, currencies, domains or subfolders, and tax and duty settings on top. For a headless storefront you read the buyer context through the Storefront API, which exposes the market and its currency and pricing, and your front end renders the right prices without you maintaining parallel catalogs.
The strength is that shared truth stays shared. Inventory is one pool, so you are never reconciling stock across stores. A product edit happens once. Adding a market is largely configuration rather than engineering. For a brand selling substantially the same catalog into several countries with regional pricing and tax, that is exactly the shape you want, and it keeps your operational overhead close to that of a single market store.
The ceiling is divergence. Markets assumes markets are variations on one store. When a region needs a genuinely different catalog, different products, different bundling, a different merchandising structure, or workflows that the override model cannot express, you start fighting the tool. The signal that you are approaching the ceiling is a growing pile of conditional logic in the storefront that special cases one region, and metafields bent to store per market data the platform did not intend. If most of your complexity is pricing, currency, tax, and language, Markets holds. If it is structural divergence between regions, it strains.
Multi-Store: A Store Per Region
The multi-store model gives each region its own Shopify store. Regions diverge freely because they share nothing by default: independent catalogs, independent pricing, independent apps, independent tax setup. For a business whose markets are genuinely different operations, distinct assortments, distinct suppliers, distinct compliance regimes, that isolation is a feature, and it is often the honest reflection of how the business actually runs.
The cost is that everything shared becomes a synchronization problem. Inventory is the sharp edge. If two stores sell from the same warehouse, you now need a system that reconciles stock across stores in near real time or you oversell, and that system is usually an order management layer or the ERP sitting behind both stores rather than Shopify itself. The same duplication hits catalog changes, customer accounts, and reporting, each of which now spans stores and needs consolidation. The operational overhead is the highest of the three, and it grows with the number of stores. This is the model where the ERP of record decision matters most, which we worked through in the NetSuite versus Acumatica analysis, because that system becomes the thing holding the stores together.
Multi-store is the right call when regions are truly separate businesses that happen to share a brand. It is the wrong call when they are one business selling one catalog in several currencies, because then you have paid for isolation you did not need and inherited a reconciliation burden you did not have to carry.
Custom i18n Layer: Shopify as a Backend
The third model inverts the relationship. Your own services own pricing, catalog, currency, and buyer routing, and Shopify becomes a checkout and fulfillment engine that you call rather than the system of record. The storefront reads from your catalog and pricing services, and only hands off to Shopify at the point of checkout and order creation. This is the most flexible option and the one with no ceiling, because anything Shopify will not model, you model yourself.
It is also the most expensive to build and own, and the flexibility is a liability as often as an asset. You are now responsible for tax correctness, which means owning an integration with a dedicated tax engine rather than leaning on Shopify's, a decision we compared in the Stripe Tax versus Avalara versus TaxJar analysis. You own currency conversion, catalog consistency, and the correctness of the handoff to Shopify at checkout, where a mismatch between the price your service quoted and the price Shopify charges is a real and painful class of bug. The overhead is front loaded into the build and then ongoing, and you carry it forever.
This model earns its keep only when the business genuinely exceeds what Markets and multi-store can express: many markets with structurally different catalogs and pricing logic, a commerce backend that must serve channels beyond Shopify, or scale where the platform's native internationalization becomes a constraint rather than a convenience. For most brands it is more architecture than the problem needs. The same build or buy tension shows up in wholesale, which we covered in the B2B platform comparison.
A Decision Rule
Start with Markets unless you have a concrete reason not to. It shares truth by default, keeps overhead low, and covers the common case of one catalog sold in several currencies with regional tax. Move to multi-store when regions are separate operations with distinct assortments and you can afford the inventory reconciliation, usually via the ERP. Reach for a custom layer only when both native options provably cannot express your catalog or when Shopify is one channel among several rather than the store itself. The expensive mistake is starting with the custom layer because it feels more capable, then discovering you rebuilt currency, tax, and catalog features that Markets would have given you for free.
When This Applies to Your Stack
The trap in global commerce is choosing the most flexible option before you know you need it. Flexibility you do not use is just cost and surface area for bugs, and the custom layer in particular is a large ongoing liability that most brands adopt too early. Match the model to how the business actually operates: shared catalog and shared inventory point at Markets, genuinely separate regional operations point at multi-store, and only a real ceiling on both points at a custom layer.
If your team is planning international expansion on Shopify Plus and wants the truth boundaries drawn before the code is written, Contra Collective architects and implements headless commerce and platform migrations that put currency, tax, inventory, and catalog in the right systems from the start. The cheapest market to add is the second one, while the architecture is still a choice rather than a rewrite.
FAQ
Should I use Shopify Markets or separate stores for international selling? Use Shopify Markets when you sell substantially the same catalog into multiple countries with regional pricing, currency, and tax, because it keeps one shared inventory pool and one catalog. Use separate stores when regions are genuinely different operations with distinct assortments, suppliers, or compliance, and you can afford to reconcile inventory across stores, usually through an ERP.
Where does inventory truth live in a multi-region headless setup? It depends on the model. Shopify Markets keeps one shared inventory pool in the single store. A multi-store setup splits inventory per store and needs an order management system or ERP to reconcile shared stock and prevent overselling. A custom internationalization layer moves inventory truth into your own service or the ERP entirely.
When is a custom internationalization layer worth building? Only when Shopify Markets and multi-store provably cannot express your requirements: structurally different catalogs per region, pricing logic the platform cannot model, or a commerce backend that must serve channels beyond Shopify. It has no functional ceiling but the highest build and ownership cost, so adopting it before you hit that wall usually means rebuilding features Markets provides natively.
How is tax handled across the three models? Shopify Markets uses Shopify's tax settings plus a tax app per market. Multi-store configures tax independently in each store. A custom layer makes you responsible for tax correctness through a dedicated tax engine integration. The more truth you pull out of Shopify, the more of tax compliance you own directly.
Can I start with Markets and move to multi-store later? Yes, and that is often the right sequence. Starting on Markets keeps early overhead low, and you migrate a region to its own store when it outgrows the override model. The migration is real work, mostly around splitting inventory and catalog, but starting simple and moving up is cheaper than starting on a custom layer you did not yet need.
More from the lab.
Segment vs RudderStack vs mParticle: Customer Data Platform for Headless Commerce (2026)
A customer data platform is the least visible and most load-bearing piece of a headless commerce stack. It is the layer that captures every event from the storefront, the mobile app, and the backend, resolves those events into a single view of the customer, and fans them out to analytics, email, ads, and the warehouse. Because it sits in the middle of everything, the CDP choice quietly decides three things that are expensive to change later: whether you own your customer data or rent access to it, how much of your compliance and consent surface lives inside a vendor versus your own infrastructure, and how your bill scales as event volume grows, which in commerce it always does. Segment, RudderStack, and mParticle are the three platforms most enterprise commerce teams shortlist, and they embody genuinely different philosophies rather than being feature-for-feature clones. Segment is the managed incumbent optimized for time to value. RudderStack is the warehouse-first, self-hostable challenger built for teams that want to own the pipeline. mParticle is the mobile-heavy enterprise option with the deepest identity and audience tooling. For a headless architecture, where the storefront is decoupled and events originate from several surfaces at once, the differences in how each handles server-side collection, identity resolution, and pricing at volume are what separate a clean integration from a costly one. This post lays out those differences and the decision framework that follows from them.
Multi Currency and Cross Border Pricing in Headless Commerce: Duties, Rounding, and the Presentment Problem (2026)
Selling internationally on a packaged storefront is mostly a settings screen: turn on the currencies, let the platform convert, and the theme shows the right number. Go headless and the convenience disappears, because now your own frontend is responsible for asking the API for a price in the customer's currency, displaying it with the correct rounding, carrying that currency all the way through the cart and into checkout, and reconciling what the customer paid against what the store settles in. Each of those steps has a way to go wrong that a themed store never exposed you to, and the most common one is subtle: the storefront requests a presentment currency and the API quietly returns the amount in the store's base currency anyway, so the customer sees a euro sign in front of a dollar number. Add duties and import taxes on a cross border order and the surface expands again, because now the total the customer sees at checkout has to include or exclude a duty depending on whether you sell delivered duty paid or delivered duty unpaid, and getting that wrong means either a surprised customer or a margin you did not plan to give away. This post is about the architecture that keeps a headless international store honest: which system owns the converted price, how presentment currency actually flows through the Storefront API, why rounding is a real rule and not a rounding error, and how duties change the checkout total.
Migrating from Salesforce Commerce Cloud to Headless Shopify Plus: A Replatforming Playbook (2026)
The decision to leave Salesforce Commerce Cloud is usually made on cost and velocity, and by the time it reaches engineering it has hardened into a deadline. That is where replatforming projects go wrong, because moving from SFCC to a headless Shopify Plus stack is not a migration in the copy the data and flip the switch sense; it is a rebuild of the parts of your commerce logic that lived inside SFCC cartridges and pipelines, wrapped around a data migration that is the easy part by comparison. SFCC gave you a monolith where the storefront, the business logic, and the platform were fused, and headless Shopify Plus deliberately unfuses them: Shopify becomes the commerce engine behind an API, and the storefront becomes your own application. Everything that made SFCC feel complete, the cartridge ecosystem, the pipeline customizations, the server side rendering baked in, becomes something you now own explicitly. This playbook walks the migration in the order that actually de-risks it: what maps cleanly from the SFCC data model to Shopify, what has to be rebuilt rather than ported, how to protect the SEO equity that a careless cutover destroys, and the sequencing that lets you move without a big bang launch. The projects that fail treat this as a data problem. The ones that succeed treat it as a rebuild with a data migration attached.