WooCommerce Subscriptions 8.6.1 Renewal Mode Bug: Fix

Problem

WooCommerce Subscriptions 8.6.1 shipped a small-looking note on April 23, 2026, but the bug class behind it is not small at all.

WooCommerce said the release fixes two renewal-state problems for stores running HPOS:

• when a subscriber upgraded or downgraded on the same payment gateway, the renewal mode could stay unchanged
• when the subscriber switched to a different payment gateway, the subscription could incorrectly flip from manual to automatic renewal

That second one is especially bad because it overrides subscriber intent. The first one is quieter, but it still leaves subscription state out of sync with what the store thinks just happened.

The official source is WooCommerce Subscriptions 8.6.1: renewal state improvements for HPOS stores. If you are running Subscriptions on HPOS and your store supports plan switching or payment-method changes, you should read it closely.

Why It Happens

Subscription state bugs like this usually sit between three systems:

• the subscription object itself
• the payment token / gateway state
• the switching logic that maps a customer action back to renewal mode

When any of those get out of sync, the storefront can look fine while billing behavior is wrong underneath.

I have seen this in real work after migrations where teams assume “manual vs automatic” is derived automatically from the gateway every time. It is not that simple. Renewal mode can be persisted state, and once a switch flow writes the wrong thing, later jobs trust that stored value.

That is why I do not like patching subscription metadata directly. It hides the actual bug path and makes future upgrades harder to trust.

If you are also dealing with stores that have HPOS migration baggage underneath these renewal-state issues, pair this with WooCommerce 10.7 HPOS Sync on Read Fix. The two problems often show up on the same stores.

The Fix

The immediate fix is straightforward: update to 8.6.1 or later. The practical fix is auditing any subscriptions that went through plan or gateway switching before the update.

1. Update first

Do not spend hours normalizing renewal mode on an old version that still contains the bug.

2. Audit switched subscriptions

I like a narrow script that lists subscriptions where payment method and renewal mode deserve a second look.

$subscriptions = wcs_get_subscriptions(
    [
        'subscriptions_per_page' => 100,
        'subscription_status'    => ['active', 'on-hold'],
    ]
);

foreach ( $subscriptions as $subscription ) {
    $manual         = $subscription->is_manual();
    $payment_method = $subscription->get_payment_method();
    $next_payment   = $subscription->get_date( 'next_payment' );

    if ( ! $manual && empty( $payment_method ) ) {
        error_log(
            sprintf(
                'Subscription #%d is auto-renewal without a payment method',
                $subscription->get_id(),
            )
        );
    }

    if ( $manual && ! empty( $payment_method ) && ! empty( $next_payment ) ) {
        error_log(
            sprintf(
                'Subscription #%d is manual on %s with next payment %s',
                $subscription->get_id(),
                $payment_method,
                $next_payment
            )
        );
    }
}

This is not perfect, but it catches the most obvious “automatic renewal state without the data to support it” mismatch.

3. Reconcile state through the Subscriptions API, not raw metadata

If you confirm the renewal mode is wrong, fix it through the object methods, not through direct post meta updates:

$subscription = wcs_get_subscription( $subscription_id );

if ( $subscription && $subscription->get_payment_method() === 'bacs' ) {
    $subscription->set_requires_manual_renewal( true );
    $subscription->save();
}

That keeps the write path aligned with the plugin’s own expectations.

4. Review plan-switch and gateway-switch customisations

If the store adds custom logic during upgrades, downgrades, or gateway changes, read that code carefully. The official fix covers the core bug, but custom switch flows can still reintroduce bad state if they assume too much.

5. Run a follow-up Health Check

Once the store is updated, I run the Subscriptions Health Check and look specifically for subscriptions that still appear suspicious. It is the fastest way to confirm the upgrade cleaned up the practical fallout.

The Practical Rule

Whenever WooCommerce says a release fixes renewal-state handling, I assume there are stores already carrying wrong state in production.

For this 8.6.1 issue, the safe order is:

1. update the plugin
2. audit subscriptions affected by switching flows
3. repair state through the API
4. re-check with the Health Check tool

That is cheaper than waiting for the first angry renewal ticket.

CTA

If your store is carrying years of subscription history, custom gateway code, and HPOS migration baggage, see my services. I help WooCommerce teams fix recurring revenue bugs without guessing at order state or renewal logic.