WooCommerce 11.0 uses a 60-minute default when custom code calls ReserveStock::reserve_stock_for_order without a duration. Integrations that relied on an implicit or different hold can keep scarce inventory unavailable longer than expected or release it too early relative to payment completion.
Use this for custom checkout flows, headless stores, payment links, deposits, delayed gateways, reservation plugins, flash sales, or any extension that calls reserve_stock_for_order directly.
Quick answer
WooCommerce 11.0 Reserve Stock 60 Minute Hold Audit should be handled with a narrow evidence-first workflow: find custom callers, define gateway holds, run low-stock tests, then verify the result before making broader changes.
What to check first
- Search custom code and dependencies for reserve_stock_for_order and record whether each call supplies a duration.
- Map the intended hold time for card, bank transfer, buy-now-pay-later, payment link, and custom checkout flows.
- Create low-stock staging products and observe reservation, payment completion, cancellation, timeout, and release timestamps.
- Pass an explicit duration for flows that should not use the new 60-minute default.
- Monitor held stock, unpaid orders, failed payments, scheduled cleanup, and oversell attempts after rollout.
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 |
|---|
| Find custom callers | Search custom code and dependencies for reserve_stock_for_order and record whether each call supplies a duration. | Each checkout flow has a documented reservation duration and owner. |
| Define gateway holds | Map the intended hold time for card, bank transfer, buy-now-pay-later, payment link, and custom checkout flows. | Paid orders retain stock while failed, cancelled, and expired attempts release it as expected. |
| Run low-stock tests | Create low-stock staging products and observe reservation, payment completion, cancellation, timeout, and release timestamps. | Cleanup jobs run close enough to the intended time under production queue load. |
| Set explicit durations | Pass an explicit duration for flows that should not use the new 60-minute default. | A two-customer low-stock test neither oversells nor blocks inventory beyond policy. |
Why this usually happens
- Custom callers can omit a duration because older behavior was not explicit.
- A gateway can complete after the reservation expires or fail while stock remains held.
- Action Scheduler or WP-Cron delays can shift the actual release time.
- High-demand products make even a small hold mismatch visible to customers.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
wp db query "SELECT order_id, stock_reduced, date_created_gmt FROM wp_wc_orders ORDER BY date_created_gmt DESC LIMIT 20"
wp action-scheduler list --search=stock --fields=action_id,hook,status,scheduled_date_gmt
# Use staging order IDs and confirm the site's table prefix first.
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.
- Find custom callers
- Define gateway holds
- Run low-stock tests
- Set explicit durations
- Monitor release timing
What to tell the client or owner
Provide the caller, supplied duration, gateway, order status path, reservation and release timestamps, queue delay, and low-stock test result.
Production verification checklist
- Each checkout flow has a documented reservation duration and owner.
- Paid orders retain stock while failed, cancelled, and expired attempts release it as expected.
- Cleanup jobs run close enough to the intended time under production queue load.
- A two-customer low-stock test neither oversells nor blocks inventory beyond policy.
Mistakes to avoid
- Do not judge the fix by one browser or the homepage only.
- Do not delete evidence before recording usernames, file paths, timestamps, and response headers.
- Do not add a cache, security, or tracking plugin while the original problem is still unclear.
- Do not leave test users, temporary debug logs, or broad API keys active after verification.
When HandL WP should help
Bring in help when this affects leads, checkout, search visibility, malware risk, paid media reporting, or a client production site. HandL WP can trace the issue through WordPress, hosting, cache, tracking, and Search Console, then verify the workflow after the technical fix.
If this is active on a production site, audit WooCommerce inventory behavior.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references