Webhook delivery failed
Stripe may have sent the event, but WooCommerce or the connected plugin did not receive or process it correctly.
WooCommerce + Stripe payment issue
Stripe paid but WooCommerce order still pending? Webhook checks before you edit orders
Before you manually mark the order paid, check the evidence. Stripe events, WooCommerce order notes, webhook delivery, signature validation and plugin settings can all explain why a payment succeeded but the store stayed out of sync.
Do not blindly mark the order paid
Manually changing WooCommerce order state may be correct sometimes. Doing it before checking the evidence can hide the real problem, confuse fulfilment, trigger emails incorrectly, or make later investigation harder.
If Stripe says paid but WooCommerce is still pending, treat it as an evidence problem first. Confirm what happened before editing the order.
Safety note
This guide is informational. It does not replace checking your own Stripe dashboard, WooCommerce logs, plugin settings or developer support. If customer money or fulfilment is affected, keep a clear audit trail of any manual changes.
Common causes
Why this happens
A pending order after a successful Stripe payment is usually an evidence mismatch, not a single guaranteed cause.
Webhook signature validation failed
If the endpoint secret, Stripe-Signature header handling or raw request body handling is wrong, the event may be rejected.
Wrong webhook endpoint or secret
Live and test mode endpoints, old endpoint secrets, or changed URLs can leave the store listening in the wrong place.
Plugin or custom-code processing issue
A plugin update, custom order-status logic or checkout extension can change how events are processed.
Delayed processing or queued job
Sometimes payment state catches up later, especially on busy stores or systems with background jobs.
Duplicate or mismatched record
The Stripe payment and WooCommerce order may not match cleanly by amount, currency, email, timestamp or metadata.
Evidence first
What to check before editing the order
Work from records outward: Stripe payment evidence, WooCommerce order notes, webhook delivery, then recent changes.
- 1
Check the Stripe payment or PaymentIntent
Confirm status, amount, currency, customer email, timestamp and related events.
- 2
Check WooCommerce order notes
Look for Stripe payment notes, webhook messages, failed validation messages, plugin errors or order-status transitions.
- 3
Check Stripe webhook delivery
Look for recent delivery attempts, response codes, retries and failures around the payment time.
- 4
Confirm the webhook endpoint URL
Make sure the endpoint is current, live-mode where appropriate, and points to the right WooCommerce or plugin route.
- 5
Check signature validation
Confirm the endpoint secret and raw-body handling are correct. Do not assume a 200 response means everything is safe.
- 6
Review recent changes
Plugin updates, hosting changes, caching or security plugins, route changes and custom code can all affect webhook processing.
- 7
Avoid duplicate fulfilment
If fulfilment or emails depend on order status, be careful before manually marking anything paid.
Need help checking the evidence before changing the order?
Request Payment Rescue ReviewWebhook security angle
When a payment-sync issue becomes a webhook security concern
Not every pending-order issue is a security issue. It becomes security-relevant when the webhook boundary, invalid-signature rejection, route exposure or fix proof is unclear.
For a deeper review of webhook endpoint exposure and invalid-signature rejection, see our Stripe webhook security review.
Webhook rejection behaviour is unclear
The endpoint appears to accept invalid signatures
Public API or payment routes are exposed
OpenAPI or route hints show sensitive payment/admin paths
Custom code handles payment events
There is no clear retest proof after fixes
How VaultDev can help
Two practical paths after the evidence check
The right next step depends on whether this is an urgent order-state mismatch or a broader public webhook/app exposure concern.
Payment Rescue Review
Best when you have a live WooCommerce/Stripe mismatch and need human confirmation of what likely happened before making operational changes.
Example WooCommerce order evidence
Stripe payment and event review
WooCommerce order-note review
Webhook delivery clues
Recommended next steps before operational changes
Security Snapshot
Best when you want a broader authorised no-login review of public app/API/webhook exposure, practical fixes, limitations and retest proof.
Approved public app/API/webhook surface
Security headers, TLS, CORS and cookies
OpenAPI/GraphQL, source-map and backup exposure signals
Positive controls, limitations and retest proof
Example scenario
Paid in Stripe, pending in WooCommerce
Customer pays by Stripe. Stripe shows succeeded. WooCommerce order remains pending.
Stripe event exists
Woo order notes show no matching paid or processing update
Webhook delivery returned an error or was not processed
Signature or endpoint setting needs review
Likely next step: review webhook configuration and event handling before manually editing the order. If a fix is made, retest with evidence.
FAQ
Short answers
Should I manually mark the WooCommerce order paid?
Sometimes a manual update is appropriate, but check the payment, order notes, webhook delivery and audit trail first. Editing the order too early can hide the real cause or trigger fulfilment and emails incorrectly.
Does a pending WooCommerce order mean Stripe failed?
No. Stripe can show a succeeded payment while WooCommerce remains pending because webhook processing, plugin logic, endpoint configuration or delayed jobs did not complete the store-side update.
Is every Stripe webhook failure a security issue?
No. Many failures are configuration or processing issues. It becomes security-relevant when endpoint exposure, invalid-signature rejection, route handling or custom payment-event code is unclear.
Will VaultDev edit orders or replay live Stripe events?
Not by default. Payment Rescue Review is evidence-led. State-changing actions, real event replay, refunds or customer-data changes require separate written scope and approval.
What should I send for review?
Useful starting evidence includes the WooCommerce order ID, Stripe PaymentIntent or charge ID, order notes, relevant webhook delivery entries, timestamps, recent plugin changes and a short description of what the customer saw.
Check the evidence before changing the order.
Payment Rescue Review is built for WooCommerce and Stripe mismatches where you need a calm, evidence-led read before operational changes.
Informational guide only. No order edits, refunds, real event replay or customer-data changes by default.