---
title: "WooCommerce B2B: How to Set Up a Wholesale Store"
source: https://refact.co/insights/ecommerce/woocommerce-b2b-store-setup
author: "Masoud Golchin"
date: "2026-09-24"
---

# WooCommerce B2B: How to Set Up a Wholesale Store

It often starts with one email. A buyer asks for a CSV price list, Net 30 terms, and somewhere to enter a PO number at checkout. The request looks small. It shows that your store was built for retail, where anyone can sign up, pay by card, and see one price per product. A **WooCommerce B2B** store works on a different model. Buyers need approval, negotiated prices, company accounts, and payment terms that fit how their purchasing team works.

These requests are becoming normal. McKinsey’s 2024 B2B Pulse survey found that 71% of B2B organizations now offer some form of ecommerce. A Sapio Research buyer study found that 74% of buyers would switch suppliers for a better web store. This guide is for merchants, operators, and technical leads deciding how to set up WooCommerce for wholesale. It covers what core WooCommerce does, what it leaves to you, and where these projects usually go wrong.

WooCommerce can run serious B2B commerce. It does that as one part of a larger system, though, and a wholesale plugin with a few settings changed is not that system. Showing a wholesale price is the easy part. The hard part is keeping customer-specific prices, stock, orders, tax, and accounting consistent across systems, and keeping them consistent through every update after launch.

## What Core WooCommerce Gives You, and What It Leaves Out

Core WooCommerce gives you products, orders, customer accounts, and basic tax settings. For B2B, that’s about it. Role-based and customer-specific pricing, account approval, quotes, minimum order rules, company accounts, and trade payment workflows all come from extensions or custom code. Simple percentage discounts for a wholesale role are easy. Contract pricing with overlapping rules is not.

The deeper gap is structural. B2B selling runs on organizations, and a user role can’t represent one. A real trade customer is a company with several buyers, an approver, a credit limit, shared order history, and maybe its own catalog. WordPress roles can’t show who belongs to which company or who can approve an order. So buyers end up seeing too much or too little. That is why practitioners who like B2BKing tend to mention sub-users first: one master account, with separate logins for staff or locations.

WooCommerce’s official B2B marketplace listings show the gap clearly. The feature lists cover company accounts, credit limits, MOQs, RFQs, and Net 15/30/60 terms. They don’t say how pricing conflicts resolve, how company and individual limits interact, or whether a quote reserves stock. A feature list is not a spec of your business rules. If you are still at the planning stage, our guide to [B2B ecommerce website design](https://refact.co/insights/ecommerce/b2b-ecommerce-website-design) covers account structure and reorder flows on any platform.

## Write Your Pricing Rules Before You Pick a Plugin

Pricing is the first thing that goes wrong. A single buyer can match a role price, a customer-specific price, a regional rule, a quantity tier, and a sale price all at once. Most plugins don’t tell you clearly which one wins. Practitioners describe the result as “pricing spaghetti”: contract terms turned into coupon workarounds, and categories created only to trigger discounts. One physiotherapy supplier with consumer, Pro, and Dealer tiers ended up adding extra categories just so its pricing rules would fire.

Write a precedence table before you evaluate any extension. It should answer these questions:

-   Does an individual customer price override a company price?
-   Does a customer price override a role price, and does a role price override a geography rule?
-   Does a contract price beat a quantity tier, or do they stack?
-   Is the minimum order value calculated before or after discounts, tax, and shipping?
-   When a quote is accepted, does the buyer pay the quoted price or the current live price?
-   Which system owns stock: WooCommerce or the ERP?

Then choose between the two main pricing models. Fixed price lists per group suit stable contracts and protect margins, but someone has to maintain them. Percentage or tiered rules suit catalogs that change often. They can also wipe out the margin on low-margin products, because 30% off is fine on a $200 item and a loss on a $4 consumable. For how the basic mechanics work in the admin, this walkthrough of [implementing WooCommerce wholesale pricing](https://www.thedotstore.com/how-to-implement-wholesale-pricing-in-woocommerce/) covers tiered discounts and plugin options. Use it once your rules are written down, not in place of writing them.

Minimums need the same care. A product MOQ, a cart minimum, case-pack multiples, pallet multiples, and a minimum spend are five different rules. Extensions can enforce them globally or by category, product, or role. You still have to say which ones apply, and in what order.

![WooCommerce B2B wholesale pricing settings for different user roles in the admin](https://cdn.refact.co/uploads/2026/09/image_placeholder_1-68.avif)

Defining role-based rates is straightforward, but configuring the underlying priority order is what ensures customer-specific discounts properly override general tiered pricing. · Source: woocommerce.com

## One Plugin, a Small Stack, or Custom Code

Most WooCommerce B2B failures happen at the points where plugins meet. Each plugin works when tested alone. Put them together and they fight over the same pricing hooks, and the damage usually shows in the cart, not on the product page. The public record has plenty of examples:

-   A merchant found that Wombat, a product options plugin, and B2BKing didn’t work well together.
-   Role discounts applied to base products but not to add-ons. The support fix then made cart items revert to full price.
-   Dynamic Pricing removed wholesale prices set by Wholesale Suite.
-   Country Based Restrictions showed the wrong line-item prices at checkout while the totals stayed correct. The bug was still there in version 3.5 and fixed only in 3.6.

The last example is the one to remember. The totals were right, so a quick test passed. The buyer still saw wrong numbers on their order, and that costs you trust even when no money is lost. It also shows that plugin fixes can take several releases to arrive.

| Approach | Time to launch | Flexibility | Main risk | Fits when |
| --- | --- | --- | --- | --- |
| All-in-one B2B suite | Fastest | Lower | Lock-in to the suite’s assumptions | One market, one tax regime, simple role pricing |
| Small, governed plugin stack | Moderate | Higher | Conflicts between pricing engines | Several buyer types, one clear owner for each rule |
| Extensions plus selective custom code | Slowest | Highest | Needs ongoing developer ownership | Contract pricing, ERP-driven rules, custom quote flows |

Practitioners disagree on how many plugins is too many. One agency calls roughly 40 active plugins on an enterprise store “a recipe for trouble.” Another developer says 15 to 20 plugins plus custom code runs fast on proper hosting with Varnish and a CDN. The number matters less than the overlap. Two plugins that both change prices are a bigger risk than ten that don’t touch pricing at all. One merchant who began with “a plugin for every little logic” saw the site slow down badly. They moved the heavy logic into custom scripts that call the WooCommerce API.

A rule of thumb that holds up: if you can explain your pricing in one paragraph, a suite or small stack is probably enough. If you need a flowchart, plan for custom work. Our piece on [when custom WooCommerce development pays off](https://refact.co/insights/ecommerce/custom-woocommerce-development) covers how to spot that point and scope it.

## Accounts, Approval, and Who Sees What

Wholesale registration should work like a gate. The usual flow is a registration form, business details (tax ID, resale certificate, VAT number), a pending state, then approval or rejection, and finally role assignment. Automatic approval saves admin time. It’s risky when resale certificates, credit checks, or regulated products are involved, because an approved account can see negotiated prices the moment it logs in.

Deciding whether guests see prices is a real tradeoff. Hiding prices, or the whole catalog, protects negotiated pricing, but search engines and new buyers can’t find what you sell. Showing retail prices publicly helps discovery and makes negotiated pricing harder to manage. Many hybrid stores settle on public product pages with prices shown only after login for trade-only lines. That setup is also where caching bugs tend to show a wrong price to the wrong visitor.

### Rep dashboards need a different API than the storefront

This is the technical detail most teams find out late. The WooCommerce Store API powers the cart and checkout. By design, it is unauthenticated, tied to the current session, and limited to the current customer. It can’t look up other customers or their orders. So a sales rep dashboard, a company admin console, or ordering on a buyer’s behalf all need the authenticated REST API or custom endpoints.

That raises a security question. WooCommerce’s own developer guidance says that exposing other customers’ orders is a privacy breach. Every company-wide read should be checked on the server along the chain: current user, company, permitted data. It should never trust a customer ID sent from the browser. Log every action a rep takes for a buyer, so you can later answer who placed an order and on whose authority.

## Quotes, POs, and Net Terms Are Three Different Problems

Many teams discover this after launch. WooCommerce’s official Purchase Order Gateway adds a PO number field, records it on the order, and leaves billing to your offline process. It doesn’t set up credit, check the PO against your ERP, enforce limits, create invoices, or reconcile payments.

Treat payment terms as three separate layers:

1.  **Commercial entitlement.** Is this customer allowed Net 30 at all?
2.  **Checkout method.** Can they submit an order without paying right away?
3.  **Financial control.** Is credit available? Is the order approved, invoiced, and reconciled?

Extensions handle the first two much more often than the third. A “Net 30” plugin may only control whether an option appears at checkout. If finance thinks it enforces credit limits, over-limit orders will get through. The card and ACH side needs the same scrutiny. Comparing [payment gateway providers](https://platformdtc.com/payment-gateways) side by side helps you see which ones handle pay-later, saved payment methods, and account billing, and which only take a card at checkout.

### Design quotes as a set of states

The official request-for-quote flow is short: the buyer picks items, an admin adjusts price and terms, the buyer accepts, and the quote becomes an order. What happens between those steps is left undefined. Does the quote reserve stock? When does it expire? Can the buyer counteroffer or accept only part of it? What if the ERP rejects the order after the buyer has accepted?

Define the states before you build: draft, submitted, under review, priced, countered, approved, accepted, expired, rejected, converted, cancelled. For each one, decide whether the price is frozen, whether stock is held, and who has to approve. When the quote converts, re-check price and stock, and store the accepted quote on the order as a record that can’t be edited. Skip this and you’ll get duplicate orders, stale prices, and accepted orders you can’t fulfill.

![WooCommerce B2B request a quote workflow on a wholesale product page](https://cdn.refact.co/uploads/2026/09/image_placeholder_2-59.avif)

Tracking quotes across defined statuses like ‘New’ and ‘Pending’ transforms casual product inquiries into a structured B2B sales workflow. · Source: yithemes.com

## Treat Tax Exemption as a Financial Control

Tax bugs are dangerous because they look fine to a quick tester. In one documented case, tax-exempt roles saw VAT-inclusive prices in the wholesale order form even though VAT wasn’t charged. Net prices typed in by hand during admin order editing could also be read as tax-inclusive, so VAT came off a second time. Another merchant put tax-removal code in the parent theme’s `functions.php`. A theme update erased it, and the merchant had to refund tax to dealers.

Three rules prevent most of this. Put custom logic in a child theme, a site plugin, or proper hooks, never in the parent theme. Test net and gross prices, exempt and VAT-registered buyers, refunds, edited orders, and invoices. And remember that collecting a VAT number or exemption certificate doesn’t validate it. Someone still has to check it and decide where you owe tax.

## The ERP Handoff Decides Whether WooCommerce B2B Scales

Once a B2B store has real volume, the main work moves from the storefront to the connection with your back office. The clearest public example is an industrial distributor in Spain, documented by the agency awp.agency. The store has 52,000+ product references, pricing that depends on customer, volume, and contract, and two-way sync with SAP Business One. It is built from WP-CLI batch imports on a 30-minute cron, custom sync scripts, a custom pricing plugin, Redis object caching, and a dedicated server. The agency reports query times dropping from about 800 ms to about 45 ms with Redis, 200 to 400 orders a day, and 60% less reliance on phone orders.

These are one agency’s own numbers. They show what that project needed, not a guarantee of what WooCommerce can handle. The architecture is the useful part. Commercial data lives in the ERP. Syncs move only changes, not full imports. Batch jobs run outside the WordPress admin. Pricing logic is predictable and testable.

### Webhooks alone are not an integration

WooCommerce’s webhook documentation lists limits every ERP project should plan around. Delivery runs through WP-Cron by default. Any response other than a 2xx counts as a failure. Five failures in a row disable the webhook, and only 25 delivery logs are kept. That page is an older REST API v2 document, so check its limits against your current version. The risk is the same either way. A short ERP outage can switch off order sync with no alert, and by the time someone notices, the logs that explain why are gone.

Treat a webhook as a notification, not as the only copy of a transaction. A sound integration adds:

-   A durable queue with explicit acknowledgment on the receiving side
-   Idempotency keys (order ID plus event version) so a repeated event can’t create a second ERP order
-   Retries for temporary failures, and a quarantine for records that keep failing
-   An alert when a webhook is disabled
-   Scheduled reconciliation that compares WooCommerce and ERP records and flags differences

| Integration point | Common failure | Safeguard |
| --- | --- | --- |
| Customer accounts | ID mismatches between systems | One owner per field, with a mapping table |
| Order export | PO numbers and plugin fields dropped | Explicit field mapping, tested with real orders |
| Pricing | Store price differs from ERP contract price | ERP as source, with each price’s source and effective date recorded |
| Payment terms | Credit limits not enforced at checkout | Credit status synced into the store before submission |
| Stock | Real-time ERP calls slow page loads | Cached stock, updated on a schedule |

One food-service wholesaler described the flow they wanted as: quote in WordPress, sales order in the ERP, invoice in the ERP, then the WordPress order updated. That flow needed custom development, and they put online payment off to a later phase because offline stock checks had to come first. Launching order capture without payment is a sensible first phase. If the back office itself is the bottleneck, our guide to [custom ERP development](https://refact.co/insights/digital-product/custom-erp-development) covers when to fix the ERP instead of working around it.

## HPOS and Checkout Blocks Can Quietly Break Older B2B Code

Two recent WooCommerce platform changes create compatibility work that B2B stores are especially exposed to. B2B code tends to store PO numbers, buyer IDs, contract IDs, and ERP document numbers as order metadata, and it runs bulk exports and sync jobs against that data.

High-Performance Order Storage (HPOS) moves orders out of WordPress posts tables into dedicated tables. Code that reads the old tables directly can get stale orders. Code that writes to them can update data WooCommerce no longer reads. Extensions have to use the CRUD methods instead: `wc_get_order`, `update_meta_data`, and `save()`, calling `save()` once per object rather than over and over. New Marketplace extensions must be HPOS-compatible. Older third-party plugins already on your store aren’t guaranteed to be.

![WooCommerce HPOS order storage settings used when upgrading a B2B store](https://cdn.refact.co/uploads/2026/09/image_placeholder_3-35.avif)

Enabling compatibility mode allows order data to synchronize between traditional post tables and dedicated HPOS tables, ensuring legacy code remains functional during migration. · Source: developer.woocommerce.com

Roll out HPOS in stages. List every extension that touches orders, then test on staging with HPOS on. Sync the two storage systems; compatibility mode backfills 25 orders at a time through background actions. Before you switch for good, check ERP exports, webhooks, refunds, and admin screens. Switching back is possible, so keep that rollback plan until everything has been verified.

Cart and Checkout Blocks are a second, separate compatibility check. Payment methods in the block checkout have to be registered client-side, including a `canMakePayment` check, and server-side logic may need Store API hooks. When that is missed, B2B failures look like this: a PO field that never saves, a payment method shown to buyers who shouldn’t have it, an approval state that never gets submitted, or a method hidden in the UI that the server still accepts. In 2024 WooCommerce issued a developer advisory after Jetpack Boost’s JavaScript concatenation broke the Cart, Checkout, and Mini-cart blocks following WooCommerce 8.9. Test every B2B rule in the checkout mode you actually run in production.

## Performance Problems Come From Logged-In Buyers

Most WooCommerce speed advice assumes visitors who aren’t logged in and a page cache. B2B breaks that assumption. Wholesale buyers are logged in, see account-specific prices and catalogs, and skip the page cache. The real bottlenecks are uncached pricing calculations, variation queries, catalog visibility checks, live ERP calls, and checkout recalculation.

For large catalogs, the distributor case above used Redis or Memcached, PHP OPcache, a CDN, optimized tables, a lightweight theme, and Elasticsearch or Algolia for search. Keep ERP calls out of page loads and run imports through WP-CLI or background workers. When you load-test, simulate many logged-in buyers loading pricing, search, cart, and account pages at once. Anonymous homepage traffic tells you very little.

Mobile makes this worse. NettoProfit’s [2026 WooCommerce market analysis](https://www.nettoprofit.com/blog/woocommerce-market-analysis-2026) puts mobile at 68% of traffic but only 44% of revenue. Those are figures for WooCommerce stores in general, not B2B. The direction still applies to a buyer checking stock on a phone in a warehouse. A slow login and a price list that only comes as a PDF lose that reorder.

## WooCommerce or Another Platform for B2B

WooCommerce wins on owning your code and data and on flexibility, and there are plenty of WordPress developers to hire. Hosted platforms win on managed infrastructure and lower maintenance. Operations that need deep company accounts, heavy quoting, and multiple storefronts may be better served by an enterprise platform. Some practitioners point to Shopware or OroCommerce for quote-heavy B2B.

The anecdotes go both ways. Landyachtz left Shopify Plus for WooCommerce and cut platform costs from about $45,000 to under $10,000 a year, though its wholesale migration was still only planned. A wholesale operator on X said they spent several months and about $50,000 on WooCommerce freelancers before moving to Shopify. Another operator coming from Shopify Plus found the Woo B2B plugins big and clunky. No public data shows the size or complexity at which one platform becomes cheaper than the other. Your requirements decide it. For a direct comparison, see our [WooCommerce vs Shopify guide](https://refact.co/insights/ecommerce/woocommerce-vs-shopify).

One store or two is a similar call. WooCommerce supports mixed B2B and B2C setups, with roles controlling price, visibility, tax, shipping, and payment methods. A separate B2B site simplifies pricing and shipping rules but makes inventory and order tracking much harder. Run one store unless the catalogs, brands, or checkout flows are truly different.

## A Build Order That Keeps the Store Stable

The projects that work tend to follow the same order. They map the workflow before choosing tools, keep the extension set small, and assign someone to run the system after launch.

1.  **Write the rules.** Pricing precedence, minimums, quote states, payment term layers, and which system owns each field. Get sales, finance, and operations to agree. That agreement is often the hardest step.
2.  **Pick one pricing engine.** Test two candidates on a staging copy using your real rules before buying a license.
3.  **Set up accounts and approval.** Registration fields, pending states, role or company assignment.
4.  **Add catalogs, quotes, and PO capture.** Test in your production checkout mode, with HPOS on.
5.  **Connect the ERP.** Queue-based, idempotent, reconciled, with alerts for failures.
6.  **Test every role end to end.** Use separate guest, retail, approved wholesale, pending, and admin accounts in uncached sessions. Follow each order from product page through cart, checkout, admin edit, refund, and invoice.
7.  **Launch a narrow but complete workflow.** Measure it, then expand.

After launch, the unglamorous work matters most. In one discussion about a seven-figure wholesale store, the operator said their biggest gain came from following up on POs, inquiries, and abandoned carts on time, not from changing platforms. That is one operator’s experience, but it fits a wider pattern. The store needs owners for monitoring, updates, data quality, and the sales follow-up that turns a portal into revenue.

In our [WooCommerce build for NudFud](https://refact.co/work/nudfud), the hard part wasn’t checkout. It was the product structure. Variants, certifications, and nutritional data had to stay consistent on every page for a brand selling across Canada, the US, and Asia. A B2B store has the same problem with more on top: each product also carries different prices, minimums, and visibility for each account. Get that model right and the plugins and integrations have something stable to work with.

WooCommerce is a sound base for B2B when you treat it as one part of your commerce system. If you’re deciding which rules, integrations, and platform tradeoffs to settle before development starts, Refact’s [ecommerce development team](https://refact.co/services/ecommerce) starts with that mapping work, before any plugin gets installed.

## FAQ

### Does WooCommerce support B2B and wholesale pricing natively?

Mostly no. Core WooCommerce gives you products, orders, customer accounts, and basic tax settings. Role-based and customer-specific pricing, account approval, quotes, minimum order rules, company accounts, and trade payment terms all come from extensions or custom code.

### Can one WooCommerce store serve both B2B and B2C customers?

Yes. User roles can control pricing, product visibility, tax, shipping, and payment methods for each buyer type. Hybrid stores are also where most caching and pricing-precedence bugs show up, so test every role in an uncached session before launch.

### Can WooCommerce offer Net 30 terms and purchase orders?

It can be extended to. Be clear about what you're getting, though. The official Purchase Order Gateway only records a PO number, and many Net 30 options only control what appears at checkout. Credit limits, approvals, invoicing, and reconciliation are separate and usually need an ERP connection or custom work.

### Which WooCommerce B2B plugin is best?

No independent comparison settles it. Practitioners have praised Wholesale Suite as reliable and B2BKing for its support and sub-user accounts, and they've also reported conflicts when either is combined with other pricing or product options plugins. Write your pricing rules first, then test your top two candidates on staging against real orders.

### How much does a WooCommerce B2B store cost?

There's no reliable benchmark, because cost depends on pricing complexity and integrations. Plugin licenses are the small part, often a few hundred dollars a year. Most of the budget goes to ERP integration, testing, hosting that can handle logged-in buyers, and maintenance through WooCommerce updates.

### Should wholesale prices be hidden from guests?

It depends on what you're protecting. Hiding prices protects negotiated pricing but makes products harder for search engines and new buyers to find. Many stores show product pages publicly and reveal trade prices only after an approved account logs in.