A WooCommerce Stripe webhook can fail before WordPress, during signature verification, inside the gateway handler, while changing the order, or in a downstream scheduled action. Stripe may show Delivered while the wrong endpoint, account, mode, API version, or order mapping prevents the intended result. Retries and manual resends add another risk: the same event can be processed more than once unless the integration records stable identities and makes state transitions idempotent.
Use this when Stripe payment status and WooCommerce order status disagree, signatures fail, webhook deliveries return 4xx or 5xx, orders stay pending, or replay creates duplicate notes, stock changes, emails, or conversions.
Quick answer
Start with one Stripe event ID and one WooCommerce order ID. Record account, test or live mode, endpoint ID, endpoint URL, signing-secret version, API version, delivery attempts, HTTP response, WooCommerce gateway log, order notes, scheduled actions, stock, email, and analytics events. Signature verification requires the unchanged raw request body, Stripe-Signature header, and secret for that endpoint. Return a fast 2xx after durable acceptance, process work asynchronously when appropriate, and make every downstream transition safe to repeat.
Test scenarios to run
Run the same controlled fixture across these branches. Write down the expected result before testing so a surprising response is easy to identify.
| Scenario | Fixture | Expected result |
|---|
| Valid delivery | Correct raw body and secret | 2xx and one transition |
| Wrong secret | Endpoint mismatch | Signature failure with no state change |
| Duplicate event | Same event ID | No duplicate side effect |
| Out-of-order event | Later state arrives first | Object state is reconciled safely |
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence | Verification |
|---|
| Anchor on one event and order | Confirm the Stripe account, mode, endpoint, URL, selected event types, API version, signing secret, TLS, DNS, and WordPress route. | Stripe shows the intended endpoint received a 2xx response for the controlled event. |
| Verify endpoint and signature inputs | Open the exact event delivery and preserve event ID, object ID, created time, attempt time, response code, response body, and next retry. | The correct WooCommerce order reaches the expected state exactly once. |
| Trace the WooCommerce transition | Match the raw request and signature result to the WooCommerce Stripe log, request ID, order lookup, order note, and gateway state transition. | Order notes, stock, scheduled actions, customer email, CRM, and conversion events are complete and not duplicated. |
| Make processing replay-safe | Inspect duplicate event handling, out-of-order delivery, automatic retry, manual resend, Action Scheduler, stock, email, CRM, and conversion deduplication. | Signature, endpoint, mode, and API version evidence is stored without exposing secrets. |
What to check first
- Confirm the Stripe account, mode, endpoint, URL, selected event types, API version, signing secret, TLS, DNS, and WordPress route.
- Open the exact event delivery and preserve event ID, object ID, created time, attempt time, response code, response body, and next retry.
- Match the raw request and signature result to the WooCommerce Stripe log, request ID, order lookup, order note, and gateway state transition.
- Inspect duplicate event handling, out-of-order delivery, automatic retry, manual resend, Action Scheduler, stock, email, CRM, and conversion deduplication.
- Replay only a controlled event after idempotency is proven, then reconcile Stripe payment state, order state, totals, inventory, email, and analytics.
Field notes
- Write the expected result before making a change and keep one repeatable canary fixture.
- Record versions and timestamps because release, cache, and delivery behavior can change between tests.
- Use one canonical owner page for each query family and give every supporting page a distinct task.
- Close the incident only after the public workflow and the downstream record both pass verification.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
event_id=evt_example
object_id=pi_example
endpoint_id=we_example
mode=live
delivery_status=failed
http_status=500
order_id=4812
processed_event_id=none
next_action=fix_handler_then_replay_once
Why this usually happens
- Test and live endpoints use different secrets and event histories.
- JSON middleware changes the raw body before signature verification.
- A WAF, cache, redirect, or maintenance page changes the expected POST response.
- Order state logic assumes events arrive once and in creation order, which Stripe does not guarantee.
Decision rule
Do not resend a production event until the handler can identify prior processing and protect order state, stock, email, CRM, and analytics from duplication. Fix the first failed layer, then replay one controlled event and reconcile the complete order record.
Production verification checklist
- Stripe shows the intended endpoint received a 2xx response for the controlled event.
- The correct WooCommerce order reaches the expected state exactly once.
- Order notes, stock, scheduled actions, customer email, CRM, and conversion events are complete and not duplicated.
- Signature, endpoint, mode, and API version evidence is stored without exposing secrets.
Safe fix order
Use a sequence that makes each result easy to prove. Stop when new evidence changes the scope or owner of the problem.
- Anchor on one event and order
- Verify endpoint and signature inputs
- Trace the WooCommerce transition
- Make processing replay-safe
- Reconcile every downstream effect
Mistakes to avoid
- Changing production files, recipients, hooks, cache settings, or update policy before preserving the failing request and current configuration.
- Treating one warning, one successful test, or one dashboard status as a complete diagnosis without checking the next system in the path.
- Testing with a different account, order state, form embed, locale, plugin version, or cache state than the real failure.
- Publishing a new broad answer when an established owner already exists, which splits internal links and creates query overlap.
Questions teams ask during testing
Can I run this directly on production?
Read-only inspection is often appropriate on production when access is controlled and output is redacted. Make backups first, test state-changing steps on staging, define rollback, and schedule any production change for a monitored window.
How do I avoid a false positive?
Match the exact installed version, locale, request, order, form, role, cache state, and integration path. Repeat the same fixture after the fix and keep evidence from both runs.
What evidence should I keep?
Keep UTC time, site and plugin versions, request or record ID, command, expected result, actual result, relevant logs, configuration snapshot, change, rollback point, and final verification. Redact secrets and personal data.
When should a specialist take over?
Escalate when checkout, customer email, lead capture, security, payment state, production updates, or several plugins are affected, or when the safe next step is unclear. A short evidence packet saves time and limits guesswork.
What to tell the client or owner
Give the site owner a concise evidence packet containing the affected workflow, exact versions, UTC test time, fixture or record ID, expected and actual result, logs, change made, rollback point, final verification, owner, and next review date. Remove passwords, tokens, payment details, and personal data before sharing it.
When HandL WP should help
Bring in help when this affects leads, checkout, search visibility, security, 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, have HandL WP trace the Stripe event through WooCommerce.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Test API-version changes and timestamp failures separately
For a webhook API-version upgrade, use the WooCommerce Stripe shadow endpoint test to compare payloads without duplicating order mutations. For timestamp or tolerance failures, use the Stripe clock skew and signature audit before widening the recency window.
Helpful references