The WooCommerce B2B Price Bug Is a Load-Order Bug

A post on dev.to from the team behind Softminal B2B Suite makes a claim worth separating from the product it is selling: the familiar WooCommerce B2B symptom, $12 on the product page, $10.80 in the cart, and something different again in Checkout Blocks, is not a bad plugin but the predictable result of several add-ons hooking the same price filter ^[1][3]. That matters because if the diagnosis is right, no amount of patching any single plugin fixes it, and the debugging session you are about to run is the wrong one.

The stack described is the common one: wholesale pricing, hide-price-until-login, registration fields, request-a-quote, min/max quantities, invoices. Six add-ons, each competent inside its own slice, none aware that the others exist, all competing for the same price and visibility filters ^[4]. The author's point is that the final price is therefore not decided by a rule anyone can point at, but by whoever hooked in last ^[3]. The tell is the debugging move itself: you end up grepping the plugin directory for `woocommerce_product_get_price` to find out which one fired last ^[2]. The $1.20 gap between the two figures in the example is 10 percent of the displayed price ^[1], which is enough to matter on a purchase order, and when a buyer asks why their line came to $68.40 the store has no record of which rule won ^[5].

That is an architecture problem, not a vendor problem. A filter is a queue with no arbitrator. Every participant gets the value and returns a value, and the store's effective pricing logic becomes a property of the install rather than of anything you configured.

The fix the post describes is consolidation, and it is worth reading as a design pattern regardless of whether you buy the plugin. According to the author, all price mutation runs through a single `Pricing\Resolver` pipeline, and any stray Woo price filter found in the codebase is treated as a bug to remove rather than a feature ^[6]. The pipeline walks a fixed precedence order and stops at the first hit: accepted quote, customer-specific rule, company rule, group rule, category or tag rule, sale price, regular price ^[7]. That is seven tiers, resolved in one pass ^[2]. The same walk answers the shop, the product page, the cart, the Store API that Checkout Blocks reads, and the "why this price" panel, so the explanation cannot drift from the charge because it is the same code ^[8][9].

Two adjacent rules in the post are the ones that will age best. First, no B2B data in postmeta: pricing rules, companies, quotes and credit live in dedicated `smb2b_` tables, which the author frames as a relational problem (customers in groups, groups owning rules, rules targeting categories, companies carrying a credit ledger) and which also lets `uninstall.php` drop everything cleanly ^[10][12][13]. The stated failure mode of the alternative, a shop page doing a `meta_query` join against a multi-million-row table and taking four seconds to paint, is offered as experience rather than measurement ^[11]. Second, all order access goes through `WC_Order` CRUD rather than direct queries on `wp_posts`, because a plugin reading orders from the posts table is already broken on any store with HPOS enabled ^[14], and every checkout-affecting feature has to work in both classic checkout and Cart and Checkout Blocks including the Store API ^[15]. The author notes that many older B2B plugins predate both and were patched forward ^[16].

The unexamined cost is the obvious one: this trades six independent tools for one dependency that owns pricing, quotes and credit at once, and the post is the vendor describing its own codebase.