Stripe shows paid, WooCommerce stays pending
A customer may be charged while the store does not complete fulfilment, order emails, stock reduction or processing.
Stripe webhook security review
Stripe webhook security review for WooCommerce and SaaS APIs
Stripe webhooks should reject fake callers before they touch orders, payments or internal workflows. VaultDevLabs reviews your approved webhook endpoints, signature handling and payment-sync exposure, then gives you evidence-backed findings, practical fixes and retest proof.
No login required to start
Unauthenticated V2 review by default.
Authorised scope only
Approved URLs, APIs and webhook paths.
No real order edits
Non-destructive review unless separately approved.
Retest proof available
Before/after evidence after fixes.
When webhook trust breaks, payment state gets messy
Stripe may show a successful payment while WooCommerce or an internal SaaS workflow stays pending, out of sync, or uncertain. The review helps separate webhook security evidence from payment workflow guesswork.
Webhook signatures are not clearly verified
If webhook endpoints do not reject invalid signatures before business logic runs, fake or malformed events may be accepted.
Payment routes are hard to reason about
Webhook, admin, order and API routes often live across plugins, custom code and hosting layers. A review gives you evidence, not guesswork.
Teams need fix proof
After changes, you need a clean retest showing what was fixed, what remains limited, and what evidence supports the result.
What the webhook review checks
The review starts from approved scope and non-destructive checks. Where you provide route hints, source snippets or OpenAPI/Swagger files, we use them to improve coverage without guessing.
Webhook endpoint exposure
We identify approved webhook-looking routes and check whether they are publicly reachable as expected.
Invalid-signature rejection
We verify that harmless dummy webhook requests with invalid signatures are rejected before business logic is trusted.
Stripe-Signature handling
We review whether the implementation appears to rely on the expected signature header and safe verification path.
Raw-body / parsing risk
Where code or route evidence is available, we flag common signature-verification pitfalls such as parsed-body verification mistakes.
WooCommerce order-state sync signals
We connect webhook review to common WooCommerce outcomes such as paid-in-Stripe but pending-in-WooCommerce states.
API and route exposure
We review approved API route hints, OpenAPI/Swagger data and public crawl evidence for sensitive webhook/payment/admin surfaces.
Security headers, TLS, CORS and cookies
We include surrounding web security posture where it affects trust and exposure around the approved app/API.
Retest evidence
After fixes, we can rerun the approved checks and compare before/after evidence.
What we do not do by default
The default Security Snapshot review is safe and non-destructive. It is designed to find public exposure, missing rejection behaviour and risky configuration without changing real customer, payment or order data.
No real refunds
We do not trigger live refunds in the default review.
No order edits
We do not change production WooCommerce orders or customer records.
No real Stripe event replay
We do not replay real Stripe events unless separately approved in a controlled engagement.
No credential attacks
No brute force, password spraying or account guessing is part of the default review.
No data exfiltration
We do not extract customer, order or payment data as part of the default review.
No hidden changes
Any credentialed, state-changing or high-impact validation needs written approval first.
No destructive testing
High-impact validation belongs in a separate authorised engagement, usually staging first.
No customer-data mutation
The default review is evidence-led and non-destructive.
Credentialed role, IDOR, refund-permission and deeper business-logic testing require a separate written V3/V4 scope with client-provided test accounts and test records.
What you receive
The output is written for decision-makers and implementation teams: clear evidence, practical fixes, positive controls and explicit limitations.
Plain-English summary
What was reviewed, what was found and what matters first.
Evidence-backed findings
Affected endpoint, observed response, redacted snippets and evidence references where available.
Positive controls
Examples of controls that behaved correctly, such as invalid-signature rejection.
Limitations
Clear statements for unauthenticated-only coverage, missing route evidence or blocked scope.
Recommended fixes
Practical steps for webhook validation, route protection, headers, CORS or deployment changes.
Retest proof
Before/after comparison once fixes are deployed.
Example finding: webhook accepted invalid signature
Critical / HighTitle
Webhook accepted invalid signature
Affected asset
/api/stripe/webhook
Evidence
Harmless dummy webhook payload with invalid signature returned 200/202 instead of rejecting the request.
Why it matters
A webhook endpoint should verify authenticity before trusting event data. If invalid events are accepted, payment, order, fulfilment, email or subscription workflows may be exposed to fake or malformed triggers.
Recommended fix
Verify Stripe signatures before business logic, use the official verification helper where possible, preserve the raw request body, fail closed on invalid signatures, and add regression tests for invalid-signature rejection.
Retest step
Send the same harmless invalid-signature probe after deployment and confirm the endpoint returns a rejection response before side effects occur.
Example only. Real findings depend on authorised scope and evidence.
Why this matters for WooCommerce
WooCommerce payment issues often show up as operational confusion: Stripe records a payment, but WooCommerce stays pending or does not complete the expected order-state transition. Webhook signature handling, delivery configuration and plugin/custom-code routing can all affect the reliability of that flow.
paid in Stripe, pending in WooCommerce
webhook delivery failed or was not processed
signature mismatch blocked event handling
custom code changed expected order-state behaviour
support team needs evidence before editing orders
Why this matters for SaaS APIs
Signed webhooks often trigger more than payment records. They can update subscriptions, provision credits, send emails, unlock features, trigger fulfilment or notify internal systems. A weak webhook boundary can become a weak business-logic boundary.
Subscriptions
Credits and usage
Customer emails
Fulfilment
Admin workflows
Internal automation
Start with a no-login Security Snapshot
We can start without login details by reviewing your approved public app/API/webhook surface. Deeper authenticated role and business-logic testing can be scoped later.
Webhook Review
For Stripe/WooCommerce/SaaS webhook endpoints
Endpoint exposure, invalid-signature rejection, route coverage and fix guidance.
Security Snapshot
For broader app/API exposure
Headers, TLS, CORS, cookies, APIs, webhooks, source maps, backups and route hints.
Retest Proof
For fixed findings
Before/after evidence and delivery-ready summary.
FAQ
Scope boundaries matter. This page describes a no-login-first review, not a full penetration test.
Do you need login details for this review?
No. The default review can start without login details. It checks the approved public app/API/webhook surface. Authenticated role, IDOR and logged-in business-logic testing require a separate credentialed review with written approval and test accounts.
Will you send real Stripe events?
Not in the default review. The no-login review uses harmless invalid-signature checks and evidence review. Real event replay or state-changing validation requires a separate controlled scope, usually against staging or test records.
Can you test production webhooks?
Yes, if they are explicitly approved in scope, but the default checks are non-destructive. We verify rejection behaviour and public exposure without editing orders, issuing refunds or changing customer data.
What if my WooCommerce order is stuck pending after Stripe payment?
That can happen when webhook delivery, signature validation, plugin logic or order-state processing fails. The review helps identify whether webhook/security signals should be investigated before manual order edits.
Is this a full penetration test?
No. This is an authorised app/API/webhook security review with evidence-backed findings and limitations. It is not a full manual penetration test or red-team engagement.
Can you help fix the issue?
Yes. After the review, we can quote a hardening or setup sprint, then rerun the relevant checks to produce retest proof.
Can you review OpenAPI or source routes?
Yes, where provided and approved. Static route hints and OpenAPI/Swagger data can improve API coverage without relying only on crawler discovery.
What does the report include?
The report includes findings, positive controls, evidence notes, limitations, practical fixes and optional retest guidance.
Need confidence in your Stripe webhook boundary?
Start with an authorised no-login review. If deeper role or state-changing validation is needed, we scope that separately with written approval and test data.
Authorised testing only. No destructive actions. No credential attacks.
Security Snapshot is an authorised external security review. It is not a penetration test, Cyber Essentials assessment, PCI ASV scan, legal opinion or certification. Findings reflect the agreed scope and test window only. Security improvements reduce risk; they do not guarantee the absence of compromise.