WooCommerce 11.3 Update: What to Test Before You Install It

The WooCommerce 11.3 update is scheduled for the week of 9 November 2026, and it is a feature release, not a security release. You do not need to rush it. You do need to test it, because the beta notes list several behavior changes that can break custom code, integrations and refund automation without any visible error on the storefront.

Everything below comes from the WooCommerce 11.3 pre-release post (published 26 October) and the WordPress.org plugin API, read on 10 November 2026. At that point WordPress.org still listed 11.2.2 as the current version, so 11.3 had not shipped and the beta notes can still change. Recheck the final release notes before you act.

What is confirmed about the WooCommerce 11.3 update

The post describes 11.3 as available for testing as 11.3.0-beta.1, with a release week of 9 November. It reports 1,310 commits and 117 contributors so far, so it is a large release. It includes a database update, and it lists a set of breaking changes and deprecations. It is not flagged as a security release. The most recent WooCommerce security release is still 11.2.2 from 4 November, which I covered in the 11.2.2 security update checklist. If you have not installed that one, it comes first.

Who needs to care, and who probably does not

A store with a stock theme, a handful of well-maintained plugins and no custom code is the least exposed. Most of the listed changes affect one of these groups:

Stores with custom code or a developer-built plugin: several items are changes to internal methods, hooks and SQL.
Stores that automate refunds through the REST API, for example from a helpdesk, ERP or accounting tool.
Stores with a very large order table, because of the database update.
Agencies and extension authors, who should read the full list of breaking changes.

I cannot tell from the notes how many extensions are affected, and I have not tested the beta, so treat the list as a review task, not a known problem.

Refunds through the REST API can now fail instead of succeeding

This is the item I would test first, because a refund integration failing quietly is a money problem. For POST /wp-json/wc/v3/orders/{order_id}/refunds, the notes say explicit line_items amounts are now validated before a refund is created. The checks include that each allocation refers to a line on the same order, that line amounts do not exceed the original or remaining refundable balance, and that the line total does not exceed the top-level amount.

In the notes’ words, invalid requests “can now return HTTP 400 or 422, with a woocommerce_rest_* error code, rather than creating a refund.” The example given is amount: "3" with a line refund_total of 4, which returns 400 with woocommerce_rest_invalid_refund_amount.

The gotcha is on the caller’s side. An integration that sloppily rounds line amounts used to get a refund created and may now get a 400 it does not handle. The notes say to handle 400 and 422 as validation failures and to correct the allocation rather than retry the same payload. If you use a tool that refunds through the API, ask its vendor, or test a partial refund on staging and check what the tool reports.

The MCP endpoint is removed

The notes say 11.3 “removes its deprecated /wp-json/woocommerce/mcp endpoint and its REST API key connection path.” Clients should connect through the WordPress MCP Adapter plugin with an application password instead. If you never connected an AI or automation client to your store this way, nothing changes. If someone on your team did, find out before updating, because that connection will stop working.

Custom code: the changes to look for

Ask your developer, or search your own plugin and theme code, for these items from the breaking-changes list:

Single Product context: the protected extract_single_product_inner_block_names() method and the $product_id and $single_product_inner_blocks_names properties are removed. PHP subclasses using them are affected.
Product filters: URL filters now use the Product Filters engine. Extensions should change query args such as max_price instead of the generated meta_query or tax_query clauses. A new woocommerce_product_filter_params hook exists, and the notes say only taxonomy changes are supported in 11.3.
Products API: combining on_sale with include or exclude now behaves predictably. The notes’ example: on_sale=true&include=10,13 used to return six products and now returns only product 13. A feed or app that relied on the old result will see different data.
Analytics SQL: custom queries joining wc_orders with a bare payment_method column fail with an “ambiguous” error, so qualify the column.
VAT exemption: the exempt flag and calculated shipping now persist when a customer account is saved. Code that relied on a save clearing set_is_vat_exempt( true ) must set the flag both ways. The notes suggest testing an exempt customer through a declined payment and a retry.
Shop page template: reading _wp_page_template for the Shop page returns archive-product on a block theme even if a custom template is saved. The stored value is unchanged.

Smaller items include the legacy Reports menu being hidden on stores first installed on 11.3 or later (the page itself still works), and the woocommerce_json_search_found_customers filter using the user ID as the key instead of 0.

The database update on large stores

The notes say 11.3 adds a nullable payment_method column and an index to the wc_order_stats table, then backfills existing orders in the background through Action Scheduler, 500 per batch. They give the index size as about 47 MB per million orders, and say that on MySQL 5.7 adding the column rebuilds the whole table, so large stores should plan the update for a quiet time.

Practically: take a backup first, update outside your busy hours, and afterwards check the Action Scheduler queue (Tools > Scheduled Actions) until the backfill finishes. If your host runs a slow queue, order analytics may lag while it catches up. Your database version is in Tools > Site Health > Info.

A safe order for the update

Install WooCommerce 11.2.2 first if you have not, on its own, and confirm checkout works.
Wait for the final 11.3 release notes. Do not install the beta on a store that takes orders. The pre-release post says to use the WooCommerce Beta Tester plugin on a non-production site.
Take a backup, copy the live store to staging, and update there.
Run the tests that match the list above: a normal order, a partial refund from the admin, a refund from any connected tool, an exempt customer if you sell tax-exempt, and the Shop page on your theme.
Check the PHP error log, then update live outside peak hours. I would also avoid updating on a Friday, since a refund or tax issue found late is harder to staff.

If you want the general method for staging, see how to update WooCommerce plugins safely. If something breaks afterwards and you cannot tell which plugin is responsible, finding a plugin conflict without taking the live site down walks through narrowing it down safely.

A last point on timing: the final release can differ from the beta, and a 11.3.1 may follow. Recheck the WooCommerce developer blog when 11.3 lands, and again a week later.