When WooCommerce 11.3 shows payment methods for new orders but not older ones, check the Analytics backfill before rebuilding reports or editing order records. The report uses its own lookup data. A valid gateway on the order can coexist temporarily with an incomplete reporting value.
Use protected staging for the 11.3 prerelease. This checklist concerns historical data completeness, not payment processing or a recommendation to install beta software on a live store.
First distinguish missing data from a failed request
Open Analytics > Orders with a narrow date range containing known fixtures. Inspect whether the request succeeds and whether the table contains orders with blank payment methods, or whether the report fails completely.
An explicit SQL ambiguous-column error belongs to the payment_method query repair guide. Waiting for backfill will not correct malformed SQL. Conversely, rewriting a query is not the first response to a successful report with unfinished historical data.
Understand what is being populated
The implementation adds payment_method to wc_order_stats and populates older rows in background batches. The value is the gateway identifier, while the report can display a friendlier gateway title. Refund reporting takes the gateway from the original order; an order with no gateway is a different case from an unprocessed historical row.
Do not compare a display label with a raw identifier and call it a mismatch. Record both forms in your worksheet, along with the order ID, order date, status and reporting date range. Keep names, addresses and payment credentials out of the worksheet.
Select four records that reveal different failures
Choose a known old order with a gateway, a recent sandbox order, a controlled refund and a legitimate no-gateway fixture. Establish the expected source data through the supported order interface. Never create a real refund merely to populate this test.
Compare each record with the report after synchronization. If only older records are incomplete, inspect background progress. If the recent fixture is also missing, investigate synchronization and errors rather than assuming the historical task is the whole problem.
Reconcile four order classes before treating every missing Analytics payment method as a failed migration. Synthetic explanatory visual.
Inspect Scheduled Actions without resetting versions
Use the store's supported Scheduled Actions interface to find the relevant update and its state. Record pending, running, completed and failed work, the latest attempt time and the first actionable error. A large pending queue needs capacity analysis, not a repeated manual trigger every few seconds.
Do not copy development instructions that lower WooCommerce's stored database version into production. Such instructions can be useful for reproducing an upgrade on a disposable development database, but they are not a routine repair for a real store's migration state.
If a task failed, ask the maintainer to identify the failure before retrying it through the supported recovery path. Confirm whether another worker already owns the job. Preserve database and application logs for the same time window so a timeout is not confused with a permissions or schema error.
Allow for a store-sized migration
A tiny staging fixture demonstrates behavior, not the runtime of a production table with millions of rows. Before rollout, have the host review database engine, table size, available disk and expected background load. Schedule observation of the reporting update as well as the plugin deployment.
Do not run a full Analytics reimport solely because one column is empty immediately after an upgrade. That can create extra work while hiding the original evidence. Use the existing migration's documented recovery procedure and verify progress against the same fixture IDs.
Reconcile the export before trusting a breakdown
Once background work completes, compare the order table, payment-method filter and downloaded CSV for the same date and status settings. Open the raw CSV header rather than assuming an old spreadsheet's fixed column positions still apply. Keep the original export for comparison.
A passing record shows the expected gateway for the old and recent orders, the intended refund relationship and a separately understood no-gateway case. It also records the completed job state. Request a WooCommerce reporting investigation if those layers disagree, supplying redacted fixture IDs and the failed action details rather than a full customer export.
Reference and review date
Primary technical reference. Sources checked October 29, 2026. The proposed procedures and original diagrams are explanatory test aids, not claims of customer testing or measured improvements.