WooCommerce Role Based Pricing - WordPress Plugin

How to Set Up WooCommerce Role Based Pricing for Role-Based and Customer-Specific Pricing

WooCommerce Role Based Pricing is not about adding a polished marketing feature. It solves a very practical problem: showing different prices, quantity limits, or purchase availability to different groups of buyers within the same WooCommerce store. In this guide, we will walk through a clean setup approach: when to use product-level pricing, when a global rule makes more sense, how to avoid stacking a role discount on top of a sale price, and how to verify the result from the perspective of a specific role.

This article is written for store owners, WordPress administrators, and specialists responsible for B2B pricing, wholesale pricing, VIP customers, or a private catalog. We are not going to rehash the product listing. Instead, we will follow a real workflow: preparing roles, installing the plugin, configuring the first settings, creating product and category rules, handling variations, importing CSV data, hiding prices, checking cart behavior, troubleshooting common issues, and comparing similar solutions.

The main idea is simple: pricing should change in a predictable and testable way. If you cannot explain a rule to a store manager, test it in a separate browser window, and roll it back safely, it should probably be simplified before going live. This matters even more in stores that serve retail customers, wholesalers, dealers, regional buyers, and customers with individual pricing agreements at the same time.

According to the official documentation, the plugin works with user roles and individual customers, lets you set a fixed price, markup, or discount, enforce quantity limits, hide prices and purchase buttons, and read rules through the REST API. In the article below, those features are turned into a practical system so you can do more than just enable the extension - you can configure it for a real store.

Where the Plugin Is Truly Useful, and Where It Is Overkill

Role-based pricing may sound like a universal answer for any kind of discount, but it is not. WooCommerce Role Based Pricing works best when the price depends on the buyer's status, not just on a coupon, a temporary promotion, or the number of items in the cart. Typical roles include wholesaler, dealer, VIP customer, corporate buyer, private club member, regional partner, or a specific customer with a custom agreement.

The plugin is especially useful when the same products are sold to different audiences. For example, a retail customer sees the standard price, an approved wholesaler sees a fixed contract price, and a VIP group gets a percentage discount on a specific category. In that scenario, there is no need to build a separate site, duplicate products, or maintain multiple catalogs by hand.

There are also cases where this tool may be more than you need. If you just need a one-time promotion for all buyers, coupons, standard sale prices, or a dedicated dynamic discount module will usually be more convenient. If you need a full B2B portal with wholesale registration, approval workflows, quotas, tax logic, shipping and payment restrictions, a pricing plugin alone may not be enough. In that case, WooCommerce Role Based Pricing becomes only one part of a broader system.

Good Use Cases

• Wholesale customers get a fixed price or percentage discount on specific categories.
• VIP customers see a special price, while regular visitors see the standard price.
• Some customers receive an individual price without requiring a separate role.
• Variable products need different pricing conditions for sizes, colors, or bundles.
• Guests should not see the price or purchase button and should see custom text or a link to an inquiry form instead.
• A seasonal rule needs to work only during a specific time period, if that option is available in your version.

When It Makes Sense to Consider Another Solution

If your store needs complex logic such as "buy three, get the fourth free," cart-total discounts, gifts, product bundles, or advanced rules based on payment methods, look at dynamic pricing tools or full B2B suites. If your only goal is to restrict shipping and payment methods by role, there is a narrower class of extensions designed specifically for that. If you just need one wholesale pricing tier without customer-specific rules, a free or freemium wholesale plugin may solve the problem more simply.

A practical pre-selection check: write down three real pricing rules from your store in plain language. If each one can be expressed as "for this role or this customer, apply this price to these products," this plugin is a good fit. If the rule depends on complex cart logic, multiple conditions at once, or a separate B2B registration process, evaluate a broader tool.

How the Pricing Logic Works: Role, Customer, Product, Rule, and Priority

The most common mistake when implementing role-based pricing is thinking of the plugin as just a discount table. In practice, it works as a layer of conditions between the WooCommerce product price and what a specific buyer sees in the catalog, on the product page, in the cart, and at checkout. That is why setup should begin not with a discount percentage, but with the question: who exactly should see the modified price, and where should that rule apply?

The documentation describes two main configuration levels: product-level pricing and rule-based management for products or categories. The first level is convenient when you need an exact price for a single product or variation. The second is used when a rule should cover a group of products, a category, or several selected products at once. The plugin also supports customer-specific rules, so a price can be assigned not only to a role but to an individual user as well.

Why Priority Matters More Than Rule Count

The plugin uses priorities for overlapping conditions. Product-level settings are considered first, then global rules. Within those groups, customer-specific settings carry more weight than role-based settings. That is logical: if a particular buyer has an individual price assigned, it should usually take precedence over the general rule for their group.

For an administrator, that means this: do not create five rules when one is enough. If a product already has a customer-specific price, do not assume the role rule will automatically stack on top of it for the same user. That situation should be documented in your rule map and tested separately.

Five Types of Price Adjustment

According to Addify and WooCommerce Marketplace descriptions, the plugin supports several adjustment types: fixed price, fixed increase, fixed decrease, percentage increase, and percentage decrease. That gives you flexibility, but it also creates room for bad pricing math. For negotiated B2B pricing, a fixed price is often the safest choice because the manager sees the exact final amount. For a general loyalty program, a percentage decrease is more convenient. For a regional markup or service surcharge, a fixed or percentage increase may be the better fit.

Quick takeaway from this section: design the rule hierarchy first, then enter the numbers. The clearer the priorities are, the fewer disputed orders and manual corrections you will have later.

What to Check Before Installing It on a Live Store

Any plugin that changes pricing affects more than just the product page. It touches the cart, checkout, admin orders, analytics, exports, emails, caching, and sometimes third-party product modules. That is why installing it directly on a live store without testing is a bad idea. Preparation takes less time than handling a complaint from a wholesale customer who saw a retail price in the cart.

Check Roles and Users

WordPress includes standard roles by default, and WooCommerce adds customer and shop manager roles. WooCommerce Role Based Pricing itself is not designed to create new roles. The documentation explicitly states that if you do not see a wholesale role after installation, you need to create it with a separate role editor plugin or another standard method. So before you configure prices, make a list of the roles that already exist in the store and separate technical roles from commercial ones.

• Keep only the roles in your pricing rules that should actually affect pricing.
• Do not use the administrator role as a test commercial role, because it has special privileges.
• Create a separate test user with a customer, wholesale, or VIP role.
• Check whether a single customer has multiple roles assigned if the site uses extended access control.

Check Products, Variations, and Sale Prices

The plugin is compatible with WooCommerce variations and lets you configure pricing at the variation level. But variable products always create more room for error: parent product, variation, price range, front-end cache, price filters, and cart display. If you have many sizes or colors, start with one product and one variation, not with a bulk rule across the entire catalog.

Also review products that already use WooCommerce sale pricing. In the plugin's general settings, you can choose how adjustments apply to the regular price or sale price, and whether role-based discounts should be skipped for items already on sale. This is a critical setting for stores where seasonal promotions overlap with wholesale pricing.

Check Caching, the Theme, and Cart/Checkout Blocks

Page and fragment caching can interfere with personalized pricing output. If the store caches product pages the same way for guests and logged-in users, special pricing may display incorrectly or with a delay. On the WooCommerce side, you also need to test the cart and checkout. Addify's changelog mentions compatibility with Cart & Checkout Blocks, but any custom theme, third-party blocks, or checkout extensions still need to be tested on your own site.

Minimum safe preparation: create a backup, test the plugin on a staging copy, create a test user with the target role, disable aggressive caching for logged-in buyers, and prepare a short list of products to verify in advance.

Installation and Initial Testing Without the Purchase Walkthrough

This guide does not cover purchasing the plugin, activating a license, or obtaining the paid version. We will assume you already have the installation ZIP and WordPress administrator access. The installation flow is the standard one for commercial WordPress extensions: upload the ZIP through the admin panel, install it, activate it, and make sure a new pricing management item appears.

Basic Installation Steps

1. Open Plugins and go to Add New.
2. Click Upload Plugin and select the extension ZIP file.
3. Click Install Now, then Activate.
4. After activation, find the left admin menu item related to Price by User Role or Role-Based Pricing.
5. Open any test product and check whether a role-based pricing settings block appears on the product edit screen.

Do not rush into creating bulk rules right after installation. First, confirm that the plugin can see roles, products, and customers. If the role list contains too many technical entries, use the setting that excludes roles from the configuration list. That does not change user permissions, but it simplifies the admin interface and reduces the chance of selecting the wrong role.

The First Test After Activation

Create a simple test product with a regular price and assign a small fixed or percentage discount to the customer role. Open the product in one window as an administrator, in another as a test customer, and in a third as a guest. The difference between the three states should be obvious. If it is not, do not move on to complex rules yet. First sort out the user role, caching, theme behavior, and the place where the price is rendered.

Quick takeaway: installation is successful not when the plugin is activated, but when you can see the modified price on the public storefront under the correct role and the normal price under a different role.

Detailed Configuration After Installation

A useful WooCommerce Role Based Pricing setup takes several passes. The first pass is to clean up the interface and define which roles are used in pricing. The second is to decide how the plugin should behave with sale prices, taxes, and min/max quantity. The third is to configure rules at the product, variation, or category level. The fourth is to validate the public-facing result and the cart.

General Settings: What to Enable First

Start with the parameters that define system-wide behavior. The documentation lists settings for tax handling on discounts, enforcement of min/max quantity, role exclusion from configuration, and the pricing base for discounts or markups - regular price, sale price, or ignoring role-based discounts when a sale price exists. For most stores, the first real decision is about sale prices.

How to Handle Sale Prices

If your store runs promotions often, do not automatically apply a role-based discount on top of a sale price until you have checked the margin. Without that control, a wholesaler may get two discounts: one from the sale and another from the role. A safe starting point is to apply the rule to the regular price or to skip role-based discounts on products with a sale price, if that matches your pricing policy.

When to Enable Enforced Quantity Limits

The min/max quantity setting matters for wholesale conditions. According to the documentation, if enforcement is enabled, the buyer will not be able to purchase the product outside the specified range. If it is disabled, the buyer can still add the product outside that range, but only at the existing price. Those are two different business scenarios. The first fits strict wholesale rules, while the second fits a softer discount model where the discount simply does not apply below the threshold.

If you enable quantity limits, make sure the error messages are clear. The documentation notes among common issues that the add-to-cart button may appear broken when the minimum quantity is greater than one and no message is configured. The user clicks the button, the product is not added, and they do not see why. That is not only a technical issue - it is also a trust issue.

Product-Level Pricing Setup

The product level works best for exceptions: a specific SKU, a customer-specific item, a key variation, or a negotiated individual price. On the product edit page, open the Price by User Role block and specify the role or customer, the adjustment type, the value, and min/max quantity if needed. If the price field is left empty for a role, the standard WooCommerce price should be used.

For variations, open the variation settings and check the separate role-based pricing block there. The documentation notes that variations are supported, but bulk updates by attributes and variations have limitations. That is why, for a catalog with dozens of variations, you should decide early where a category-wide rule is enough and where each variation needs its own exact setup.

Bulk Rules for Products and Categories

Rule-based management is useful when pricing depends on a group rather than a single product. For example, all products in the "Supplies" category may give a wholesaler a percentage discount, while the "Premium Kits" category may have a markup for a specific region. In the Price by User Role section, create a new rule and choose the roles or customers, products or categories, adjustment type, and quantity range.

The main maintenance rule is simple: one business condition equals one clear rule. Do not mix products with different validation logic into one rule. If a manager cannot easily explain why a product falls under a rule, it will be hard to diagnose a disputed order price later.

CSV Import and Export

Import and export become useful when prices are managed outside WordPress: in a purchasing spreadsheet, ERP, accounting system, or a file maintained by a manager. The plugin supports CSV import and export for role-based prices and rules. But CSV should not become a way to "upload something and see what happens." Before importing, export the current rules, save a backup of the file, and test the import on a small product set.

After import, check not just the admin area but the storefront as well: a simple product, a variation, a category, the cart, and an order. If your CSV contains decimal values, pay attention to the separator format, because the plugin's changelog includes fixes related to the European decimal separator. Do not judge the result based on a single product page.

Setting Up Hidden Prices and the Purchase Button

Hiding the price and the Add to Cart button is one of the most useful features for a private catalog. It lets you show the assortment without revealing prices to guests or selected roles. The settings let you hide the price and button together, hide only the button, replace the price with custom text, replace the button with new text and a link, and limit the behavior to specific products or categories.

This feature is especially important in B2B, where the price depends on a contract, region, volume, or customer status. But it is easy to configure too aggressively. If a guest cannot see the price, they should understand what to do next: sign in, register, request access, or contact a manager. A product page with no price and no explanation looks like a broken website.

How to Hide Pricing Without Losing Leads

• Use clear replacement text instead of the price, such as "Sign in to see your price" or "Request access to wholesale pricing."
• Replace the purchase button with a link to the login page, B2B registration page, or inquiry form, if your site structure supports that.
• Do not hide prices across the entire catalog until you have checked the categories where retail sales should remain open.
• Check how the hidden price appears on the product page, category archive, search results, mini cart, and related products.

What to Check After Enabling It

Open the product as a guest, as a regular customer, and as the role that should see the price. The guest should see clear text and the correct link. The regular customer should see the variant that matches your policy. The wholesaler should see both the price and the purchase button. If an old button is still visible somewhere, check the theme, the cache, and whether the price is being output by a separate custom product template.

This setting affects the user journey more than it may seem. For restricted pricing, it is not enough to hide the amount - you also need to guide the person to the next action. Otherwise, the catalog turns into a storefront with no entry point into the funnel.

Practical Example: Wholesale Role, Category Discount, and Order Verification

Let us walk through a specific scenario. The store sells to retail customers and wholesalers. Wholesalers should receive a percentage discount on the "Supplies" category, but only when they buy at least a certain quantity. One key customer also needs a custom fixed price for a specific product. Guests see the regular catalog, but they should not see wholesale pricing.

Goal

Build a predictable system: a regular customer sees the standard price, the wholesale role sees a category discount at the required quantity, and one specific customer sees a custom price for one product. The amount shown in the cart and order should match what was shown on the product page.

Preparation

1. Create or verify a commercial role such as wholesale_customer if it already exists in your store through a separate role editor.
2. Create a test user and assign that role to them.
3. Select one test category and two products: one simple product and one variable product.
4. Make sure those products have standard WooCommerce pricing and are not involved in other promotions that could distort the test.

Setup Steps

1. Open the Price by User Role section and create a new rule.
2. Select the wholesale role and the category the rule should apply to.
3. Choose the adjustment type, for example a percentage decrease, and enter the discount value.
4. Set the minimum quantity if the special price should apply only to wholesale purchases.
5. Check whether you need enforced min/max quantity limits or whether a softer model is enough, where the regular price applies outside the allowed range.
6. Save the rule and open the individual product that needs a custom contract price for a particular customer.
7. In the product-level role pricing block, specify the exact customer and the fixed price.

Verifying the Result

Open the storefront in a separate browser or private window. First check the product as a guest: the price should be standard, or hidden if you configured catalog mode. Then sign in as the test wholesaler and open a product from the selected category. Change the quantity below and above the minimum threshold, add the item to the cart, and verify the result. After that, sign in as the customer with the custom price and make sure their product shows the individual amount rather than the general role rule.

Important detail: if a specific customer has a custom price assigned, do not treat it as a bug when the general role rule does not apply to that user. That is expected priority behavior. The real mistake would be failing to document that in your internal rule map.

What to Document After the Test

Keep a small table for managers: role, rule, products or categories, adjustment type, min/max quantity, what the user sees, and how to verify it. That is not bureaucracy - it is protection against future edits. A few months from now, no one will remember why one customer gets a fixed price unless the reason is written down.

Checking the Result on the Storefront, in the Cart, and in the Order

For a pricing plugin, checking the admin area proves almost nothing. What matters is seeing how the price flows through the entire buyer journey. The minimum path is this: product page, category archive, variation selection, cart, checkout, the created order in the admin panel, and email or notification output if that matters for your process.

Three User States

Test each rule in at least three states: guest, regular customer, and the role with special pricing. If you have a customer-specific price, add a fourth state. Do not use the administrator for final verification because that role has special privileges. It is better to create separate test accounts with realistic roles.

What to Check on the Product Page

• The price changes only for the intended role or customer.
• The original price is struck through or replaced according to the selected setting.
• For a variable product, the correct price appears after selecting a variation.
• Hidden-price text does not break the theme layout.
• The purchase button leads where you intended if it has been replaced.

What to Check in the Cart and Checkout

In the cart, review the line item, quantity, subtotal, taxes, and total. If you use Cart/Checkout Blocks, test the current cart and checkout template specifically. If the site has been switched back to classic shortcodes, test those instead. The storefront price and the order price should match in meaning; if the product page shows a discount but the cart shows the regular price, look for a cache conflict, a theme issue, or another discount plugin.

Checking the Admin Order

Create a test order and open it in the admin panel. Check the line items, taxes, coupons, and final total. The plugin's change history includes fixes related to admin order pricing and cart behavior, so this step should not be skipped. If the store often creates manual orders for wholesalers, also test manual order creation on behalf of the target customer.

Variation Behavior, Sale Prices, and Overlapping Rules

This is where complaints most often appear: "it works for simple products but not for variations," "the discount was applied twice," "the category rule overrode the custom price," or "the cart price is different." These situations do not always mean the plugin is broken. Very often, the real issue is that the pricing logic was never organized by level.

Variations: Do Not Mix Parent and Child Values

If a product has variations, test the exact variation price. The plugin lets you define role-based pricing for variations, but the official documentation describes limitations for bulk updates by attributes and variations. So do not plan a complex matrix like "role + attribute + custom customer" without first testing it on a small sample.

For a catalog with many sizes and colors, a category rule is often better if all variations should behave the same way. If one variation has a unique cost structure or negotiated price, configure it separately and document it as an exception.

Sale Prices: Avoid Unintentional Double Discounts

A role discount and a sale price can work together, but only when the policy is clear. If a wholesaler always gets a contract price, a seasonal sale price may not matter to them at all. If a VIP customer gets a discount as an added benefit, it may be acceptable to apply it to the sale price, but the margin needs to be calculated in advance. In the general settings, choose that behavior deliberately rather than leaving it to chance.

Overlapping Rules: Keep a Priority Map

Use a short internal map: product-level customer, product-level role, rule-based customer, rule-based role. According to the documentation, those are the levels involved in priority resolution. When a price looks unexpected, work through that map from top to bottom. First look for a customer-specific price at the product level, then a role-based product price, then a customer rule, then a role rule. That order saves time and avoids unnecessary arguments between the manager and the administrator.

Import, Export, and REST API: When the Technical Features Matter

For a small store, manual configuration is faster and safer. But if you have many prices, complex roles, and contract terms managed in another system, import, export, and the read-only API become valuable. It is important to understand the boundaries: import changes data, while the REST API is documented as a way to read rules and product prices. You should not turn the API into an undocumented bulk price-writing method unless the developer explicitly supports it.

CSV as a Control Tool, Not Just an Upload Format

A CSV export is useful even when you do not plan to import prices. It gives you a snapshot of the current configuration that can be saved before a major change. If something goes wrong afterward, comparing exports is often the fastest way to see which rules were affected. For team workflows, that is frequently more important than the upload itself.

Read-Only REST API for Rule Verification

The documentation describes a WooCommerce REST API v3 extension for viewing the list of rules and product-level pricing. This is useful for a developer or integrator who wants to compare what appears in the admin area with what an external reporting system sees. For the API to work, the documented requirements must be met: supported WooCommerce and WordPress versions, pretty permalinks, and standard WooCommerce REST API authentication.

/wp-json/wc/v3/role_based_rules/
/wp-json/wc/v3/role_based_pricing/product/{product_id}

Do not add an API integration just out of curiosity. If the business need is fully handled through the admin UI and CSV, that is enough. The API makes sense when you need reporting, rule auditing, integration with an external catalog, or a way to verify which conditions apply to a specific product.

Safe Operation: Caching, Access Control, SEO, and Store Support

Role-based pricing should not turn your store into a system that is hard to maintain. After setup, think about four adjacent layers: caching, access control, indexing, and manager support. Each one may not break the plugin directly, but each can affect the buyer's final experience.

Caching and Personalized Pricing

If the price depends on the logged-in user, the product page should not be served from one static cache to everyone. Check the settings of your cache plugin and hosting environment: pages for signed-in users are usually not cached the same way as guest pages, and cart fragments should refresh correctly. If you use object caching, a CDN, or JavaScript optimization, test pricing after clearing cache and across different roles.

Access Rights and Roles

Do not confuse a role as a commercial segment with a role as a set of WordPress capabilities. A wholesale role should not accidentally receive administrative permissions. WooCommerce recommends using plugins or extensions to modify roles instead of editing code by hand. If you create a new role, inherit only the capabilities you actually need rather than copying shop manager permissions.

SEO and Hidden Prices

Hiding prices from guests can change how product pages are perceived by both search engines and users. Do not expect an automatic SEO benefit from a restricted catalog. Instead, make sure the page remains useful: it should include a product description, access conditions, a clear login or inquiry link, and structured data that does not conflict with the actual price output. If the price is hidden, do not try to imply otherwise in the snippet.

Support for Store Managers

The most reliable setup is still useless if managers do not know where to look for the reason behind a price. Give them a short operating checklist: what role the customer has, which rule applies, where to view custom prices, how to test a product in a private window, and when to escalate the issue to an administrator. In stores with frequent contract changes, this reduces the number of urgent support requests.

How to Maintain a Rule Map So Pricing Does Not Become a Black Box

The longer a store uses role-based pricing, the greater the risk of accumulating rules whose origin no one remembers. At first, this looks harmless: one customer gets a custom price, then a wholesale category discount is added, then a temporary regional markup, then prices are hidden from guests in part of the catalog. A few months later, the administrator sees dozens of rules, and the manager cannot explain why a specific buyer received that exact amount.

For WooCommerce Role Based Pricing, keeping a rule map is especially important because the plugin allows several levels of influence over the final price: product, variation, category, role, customer, quantity, date range, sale price, and hide-price mode. The map does not need to become a complex CRM system. A simple table is enough, as long as each rule is described in human terms and tied to a business reason.

Minimum Structure for a Rule Map

Create a separate document for the store team. It can live in Google Sheets, an internal knowledge base, or a project task. What matters is that it is updated at the same time as the rules in the admin panel. For each rule, document not just the discount amount, but the meaning behind it.

This kind of table helps more than just the administrator. A sales manager can see why a customer received a discount, an accountant can understand why an order total differs from the retail price, and a developer can rule out a technical issue more quickly.

A Safe Sequence for Expanding Rules

Do not add a new role or category rule across the entire catalog all at once. Use a staged rollout. Start with one product, one role, one adjustment type. Then test a variable product. Then move to a category. Only after that should you scale to CSV or broader rules. That process may feel slow, but it is still faster than rolling back dozens of incorrect prices.

1. Create the new rule in a disabled or minimally impactful scenario, if your store workflow allows it.
2. Test a simple product page as a guest, a regular customer, and the target role.
3. Add the product to the cart and create a test order.
4. Repeat the check on a variable product if that product type exists in the affected category.
5. Record the result in the rule map, and only then extend the rule to a category or a CSV import.

How to Review Rules Every Few Months

A rule review is useful not only before updating the plugin. Business conditions change: customers leave, roles get renamed, categories are merged, sales end. If old rules remain active, the store may lose margin or show buyers outdated terms. Every few months, export the rules, compare them with the rule map, and ask three questions for each one: why does this rule exist, who owns it, and how do we verify it?

If you do not have those answers, do not necessarily delete the rule right away. First disable it or narrow its scope in a test environment, check the affected products, and confirm the decision with the responsible manager. For customer-specific prices, it is especially important not to remove conditions without business confirmation: those records may reflect a contract that is not visible inside WooCommerce admin.

Good practice: every new role-based pricing rule should have an owner and a verification product. If a rule has no owner, it quickly turns into a "magic discount" that no one is willing to change.

Common WooCommerce Role Based Pricing Issues and Fast Troubleshooting

Below are the issues most typical for role-based pricing in WooCommerce. Some are described directly in the official documentation, while others come from common WordPress, WooCommerce, caching, and variable-product behavior. Troubleshooting is best done on a test product and a test user so you do not affect real orders.

Customer-Specific Pricing Works, but the Role Price Does Not Apply

Symptom: a specific user sees a custom price, but the general rule for their role appears to be ignored. For other users with the same role, the discount may still work.

Possible cause: the customer-specific setting has higher priority. The documentation explicitly states that with customer-specific pricing, the role rule for that customer may not apply, even though it continues to work for other users with that role.

What to check: open the product and the global rules, and look for settings assigned to that specific customer. Then test another user with the same role but without a custom price.

How to fix it: remove or change the custom price if it is no longer needed, or keep it as an intentional exception and document it in the rule map. There is no need to roll back the general role rule if it still works for everyone else.

The Needed Wholesale Role Is Not Visible

Symptom: after installing the plugin, the administrator expects to see a wholesale role, but it is missing from the list.

Possible cause: the extension does not create custom roles. It uses existing WordPress/WooCommerce roles and roles created by a separate tool.

What to check: open the user list and the role editor if one is in use. Make sure the role has been created, assigned to a test user, and not excluded from the list in the plugin settings.

How to fix it: create the commercial role with a reliable role management plugin or another solution accepted in the project, then return to the price settings. Do not give wholesalers administrator or shop manager permissions just for testing.

The Add-to-Cart Button Looks Broken

Symptom: the buyer clicks Add to Cart, but the product does not go into the cart, or the behavior is unclear.

Possible cause: a minimum or maximum quantity is set, but the error message is not configured or is not being shown by the theme. The documentation specifically mentions this scenario for min/max quantity.

What to check: the quantity value on the product, whether enforcement is enabled, the min/max quantity message text, and whether the Store Notices block or classic WooCommerce notices are working.

How to fix it: add a clear message and verify that notices appear on the product page and in the cart. If the restriction interferes with sales, temporarily disable enforcement and keep the regular price outside the allowed range.

The Product Page Price Differs from the Cart Price

Symptom: a special price is visible on the product page, but the cart or checkout shows the regular price.

Possible cause: a conflict with cache, a third-party discount plugin, the theme, a variation rule, sale-price handling, or an incompatible checkout extension.

What to check: clear the cache, repeat the test under the required role, test a simple product with no variations, then a variation, then a product with no sale price. If the problem disappears on a simple product, the issue may be in overlapping conditions.

How to fix it: simplify the rule, rule out the conflicting discount plugin, and test compatibility with both Cart/Checkout Blocks and the classic checkout flow. If the issue appears only with a specific product module or product options extension, treat the official compatibility limitation as relevant.

The Discount Applies to the Sale Price Differently Than Expected

Symptom: the final price is too low, or the discount does not apply to an on-sale product at all.

Possible cause: the general settings are using the wrong mode for applying adjustments to the regular price or sale price, or the option to ignore discounts when a sale price exists is enabled.

What to check: the global discount/markup settings, whether the product has a sale price, and any overlap with coupons or other discount rules.

How to fix it: choose one commercial principle and apply it consistently. If the store runs promotions often, define in advance whether a wholesale discount is allowed to stack with a sale.

The Rule Does Not Work with Product Options or Add-Ons

Symptom: standard variations work, but products with extra product options produce unpredictable final pricing.

Possible cause: the official documentation confirms compatibility with default variations and notes limitations for product options/addons. Reviews also mention incompatibility with the official Product Bundles extension.

What to check: repeat the test on a simple product, a standard variation, and a product with add-ons. Compare the behavior.

How to fix it: do not build critical pricing logic on an unconfirmed integration. If add-ons or bundles are required, confirm compatibility with the developer or choose an alternative that explicitly supports that scenario.

When WooCommerce Role Based Pricing Is the Right Choice

This plugin is worth using if your store already understands its commercial segments and wants to manage pricing without duplicating the catalog. It is a good fit for role-based and customer-specific pricing, bulk rules by product and category, variations, min/max quantity, CSV maintenance, and hiding prices from guests or selected roles. Its real value is not the number of checkboxes - it is the ability to connect a specific buyer to a specific price and verify the result inside WooCommerce.

Do not launch it as "just another discount plugin." First map out your roles, define your sale-price policy, check for overlapping discount logic, create test users, and walk the full path from the product page to the order. If that path works without surprises, you can move from testing to the live catalog.

If, after reading this, you understand which roles you need, where the rules will live, and how to verify the result, you can download WooCommerce Role Based Pricing and test the plugin on a staging copy of your store. Start with one product, one role, and one rule. It is much easier to scale a clear system than to untangle dozens of overlapping conditions after launch.