Description

The Subscriptions search in wp-admin -> WooCommerce -> Subscriptions is very slow. It takes as much as 30 seconds on our client website.

We find that this query in WCS_Subscription_Data_Store_CPT::search_subscriptions() is way too slow:

SELECT DISTINCT p1.post_id
FROM wp_postmeta p1
WHERE p1.meta_value LIKE '%phrase%' AND p1.meta_key IN ('_order_key','_billing_address_index','_shipping_address_index','_billing_email')

Looking as the SQL EXPLAIN I can see that on our client website it has to check 4,000,000 fields.When I split that query into 4 individual queries - one for each meta_key, then it's much faster. The above takes 17 to 20 seconds.

We found the The individual queries only take about 4 seconds when I sum the times for each:

SELECT SQL_NO_CACHE DISTINCT p1.post_id
FROM wp_postmeta p1
WHERE p1.meta_value LIKE '%phrase%' AND p1.meta_key IN ('_order_key');

SELECT SQL_NO_CACHE DISTINCT p1.post_id
FROM wp_postmeta p1
WHERE p1.meta_value LIKE '%phrase%' AND p1.meta_key IN ('_billing_address_index');

SELECT SQL_NO_CACHE DISTINCT p1.post_id
FROM wp_postmeta p1
WHERE p1.meta_value LIKE '%phrase%' AND p1.meta_key IN ('_shipping_address_index');

SELECT SQL_NO_CACHE DISTINCT p1.post_id
FROM wp_postmeta p1
WHERE p1.meta_value LIKE '%phrase%' AND p1.meta_key IN ('_billing_email');

Here's what the Query Monitor plugin reports without the fix:

• total time of 28 seconds
• 5 slow queries, the slowest taking 25

seconds

And here's with the fix:

• total time of 4.1 seconds
• 8 slow queries, but all the 4 individual search queries are still much faster than the single query from before

How to test this PR

1. Make sure you have a lot of Subscriptions in your database. In our case it's 30,000.
2. Go to wp-admin -> WooCommerce -> Subscriptions
3. Enter some search phrase and click "Search Subscriptions"
4. If you have about 30,000 subscriptions you will wait for 20 - 30 seconds to get the results

Product impact

• [ ] Added changelog entry (or does not apply)
• [yes] Will this PR affect WooCommerce Subscriptions? yes/no/tbc, add issue ref
• [no] Will this PR affect WooCommerce Payments? yes/no/tbc, add issue ref

Fixes #144 partially.

Description

This PR only replaces get_posts() call in get_users_subscription_orders() with wc_get_orders().

Some key points:

• I follow this guide to pass the meta_query bit.
• I change the field name following this map.
• I use customer_id parameter, instead of passing it in meta_query.

How to test this PR

1. Install woocommerce-subscriptions-core as a plugin.
2. Since I get_users_subscription_orders() isn't called anywhere, I use wp-console to call it.

Actually, I wondered if we can just delete get_users_subscription_orders() but then I think someone out there (another plugin or custom code) might depend on it.

3. Run WC_Subscriptions_Order::get_users_subscription_orders(); and make sure base branch and PR branch returns the same output.

4. I also add this code as a mu-plugin, in a file wp-content/mu-plugins/something.php.

define('SAVEQUERIES', true);
add_action( 'shutdown', function() {
    global $wpdb;
    foreach($wpdb->queries as $q) {
        file_put_contents('/tmp/debug.log', "-----start\n" . $q[0] . "\n-----end\n");
    }
} );

To log queries going to the database. I search for subscription_renewal. I format the query and diff the query made using base branch vs PR branch.

There is some diff but looks OK:

Product impact

• [ ] Added changelog entry (or does not apply)
• [x] Will this PR affect WooCommerce Subscriptions? no
• [x] Will this PR affect WooCommerce Payments? no

Fixes #321

Note This PR is targeting the hpos-admin-ui-support branch due to the changes required for admin screens in HPOS environments awaiting merge

Description

Bulk actions are missing from the Subscriptions listing page in wp-admin when HPOS is enabled.

NB: Bulk actions will not work with this PR, there is an open issue for this https://github.com/woocommerce/woocommerce/issues/35750.

There was a small refactor to go along with this change. Previously, the function print_bulk_actions_script() appends the Subscription bulk actions to the dropdown list using jquery. This was due to the bulk_actions-edit-shop_subscription previously not allowing the addition of items but only the removal. This restriction was dropped in WP 4.7.0 (2016-12-06.)

CPT HPOS

How to test this PR

With HPOS enabled and using HPOS Admin UI support and associated WooCommerce PR

1. With HPOS enabled, Go to 'Subscriptions' in wp-admin.
2. Click on the 'Bulk actions' drop down and compare the options when the store is in CPT mode.

Product impact

• [x] Added changelog entry (or does not apply) - This will be rolled up into one changelog entry for admin screens working under HPOS.
• [x] Will this PR affect WooCommerce Subscriptions? yes/no/tbc, add issue ref
• [x] Will this PR affect WooCommerce Payments? yes/no/tbc, add issue ref
• [ ] Added deprecated functions, hooks or classes to the spreadsheet

Fixes #58

Description

Adds JS linting

How to test this PR

1. npm run lint:js
2. should have no errors or warnings

Product impact

• [x] Will this PR affect WooCommerce Subscriptions? no
• [x] Will this PR affect WooCommerce Payments? no

Fixes #142

Description

When order data is moved to custom tables, updating order meta using update_post_meta() will no longer work. This PR updates all cases of update_post_meta() where an Order ID is passed - thankfully there wasn't many cases in our codebase 😅

How to test this PR

Testing wcs_set_objects_property() changes

This function is pretty well covered in unit tests, however to test nothing is broken a simple test would be to process a subscription renewal order and make sure the renewal order has the correct meta data.

1. With an active subscription, process a renewal order
2. Confirm the new renewal order has _billing_address_1 metadata set

Testing save_old_paypal_meta() changes

This one was a little trickier to test so I just hacked some of the conditions because the only changes we cared about is the order updating post meta:

1. Edit the save_old_paypal_meta() function to pass if conditions using, true ||
2. Manually set $subscriptions to be $subscriptions = [ 101823 => wcs_get_subscription( 101823 ) ];
3. Run the following snippet:

add_action( 'admin_footer', function() {
	update_post_meta( 101823, '_paypal_subscription_id', 'S-fake1234' );
	update_post_meta( 101823, '_payment_method', 'paypal' );

	WCS_PayPal_Standard_Switcher::save_old_paypal_meta( 101824, [] );
} );

4. Confirm the $order meta is set in the DB

Product impact

• [x] Added changelog entry (or does not apply)
• [x] Will this PR affect WooCommerce Subscriptions? yes/no/tbc, add issue ref
• [ ] Will this PR affect WooCommerce Payments? yes/no/tbc, add issue ref

Fixes #323

Note This PR is targeting the hpos-admin-ui-support branch due to the changes required for admin screens in HPOS environments awaiting merge.

Description

The custom filters that we add to the Subscriptions list screen were not showing when HPOS is enabled.

A new filter has been added in HPOS environments for this purpose woocommerce_order_list_table_extra_tablenav additionally the usage of global $typenow; has been removed with checks against the order type instead.

How to test this PR

1. On a HPOS enabled site, go to the Subscriptions listing screen in wp-admin.
2. The filters should be visible.

NB: The filters for product/customers are unreadable due to the width. There is an open issue for this.

Product impact

• [x] Added changelog entry (or does not apply)- This will be rolled up into one changelog entry for admin screens working under HPOS.
• [ ] Will this PR affect WooCommerce Subscriptions? yes/no/tbc, add issue ref
• [ ] Will this PR affect WooCommerce Payments? yes/no/tbc, add issue ref
• [ ] Added deprecated functions, hooks or classes to the spreadsheet

Warning This PR is semi-blocked by upstream changes in WC https://github.com/woocommerce/woocommerce/pull/35658 these changes should be okay to merge prior to this but need these changes for testing.

fixes #293 fixes #223 fixes #298 fixes #322 fixes #321

Description

PR bringing a number of fixes to Admin UI based on the changes introduced in https://github.com/woocommerce/woocommerce/pull/35658

How to test this PR

HPOS

⚠️ Important: Parts of this flow will be broken and errors will be thrown. For HPOS this PR is aimed at laying the groundwork. File any usability issues you come across while testing.

1. Enable HPOS tables.
2. Purchase subscriptions.
3. Go to the WooCommerce > Subscriptions admin screen.
4. Note that the page loads and subscriptions are listed.
5. Click on a subscription to edit it.
6. Note the page loads.

CPT

⚠️ Important: This PR shouldn't break any CPT flows or UIs. This PR needs to be releasable to existing CPT stores.

1. Enable CPT tables.
2. Purchase subscriptions.
3. Go to the WooCommerce > Subscriptions admin screen.
4. Note that the page loads and subscriptions are listed.
   • Filter by customer
   • Filter by product
   • filter by status
   • use the bulk actions
   • use the individual actions by hovering a subscription (suspend, reactivate etc).
5. Click on a subscription to edit it.
6. Note the page loads.
   • Change the billing schedule
   • Change the subscription data (change the customer, parent order, address data etc.)
7. Save and make sure things save correctly.

Product impact

• [ ] Added changelog entry (or does not apply)
• [ ] Will this PR affect WooCommerce Subscriptions? yes/no/tbc, add issue ref
• [ ] Will this PR affect WooCommerce Payments? yes/no/tbc, add issue ref
• [ ] Added deprecated functions, hooks or classes to the spreadsheet

Describe the bug

To support subscriptions stored in different data stores, we need to replace all cases of get_post_type() with WC_Data_Store::load( 'subscription' )->get_order_type( $id ).

Doing a search of get_post_type( in subscriptions-core code there's 15 instances of this still being used.

In #153 we only targetted code which used this function on WC Orders, but as part of tackling this issue we should replace all cases.

Updating get_post_type( $subscription_id )

'shop_subscription' == get_post_type( $post_id )

Replace with:

'shop_subscription' === WC_Data_Store::load( 'subscription' )->get_order_type( $id )

Updating get_post_type( $product_id )

I could only find one instance where we're using get_post_type() with product ID inside user_can_not_delete_subscription()

0 === strpos( get_post_type( $args[2] ), 'product' )

The issue withWC_Data_Store::load( 'product' )->get_product_type( $id ) is that it formats product types i.e. 'product_variation' is returned as just 'variation' so there's not a simple one-to-one replacement for this one.

We can probably just ignore this one case for now.

Fixes #145

Description

This PR updates our WCS_Related_Order_Store_Cached_CPT and WCS_Related_Order_Store_CPT classes to use WC CRUD methods to be able to support both WP Posts and High-Performance Order Storage (HPOS) environments.

Note - Doesn't include renaming our classes

This PR doesn't rename our classes to remove the reference to Custom Post Types with the _CPT suffix. Renaming these classes and deprecating the class isn't a critical part to this refactor, so I will create a separate issue to tackle this at a later time.

Note - Can't test with HPOS

This PR does not update our WCS_Post_Meta_Cache_Manager class which triggers a lot of the functionality in these related orders store classes, this means you cannot test this PR with HPOS enabled. You must be using WP Posts.

What are these caches?

Subscription related orders (renewals, switch and resubscribe orders) record their relationship in order meta. Historically finding these subscription related orders was costly as it required querying the database for orders with specific meta (a meta query and post join). To fix this in WC Subscriptions 2.3 we introduced a persistent caching layer. In subscription meta we now store a single key to keep track of the subscriptions related orders.

Now to get a subscription's list of renewal orders we simply just refer to this single meta key on the subscription rather than multiple values stored on every order.

These cache classes act as gatekeepers by providing APIs for fetching related orders get_related_order_ids() and they also house all the hooks for keeping the cache up to date. If a renewal order is trashed, this class is responsible for removing that record for the subscription's related order cache.

There are 2 public facing pages that include some details of these classes:

• Subscription Caches → Subscription Related Order Cache
• What’s New in Subscriptions 2.3 → Performance

What's new?

There's a fair bit changing in this PR so let's go through it:

• New Subscriptions data store functions:
  • delete_all_metadata_by_key - Previously we used WP's delete_metadata() to remove every cache meta we had stored. There's no equivalent in the WC HPOS data stores so we created our own.
  • ~get_metadata_by_key - When fetching related order cache meta data we need to make sure it's fetched directly from the database. This function pulls the metadata directly from the new orders table or if using wp posts, it calls get_post_meta()~
• Replaced instanced of get_post_meta, update_post_meta & delete_post_meta with relevant WC CRUD method.
• Replaced uses of get_posts() with new wcs_get_orders_with_meta_query()
• ~New helper function get_subscription_with_cache_meta() to help us get an instance of WC Subscriptions with all of our related order cache meta in memory. This solves a problem I was facing with trying to fetch the cache returning an empty array and trying to update the cache, creating a duplicate postmeta entry.~

How to test this PR

Testing this PR should hopefully be pretty straightforward and the main thing we need to test is making sure the subscription's related-order cache is properly updated when its list of related orders changes, and when an order is updated we also need to make sure the relevant related order meta is updated on the orders.

Flows to test:

1. After processing a renewal order, the renewal order is visible in the related orders table on the Edit Subscription page
2. After processing a renewal order, the new renewal order ID is inside the _subscription_renewal_order_ids_cache on the subscription
3. After processing a renewal order, make sure the renewal order has the _subscription_renewal and proper subscription ID saved in postmeta.
4. After trashing a renewal order, the renewal order ID is removed from the _subscription_renewal_order_ids_cache array in subscription postmeta
5. After trashing a renewal order, the renewal order should not show up in the related orders table on the subscription

Product impact

• [ ] Added changelog entry (or does not apply)
• [x] Will this PR affect WooCommerce Subscriptions? yes/no/tbc, add issue ref
• [x] Will this PR affect WooCommerce Payments? yes/no/tbc, add issue ref
• [x] Added deprecated functions, hooks or classes to the spreadsheet

Fixes #192

Description

This PR displays the related orders table meta box on the "Edit Order" and "Edit Subscription" when HPOS is enabled with non-HPOS compatibility.

In addition:

• [x] PHPCS formatting has been fixed in related files. (mostly moved to #280)
• [x] PHPCS errors/warnings have been addressed in related files. (mostly moved to #280)
  • Some low-hanging errors/warnings have been addressed.
• [x] Added deprecated functions, hooks or classes to the spreadsheet - yes, 3 hooks added

How to test this PR

1. Enable the COT feature and turn on COT (see guide here).
2. Go into WooCommerce > Settings > Advanced > Custom Data Stores.
3. Make sure "Use the WooCommerce orders tables" is enabled.
4. Purchase a subscription and note the order ID.
5. From WP admin dashboard, go to WooCommerce > Orders and view the "Edit Order" page for the order ID noted above.
6. Notice that the Related Orders table meta box is visible and contains a link to the related Subscription. You should not see the current order within this table.
7. Click on the related Subscription to be taken to the "Edit Subscription" page. You should not see the current subscription within this table.
8. Notice that the Related Orders table meta box is visible and contains a link to the parent order.
9. Clicking on the parent order will take you to the "Edit Order" page as above.

Recommended compatibility tests (checked = tested by PR author):

• [x] WCPay
• [x] WC Subs
  • [x] with WC Subs activated + HPOS enabled + syncing on, ~the Related Orders table isn't rendered correctly and following PHP Notice occurs~ it uses a newly deprecated hook. Need to update this issue to clarify: https://github.com/woocommerce/woocommerce-subscriptions/issues/4417
• [x] WC 6.8.0 – toggling between this subs-core branch & trunk results in identical output.
• [x] WC HPOS enabled + syncing off
• [x] WC HPOS enabled + syncing on
• [x] WC HPOS disabled

Product impact

• [x] Added changelog entry (or does not apply)
• [ ] Will this PR affect WooCommerce Subscriptions? yes/no/tbc, add issue ref
• [ ] Will this PR affect WooCommerce Payments? yes/no/tbc, add issue ref

Describe the bug

In #177, a fix was implemented to prevent a divide by zero error if the store is running on PHP8. The following code is used to check for this:

// In rare cases quantity can be zero. Check first to prevent triggering a fatal error in php8+
                if ( 0 !== $item_to_renew['qty'] ) {
                    $_product->set_price( $price / $item_to_renew['qty'] );
                }

However, it looks like $item_to_renew['qty'] is not an integer (presumably it is a string), so this check doesn't have the desired effect. We had a customer report (5461670-zd-woothemes) reporting a fatal error and proposing the following fix:

// In rare cases quantity can be zero. Check first to prevent triggering a fatal error in php8+
                if ( 0 !== intval($item_to_renew['qty']) ) {
                    $_product->set_price( $price / intval($item_to_renew['qty']) );
                }

This should prevent this error happening in all cases.

To Reproduce

See #175 (alternatively, the customer who raised this issue suggested it occurs when a new customer logs into their store).

Expected behavior

We don't see any fatal errors related to division by zero errors.

• [x] Does this issue affect WooCommerce Subscriptions? yes: 5461670-zd-woothemes
• [ ] Does this issue affect WooCommerce Payments? TBC

Blocked by https://github.com/Automattic/woocommerce-subscriptions-core/pull/336

Describe the bug

When the post record becomes out of sync with the HPOS table record, WC will attempt to sync the subscription using the post record as the authoritative table.

This doesn't work with some subscription-specific data. eg dates.

To Reproduce

1. Enable HPOS and syncing (see screenshot below).
2. Go into the database and manually alter the next payment date of a subscription.
3. View the subscription via the admin screen or customer my account page.
4. The next payment date should update to reflect the change you made manually. On trunk currently, it won't.

Expected behavior

The subscription should sync all data from the post record when it gets out of sync.

Actual behavior

Next payment dates and possibly other data points don't sync.

Product impact

• [ ] Does this issue affect WooCommerce Subscriptions? yes/no/tbc, add issue ref
• [ ] Does this issue affect WooCommerce Payments? yes/no/tbc, add issue ref

Additional context

From the brief investigation I've done, this is caused by a bug in OrdersTableDataStore::set_order_prop() which is called from OrdersTableDataStore::migrate_post_record()

Fixes #260

Work in progress/prototype branch. Feel free to take over :)

Description

How to test this PR

1. Go to …
2. Click on …

Product impact

• [ ] Added changelog entry (or does not apply)
• [ ] Will this PR affect WooCommerce Subscriptions? yes/no/tbc, add issue ref
• [ ] Will this PR affect WooCommerce Payments? yes/no/tbc, add issue ref
• [ ] Added deprecated functions, hooks or classes to the spreadsheet

Fixes #221 Fixes #195

Description

This PR updates all of the WP Post-related hooks we were using to hook onto the trashing, deleting and untrashing of orders and subscriptions in the WC_Subscriptions_Manager class to now use the CRUD/HPOS equivalent hooks so that this functionality continues to work on stores that are using custom order tables.

This PR consists of the following changes:

1. Moved all of the trash, untrash & delete hooks into a new function that is ran on woocommerce_loaded
2. Added new add_action()'s calls for when HPOS is enabled to hook onto the new WC order hooks
3. Updated the existing maybe_trash_subscription() & maybe_cancel_subscription() functions to use CRUD methods

1. Moved actions into a new function on woocommerce_loaded

In order to load the new hooks we need to run wcs_is_custom_order_tables_usage_enabled() but this function only works after WC has been loaded.

While testing this PR I was getting errors due to some WC classes/instances not existing yet when trying to check if HPOS is enabled.

To fix this, I moved these hooks into their own function which is attached to the WC loaded do action.

2. New Add Actions

Here are all of the _post hooks changing in this PR and their new HPOS equivalent hooks:

• wp_trash_post is now woocommerce_before_trash_order
• untrashed_post is now woocommerce_untrash_order
• before_delete_post is now woocommerce_before_delete_order
• trashed_post is now woocommerce_trash_order
• deleted_post is nowwoocommerce_delete_order`

To avoid breaking backwards compatibility, I made it so these new action hooks are only used on stores with HPOS enabled.

3. Updating functions to use CRUD methods

Most of the changes in these functions are pretty self-explanatory but there are some I wanted to make note of. order_data_store::untrash_order() method only exists in the OrderTablesDataStore class so I made it so we only use this function if it exists, otherwise, fall back to using the wp_untrash_post() function.

When fixing fix_trash_meta_status() to work in CRUD, I couldn't use update_meta_data() as it was creating duplicate rows in the database, so I had to use the read_meta() and update_meta() approach which writes this data directly to the DB and works in both HPOS and none-HPOS environments.

How to test this PR

There are 4 main flows that need to be tested in this PR:

1. Trashing a parent order, cancels the subscription first, then trashes it
2. Trashing a parent order correctly sets the _wp_trash_meta_status to wc-cancelled if the subscription previously had an active status.
3. Untrashing a parent order also untrashes the subscription (Note: untrashed subscriptions go to pending status)
4. Deleting a parent order deletes the subscription

My own testing on this PR:

HPOS off:

• [x] Trash a parent order
  • [x] Confirm subscription was cancelled first (need to check order notes)
  • [x] Confirm subscription is trashed
  • [x] Confirm _wp_trash_meta_status is set on subscription
• [x] Untrash parent order
  • [x] Confirm subscription is also untrashed
• [x] Delete a parent order
  • [x] Confirm subscription has been deleted from DB
• [x] Confirm woocommerce_subscription_trashed action hook is triggered after trash
• [x] Confirm woocommerce_subscription_deleted action hook is triggered after delete

HPOS on, syncing off:

• [x] Trash a parent order
  • [x] Confirm subscription was cancelled first (need to check order notes)
  • [x] Confirm subscription is trashed
  • [x] Confirm _wp_trash_meta_status is set on subscription
• [x] Untrash parent order
  • [x] Confirm subscription is also untrashed
• [x] Delete a parent order
  • [x] Confirm subscription has been deleted from DB
• [x] Confirm woocommerce_subscription_trashed action hook is triggered after trash
• [x] Confirm woocommerce_subscription_deleted action hook is triggered after delete

HPOS on, syncing on:

• [x] Trash a parent order
  • [x] Confirm subscription was cancelled first (need to check order notes)
  • [x] Confirm subscription is trashed
  • [x] Confirm _wp_trash_meta_status is set on subscription
• [x] Untrash parent order
  • [x] Confirm subscription is also untrashed
• [x] Delete a parent order
  • [x] Confirm subscription has been deleted from DB
• [x] Confirm woocommerce_subscription_trashed action hook is triggered after trash
• [x] Confirm woocommerce_subscription_deleted action hook is triggered after delete

WC 6.8 (HPOS off):

• [x] Trash a parent order
  • [x] Confirm subscription was cancelled first (need to check order notes)
  • [x] Confirm subscription is trashed
  • [x] Confirm _wp_trash_meta_status is set on subscription
• [x] Untrash parent order
  • [x] Confirm subscription is also untrashed
• [x] Delete a parent order
  • [x] Confirm subscription has been deleted from DB
• [x] Confirm woocommerce_subscription_trashed action hook is triggered after trash
• [x] Confirm woocommerce_subscription_deleted action hook is triggered after delete

Product impact

• [x] Added changelog entry (or does not apply)
• [x] Will this PR affect WooCommerce Subscriptions? yes/no/tbc, add issue ref
• [x] Will this PR affect WooCommerce Payments? yes/no/tbc, add issue ref
• [x] Added deprecated functions, hooks or classes to the spreadsheet

Description

When (automatically) adding a new renewal, taxes for the corresponding renewal order should be recalculated. Tax rates in WooCommerce may be subject to change, e.g.:

• VAT rates may be reduced for a certain amount of time
• VAT rates may change, increase, decrease for certain countries

Is there any reason why taxes are not being (re-) calculated for renewals based on the current settings? For orders where prices do not include taxes this may lead to higher/lower total prices but nevertheless taxes would at least be precise and not wrong.

Testing instructions

1. Create a new subscription
2. Update a tax rate, e.g. change percentage
3. Generate a renewal for the old subscription
4. See how the renewal does not reflect current tax rates.

https://github.com/Automattic/woocommerce-subscriptions-core/blob/6b8c650c06d92eb1cb2bdb79e3e98aec14920414/woocommerce-subscriptions-core.php#L5

The plugin description string currently could be more sternly worded to clarify that running subs-core as a plugin is only appropriate for local development. Suggest something like "Development package of core subscriptions functionality. Not recommended for testing or production."

Fixes #330, please see for details.

Please also see discussion in p1670014386600359-slack-C029ME0FYRZ for how this affects processing subscription payment method changes with WooCommerce Payments in particular.

Description

See #330 for a description.

How to test this PR

Use the Change Payment Method instructions:

https://woocommerce.com/document/subscriptions/customers-view/#section-11

To simulate a failure, you could either block the network request w/ Developer Tools or use a test card that will decline. Instead of a fatal error because of a failure, you should instead see a notice with the error.

Product impact

• [ ] Added changelog entry (or does not apply)
• [x] Will this PR affect WooCommerce Subscriptions? yes/no/tbc, add issue ref
• [x] Will this PR affect WooCommerce Payments? yes/no/tbc, add issue ref