The November 3 WooPayments security advisory requires checking the installed WooPayments version against its fixed-release table. Updating WooCommerce core, or the separate WooCommerce Subscriptions extension, does not prove that WooPayments has been updated.
Start with the plugin name, then the release branch
The official WooPayments advisory addresses bundled subscriptions functionality and extends an earlier fix. It provides fixed builds for several release lines. Examples include 11.2.0 to 11.2.1, 11.1.0 to 11.1.1, and 11.0.0 or 11.0.1 to 11.0.2. It directs versions older than 9.0.0 to 11.2.1. Check the complete live table for other branches.
Do not apply the number from a different product's advisory. WooCommerce, WooPayments and WooCommerce Subscriptions have independent version histories. If your site also uses the separate Subscriptions extension, retain its security and site-control checklist as a separate task.
Record what is installed, not what you expected to install
Open Plugins, Installed Plugins on the intended site and find WooPayments. Record its installed version and activation state. Verify the site's identity before taking a screenshot: similar production and staging hostnames are easy to confuse.
For administrators using WP-CLI, this read-only inventory can help identify the installed packages:
wp --skip-plugins --skip-themes plugin list --skip-update-check --fields=name,status,version --format=table
Run it only from the intended WordPress installation or with an explicitly verified path. The WP-CLI reference documents the displayed fields and skip options. Must-use plugins still load with these flags. A bootstrap failure should be diagnosed, not treated as proof that the payment plugin is absent.
This command intentionally does not fetch available updates. Compare its installed-version result with the vendor advisory separately. Do not mistake a deployment label, an update email or an enabled automatic-update setting for a second reading of the running site's package.
Keep one row per site copy
Inventory production and every reachable staging, development or older copy that might still contain the plugin. Name an owner for each row, including sites managed by another agency or hosting team. Mark an unchecked copy as unknown rather than assuming it inherits production's result.
Keep the inventory private. It should contain site identity, installed package version, required fixed branch, verified completion time and unresolved error. Do not add payment secrets, customer records or full server environment dumps.
If an old copy is no longer needed, coordinate its access restriction or retirement with the responsible owner. Do not delete it as part of a version-check exercise. It may contain needed historical data or still receive an integration callback.
A rollout ledger needs separate rows for production and other reachable copies. Blank cells mean unverified, not protected. Example worksheet, not a real customer inventory. Explanatory diagram.
Update through the trusted channel and verify again
Use the normal trusted plugin update path or coordinate with the host that owns deployments. Preserve a restorable backup and the current version record. The completion step is a fresh installed-version check on that same copy, followed by the relevant functional test.
If an update is unavailable, record the current branch and exact update error, then ask WooCommerce Support or the hosting owner for the supported route. Do not download a similarly named package from an unrelated site or copy internal subscription-library files between plugins.
Separate a failed download, an installation failure and a site that still serves old deployed files. They need different evidence. For managed deployments, confirm which release directory or image serves the live request. A successful build log alone is not enough.
Test the gateway without creating real charges
Use an isolated staging environment and WooPayments test-mode guidance for diagnostic orders. Confirm the environment cannot send real fulfillment instructions or customer emails. Do not switch a live trading store into test mode casually.
Choose one ordinary test purchase and record the order identifier, expected amount and gateway result. Include a subscription-related fixture only if that functionality is actually part of the store's configuration. Keep the test small enough that a mismatch can be traced to one attempt.
Do not manually execute a production renewal queue as an update test. If a test fails, record the failing transition: order creation, gateway response, stored order status or downstream action. A gateway connection problem is not automatically evidence that the security update did not install.
Know what the version check cannot prove
A confirmed fixed package closes one verification task. It does not establish whether an earlier compromise occurred or explain an unrecognized account, key or file change. Preserve suspicious evidence and escalate separately if the store shows unexplained activity. Avoid claiming either exploitation or a clean incident history solely from the version number.
For an agency handoff, provide the per-site completion ledger, outstanding owners and one representative test outcome. HandL WP can verify WooCommerce payment updates when installation status, deployment ownership or payment behavior remains unclear.
The WooCommerce 11.2.2 checkout and database checklist covers the separate core release. Keep both tasks visible when the store uses both products, and close each with its own evidence.
Sources reviewed November 5, 2026. Examples and diagrams are diagnostic aids, not customer test results.