Stripe can retry a webhook while WooCommerce also schedules follow-up work. Looking at either system alone can hide the oldest customer-impacting action, a stuck claim, duplicate event processing, a completed payment with a pending order, or a stale retry that should be acknowledged without repeating side effects.
Use this for WooCommerce payment operators, agencies, support engineers, and stores diagnosing Stripe webhook delays or duplicate handling.
Quick answer
Choose one safe Stripe test event and join event ID, type, created time, delivery attempt, endpoint response, WooCommerce action ID, hook, group, scheduled time, claim, attempts, order ID, payment intent, transaction ID, order notes, stock, email, and final status. Keep Stripe event ID as the idempotency boundary. Repair the oldest action that blocks customer state, then replay only through the supported test or provider path and prove a single payment outcome.
What to check first
- Record WooCommerce, Stripe extension, Action Scheduler, worker, PHP, webhook endpoint, and secret versions.
- Create a test-mode event and preserve Stripe event, payment intent, order, transaction, and scheduled action IDs.
- Capture provider attempt times, HTTP status and body, action schedule, claim, attempts, exception, and completion.
- Inspect order status, notes, stock, emails, refunds, and downstream conversion events for duplicate side effects.
- Compare the oldest action in the payment hook class with the store's payment-state SLO and customer support timeline.
Why this usually happens
- Provider delivery and WordPress background processing have different retry clocks.
- An HTTP timeout does not prove the application failed before committing state.
- Queue dashboards can hide the business impact of one payment hook.
- Order notes may describe attempts but not the provider's final acknowledgement.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
stripe_event,provider_attempt,http,action,age,claim,order,payment,side_effects,result
evt_101,1,500,8812,18m,expired,10511,paid,none,retry-safe
evt_101,2,200,8812,0m,complete,10511,processing,one,pass
evt_102,2,200,8819,0m,complete,10518,processing,duplicate-blocked,pass
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Freeze provider, queue, order, and payment evidence for one test event. | Record WooCommerce, Stripe extension, Action Scheduler, worker, PHP, webhook endpoint, and secret versions. | Provider attempts and endpoint responses share the preserved Stripe event ID. |
| Repair endpoint authentication, worker, claim, or hook-specific backlog at the failing boundary. | Create a test-mode event and preserve Stripe event, payment intent, order, transaction, and scheduled action IDs. | Action status, age, claims, attempts, and completion reconcile. |
| Enforce Stripe event identity before stock, email, fulfillment, or conversion side effects. | Capture provider attempt times, HTTP status and body, action schedule, claim, attempts, exception, and completion. | Order, payment intent, transaction, stock, and email state agree. |
| Replay through a supported test path and observe every downstream state. | Inspect order status, notes, stock, emails, refunds, and downstream conversion events for duplicate side effects. | Duplicate delivery creates no duplicate business side effect. |
Decision rule
Close when the same Stripe event can be retried safely, the oldest payment action stays within SLO, and exactly one order, stock, email, fulfillment, and tracking outcome remains.
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 |
|---|
| Provider retry | First endpoint response timed out | Same event ID remains idempotent |
| Action pending | Webhook accepted but follow-up is old | Repair queue owner before replay |
| Duplicate delivery | Event already completed | Return safe response without side effects |
| Paid but pending | Transaction exists, order not updated | Reconcile one authoritative state |
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.
- Freeze provider, queue, order, and payment evidence for one test event.
- Repair endpoint authentication, worker, claim, or hook-specific backlog at the failing boundary.
- Enforce Stripe event identity before stock, email, fulfillment, or conversion side effects.
- Replay through a supported test path and observe every downstream state.
- Alert on oldest customer-impacting payment actions and unresolved paid-order mismatches.
Production verification checklist
- Provider attempts and endpoint responses share the preserved Stripe event ID.
- Action status, age, claims, attempts, and completion reconcile.
- Order, payment intent, transaction, stock, and email state agree.
- Duplicate delivery creates no duplicate business side effect.
What to tell the client or owner
Give the owner the affected versions, exact fixture, stable IDs, UTC timeline, before and after evidence, decision, rollback point, unresolved risks, and next review date. State which measurements prove success and which observation window still remains.
Mistakes to avoid
- Changing production before preserving the current result, exact versions, timestamps, and a reproducible fixture.
- Treating one successful screen or request as proof that every queue, provider, report, browser, and customer path agrees.
- Removing logs, identifiers, or rollback evidence before the failure boundary and accountable owner are known.
- Testing only an administrator session instead of the roles, devices, consent states, networks, and failure paths users actually have.
Questions teams ask during testing
Can this be tested on production?
Use production for read-only confirmation and one narrow synthetic fixture. Perform destructive changes, upgrades, queue repairs, cache-policy changes, and schema changes on staging first. Promote only the smallest change that has a measured rollback point.
What evidence should be kept?
Keep component versions, stable fixture IDs, UTC timestamps, request or export evidence, expected and actual outcomes, the decision owner, rollback point, and final clean verification. Remove or redact personal data before sharing.
When is the work finished?
Finish when the canonical user path passes, downstream records reconcile, failure cases are understood, monitoring is active, and an established page links to the new guide with useful context.
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, diagnose a WooCommerce Stripe webhook.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references