100,000+ Stores Run This WooCommerce Plugin  🔗 **Source:** [100,000+ Stores Run This WooCommerce Plugin](https://twitter.com/SybreWaaijer/status/2045660722168758336/?rw_tt_thread=True) > [!note]+ Document Notes > ```markdown > --- > tags: [WordPress, WooCommerce, Subscriptions] > author: Sybre Waaijer > source: Twitter > reference: [https://twitter.com/SybreWaaijer/status/2045660722168758336/?rw_tt_thread=True] > date created: {{date:YYYY-MM-DD}} {{time:HH:mm}} > --- > # 🏷️ Title: 100,000+ stores run this WooCommerce plugin > ## 🧭 Table of Contents > - [📝 Summary](#-summary) > - [📖 Main Content](#-main-content) > - [🗒️ Notes](#️-notes) > - [📚 References](#-references) > - [🗣️ Paraphrase](#️-paraphrase) > - [📰 Newsletter](#-newsletter) > - [✅ Action Items](#-action-items) > - [🧪 Hypotheses](#-hypotheses) > - [📊 Methodology](#-methodology) > - [❓ Questions](#-questions) > - [🔮 Future Research](#-future-research) > - [💡 Implications](#-implications) > - [🧠 Learning Styles Assessment](#-learning-styles-assessment) > - [📊 Accessibility Assessment](#-accessibility-assessment) > - [🌍 DEIB Assessment](#-deib-assessment) > - [✅ Logical Validity](#-logical-validity) > - [🛡️ DARVO Analysis](#-darvo-analysis) > - [🎯 Conclusion](#-conclusion) > ### 🔗 References > - Include links cited in or relevant to the article. > --- > ## 📝 Summary > - What happened: A WooCommerce Subscriptions bug (actually multiple bugs) silently set some subscriptions to manual payments, so renewals never auto-charged after checkout or product switches. > - Why it matters: Stores could lose ~7% of subscription revenue for years without any clear error signal, potentially hundreds of thousands per site. > - Key stakeholders: WooCommerce core & Subscriptions teams, payment gateway developers, WordPress/WooCommerce merchants, auditors/consultants. > - Risks and tradeoffs: Lost MRR, hidden churn, inaccurate metrics, possible customer confusion or involuntary “downgrades” to manual payment. > - Bottom line: Any store running WooCommerce Subscriptions—especially older installs—should audit subscription payment types and ensure they’re on fixed plugin versions. > --- > ## 📖 Main Content > - The thread explains that WooCommerce Subscriptions uses an internal flag to decide if a subscription should auto-charge via gateways like Stripe/PayPal or wait for manual payment. > - If this flag is incorrectly left on “manual,” renewals: > - Are never attempted automatically. > - Do not send failure emails. > - Move to “on hold” and rely on customers noticing and paying manually. > - The author originally reported a bug related to product switches breaking subscription payments, then performed a broader audit on a real store’s data from 2017–2024. > - They found three bugs: > - **Bug 1 – Stale cache**: After saving subscription dates, the order cache was not cleared, so later saves could reuse an object where the flag was still the default (manual). Fixed in `subscriptions-core 6.9.0`. > - **Bug 2 – Broken HPOS backfill**: Missing getters/setters prevented subscription metadata syncing correctly when HPOS data sync was on, causing bad or missing payment-related state. Fixed in `subscriptions-core 6.5.0`. > - **Bug 3 – Unnecessary re-fetch**: `wcs_create_subscription()` re-fetched the subscription from cache/DB instead of using the configured instance, discarding unsaved state, including the corrected payment flag. Fixed in `subscriptions-core 7.1.0`. > - Combined, these issues caused about **7%** of checkout-created subscriptions to start life with broken automatic payments while the initial checkout still succeeded. > - Over seven years, one audited store had **121 affected subscriptions** and **$43,274** in lost revenue; extrapolated to 100k+ installs and larger ARR, this could mean very large aggregate losses. > - The author urges WooCommerce store owners and consultants to: > - Verify plugin versions. > - Audit subscriptions for incorrect payment types. > - Add monitoring/alerts for unexpected manual renewals and “on hold” states. > --- > ### 🗒️ Notes > - WooCommerce Subscriptions relies on an *internal payment type flag* (“automatic” vs “manual”) that is easy to silently mis-set via bugs in how subscriptions are created or updated. > - When a customer checks out with Stripe or PayPal, the expected behavior is that their subscription will continue to be charged automatically without further action. > - If that flag is left on manual: > - The system never calls the payment gateway for renewals. > - No renewals fail in the usual way, so normal failure notifications are not triggered. > - The subscription just goes on hold, creating “invisible churn.” > - The author initially reported a product-switch bug that broke renewals, then broadened their analysis when they realized the underlying handling of subscription objects might be flawed. > - The three bugs have different root causes (caching, HPOS metadata synchronization, and object lifecycle), but all converge on losing the correct state for the auto-payment flag. > - Fix versions matter: > - Sites pinned to older `subscriptions-core` versions remain exposed. > - Even upgraded sites may have *legacy broken subscriptions* that will never self-heal without active correction. > - The real-store case study quantifies impact: tens of thousands in lost revenue from just 121 subscriptions across several years. > - There is an implied need for: > - Better end-to-end tests around subscription creation paths. > - Stronger observability (e.g., dashboards for “on hold” vs “active” subscriptions, and manual vs automatic payment mix). > - Safer caching and object APIs inside Subscriptions’ core. > --- > ## 📚 References > - [Sybre Waaijer – 100,000+ stores run this WooCommerce plugin (Twitter thread)](https://twitter.com/SybreWaaijer/status/2045660722168758336/?rw_tt_thread=True) > - [WooCommerce Subscriptions documentation](https://woocommerce.com/products/woocommerce-subscriptions/) > - [WooCommerce High Performance Order Storage (HPOS) overview](https://woocommerce.com/document/high-performance-order-storage/) > --- > ## 🗣️ Paraphrase > - The WooCommerce Subscriptions plugin had several long-standing bugs that caused some subscriptions created at checkout to be incorrectly set to manual payments, silently disabling automatic renewals and costing stores substantial recurring revenue. > - By auditing a single store’s historical data, the author found over a hundred affected subscriptions and more than forty thousand dollars in lost income, then traced the problem to three specific bugs that have been fixed in recent plugin versions but may still affect legacy data. > --- > ## 📰 Newsletter > In today’s WordPress corner, a vital heads-up for WooCommerce merchants and agencies: Sybre Waaijer uncovered multiple bugs in WooCommerce Subscriptions that silently disabled automatic renewals for a slice of customers. One real store lost over $43k in MRR because subscriptions quietly flipped to manual payments. > If you manage WooCommerce Subscriptions, now’s the time to: > - Confirm you’re running up-to-date `subscriptions-core` (≥7.1.0). > - Audit subscriptions where customers checked out with Stripe/PayPal but the payment type isn’t automatic. > - Review your monitoring: track “on-hold” subscriptions and unexpected manual renewals. > Useful starting points: > - WooCommerce Subscriptions: https://woocommerce.com/products/woocommerce-subscriptions/ > - HPOS overview: https://woocommerce.com/document/high-performance-order-storage/ > Stay safe, keep those renewals flowing, and consider building a small health-check report for your clients’ stores. > --- > ## ✅ Action Items > #### DevRel > - Document the subscription payment-type flag behavior in developer docs, including known historical bugs and fixed versions. > - Prepare a demo or blog post showing how to audit and repair affected subscriptions programmatically. > - Add example code for defensive checks around `wcs_create_subscription()` and caching with HPOS. > #### OSPO > - Encourage plugin teams to adopt stricter regression testing for payment and billing logic. > - Integrate subscription and payment-path checks into standard open source review and QA guidelines. > #### Community > - Share an auditing checklist for WooCommerce merchants in forums, Slack, and meetups. > - Encourage agencies to run one-time audits on legacy stores and communicate findings transparently to clients. > #### WordPress > - Core: No direct change, but highlight the need for robust plugin QA a 100,000+ stores run this WooCommerce plugin. I doubt any of them know their payments are broken. Any store with $1M ARR could be missing $700k+ in revenue. If you run WooCommerce Subscriptions, check your store. Yesterday, I reported a bug to WooCommerce that silently broke subscription payments after a product switch. Then I got worried: if they missed something this obvious, what else did they get wrong? So I started auditing. Within hours, I had found three more bugs. There were 121 affected subscriptions, and $43,274 in lost revenue. Here's what I found. WooCommerce Subscriptions has an internal flag that controls whether a subscription charges the customer automatically or waits for them to pay manually. When a customer checks out with (for example) Stripe or PayPal, this flag should be set to "automatic." If it isn't, subscription renewals silently stop working: no charge is attempted, no failure email is sent, and the subscription goes on hold until the customer notices and pays manually, or doesn't and churns. Bug 1 (stale cache): After saving subscription dates, the order cache was never cleared. Subsequent saves could serve a stale object with the flag still set to its default: manual. Fixed in subscriptions-core 6.9.0. Bug 2 (broken HPOS backfill): Missing getter/setter methods prevented subscription metadata from being properly synced to postmeta in HPOS when data sync is enabled. Fixed in subscriptions-core 6.5.0. Bug 3 (unnecessary re-fetch): wcs\_create\_subscription() returned a freshly fetched instance from cache/DB instead of the already-configured object. Any unsaved state, including the corrected flag, was silently discarded. Fixed in subscriptions-core 7.1.0. These three combined accounted for roughly 7% of all subscriptions created at checkout that were silently born broken, despite the customer paying successfully. For 7+ years (we have data from 2017–2024). Automatic payments NEVER fired for these subscriptions. Users never got renewal emails, either. The only way to know they were broken was if the customer noticed they lost access and contacted support, or if the merchant audited their database manually. Bug 4 (switch): When a customer upgrades or downgrades their subscription, the switcher flags the subscription as manual renewal; it only corrects the flag if the payment gateway changes. A customer switching plans while keeping the same gateway (e.g. Stripe to Stripe) cements the flag stuck on manual. I discovered this two days ago, when I found a happy customer in the store overview that I had just helped upgrade, with multiple valid cards on file, put "On Hold" because of a missed payment. For years, I've offered to help WooCommerce improve its code quality and performance. I dry-run code: I find bugs by reading. All four of these bugs are clearly visible in the source without needing to use the software. They could have been caught early. They weren't. The incompetence is immeasurable (well, actually, with the diagnostic queries in my next post, it might be measurable). Our store is small. WooCommerce Subscriptions powers hundreds of thousands of stores. If 7% of subscriptions were silently broken across even a fraction of them, we're looking at potentially millions of dollars in spoiled revenue industry-wide that could have been prevented. Perhaps even billions. None of this was disclosed well or at all. No admin notice. No email. No advisory. The fixes shipped under vague changelog lines like "Make sure we always clear the subscription object from cache after updating dates" and "Ensure proper backfilling of subscription metadata." One fix was labeled "Dev" instead of "Fix." Two don't appear in the GitHub release notes at all. No remediation tool or diagnostic query was provided. Store owners have NO way to know they're affected unless they manually audit their database. The woocommerce-subscriptions-core repo was archived in May 2025 after the code was absorbed into WooCommerce core — making the fix history harder to trace. If you run WooCommerce Subscriptions and used HPOS before mid-2024, check your store. Queries are linked in the tweet below. --- Here are the diagnostic queries and remediation steps for the switch bug. You must replace {prefix} with your actual WordPress table prefix (e.g., wp\_). Note: Do not run the remediation queries WITHOUT READING THEM FIRST. DO NOT RUN THEM ALL AT ONCE. Read each one, understand what it does, run them in order, and verify the results at each step before proceeding to the next. Always back up your database before running any SQL queries. Or, better yet, run them on a staging copy first to verify the results before applying to production. <https://t.co/IDYgFptfcY> --- While digging through the code, I also noticed how subscriptions-core handles payment gateways. Three methods — get\_available\_payment\_gateways(), gateway\_supports\_subscriptions(), and has\_available\_payment\_method() — are all hardcoded to accept only WooCommerce Payments. Not gated behind a filter or capability check. Just hardcoded string comparisons: if your gateway ID isn't "woocommerce\_payments," you're stripped out. The full WooCommerce Subscriptions plugin ($279/year, 3.2 stars, 100,000+ installs) overrides all three to properly check gateway capabilities, which is how it should work everywhere. But the base layer, subscriptions-core, is deliberately crippled at the class level to lock you into their gateway. From the people who invented WordPress hooks and filters, the system that makes the entire ecosystem extensible. In their own billing code, they didn't use it. They bypassed it entirely to privilege their own payment product. The same will happen to WordPress 7.0, by the way. It's a pattern. Oh, and over a year later, they STILL haven't fixed this: WooCommerce silently enables tracking without consent when you connect your store to their services. <https://t.co/i4hdgQJfQ0> That tracker collects store data — order counts, subscription stats, plugin versions. Which means WooCommerce potentially already knows exactly how many stores are affected and how much revenue was lost. They just haven't told anyone., 100,000+ Stores Run This WooCommerce Plugin, Sybre Waaijer, 01kphn247xwnfx0yjp3src5xb3.