Adobe Commerce B2B prices wholesale buyers through two connected features: shared catalogs control which SKUs a company sees, and tier pricing sets quantity-based price breaks per customer group. Each shared catalog creates its own customer group, so a logged-in buyer sees only their assigned products at their negotiated prices.
That two-part model is what lets a distributor run different price lists for different buyers without maintaining duplicate catalogs. Below is how the pieces fit, how to load prices at scale, and how a Hyva storefront renders tiered pricing without slowing down.
The Two Mechanisms, and How They Relate
Wholesale pricing in Adobe Commerce is not one setting. It is the interaction of a visibility control and a pricing control, and understanding the split prevents most configuration mistakes.
A shared catalog is a curated subset of your catalog with its own pricing structure, assigned to one or more company accounts. When you create a shared catalog, Adobe Commerce creates a dedicated customer group and ties it to that catalog. A buyer belonging to that company logs in, lands in that customer group, and sees the products and prices you assigned, not the public catalog. Adobe’s shared catalog module reference documents how the catalog, its customer group, and permissions are wired together under the hood.
Magento Open Source has tier pricing and customer groups, so basic group-based pricing is possible there. Shared catalogs, company accounts, and the wider B2B toolset are exclusive to Adobe Commerce, which is why most operations running real wholesale price lists sit on Adobe Commerce rather than Open Source.
Tier pricing sets the actual numbers. It applies quantity-based price breaks that can be restricted by website and by customer group or shared catalog. Because each shared catalog owns a customer group, tier pricing is the lever that gives each catalog its own price list.
The public catalog is the default every shopper sees. Custom shared catalogs sit on top for companies you price individually. This structure maps directly onto how Adobe Commerce models B2B customer hierarchies for distributors, where a parent company and its sub-accounts can share a catalog and its pricing.
How Tier Pricing Actually Behaves
Tier pricing rewards larger quantities, and the precedence rule is specific. Per Adobe’s documentation on tier pricing, if you set a tier for quantity 5 and another for quantity 10, a buyer adding 5 to 9 units gets the tier-5 price, and adding a 10th unit switches the whole line to the tier-10 price. Higher tiers override lower ones as the cart quantity climbs.
Each tier can be defined two ways:
- Fixed price, where you set the exact per-unit amount at that quantity.
- Percentage discount, where you enter a percentage off the base price. Entering 15 gives a 15 percent discount, calculated from the base price rather than any special price.
Tiers are also scoped. You choose the website the tier applies to, and you limit availability by selecting a customer group or shared catalog. That scoping is what lets the same SKU carry one price ladder for Distributor A and a different one for Distributor B.
| Pricing concept | What it controls | Scope |
|---|---|---|
| Shared catalog | Which SKUs a company sees, and the catalog-level price structure | Assigned to company accounts; creates a customer group |
| Customer group | The bucket a logged-in buyer falls into | One per shared catalog, plus your general groups |
| Tier price (fixed) | Exact per-unit price at a quantity break | Website plus customer group or shared catalog |
| Tier price (percentage) | Percent off base price at a quantity break | Website plus customer group or shared catalog |
| Catalog price rule | Broad discounts across many products | Customer groups and date ranges |
Loading Prices at Scale
A wholesale catalog is not ten products. It is thousands of SKUs across several price lists, and no team should enter those by hand. Adobe’s own guidance is direct: it is more efficient to import tier price changes than to enter them individually.
The practical pattern for a real B2B operation looks like this:
- Model the price lists first. Decide how many distinct pricing structures you actually have. Ten negotiated accounts might collapse into three tiers plus a handful of exceptions.
- Map SKUs to shared catalogs. Each catalog gets its SKU subset and its customer group.
- Import advanced pricing. Use the Advanced Pricing import to load tier prices in bulk against the right customer groups, and re-import when contracts change.
- Automate from the ERP where possible. If price lists live in an ERP, schedule the export so Adobe Commerce prices track the source of truth rather than drifting from it. This is where wholesale pricing overlaps with B2B ordering portals and customer-specific pricing, which depend on the same price data being accurate at login.
The bulk import is not a one-time task. Contract renewals, cost changes, and promotions all flow through the same pipeline, so treat pricing import as an operational process with an owner, not a launch step.
It also helps to separate the two kinds of discount you will run. Tier pricing handles the standing, quantity-based price a customer group always gets. Catalog price rules handle broad, time-bound reductions across many products, such as a seasonal promotion, applied by customer group and date range. Keeping negotiated tier prices and temporary promotions in their own layers stops a promotion from quietly overwriting a contracted price, and makes it obvious which discount a buyer is actually receiving at checkout. When a buyer needs a one-off price outside these structures, that belongs in a negotiable quote, not a permanent change to the shared catalog.
Common Pricing Mistakes to Avoid
- Confusing visibility with price. A shared catalog controls what a buyer sees; tier pricing controls what they pay. Teams that expect the catalog alone to set prices end up with the public price showing to logged-in wholesale buyers.
- Too many shared catalogs. One catalog per account is unmanageable at scale. Group accounts that share a price structure into the same catalog and use exceptions sparingly.
- Manual price entry. Hand-keying tier prices guarantees drift between the ERP and the storefront. Import, and automate the import.
- Ignoring quantity break math. If tier thresholds are set carelessly, a buyer can pay more per unit at a higher quantity than a competitor pays at a lower one. Model the ladder deliberately.
- Forgetting cart and catalog caching. Wholesale prices are customer-group specific, which has real implications for how a cached storefront renders them, covered next.
Rendering Tiered Prices on a Hyva Storefront
Wholesale pricing is customer-group specific, and that collides with full page caching. The public catalog is cached and served fast to everyone, but a logged-in wholesale buyer needs to see their price, not the public one. On a Hyva storefront, this is handled the same way other personalized data is: the cached page renders the public shell, and customer-specific values, including the buyer’s tier price, load through the private, per-session data layer rather than the cached HTML.
Done well, the buyer sees their negotiated price and quantity breaks with no visible delay, and the storefront keeps the speed that Hyva theme development is chosen for. Done poorly, wholesale buyers either see the wrong price for a moment or the whole page drops out of cache and slows down. The fix is architectural, not cosmetic: keep the price display on the personalized data path and let the rest of the page stay cached.
For teams also running search and category pages, tiered and customer-group pricing needs to remain correct in those listings too, which is why a pricing project and a catalog search project should be planned together rather than in isolation.
Where This Sits in a Build
Wholesale pricing touches catalog, customer accounts, ERP integration, and the frontend at once, which is why it belongs in the hands of a team that has shipped Adobe Commerce B2B before, not just Magento development in general. The questions that expose real experience are specific: how do you handle a buyer who belongs to two companies, how do promotions stack on top of tier prices, and how do you keep prices in sync with the ERP on a schedule.
Bemeir builds Adobe Commerce and Hyva B2B storefronts and works with a broad set of technology partners across ERP, search, and payments to keep pricing accurate end to end. You can read more about Bemeir and how the team works as an extension of a merchant’s staff at bemeir.com. For merchants comparing platforms, Bemeir also delivers on Shopify and Shopify Plus, BigCommerce, and Shopware, each of which models wholesale pricing differently from Adobe Commerce.
FAQ
What is the difference between a shared catalog and tier pricing in Adobe Commerce?
A shared catalog controls which products a company sees and creates a dedicated customer group for that company. Tier pricing sets the actual quantity-based prices, scoped by website and by customer group or shared catalog. You use them together: the catalog controls visibility, and tier pricing sets what each group pays.
Can Magento Open Source do B2B wholesale pricing?
Magento Open Source supports tier pricing and customer groups, so basic quantity-based and group-based pricing is possible. Shared catalogs, company accounts, and the full B2B toolset are exclusive to Adobe Commerce, so most serious wholesale operations run on Adobe Commerce.
How do quantity price breaks work?
Higher quantity tiers override lower ones. If a product has a tier at quantity 5 and another at quantity 10, a buyer purchasing 5 to 9 units pays the tier-5 price, and reaching 10 units moves the line to the tier-10 price. Each tier can be a fixed per-unit price or a percentage off the base price.
How should we load thousands of wholesale prices?
Use the Advanced Pricing import to load tier prices in bulk against the correct customer groups, rather than entering them by hand. If your price lists live in an ERP, schedule an export so Adobe Commerce prices track the ERP automatically and do not drift as contracts change.
Will customer-specific pricing slow down a Hyva storefront?
Not if it is implemented correctly. Wholesale prices are customer-group specific, so they load through Hyva’s personalized, per-session data path while the rest of the page stays cached. The buyer sees their price quickly and the storefront keeps its speed. Problems only appear when pricing is forced into the cached HTML.
Can one buyer see different prices depending on the company they represent?
Yes. Because pricing follows the customer group tied to a shared catalog, a buyer associated with a given company sees that company’s assigned catalog and prices when logged in. Handling buyers who belong to more than one company is a specific design decision that should be settled during scoping.
