WooCommerce Stripe webhooks can receive HTTP 429 from a CDN, WAF, host, reverse proxy, or application rate limiter. Repeated manual retries can worsen the limit and create duplicate downstream work.
Use this when Stripe reports 429 webhook attempts, orders stay pending, or the endpoint recovers only after traffic drops.
Quick answer
WooCommerce Stripe Webhook 429 Retry Runbook should be handled with a narrow evidence-first workflow: capture 429 proof, match the order, find limiting layer, then verify the result before making broader changes.
What to check first
- Capture event ID, endpoint, attempt times, response headers, Retry-After, and source layer.
- Match the payment intent and event metadata to one WooCommerce order.
- Identify whether CDN, WAF, host, proxy, or WordPress code generated the 429.
- Check endpoint latency and concurrent webhook or Action Scheduler load before raising limits.
- Apply a narrow exception or capacity fix, wait for the retry window, and replay one event.
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 |
|---|
| Capture 429 proof | Capture event ID, endpoint, attempt times, response headers, Retry-After, and source layer. | The original event returns a successful endpoint response after the retry window. |
| Match the order | Match the payment intent and event metadata to one WooCommerce order. | The intended order changes state once. |
| Find limiting layer | Identify whether CDN, WAF, host, proxy, or WordPress code generated the 429. | Stock, email, fulfillment, and analytics actions are not duplicated. |
| Fix capacity or rule | Check endpoint latency and concurrent webhook or Action Scheduler load before raising limits. | Rate-limit logs show a narrow webhook exception or measured capacity fix. |
Why this usually happens
- Generic bot limits can treat signed webhook POST requests as abusive traffic.
- A slow endpoint can exhaust concurrency and trigger upstream rate controls.
- Action Scheduler backlog can make webhook processing look like endpoint failure.
- Ignoring Retry-After can extend the incident.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
curl -sSI https://example.com/wc-api/wc_stripe | grep -Ei 'HTTP/|retry-after:|server:|x-cache:'
wp action-scheduler status
wp wc order get 10618 --user=1 --fields=id,status,transaction_id,date_modified
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.
- Capture 429 proof
- Match the order
- Find limiting layer
- Fix capacity or rule
- Replay one event
What to tell the client or owner
Record the event ID, response headers, limiting layer, rule or capacity change, retry time, and order-side proof.
Production verification checklist
- The original event returns a successful endpoint response after the retry window.
- The intended order changes state once.
- Stock, email, fulfillment, and analytics actions are not duplicated.
- Rate-limit logs show a narrow webhook exception or measured capacity fix.
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, repair WooCommerce payment webhook failures.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references