WooCommerce 11.3, scheduled for the week of November 9, 2026, will let store owners filter the Analytics Orders report by payment method. The change, described in WooCommerce’s October 26 pre-release post, adds the gateway as a column in the report table, a column in the CSV export and a new advanced filter. A store that runs a card processor next to a bank transfer or buy now, pay later option can see orders for each gateway inside Analytics.
The first beta is available for testing now. WooCommerce describes 11.3 as a big release, with 1,310 commits and 117 contributors so far.
How payment method data reaches Analytics
The Analytics reports draw on a summary table called wc_order_stats. Until 11.3, only the main wc_orders table had a payment_method column. The new release adds a nullable payment_method column to wc_order_stats that holds the gateway ID, the same value WC_Order::get_payment_method() returns. A refund takes the gateway of the order it refunds, and orders with no gateway stay empty. A new index, idx_payment_method_date_paid_status, covers payment method, paid date and status.
Older orders are filled in by a background database update, wc_update_1130_backfill_order_stats_payment_method(), which runs through Action Scheduler in batches of 500 orders. Until that job finishes, older rows show no payment method. For reporting tools that pull from the REST API, items from reports/orders gain a payment_method property, and both reports/orders and reports/orders/stats accept payment_method_is and payment_method_is_not arguments that take lists of gateway IDs.
Database work on stores with large order tables
WooCommerce adds the column and index during the update. On MySQL 8.0 and later with InnoDB, the column is added instantly and the index builds without blocking writes, but MySQL still reads every row to build it. The index needs about 47 MB for every 1 million orders, and on older servers such as MySQL 5.7, adding the column rebuilds the whole table. WooCommerce’s advice is to plan the update for a quiet time on large stores.
Custom reporting code carries its own risk. Code that joins wc_orders into an Analytics query through the woocommerce_analytics_clauses_* filters and refers to payment_method without a table name will fail with an error that the column is “ambiguous,” and the Orders report will show an empty table. Adding the table name or the join alias to the column fixes it, and WooCommerce says the fix also works on earlier versions. Code that reads _payment_method from post meta is not affected.
Stricter checks on refunds sent through the REST API
Starting with 11.3, POST requests to /wp-json/wc/v3/orders/{order_id}/refunds validate line-item refund amounts before a refund is created. A request whose line items add up to more than the refund amount, or more than a line’s remaining refundable balance, now returns HTTP 400 or 422 with a woocommerce_rest_* error code. WooCommerce says such requests could previously leave order records and Analytics reporting inconsistent.
The advisory tells integrations to check the response before treating a refund as created, and to correct the allocation rather than resend the same payload. Order management, accounting and dispute tools that post partial refunds with line items are the ones most likely to notice.
Smaller changes that touch checkout and reporting
Three other items in the release affect how stores take and track money.
- A logged-in customer’s VAT exemption now stays in the session when the account is saved. Before 11.3, a VAT-exempt customer whose payment was declined could be charged tax on the retry.
- Stores first installed on WooCommerce 11.3.0 or later no longer show the legacy Reports item in the WooCommerce menu, though the page still works and a woocommerce_show_legacy_reports_menu filter can bring it back. Existing stores see no change.
- Merchants can pick a refund and returns policy page on the Page setup screen in Advanced settings, and WooCommerce adds structured data pointing search engines to it.
The Products API, Product Variations API and Store API products endpoint also change how on_sale works with include or exclude. A request for on_sale=true with an include list now returns only products that are both included and on sale.
Bundles and add-ons get a parent item filter
In a separate October 27 advisory, WooCommerce introduced the woocommerce_store_api_cart_item_parent_item_key filter and a read-only parent_item_key field in Store API cart items. Extensions that add items on behalf of another cart item, such as bundles, composite products, mix and match, force sells, chained products and “frequently bought together” tools, can use it to mark those items as children. The Product Button block’s “N in cart” count then leaves them out, so a product that arrived only inside a bundle no longer reads “1 in cart.” WooCommerce says nothing breaks if an extension ignores the filter.
What to check on a staging copy
Stores already scheduling server work around the PHP2Shell issue affecting PHP 8.1 and older can fold 11.3 testing into the same staging cycle. Based on WooCommerce’s advisories, the checks below cover the payment and reporting changes.
- After the background update finishes, confirm that every active gateway appears in the Analytics Orders payment method filter.
- Search custom code for woocommerce_analytics_clauses_* callbacks that use a bare payment_method column.
- Send a partial refund with line items through any connected integration and watch for 400 or 422 responses.
- On stores with large order histories, time the database update on staging before scheduling it in production.
- Add a bundle or add-on product to the cart and look at the “in cart” counts on the items it contains.
What WooCommerce 11.3 changes for store owners
For merchants, the headline in 11.3 is a payment method filter in Analytics Orders, backed by a new column and index in wc_order_stats and a background backfill of older orders. Large stores face a heavier database update, especially on MySQL 5.7, and developers with custom Analytics SQL need to name the table when they use payment_method. Refund requests through the REST API now fail with 400 or 422 errors when line amounts do not add up, and bundle extensions gain a way to keep child items out of “in cart” counts. With release planned for the week of November 9, the beta gives stores a few days to run those checks first.