B2B Catalog Split Across Websites with Shared Customer Accounts

Tier prices in Commerce are stored globally per product/price scope, not per website by default; the customer group is the usual isolation lever. If the wholesale buyer's account is in a group that has tier prices, and the retail website does not scope customer groups or restrict group-to-website assignment, the tier price will surface anywhere that customer shops.

Verification steps:

1. Confirm the customer's group_id and whether customer_group has tax_class/website scoping. Check customer_group_excluded_website (or equivalent assignment) - if the group is not excluded from the retail website, it is eligible there.
2. Inspect the quote/cart item price source in quote_item - is the price coming from tier price (tier_price index) or a catalog rule? Check catalogrule_product_price for that product/website/group.
3. Reproduce with a controlled account in each group on each website and log the price resolver path.

Root cause is typically that the shared account pool lets a wholesale-group customer authenticate on retail without group scoping. The fix direction: scope customer groups to websites (exclude wholesale group from retail), or use website-scoped price attributes with a price resolver, not global tier prices. Confirm which lever before changing data.

Three levers, each with tradeoffs:

• Website-scoped price attribute (custom attribute with scope=website): price varies by website, resolved at index time into a per-website price index. Clean isolation, but you must build a price indexer and a price resolver plugin, and every price consumer (cart, quote, catalog, API) must honor it. High build cost, high correctness.
• Customer-group scoping: keep base price global, use tier prices and group-website exclusion. Lower build cost, uses native machinery, but tier prices are global per product and group - isolation depends entirely on correct group-to-website assignment. Fragile if accounts move groups.
• Separate websites with distinct base price scopes: heaviest; effectively per-website catalogs. Maximizes isolation but multiplies index work.

Recommendation: website-scoped price attribute + price resolver for the base price, with customer-group exclusion as a defense-in-depth guard. Rationale: the requirement is strict price isolation across websites with shared accounts; group scoping alone cannot guarantee it because a misassigned group leaks prices. The attribute approach makes the website the source of truth. Pair it with automated tests asserting no cross-website price bleed.

Runtime scales roughly linearly with website count because price and catalog rule indexers iterate per website/group. Options:

1. Move to partial/on-demand indexing (Update by Schedule with mview) so only changed products reindex, instead of full rebuilds. This is the highest-leverage change.
2. Shard indexers by website across consumers/workers so websites index in parallel rather than serially.
3. Reduce index surface: don't index retail-only attributes for wholesale websites; scope attribute sets per website where possible.

Recommendation: switch price/catalogrule indexers to schedule mode with mview, and run per-website indexer processes in parallel via separate cron groups or message queue consumers.

Biggest risk: mview changelog bloat and version drift - if the changelog table grows unbounded or consumers fall behind, you get stale prices (the exact isolation failure you're trying to prevent). Mitigate with changelog cleanup, monitoring on mview_state version lag, and a nightly reconciliation full index as a safety net.