Magento Multi-Store

Use multi-store when your storefronts share most of the catalog, customer base, or admin operations — you get one upgrade, one extension stack, one hosting bill, and surgical per-store overrides where needed. Use separate installs when storefronts are run by different teams, have totally distinct catalogs, or need fundamentally different stacks (e.g. one Hyvä, one Luma headless). 90% of cases we see are multi-store wins — the maintenance and SEO consolidation alone usually justify it.

Magento has three scopes:

• Website — isolation boundary for customers, carts, orders and (by default) prices. Use one website per legal entity / region with separate carts.
• Store — root-category boundary. Use multiple stores per website when you need different catalog trees (e.g. brand A vs brand B sharing a checkout).
• Store view — locale boundary. Use one per language inside the same store (e.g. EN, FR, DE views of the EU store).

Wrong-scope configuration is the #1 source of multi-store pain. We map the hierarchy in the audit before any code is written.

Magento supports multiple currencies natively. We typically wire it up like this: (1) Allowed currencies set per website. (2) Live FX feed (ECB, OpenExchangeRates, fixer.io) with cron import every hour. (3) Per-currency rounding rules and price-display formatting per locale. (4) Optional fixed prices in customer-group + website scope to avoid FX drift on premium SKUs. Customers see only the currency for their region; admins see all currencies side-by-side in reports.

Three rules: (1) Every URL must reference every other locale variant of itself, including a self-reference. (2) Each variant must point back — bidirectional. (3) Always include x-default. We generate hreflang server-side per URL (not via JS), validate it on every deploy with Screaming Frog, and emit it on canonical URLs only. Common foot-guns we prevent: hreflang on non-canonical URLs, region-only tags without language, and hreflang loops between cross-linked storefronts.

Both. Magento has a customer account scope setting (Stores > Configuration > Customers > Account Sharing Options): set to Global for one account across all websites, or Per Website to isolate. Most multi-region setups want per-website isolation (so a UK customer can’t accidentally order at US prices), while same-language sibling stores often share globally. Switching this setting after launch is painful — we always decide it upfront in the audit.

Done right, no. The Magento application is shared in memory; each store view just changes what gets rendered. Done wrong — with bloated core_config_data, runaway URL rewrites per store, or unscoped extension queries — multi-store can be measurably slower. We size Redis + Varnish for the storefront count, scope every config to the right level, and load-test each store view separately before launch. We commit Lighthouse 90+ on every storefront, regardless of count.

Payment method config is scoped per website. We typically enable: iDEAL + Bancontact for NL/BE, Klarna + Sofort for DE/AT, BACS + Worldpay for UK, Stripe + Apple Pay + Google Pay for US/CA, Razorpay + UPI for IN, plus PayPal as a global fallback. Each website only exposes payment methods that work for its region — customers never see options that will fail at gateway.

Yes — three layers of control: (1) Catalog price scope set to Website, so each website can have its own price list. (2) Customer-group pricing for tier-based discounts (B2B, VIP, etc.). (3) Cart price rules per website for region-specific promotions. We can also import region-specific price CSVs nightly from your ERP if you have a master pricing system. Tax-inclusive (EU/UK) vs tax-exclusive (US) display is handled at the same scope.

Each regulation has different requirements — we configure them per store-view, not site-wide. GDPR (EU + UK): explicit cookie consent before any tracking, right-to-be-forgotten endpoint, data-export request flow. CCPA (California): “Do Not Sell My Personal Information” link, opt-out by default. LGPD (Brazil): explicit consent + DPO contact in footer. PIPEDA (Canada): less invasive, but still requires consent for marketing. We use scoped cookie-consent extensions that auto-detect the visitor region, and integrate with your CRM for unified data-subject-access requests.

Yes. Theme assignment is scoped per store-view, so each storefront can have its own theme, logo, colour palette, fonts, header, footer, even checkout layout. Most clients use one parent theme with per-storefront skins (cheaper to maintain, faster to build, easier to upgrade). For radically different brands — e.g. a luxury sub-brand vs a discount sub-brand on the same backend — we deploy fully separate themes with shared core blocks. Hyvä supports this pattern natively.

Yes — Adobe Commerce B2B (companies, quote workflow, requisition lists, customer-specific pricing, Net-30 / Net-60 payment terms) is scoped per website. So you can run B2C in the US, B2B in DE, and a hybrid B2B+B2C in the UK off the same backend. Each region can have its own sales reps, quote approval flow, payment terms and ERP integration. Salesforce / HubSpot / NetSuite integrations can also route per region. (Note: B2B requires Adobe Commerce, not Open Source.)

Lower than running N separate Magentos — that’s the point. (1) One upgrade applies to all storefronts. (2) One extension stack to license & maintain. (3) One hosting bill (provided you sized it for the storefront count). (4) One admin login for your ops team. The catch: set up wrong, multi-store can become an n-by-n compatibility matrix every time you change something. That’s why we audit + diagram + scope-test before any code goes live, and bake regression tests for each storefront into the deploy pipeline. 30 days post-launch + retainer covers ongoing localisation.