Multi-Store View Pricing for a Regional Launch
A B2C electronics brand sells in the US and is launching in Canada and the EU in 60 days. Today the site is one website, one store, one store view, all prices in USD, with a single base currency. The business wants CAD pricing for Canada and EUR pricing for the EU, with localized tax display (Canadian GST/HST shown at checkout, EU VAT shown inclusive in catalog prices). Marketing wants to run region-specific promotions and wants EU customers to see EU-only product variants. The catalog is shared across regions. The finance team requires that all orders roll up to a single reporting currency. The engineering team is small and wants to avoid duplicating the catalog. The launch date is fixed and there is no budget for a second Adobe Commerce instance.
1. Recommend the website / store / store-view structure and the currency and tax configuration, and justify each choice against the constraints.
Read the worked answer
The scope hierarchy is the lever here, and the constraints point to a specific shape.
Structure: three websites, one store view each (or one store per website). A website is the level that owns base currency, price scope, and customer/order scope. Because Canada and the EU need different base currencies and different tax regimes, they must be separate websites - a single website cannot carry two base currencies. Keeping the US as its own website isolates it from the change.
Catalog: keep it shared. A shared catalog across websites avoids duplicating SKUs, which satisfies the small-engineering-team constraint. Price scope is set to website, so each website can carry its own price per SKU without duplicating the product. This is the key exam point: price scope is a global config, and setting it to website is what lets one catalog serve three currencies.
Currency: each website has its own base currency (USD, CAD, EUR) and its own allowed display currencies. Finance's single reporting currency is handled at the reporting layer (or via a base-currency conversion in exports), not by forcing one base currency on all websites - forcing a single base currency would break the localized price display the business asked for.
Tax: configure tax classes and rates per website. For the EU, set catalog prices to be entered including tax so the displayed price is the VAT-inclusive price; for Canada, display exclusive and add GST/HST at checkout. These are per-store-view display settings, which is why each region gets its own store view even though it shares a website with nothing else.
Promotions and EU-only variants: cart price rules can be scoped to a website, so region-specific promotions are native. EU-only variants are handled with a shared catalog plus website assignment on the products, or a category/attribute filter - not a duplicate catalog.
2. Sixty days out, what is the single biggest schedule risk in this plan, and how would you de-risk it?
Read the worked answer
The biggest risk is price scope. Changing price scope from global to website is effectively a one-way configuration change: once prices are scoped per website, existing global prices must be migrated into per-website values, and reverting is painful. If this is discovered late, the launch slips.
De-risk by sequencing it first:
- Change price scope to website in a staging copy now, before any product data is loaded for the new regions, and run a full reindex to confirm timing is acceptable.
- Export current USD prices and load them as the US website's scoped prices so the US is unchanged.
- Only then load CAD and EUR prices for the new websites.
Secondary risks worth naming: tax display settings are per store view and easy to get wrong (EU inclusive vs. Canada exclusive), and the indexer load grows with three websites - validate reindex time in staging against the 60-day window. The launch date is fixed, so the scope change must be the first thing on the critical path, not the last.