What matters first: Stripe can complete payment asynchronously while WooCommerce depends on a signed event to update the order. A missing, delayed or rejected webhook leaves the systems out of sync.
When Stripe is paid but WooCommerce is not
The Stripe event ID and WooCommerce order notes connect the remote payment to the local state transition.
Tie the Stripe event to one WooCommerce order
- Record Stripe payment intent, event ID, order ID and timestamps.
- Check Stripe webhook delivery status, response body and retry history.
- Verify endpoint URL, signing secret and live/test mode alignment.
- Inspect WooCommerce Stripe and fatal logs for order lookup or processing errors.
Check delivery before changing order status
- Wrong signing secret: The endpoint rejects otherwise valid events.
- Mode mismatch: Live events are sent to a test endpoint or vice versa.
- Blocked endpoint: WAF, basic auth or maintenance prevents delivery.
- Processing fatal: The event arrives but custom code fails while updating the order.
Restore the signed event path
- Correct endpoint and secret configuration for the active Stripe mode.
- Resolve the exact delivery rejection or processing fatal.
- Replay a safe failed event after confirming idempotency.
- Reconcile historical payments before manually updating orders.
Secret, mode or processing failure?
If Stripe shows a failed webhook delivery, solve the response code or signing problem before touching the order. If Stripe received a successful response but WooCommerce still did not update, follow the event ID into WooCommerce and PHP logs for an order lookup or processing failure. Those are different failure modes and should not share the same repair.
A 401 or 403 on Stripe delivery should be debugged through webhook authentication and firewall checks. If delivery succeeds but the order remains wrong, compare the transaction with paid orders that still show failed before applying any manual status change.
Do not reconcile from customer reports alone
Do not mark every pending order paid based only on customer reports. Verify the Stripe transaction individually.
Verify live payment and webhook replay
- A new test payment updates the order automatically.
- Replayed events produce no duplicate side effects.
- Stripe delivery logs and WooCommerce notes reference the same event.
Close the incident only after a new Stripe payment updates the intended WooCommerce order automatically, replaying the same event has no duplicate side effects, and both systems reference the same event and transaction.
WP REPAIR INCIDENT STANDARD
Safe intervention sequence
The Stripe event ID and WooCommerce order notes connect the remote payment to the local state transition.
- Record Stripe payment intent, event ID, order ID and timestamps.
- Check Stripe webhook delivery status, response body and retry history.
- Verify endpoint URL, signing secret and live/test mode alignment.
- Inspect WooCommerce Stripe and fatal logs for order lookup or processing errors.
What must be verified
- A new test payment updates the order automatically.
- Replayed events produce no duplicate side effects.
- Stripe delivery logs and WooCommerce notes reference the same event.
Official technical sources
This guide explains the diagnosis. If the site is affected now, the intervention should preserve a rollback path and verify the real business journey.
See the emergency repair service →ABOUT THIS SYMPTOM
Frequently asked questions about this guide.
Can I just mark orders as paid manually when Stripe shows payment succeeded but WooCommerce doesn't update?+
Not based on customer reports alone. Each pending order should be verified individually against the actual Stripe transaction before manual updates, since marking every pending order paid without that check risks confirming orders that were never actually captured.
Is a live/test mode mismatch a common cause, or is it usually the signing secret?+
Both are listed as distinct, common causes with different signatures: a wrong signing secret causes otherwise-valid events to be rejected at the endpoint, while a mode mismatch means live events are being sent to a test endpoint (or vice versa), so checking live/test mode alignment is a separate step from checking the secret.
If the webhook was rejected earlier, is it safe to just replay it from the Stripe dashboard?+
Yes, but only after confirming idempotency, meaning the replay should not create duplicate order updates or side effects. Replaying a safe failed event is part of the recommended repair sequence, done after the endpoint and secret configuration have been corrected.
Does the Stripe event ID actually matter for troubleshooting, or is the order ID enough?+
The Stripe event ID matters specifically because it, together with the WooCommerce order notes, is what connects the remote payment event to the local order state transition, letting you confirm a specific event was received and processed rather than just that an order eventually changed status.