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.
What this symptom actually tells you
The Stripe event ID and WooCommerce order notes connect the remote payment to the local state transition.
Capture evidence before changing anything
- 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.
Most common causes
- 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.
Safe diagnostic and repair sequence
- 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.
How to choose between the likely causes
Do not treat Wrong signing secret and Mode mismatch as interchangeable. The endpoint rejects otherwise valid events. By contrast, live events are sent to a test endpoint or vice versa. Use two checks to separate them: Record Stripe payment intent, event ID, order ID and timestamps; and check Stripe webhook delivery status, response body and retry history. Those observations usually show whether the next safe move is to correct endpoint and secret configuration for the active Stripe mode or to preserve the current state and widen the investigation.
On a live store, reproduce the issue with a controlled test order and follow the same payment, stock, tax and notification path used by customers. Avoid changing several checkout components at once because that changes the application state and can obscure the original sequence of events needed to attribute the failure. Record the exact timestamp, affected URL or transaction, last known good state and every change made during diagnosis. That handover is often what separates a repeatable repair from a temporary disappearance of the symptom.
What not to do
Do not mark every pending order paid based only on customer reports. Verify the Stripe transaction individually.
How to verify the repair
- 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.
A visible symptom disappearing is not enough. Close the incident only when the original failing action, the surrounding business journey and the relevant logs all agree that the fault is gone.
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.