Guides

A store per country: usually Markets, sometimes yes

Selling into more countries rarely needs more stores — Markets handles currencies, domains and pricing from one. When separate country stores genuinely win.

“We are launching in Germany — do we open a German store?” is a question whose default answer changed a few years ago and whose folklore has not caught up. The honest modern sequence: exhaust Shopify Markets inside one store first, open country stores only for structural reasons — and if you do, let the warehouses, not the storefronts, dictate the inventory architecture. This guide runs that sequence.

What one store now does internationally

Shopify Markets, from a single store: local currencies with automatic or fixed conversion, country domains or subfolders (example.de, or example.com/de), per-market pricing adjustments, translations via translation apps, duties and import tax estimates at checkout, and local payment method availability through Shopify Payments.

The under-priced benefit is the one this site cares about: one store cannot disagree with itself about stock. Every country storefront of a Markets setup reads the same inventory records. There is no sync because there is nothing to sync — which, given what sync failure costs, is the strongest argument on the board.

The reasons a country store still wins

Consistent with the general second-store test, the survivors are structural:

• A separate legal entity in-country — its own VAT registration, payment processing, and books that must not blend.
• A materially different catalogue — not the same products translated, but a different range for a different market.
• A local team running a local operation — merchandising, support and fulfilment owned in-country, where sharing one admin creates more friction than two stores do.
• Regulatory or brand separation that a market inside a shared store cannot express.

“We want a .de domain and euro prices” is not on the list — Markets does both. On Plus, the same fork is framed as expansion stores, and the same test applies.

If yes: the warehouse decides the inventory model

Two country stores, and now the only question that matters for stock: how many physical pools are there?

One global warehouse → mirror

Both stores sell from one shelf in one country. This is the standard hub-and-spoke mirroring problem: the store nearest the operation (usually the original) is the source of truth, the country store follows it one-way, and the rules about restocks, continue-selling and checking the counts still agree apply unchanged. Same SKUs in both catalogues, different languages and prices on top — which is exactly the split between what should sync and what should diverge.

A warehouse per region → do not mirror

The US store ships from New Jersey, the EU store from Rotterdam. These are different pools, and mirroring one store’s total into the other would advertise stock that cannot reach that customer. Here each store honestly tracks its own warehouse, and the inventory relationship between them is transfers — purchase-order-style movements of physical stock from pool to pool, recorded on both sides — not sync. If you were reaching for a sync app for this topology, the right answer is not a better sync app; it is recognising there is nothing to sync.

Mixed → mirror the shared part only

A global warehouse for most SKUs, local stock for a few: sync matches on SKU, so the mirrored set is simply the overlap. The locally-held SKUs stay out of the sync — deliberately unmatched, which is fine as long as the unmatched list is something you read rather than ignore.

Where StockUnison sits

StockUnison fits the single-pool and mixed cases: one main store mirrored one-way into country stores, matched by SKU so a partial overlap syncs exactly the shared range, with prices and translations untouched because it syncs quantities only. Preview mode and the list of matched products — both on the free plan — are the tools for verifying which of your SKUs actually overlap before anything writes.

It is the wrong tool for the warehouse-per-region topology, and this page is the reasoning: that setup needs transfers between pools, not a mirror, and a sync app sold into it would be manufacturing overselling. If that is your shape, run each store’s stock independently and put the effort into disciplined transfers instead.