Magento Multi-Store: 12 questions answered.

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.)

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.

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.

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.

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.

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.

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.

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.

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.

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.