WooCommerce 11 restores reduced stock when an order enters failed, but ERP and warehouse connectors may receive status and inventory events out of order. A retry or delayed webhook can apply the same change again or overwrite a newer reservation.
Use this for stores connected to an ERP, WMS, marketplace, POS, 3PL, reservation service, or custom inventory webhook that reacts to WooCommerce order and product changes.
Quick answer
Assign one immutable event ID and sequence to every synthetic transition, record local stock before and after, then delay and replay webhooks deliberately. The receiver must deduplicate events, reject stale versions, and reconcile from authoritative state rather than applying blind quantity deltas. Test failed, retry, recovered, cancelled, and refunded paths.
What to check first
- Document which system owns sellable, reserved, damaged, backordered, and in-transit quantities.
- Capture order ID, item ID, product or variation ID, stock-reduced flag, event ID, sequence, timestamp, old quantity, new quantity, and receiver result.
- Delay the failed-order webhook until after a new sale, deliver events out of order, and replay each event to expose blind-delta processing.
- Test gateway retry, manual recovery, cancellation, partial fulfillment, bundles, variations, and a warehouse acknowledgement timeout.
- Run a full product reconciliation after each scenario and compare order notes, WooCommerce stock, ERP ledger, reservations, and pick lists.
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 |
|---|
| Define inventory ownership | Document which system owns sellable, reserved, damaged, backordered, and in-transit quantities. | Replaying an event produces the same final inventory with no duplicate adjustment. |
| Add event IDs and monotonic versions | Capture order ID, item ID, product or variation ID, stock-reduced flag, event ID, sequence, timestamp, old quantity, new quantity, and receiver result. | A stale event cannot overwrite a newer sale or reservation. |
| Test delay, replay, and reordering | Delay the failed-order webhook until after a new sale, deliver events out of order, and replay each event to expose blind-delta processing. | Failed, recovered, cancelled, and fulfilled orders produce the documented ERP state. |
| Reconcile authoritative quantities | Test gateway retry, manual recovery, cancellation, partial fulfillment, bundles, variations, and a warehouse acknowledgement timeout. | Automated reconciliation detects and assigns every remaining difference. |
Why this usually happens
- Distributed webhooks do not guarantee delivery order.
- Connectors may apply deltas when the sender intended state replacement.
- Retries can arrive after a later successful transition.
- ERP reservations and WooCommerce stock can use different definitions of available quantity.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
event_id: stock_evt_91f2
order_id: 91042
product_id: 628
sequence: 184
transition: processing_to_failed
authoritative_qty: 14
receiver_last_sequence: 185
action: ignore_stale
reconciliation_delta: 0
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.
- Define inventory ownership
- Add event IDs and monotonic versions
- Test delay, replay, and reordering
- Reconcile authoritative quantities
- Alert on unresolved ledger drift
Decision rule
Pass when duplicate and stale events cause no quantity change, the newest authoritative state wins, every failure path is auditable, and all inventory systems reconcile after retries.
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
- Replaying an event produces the same final inventory with no duplicate adjustment.
- A stale event cannot overwrite a newer sale or reservation.
- Failed, recovered, cancelled, and fulfilled orders produce the documented ERP state.
- Automated reconciliation detects and assigns every remaining difference.
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, background work, or mixed-version fleets.
- Do not paste secrets, personal data, complete production payloads, or customer files into tickets or screenshots.
- Do not close the test until the final user-visible state and the server-side evidence agree.
Questions teams ask during testing
Should the webhook send a delta or final quantity?
A versioned final state is usually easier to make idempotent. If deltas are required, the receiver needs immutable event IDs and a durable processed-event ledger.
What if the ERP is temporarily offline?
Queue events with retry limits, preserve ordering metadata, and reconcile from current authoritative state when service returns.
When HandL WP should help
Bring in HandL WP when a production checkout, form, email, media pipeline, code-quality gate, or paid lead workflow is at risk. We can preserve evidence, isolate the failing layer, make the smallest corrective change, and verify the result across WordPress, connected services, logs, and the user journey.
If this is active on a production site, reconcile WooCommerce and ERP inventory.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references