Why Your WooCommerce Discount Plugin Broke After You Switched to Block Checkout

You switched to WooCommerce’s block-based cart and checkout — maybe WooCommerce installed it by default, maybe your theme recommended it, maybe you just updated one day and found the layout had changed. Everything looked fine. Then a customer mentioned they weren’t seeing the discounted price at checkout. Or your cart total stopped reflecting the campaign you had running. Or the sale price displayed correctly on the product page, but disappeared the moment the item was added to the block cart.

This is a real failure mode, and it is not caused by a misconfiguration on your end. It is caused by an architectural mismatch between how certain discount plugins apply their pricing and how WooCommerce’s block-based cart and checkout renders prices.

Understanding the distinction is useful because it tells you whether the problem is fixable with a setting change, or whether it requires a different tool.

What changed when WooCommerce introduced block checkout

WooCommerce has had two ways to display the cart and checkout for years. The older approach uses PHP shortcodes — [woocommerce_cart] and [woocommerce_checkout] — rendered through WooCommerce’s classic PHP templates. Most stores that existed before 2022 are on this setup.

The newer approach uses Gutenberg blocks — the Cart Block and Checkout Block — introduced in WooCommerce 8.3 and made the default for new WooCommerce installations. Stores created after that version get block checkout out of the box.

Visually, the two can look nearly identical. The blocks can be styled to match your theme just as the classic templates can. Many store owners who migrated to block checkout did not realise that the rendering engine underneath had changed significantly — and that the change had implications for any plugin that hooks into the classic cart rendering pipeline.

How discount plugins used to hook into the cart

The classic WooCommerce cart and checkout are rendered by PHP. When a customer views the cart page or proceeds to checkout, WooCommerce fires a series of PHP action and filter hooks that plugins can attach to.

The relevant ones for discount plugins are:

• woocommerce_cart_calculate_fees — lets plugins add fee or discount line items to the cart total at calculation time
• woocommerce_before_calculate_totals — fires before WooCommerce recalculates cart totals, letting plugins modify cart item prices mid-session
• woocommerce_cart_item_price — a display filter that controls what price is shown per line item in the cart

Many WooCommerce discount plugins — particularly those built as rule engines — apply their discounts through these hooks. The product retains its original price in the database. The discount is calculated and injected at cart calculation time, in memory, every time the cart is rendered or updated.

This approach has worked reasonably well for years on classic checkout. The hooks fire reliably during PHP rendering, the discount appears in the cart total, and the customer sees the reduced price at checkout.

Why block cart and checkout bypass those hooks

The block-based cart and checkout do not go through the same PHP template rendering pipeline. They are React-powered components that communicate with WooCommerce through the Store API — a REST-like endpoint that handles cart data, product data, and checkout operations.

When a customer adds a product to the cart and views it in the block cart, WooCommerce is not rendering a PHP template. It is fetching cart data through the Store API and rendering the result in JavaScript.

Here is where the breakage happens: the PHP hooks that cart-level discount plugins rely on — woocommerce_cart_calculate_fees, woocommerce_before_calculate_totals, and friends — either do not fire in the block checkout rendering context, fire differently, or fire at a point in the process that the block cart does not read from.

The result is that a plugin that has been faithfully applying discounts through those hooks for years appears to stop working the moment the store switches to block checkout. The discount logic is still running. The hooks are still firing somewhere in the process. But the block cart is not picking up the modified prices the way the classic template did.

This is not a hypothetical edge case. It has been documented on WordPress.org support forums by users of several popular discount plugins. At least one major competitor in this space — Flycart’s Discount Rules for WooCommerce — has publicly acknowledged that their plugin lacks full block checkout integration as of recent versions. When a plugin with hundreds of thousands of installs lists block checkout compatibility as an open issue, you can assume many stores have quietly been affected without realising it.

How to tell if your discount plugin is affected

The diagnostic is straightforward, but you need to test the right combination: the discount must be active, and you need to check the block cart, not the product page.

Test 1: Check whether discounts survive the cart

1. Set up a discount campaign or rule in your plugin.
2. Add a discounted product to the cart as a guest or customer.
3. Open the cart page. Confirm whether the discounted price — not the original price — is displayed.
4. Proceed to the checkout page. Confirm whether the order total reflects the discount.

If the product page shows a strikethrough sale price but the cart shows full price, or if the order total at checkout does not include the discount, your plugin is affected.

Test 2: Check how your plugin applies discounts

If you have access to your plugin’s documentation or settings, look for how it describes its discount method. Language like “applies fees at cart level”, “modifies cart item prices on the fly”, “uses woocommerce_cart_calculate_fees“, or “real-time price adjustment” describes the hook-based approach that is vulnerable to block checkout.

If the documentation describes setting WooCommerce sale prices directly, modifying product-level pricing, or working through WooCommerce’s native sale price mechanism, the plugin is likely using an approach that is not affected by the block checkout change.

Test 3: Check WordPress.org support forums

Search the plugin’s WordPress.org support forum for “block checkout” or “blocks”. If there are multiple unanswered threads or threads where the plugin author acknowledges the limitation, that is a reliable signal about the current state of compatibility.

The approach that works with both: price-level modification

There is a fundamentally different way to apply discounts in WooCommerce, and it does not have this problem.

Instead of intercepting the cart at calculation time through PHP hooks, a plugin can write discounts directly to the product’s WooCommerce sale price field — the same field that WooCommerce itself uses when you manually set a sale price on a product. When the campaign activates, the sale price is set. When the campaign ends, it is cleared. The product always has the correct current price stored in the database.

From WooCommerce’s perspective — and from the block cart’s perspective — this is indistinguishable from a manually entered sale price. The block cart reads the product’s sale price through the Store API, gets the discounted value, and displays it correctly. No hooks, no interception, no dependency on how the cart rendering pipeline is structured.

This approach works on classic checkout, block checkout, REST API integrations, headless WooCommerce setups, and any future checkout architecture WooCommerce introduces — because it works at the data layer, not the presentation layer.

The tradeoff is that this kind of plugin has to manage the sale prices actively. It sets them when a campaign starts and removes them when a campaign ends. This requires a scheduler — something that runs at the right time to activate and deactivate discounts reliably. A plugin built this way needs a solid scheduling system underneath.

What about cart-level discount types?

It is worth acknowledging the limitation of the price-level approach: it works cleanly for product-level discounts — percentage off, fixed amount off, sale price reductions. It is less naturally suited to discounts that are inherently cart-level, like “10% off your entire order when you spend over $100” or “add this item free to orders over $75.”

Cart-level conditions still require some cart-awareness, and a plugin doing this correctly for block checkout needs to integrate with WooCommerce’s Store API extensions rather than relying solely on the classic PHP hook pipeline. This is a harder engineering problem, and it is one reason why certain discount types have lagged behind in block checkout compatibility across the ecosystem.

If your discounts are primarily product-level — sale prices, BOGO offers where the discount applies to specific products — the price-level approach covers your use case fully. If you need cart-total-based spend thresholds, the picture is more nuanced, and the specific plugin you are using matters.

This is not a niche problem — it will affect more stores over time

Block checkout is the default for new WooCommerce installations. WooCommerce’s own roadmap has consistently moved toward Gutenberg-native experiences across the board. The classic shortcode cart and checkout are not going away immediately, but their long-term trajectory is clear.

Stores that have been running on classic checkout for years will migrate — some deliberately, some when a theme update or page builder change creates a conflict that gets resolved by switching to blocks. When that happens, any discount plugin relying on the classic hook pipeline will break in the same way described above.

The store owners most at risk are those who:

• Installed WooCommerce recently (block checkout is the default)
• Updated a theme or page builder and unknowingly switched rendering engines
• Migrated their checkout pages to blocks for the improved performance or design flexibility
• Are planning a site rebuild and intend to use block-based templates throughout

If any of those describe your situation, checking your discount plugin’s block checkout compatibility now — before a sale campaign goes live — is a much better experience than discovering the problem mid-promotion when a customer notices the price at checkout does not match what the product page promised.

FAQ