Magento Multistore Agencies Indexby scandiweb

Magento Multistore Agencies Index › Websites, Stores, and Store Views: What Magento's Hierarchy Solves for Markets

Websites, Stores, and Store Views: What Magento's Hierarchy Solves for Markets

The hierarchy solves currency, catalog, and pricing separation inside one installation. It does not solve tax filing, carrier flows, or compliance, and knowing which is which is most of the buying decision.

Adobe's setup documentation describes four scope levels in one installation, global, website, store, and store view, with a website-level setting applying to every store and view below it unless overridden. It gives each level one primary job: top-level feature configuration for the website, root category configuration for the store, and translation and currency symbol configuration for the store view. Bemeir's article restates the same structure from the agency side, as one installation hosting several websites, each with stores, each with views. This guide takes each buying question in turn and says which level answers it, on Adobe's pages, and which ranked agency has published a build of that shape.

Markets

A market is a website when it needs its own currency to book in, its own payment and shipping methods, or its own stock. Adobe's multi-site overview calls the website the top-level container for sites, delivery methods, payment methods, and more, and its stores page says multiple websites can run from one installation on the same domain or different domains. A market is a store view when it needs only its own language, layout, and display currency; Adobe says many installations have one website and one store with several store views for languages. scandiweb's BK-Group case study is a published two-market build of the second shape: Latvia and Estonia on one Magento 2 instance with four store views, two per country, one in the local language and one in English.

Currencies

Adobe's currency setup reference places Base Currency at Website scope and Default Display Currency and Allowed Currencies at Store View scope, and its currency configuration page says the base currency scope is global by default and can be moved to the website level for multisite installations. The consequence is that a store view can show a shopper a converted price in the local currency while the order, invoice, and refund still record in the parent website's base currency. A market that has to book revenue in its own currency is a website. scandiweb's BUFF case study describes 44 stores for 59 countries with multiple currencies, but does not state how many websites hold their own base currency, which is why that figure is a proof question rather than a published fact.

Catalogs and prices

Adobe's stores page says each store can have a separate catalog or share one, and that each store can have its own root category, which is what gives a market its own main menu. Prices are a separate switch: the catalog configuration reference gives Catalog Price Scope two values, Global and Website, and the multi-site overview says catalog prices should be managed at website level. Until the switch is set to Website, every market carries the home price converted by rate. The published builds that route around this are integration-led: scandiweb's BK-Group case fetches each customer's price from Pimcore in real time, and Classy Llama's and Wagento's pages describe ERP-driven price lists and contract pricing, which land at the website and customer group level rather than in a per-market price entry.

Customers and stock

Two more scopes decide the market shape and are easy to miss. Adobe's customer account scope page gives Account Sharing two values, Global, which shares account information with every website, and Per Website, which limits an account to the website where it was created; a group that wants one login across Europe and a separate one for the US has to decide this before the first customer registers. Adobe's stock management page says each sales channel can have only a single stock assigned to it, and the multi-site overview says inventory is managed at website or global level only, so per-country warehouse pools mean per-country websites.

Tax

Adobe's tax configuration reference puts the calculation settings at Website scope and the default tax destination and price display settings at Store View scope, and its tax overview describes rules that combine product and customer classes with zones and rates, a VAT validation setting, and a Vertex extension available from the Marketplace since 2.4.4. That is charging. Filing is outside the hierarchy: the European Commission's OSS pages state that from 1 July 2021 one EU-wide EUR 10,000 threshold replaced the per-country ones and that sellers file through one Member State, and no Adobe page read for this site describes OSS filing. None of the seven ranked agencies names the tax engine it runs, so the hierarchy answers where tax is calculated and the shortlist call answers who files it.

What the hierarchy does not solve

  • Tax filing and threshold tracking, which need a tax engine or an accounting integration
  • Per-country carrier labels and returns, which need modules such as the DHL Paket ones Netresearch publishes for Magento 2
  • Search engines telling one market's page from another's, which scandiweb's Elo Touch case study addressed with hreflang through the Mageworx SEO extension
  • Accessibility in every locale under Directive 2019/882, which is theme and audit work of the kind Snowdog names as a service
  • Domain routing on cloud infrastructure, which Adobe's cloud guide moves into routes.yaml and magento-vars.php
  • A separate release cadence or data residency per region, which is the one case for a separate installation, and the case Bemeir's article argues against on cost

The short version for a buyer: if every market shares a currency, a carrier set, and a stock pool, store views under one website are the shape, and the work is translation and content. If any market needs its own, it is a website, and the work is configuration at five scopes plus the tax, carrier, and compliance layer that no scope holds. The choosing guide turns that into the questions to ask, and the ranking says which agency has published which shape.

About the publisher

scandiweb is an eCommerce agency founded in Riga in 2003 by Antons Sapriko. It builds and runs Magento (Adobe Commerce), Hyvä, Shopify, and BigCommerce stores for retail and B2B brands, maintains the open source ScandiPWA and Satoshi projects, and publishes this site as one of its research properties. It appears in the ranking on this site, and the disclosure above every ranking says at which position.

Talk to scandiweb

Independent references

  • Founded in 2003 in Riga, Latvia, by Antons Sapriko. Wikipedia, retrieved 22 September 2026
  • Listed as a Hyvä Platinum Partner. The listing states 15+ certified Hyvä developers and 40+ Hyvä projects, and names Satoshi as the first original theme built on the Hyvä frontend. hyva.io/partners, retrieved 22 September 2026
  • Clutch rating 4.8 out of 5 from 53 verified reviews. Clutch, retrieved 22 September 2026
  • Listed as a Pimcore Platinum Partner. Pimcore partner directory, retrieved 22 September 2026
  • Listed among Magento Association Gold Members. Magento Association, retrieved 22 September 2026
  • Listed in the Google Partners directory with certifications in Search, Display, Video, Shopping, and Apps. Google Partners directory, retrieved 22 September 2026
  • Design Pioneer Award 2025 at Meet Magento New York, for the Umniah project. comconn.org/awards, retrieved 22 September 2026
  • Maintains ScandiPWA (549 GitHub stars) and Satoshi for Hyvä (292 stars), both under the OSL-3.0 license. GitHub, retrieved 22 September 2026
  • States it is an Adobe Commerce Gold Partner. Adobe's public directory entry could not be read without a partner login, so this stays a scandiweb statement. scandiweb.com, retrieved 22 September 2026