WooCommerce Auto-Apply Coupons Replace 13,000 Lines

Every couple of years I get the same call. A store is groaning under a discount plugin that was bought when the site had two products and now has eight thousand. The plugin ships tens of thousands of lines of code, its own admin, its own settings, its own opinions, and every WooCommerce update is a small prayer. Then Black Friday hits and the finance director asks why refunds spiked.

The honest answer is almost always the same. The tiered discount you wanted did not need a plugin. It needed three or four WooCommerce coupons with the right rules, plus a small piece of glue that applies them for you. What WooCommerce shipped a case study about yesterday is that exact story, told from inside the shop that runs woocommerce.com itself.

I read it twice, because the numbers are the kind that make me suspicious. Then I looked at the code, and the pull request, and it holds up. This one is worth paying attention to.

What is actually new

On July 1, 2026, Boro Sitnikovski published Auto-apply coupon: how 209 lines of code replaced ~13,000 on the WooCommerce Developer Blog. The subject is the tiered promo engine used on the woocommerce.com store during Black Friday and Cyber Monday 2025. The team removed a third-party tiered-pricing plugin and rebuilt the same behaviour on top of native WooCommerce coupons plus a small auto-apply layer. Net line count: 209 lines added, roughly 12,888 removed.

The mechanics are unremarkable in the good way. A checkbox on the coupon edit screen stores an _auto_apply flag in wp_postmeta. On the woocommerce_after_calculate_totals hook, the cart reads every coupon marked auto-apply (result cached for twelve hours), instantiates each one as a WC_Coupon, and calls is_valid(). If a coupon passes validation and is not already on the cart it is applied silently; if it fails validation and is on the cart it is removed. The block cart and the classic cart both hide the remove-coupon button for auto-applied codes via a small JavaScript check against the block class names.

The re-entrancy problem — apply_coupon() triggers woocommerce_after_calculate_totals, which would trigger apply again — is handled with a static $running flag inside the callback. Nothing exotic; the sort of guard you write once and forget.

The upstream contribution is PR #61958, currently reopened as a draft against trunk. The article is candid about what still needs work before merge: the _auto_apply meta needs a proper migration path for HPOS, the JavaScript that targets block cart class names is brittle across Cart block versions, and the coupon codes for the promo run were hardcoded rather than driven from settings. All fair. None of it changes the fact that the pattern works and shipped tens of thousands of orders during BFCM 2025 without a single coupon-related outage.

Two business numbers from the same article are worth writing down. Refund rate dropped from 13.1 percent to 7.8 percent year over year on the same BFCM window. Net cash per customer rose 25 percent. Neither of those is a coupon-engine metric on its own — many things changed at woocommerce.com in that year — but they do describe a promotion machine that behaved well under a very large load.

Why it matters for WordPress and WooCommerce people

Two things matter here, and they are not the same thing.

First, the technical fact. You can run non-trivial promotions on plain WooCommerce coupons. Usage limits, product and category restrictions, expiry, individual-use, exclude sale items, minimum spend, customer email allowlists, per-user limits, currency handling — all of that is in WC_Coupon::is_valid() already. If your merchant asks for spend-more-save-more or a category-specific tier, you almost never need a plugin for it. You need three coupons with correct minimum-spend thresholds and the right individual-use setting, and a tiny auto-apply layer if you want the checkout to feel magical.

Second, the discipline fact. The reason WooCommerce could delete thirteen thousand lines of code is not that plugins are bad. It is that the store’s team went back to first principles and asked what the promotion actually was, in the language of the platform they were already on. That is unglamorous work. It is also the work that makes a WooCommerce site survive its fifth year without a rebuild.

For agencies, there is a specific opportunity in the next four weeks. WooCommerce 11.0 lands on July 28, 2026 with product object caching on by default for new stores (announced June 17) and Action Scheduler 4.0.0. That is the same window where most merchants start planning Q4 promotions. A promotion architecture built on native coupons cooperates cleanly with the new caching layer; a promotion architecture built on a heavy plugin that hooks every cart calculation may not.

What I would do (or not do) about it

I would not rush a live store into ripping out a working discount plugin this month. If the current setup survives without incident, wait until after the next BFCM. The value of this article is not “delete your plugin today”; it is that you now have a reference implementation, on the WooCommerce developer blog, that you can point at when the finance team asks whether the plugin is really necessary.

What I would do this week is smaller. Open your merchant’s list of active discount and pricing plugins. For each one, write down in one sentence what promotion it actually runs. Then check whether that promotion can be expressed with native coupons — minimum spend, product or category restriction, exclude sale items, usage limit, individual-use. In almost every case I have looked at, the answer is yes for two out of three. That is the shortlist for the next refactor.

For new stores I have started to default to native coupons plus a tiny custom auto-apply module, closely modelled on Boro’s pattern. Not the exact code — that PR is still a draft — but the shape. One flag on the coupon, one hook on woocommerce_after_calculate_totals, one re-entrancy guard, one twelve-hour cache. Twenty-odd lines of PHP in a site-specific plugin. That module has zero opinion on what the promotion is; it only knows how to apply and remove coupons that already validate.

One warning. Do not put an auto-apply layer in a mu-plugin that also injects marketing UI on the cart page. Keep the mechanical layer (apply and remove) separate from the presentational layer (banners, tier explainers, progress bars). The whole point of the woocommerce.com case study is that the mechanical layer stayed small enough that you could read it in one sitting. If you couple the two, you lose that property immediately.

The real headline here is not 12,888 lines of code. It is that a store as visible as woocommerce.com went into its biggest week of the year on a promotion engine short enough to fit on a laptop screen, and it worked. That is the version of WordPress and WooCommerce I have been arguing for since I started this shop, and it is nice to see the mothership prove it in production.