Adobe Commerce development
Storefront design
Performance & SEO
AI & agentic commerce
Release tracker
Magento can run a serious wholesale operation, but how much you get out of the box depends on the edition. Magento Open Source covers the basics in core: customer groups, tier (volume) pricing, minimum and maximum cart quantities by customer group, and quantity increments. Adobe Commerce adds the B2B module (a separately installed extension on cloud infrastructure and on-premises projects; check what your Adobe Commerce as a Cloud Service licence includes), which brings company accounts, shared catalogs with company-specific price lists, Quick Order by SKU, requisition lists, negotiable quotes and purchase order approvals. Anything beyond that, such as ERP-driven contract pricing, is extension or custom work on either edition.
This guide walks through the wholesale features buyers actually expect and gives you a checklist showing what is core, what needs the Adobe Commerce B2B module, and what usually needs an extension or custom build.
What makes a wholesale ecommerce platform different
A retail store sells one catalog at one price to anyone. A wholesale store sells a catalog that changes by customer: who can see which products, at what price, in what pack size, and under which payment terms. Wholesale buyers also behave differently. They know what they want, they reorder the same SKUs, they order in cases and pallets, and they often need someone else in their company to approve the purchase.
So a wholesale ecommerce platform is judged on four things:
- Price control: customer-specific or group-specific prices, volume breaks and contract pricing.
- Order rules: minimum order quantities (MOQ), case packs and quantity increments.
- Speed of ordering: SKU entry, CSV upload, saved lists and one-click reorder.
- Account structure: several buyers per company, roles, approvals and credit terms.
If you are still deciding between platforms, start with our best B2B ecommerce platform comparison and the wider B2B ecommerce guide. The rest of this post assumes Magento is on the table and focuses on how far each edition goes.
Price lists: customer groups, tier prices and shared catalogs
Magento Open Source
Price differentiation in Open Source is built on customer groups. A fresh install even ships with a group called Wholesale next to General and Retailer. You can then use:
- Tier prices (Advanced Pricing on the product): a fixed price or a percentage discount from a quantity threshold, per website and per customer group. This is how you express "10+ units at this price, 50+ at that price."
- Catalog price rules: group-wide discounts by category, brand or attribute, for example 15% off a brand for the Wholesale group.
- Customer group assignment: you approve a trade account and move it into the right group.
This works well when you have a handful of price bands. It strains when each customer has its own negotiated price list, because you end up creating one customer group per account and maintaining thousands of tier price rows.
Adobe Commerce with B2B
The B2B module adds shared catalogs. A shared catalog defines which products and categories a company can see and the custom prices it pays, and you assign companies to it. You keep one public catalog for guests and retail customers and as many custom catalogs as you have price agreements. Because the catalog controls visibility as well as price, it also handles "this distributor only sees these lines."
Contract pricing from an ERP
Many wholesalers already hold customer-specific prices in their ERP. Neither edition reads them automatically. The usual options are to sync prices into tier prices or shared catalogs on a schedule, or to call the ERP for a live price at add-to-cart time. Syncing is faster on the storefront; live pricing is always accurate but adds a dependency at the moment the buyer is waiting. Our Magento ERP integration guide covers those trade-offs in detail.
MOQ, case packs and quantity increments
Both editions include the same core inventory settings:
- Minimum Qty Allowed in Shopping Cart: set globally under Stores > Configuration > Catalog > Inventory, with different values per customer group, and overridable per product in Advanced Inventory.
- Maximum Qty Allowed in Shopping Cart: useful for allocation of scarce stock.
- Enable Qty Increments: forces multiples, so a product sold in cases of 12 can only be ordered as 12, 24, 36 and so on.
What core does not do: a minimum order value per customer group with clear messaging, MOQ that mixes SKUs ("any 24 units from this range"), or per-category minimums. Magento has a store-wide minimum order amount setting, but per-group and mixed-SKU rules are extension territory. Adobe documents the fallback order: a product's own Advanced Inventory value is used first, and the global configuration (with its customer-group values) applies only when Use Config Settings is selected. Still test the cart messaging on a staging store before you rely on it, because that is where buyers notice problems.
Quick Order, requisition lists and reorder
Wholesale buyers often arrive with a list of SKUs. In Adobe Commerce, the B2B Quick Order page lets a logged-in buyer type SKUs or product names, set quantities and add everything to the cart, or upload a CSV of SKUs and quantities. Requisition lists are saved lists of regularly ordered items that any buyer in the company can push to the cart. Open Source has neither in core; you get the standard reorder button on past orders, and an extension fills the gap.
Fast ordering is mostly a UX problem rather than a platform problem. The fields need to accept pasted lists, show stock and price per line before the buyer commits, and handle invalid SKUs without clearing the rest of the order. That is where a focused B2B storefront UX review earns its keep.
The wholesale feature checklist by edition
Use this as a scoping checklist. "Core" means configuration, not code. "Extension or custom" means you buy a Marketplace extension or build a module, and you should weigh both using our build vs buy guide.
| Wholesale requirement | Magento Open Source | Adobe Commerce (with B2B) | Notes |
|---|---|---|---|
| Group pricing and volume breaks | Core (customer groups, tier prices, catalog price rules) | Core | Fine for a few price bands |
| Company-specific price lists | Extension or custom | Core (shared catalogs) | ERP-held prices need an integration on both |
| Hide products or prices from guests | Extension | Core (shared catalogs, category permissions) | Decide early; it affects SEO and caching |
| MOQ and max qty per customer group | Core | Core | Mixed-SKU or value-based MOQ needs an extension |
| Case packs (qty increments) | Core | Core | Show the pack size on the product page and in the cart |
| Quick order by SKU and CSV upload | Extension | Core (Quick Order) | Also check search speed on partial SKUs |
| Saved order lists | Wishlist only; extension for real lists | Core (requisition lists) | Shared across buyers in the company |
| Company accounts with buyer roles | Extension or custom | Core (company accounts) | Roles control who can order, quote and approve |
| Request for quote and negotiation | Extension | Core (negotiable quotes) | Quote expiry and approval rules need agreeing up front |
| Purchase order approvals | Custom | Core (purchase order approval rules) | Approval thresholds by order value or role |
| Pay on account and credit limits | Extension or payment provider | Core (Payment on Account) | Invoicing and collections usually stay in the ERP |
| Tax-exempt trade customers | Core (customer tax classes) | Core | Exemption certificates are handled outside Magento |
| Live stock and price from ERP | Custom integration | Custom integration | Plan caching carefully; see below |
Wholesale and retail on one install, or separate?
Magento supports several websites and store views on one installation. Many merchants run a retail site and a trade site as two websites sharing one catalog, with different prices, payment methods and themes. That keeps product data in one place. The alternative, a single storefront where trade customers log in and see different prices, is simpler to maintain but makes caching and SEO harder, because guest pages and logged-in pages differ.
A rule of thumb: if trade buyers need a very different journey (SKU-first ordering, approvals, account dashboards), give them their own website. If they only need different prices, a login is usually enough. Our guide to ecommerce for manufacturers covers the same decision from a manufacturer's point of view.
Performance and caching in a wholesale store
Customer-specific pricing changes how much of the store can be cached. Magento's full page cache varies pages by customer group, so a few groups are cheap. Thousands of company-specific shared catalogs or live ERP prices mean more cache variations or more uncached requests. Before you commit to a pricing model, ask how many distinct price views exist and how often prices change. That single number shapes hosting, indexing and integration design more than any other wholesale decision.
Where to start
- List your price structures: how many price bands, how many customer-specific lists, and where prices live today.
- List your order rules: MOQ by product, group or value, pack sizes, and approval needs.
- Map each requirement against the checklist above to see whether Open Source plus extensions or Adobe Commerce with B2B is the cleaner fit.
- Prototype the ordering journey with two or three real buyers before building.
If your checklist shows a few gaps that no extension covers well, Mistri's Magento extension development service builds those pieces as maintainable modules that survive upgrades.
Sources
B2B for Adobe Commerce introduction (Adobe Experience League); Quick Order (Adobe Experience League); Catalog Inventory configuration reference (Adobe Experience League); Tier price (Adobe Experience League); Configure Inventory Management product options (Adobe Experience League); Install the Adobe Commerce B2B extension (Adobe Experience League).
