A WooCommerce Stripe webhook can fail because of a signature mismatch, timeout, plugin fatal, WAF rule, or temporary origin error. Retrying the event should update the intended order once and preserve the Stripe event ID as evidence.
Use this when Stripe shows failed webhook attempts, WooCommerce orders remain pending, or a manual resend might create duplicate notes, stock changes, emails, or fulfillment actions.
Quick answer
WooCommerce Stripe Webhook Retry and Idempotency Test should be handled with a narrow evidence-first workflow: capture event, match order, check partial work, then verify the result before making broader changes.
What to check first
- Capture the Stripe event ID, type, endpoint, signature result, attempts, and response codes.
- Match the payment intent and metadata to one WooCommerce order before retrying.
- Review order notes and logs for evidence that part of the handler already completed.
- Fix the endpoint, signature secret, timeout, WAF, or PHP error before resending.
- Resend one event and confirm the order transition and downstream actions occur once.
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 event | Capture the Stripe event ID, type, endpoint, signature result, attempts, and response codes. | The retry returns a successful endpoint response for the original event ID. |
| Match order | Match the payment intent and metadata to one WooCommerce order before retrying. | The intended order moves to the correct status once. |
| Check partial work | Review order notes and logs for evidence that part of the handler already completed. | Stock, email, fulfillment, and analytics actions are not duplicated. |
| Fix endpoint | Fix the endpoint, signature secret, timeout, WAF, or PHP error before resending. | Order notes and Stripe logs provide a complete event timeline. |
Why this usually happens
- The endpoint can return a failure after changing the order but before acknowledging the event.
- Multiple webhook secrets can remain after staging or endpoint migrations.
- WAF and cache rules can interfere with POST requests even when checkout succeeds.
- Custom status hooks can repeat stock, email, or fulfillment actions on every retry.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
wp wc order get 10531 --user=1 --fields=id,status,transaction_id,date_modified
wp post meta get 10531 _stripe_intent_id
wp wc shop_order_note list 10531 --user=1
# Compare with the Stripe event ID before resending.
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 event
- Match order
- Check partial work
- Fix endpoint
- Retry once
What to tell the client or owner
Record the event ID, payment intent, order ID, original response, fixed cause, retry response, and every downstream action checked.
Production verification checklist
- The retry returns a successful endpoint response for the original event ID.
- The intended order moves to the correct status once.
- Stock, email, fulfillment, and analytics actions are not duplicated.
- Order notes and Stripe logs provide a complete event timeline.
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 and webhook failures.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Reconcile dispute events to order operations
Use the WooCommerce Stripe dispute webhook and order note reconciliation to map events, orders, deadlines, owners, retries, and final outcomes.
Join Stripe retries to the oldest action
Add the WooCommerce Stripe webhook retry and oldest-action join to reconcile provider attempts, queue claims, order state, idempotency, and one payment outcome.
Helpful references