WooCommerce 11 adds wc_maybe_increase_stock_levels() to the failed-order status transition. Core restores only when the order indicates stock was reduced, but extensions may already increase quantities from payment failure, webhook, cancellation, or custom status hooks. The audit must prove which component owns restoration and whether repeated transitions remain idempotent.
Use this on staging for stores with payment gateways, subscriptions, ERP sync, warehouse connectors, custom order statuses, reservation plugins, or code attached to failed, cancelled, payment-failed, and stock hooks.
Quick answer
Create controlled orders with known stock, exercise on-hold to failed and pending to failed paths, and record the stock-reduced flag before each transition. Replay the webhook and status action. Pass only when legitimate reduced stock returns exactly once and transitions that never reduced stock leave inventory unchanged.
What to check first
- Inventory every callback that changes product stock during failed, cancelled, refunded, and payment-failed workflows.
- Record order status, product stock, reserved stock, reduced-stock flag, hook name, callback priority, request ID, and timestamp before each transition.
- Test pending to failed, on-hold to failed, processing to failed, failed to failed replay, failed to on-hold, and a payment webhook delivered twice.
- Include simple, variable, backordered, managed and unmanaged stock, bundles, subscriptions, and an ERP-owned item where those extensions are active.
- Confirm customer emails, order notes, analytics, and warehouse exports do not claim a restoration that did not occur.
Diagnostic table
Use this table to keep the work practical. It connects the symptom to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Map every stock-writing callback | Inventory every callback that changes product stock during failed, cancelled, refunded, and payment-failed workflows. | On-hold to failed restores the exact ordered quantity once. |
| Build a transition and product matrix | Record order status, product stock, reserved stock, reduced-stock flag, hook name, callback priority, request ID, and timestamp before each transition. | Pending to failed does not increase stock when no reduction occurred. |
| Run each path with correlation IDs | Test pending to failed, on-hold to failed, processing to failed, failed to failed replay, failed to on-hold, and a payment webhook delivered twice. | Webhook and manual replay leave the final quantity unchanged. |
| Remove or guard duplicate restoration code | Include simple, variable, backordered, managed and unmanaged stock, bundles, subscriptions, and an ERP-owned item where those extensions are active. | ERP, reservation, email, and analytics records match the order ledger. |
Why this usually happens
- Older extensions may implement their own failed-order restoration because core did not previously attach this helper to that transition.
- A gateway can deliver the same failure webhook more than once.
- Manual status edits and automated payment callbacks can race on separate workers.
- Reservations and physical stock can be released by different components.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
order_id: 84122
path: on-hold_to_failed
product_id: 402
stock_before_order: 12
quantity_ordered: 2
stock_before_failed: 10
stock_reduced_flag: true
restoration_owner: woocommerce_core
replayed_webhook: true
final_stock: 12
result: pass
Safe fix order
Do the work in a sequence that makes each result easy to prove. Stop if a step produces new evidence that changes the incident scope.
- Map every stock-writing callback
- Build a transition and product matrix
- Run each path with correlation IDs
- Remove or guard duplicate restoration code
- Replay events and reconcile final inventory
Decision rule
Pass when each legitimately reduced line returns once, unreduced lines never increase, duplicate events are harmless, and the order flag, notes, stock ledger, and external inventory agree.
What to tell the client or owner
Give the owner the affected versions, exact workflow, observed result, business impact, evidence location, temporary control, named owner, and next review time. Remove credentials and personal data from shared screenshots and logs.
Production verification checklist
- On-hold to failed restores the exact ordered quantity once.
- Pending to failed does not increase stock when no reduction occurred.
- Webhook and manual replay leave the final quantity unchanged.
- ERP, reservation, email, and analytics records match the order ledger.
Mistakes to avoid
- Do not change several plugins, cache rules, or infrastructure settings before preserving a baseline.
- Do not treat one successful test as proof for retries, alternate clients, or delayed background work.
- Do not paste secrets, personal data, or complete production payloads into tickets or screenshots.
- Do not close the test until the final user-visible state and server-side evidence agree.
Questions teams ask during testing
Does WooCommerce 11 restore every failed order automatically?
No. The helper checks whether stock was previously reduced. Custom extensions can still alter the outcome, which is why callback and replay testing matters.
Should an extension remove its failed-order stock hook?
Only after its supported version matrix proves WooCommerce core owns the same operation. Otherwise add a version-aware guard and regression tests.
When HandL WP should help
Bring in HandL WP when this affects a production site, paid lead flow, checkout, email delivery, or a managed fleet. We can preserve evidence, isolate the failing layer, make the smallest corrective change, and verify the result across WordPress, the external service, logs, and the user journey.
If this is active on a production site, audit WooCommerce failed-order inventory.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Test bundle and subscription renewal inventory
Extend the core audit with the bundle and composite stock restoration test to reconcile parent and component lines. For recurring orders, use the subscription renewal stock restoration test to follow failure, retry, recovery, and cancellation.
Reconcile failed-order stock with external inventory
After confirming local restoration ownership, use the failed-order ERP webhook ordering test to delay, reorder, replay, and reconcile inventory events across WooCommerce, reservations, ERP, warehouse, and fulfillment systems.
Helpful references