WooCommerce B2B pricing: plugin or custom code?

Classic B2C WooCommerce has a static price. Everyone sees the same thing. B2B is different: corporate customers get different prices, bulk orders earn a discount, membership tier drives a percentage off. Complexity starts right there.

I’ve solved this problem on dozens of WooCommerce B2B projects. Sometimes a plugin is enough. Sometimes custom code is the only sane option. Here are the criteria I use to decide.

B2B pricing scenarios

From simple to gnarly:

1. Customer-group based. Premium members get 10% off.

2. Quantity based. 5% at 10+ units, 15% at 50+.

3. Category based. Distributors get 20% on Electronics.

4. Product based. Specific SKUs priced individually for certain customers.

5. Customer-specific pricing. Enterprise clients with individually negotiated rates.

6. Time based. Extra 5% off wholesale on weekends.

7. Combined. All of the above layered together. A messy matrix.

The more complex the scenario, the more the choice swings toward custom.

Popular plugin options

Wholesale Prices by Rymera Web Co.
– Customer-group pricing
– Bulk discount per product
– Role-based visibility
– $99/year

B2BKing
– Full B2B feature set
– Quote system, RFQ
– Custom pricing tiers
– $149/year

WooCommerce Dynamic Pricing (official)
– Cart-based discounts
– Tiered pricing
– Combined rules
– $129/year

Price Based on Country
– Geographic pricing
– Multi-currency

ELEX WooCommerce Dynamic Pricing
– Advanced rule engine
– BOGO offers

When a plugin is enough

Plugin is enough:
– Standard B2B scenarios (group, quantity, category)
– Fewer than 20 rules
– Manageable customer base (1,000 to 5,000)
– Hosting performance is fine
– A $100 to $200 budget makes sense

Custom is required:
– Highly specific business rules
– Multi-dimensional pricing matrix
– Enterprise integration (ERP price feed)
– Performance critical (large catalog, high traffic)
– UX flow that plugins cannot deliver

Plugin pitfalls

The dark side of going plugin-only:

1. Database bloat. Every custom rule adds meta rows. On large stores wp_postmeta and wp_usermeta balloon.

2. Performance. The plugin evaluates rules on every product view. With 100+ rules you pick up hundreds of milliseconds.

3. Conflicts. Two pricing plugins active at once and the priceFilter chain turns into spaghetti.

4. Vendor dependency. The plugin author walks away from the project. No support, no updates.

5. Customization limit. You cannot step outside the logic the plugin author designed for.

Custom implementation patterns

The filters you hook for price manipulation in WooCommerce:

// Change product price (listing, single)
add_filter('woocommerce_product_get_price', function($price, $product) {
    return apply_custom_pricing($price, $product, get_current_user());
}, 10, 2);

// Sale price
add_filter('woocommerce_product_get_sale_price', function($price, $product) {
    return apply_custom_pricing($price, $product, get_current_user());
}, 10, 2);

// Cart price (after add_to_cart)
add_action('woocommerce_before_calculate_totals', function($cart) {
    foreach ($cart->get_cart() as $key => $item) {
        $custom_price = apply_custom_pricing(
            $item['data']->get_price(),
            $item['data'],
            get_current_user()
        );
        $item['data']->set_price($custom_price);
    }
});

Your apply_custom_pricing function is the business logic.

Pricing engine architecture

On larger B2B systems the pricing engine lives as its own layer:

class PricingEngine {
    public function calculatePrice(Product $product, User $user, int $quantity): float {
        $basePrice = $product->get_regular_price();
        
        // Apply rules in order of priority
        $rules = $this->getRulesFor($user, $product);
        
        foreach ($rules as $rule) {
            $basePrice = $rule->apply($basePrice, $product, $user, $quantity);
        }
        
        return apply_filters('b2b_final_price', $basePrice, $product, $user);
    }
}

Rule-based architecture. Adding a new rule is one class.

ERP integration

In enterprise B2B, prices come from the ERP (SAP, Oracle, Microsoft Dynamics). WooCommerce syncs from there.

Pattern:

1. ERP price list via API or file export
2. Daily cron job: ERP prices, then into a WooCommerce custom table
3. The pricing engine reads from that table
4. Cache invalidation on ERP changes

// Custom table
CREATE TABLE wp_b2b_prices (
    id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
    product_id BIGINT NOT NULL,
    customer_group VARCHAR(50),
    min_quantity INT DEFAULT 1,
    price DECIMAL(10,2) NOT NULL,
    effective_from DATETIME,
    effective_to DATETIME,
    INDEX idx_product_group (product_id, customer_group)
);

Display considerations

How you show the price:

Logged-out user: “Login to see prices” or a base price. Public price is often hidden on a B2B site.

Logged-in customer: their price shows. Often in a “List Price: $100, Your Price: $85” format.

Bulk pricing display:

Qty 1-9: $100 each
Qty 10-49: $95 each
Qty 50+: $85 each

Tables or charts help. Custom theme work.

Cache considerations

Dynamic pricing breaks full-page cache.

Solution:
– Logged-out users: static price, full cache fine
– Logged-in users: bypass full-page cache
– Fragment cache the pricing block
– Aggressive object cache (the user’s rules are stable for the session)

Tax handling

B2B tax is messy:
– Tax-exempt customers (reseller licenses)
– Reverse charge (EU B2B cross-border)
– Export exempt

WooCommerce tax classes cover most of it. For custom rules:

add_filter('woocommerce_product_tax_class', function($tax_class, $product) {
    if (is_tax_exempt_customer()) {
        return 'zero-rate';
    }
    return $tax_class;
}, 10, 2);

Quote system (RFQ)

Some B2B products ship as “request a quote” rather than a listed price. Plugin or custom.

Flow:
1. Product has a “Request Quote” button
2. User fills in requirements
3. Admin gets an email and a dashboard entry
4. Admin sends back a price quote
5. User approves, order is created

Plugins like B2BKing offer this flow out of the box. Custom takes 2 to 3 weeks.

Real project decision tree

In consulting work I decide like this:

1. Under 1,000 customers, under 5,000 products? A plugin is enough.
2. Under 20 pricing rules? A plugin is enough.
3. Standard rule types (group, tier, bulk)? A plugin is enough.
4. ERP sync required? Custom integration plus a rule engine.
5. Custom UX requirement (quote system, bulk order form)? Custom.
6. Very large catalog (50K+ products)? Custom, performance-optimized.
7. Long-term product (5+ years)? Custom is safer (no vendor dependency).

Cost comparison

Plugin approach:
– License: $100 to $200 per year
– Setup: 1 to 2 weeks
– Maintenance: staying compatible with plugin updates

Custom approach:
– Development: 4 to 8 weeks ($8K to $20K depending on developer rate)
– Maintenance: ongoing, your team
– Total cost of ownership evens out over 3 to 5 years

Short-term the plugin is cheap. Long-term custom buys flexibility.

Takeaway

B2B pricing choice follows complexity. Plugin is pragmatic for simple scenarios. Custom for enterprise-grade or bespoke business logic.

When picking a plugin look at author reputation, update frequency, review count. To really test a plugin, drop it into a clean WooCommerce install and try it.

If you’re going custom, design the rule engine architecture up front. You will be adding new rule types forever.