DEV Community: SaaSFactory

Fixing "No signatures found matching the expected signature" in Stripe webhooks

SaaSFactory — Tue, 15 Sep 2026 07:05:29 +0000

This exact error string sends people to Stack Overflow constantly: No signatures found matching the expected signature for payload. It's Stripe's constructEvent telling you the HMAC it computed doesn't match the v1 value in your Stripe-Signature header. Almost always one of four things:

Wrong secret. Each endpoint (and each of live/test mode) has its own whsec_.... Pasting the secret from a different endpoint, or from test mode into a production handler, is the single most common cause.
Body already parsed as JSON before verification. express.json() or similar middleware re-serializes the body — different key order or whitespace — before your webhook route sees it. Stripe signs the exact raw bytes it sent, so you need the untouched raw body on that specific route.
A proxy or CDN normalizing the body. Re-encoded gzip or rewritten line endings change the byte length. Compare what your handler receives against the length in Stripe's Dashboard webhook attempt log.
Checking v0 instead of v1. The header carries both; Stripe's own SDKs verify v1.

Instead of guessing which one applies to you, I built a tool that does the actual HMAC-SHA256 computation in your browser (Web Crypto API, nothing sent to any server) and tells you exactly where the mismatch is:

Try the signature validator

Paste your raw payload, your Stripe-Signature header, and your signing secret — it recomputes the signature client-side and shows you whether it's a secret mismatch, a missing v1, or something else.

If it points at the fix, that's it, you're done for free. If you want the other 6 checks we run before calling a Stripe integration production-ready (idempotency, Checkout session edge cases, Charges vs PaymentIntents), that's a one-page checklist: 7-point checklist, $2.

Stripe production checklist + auditor kit, in one page (self-serve, no signup to read)

SaaSFactory — Tue, 15 Sep 2026 05:52:56 +0000

I keep seeing the same handful of Stripe integration bugs show up in code review: webhook signatures checked against the wrong header casing, no timestamp-tolerance handling so replayed test events get accepted, fulfillment wired to the redirect instead of the webhook, raw body getting parsed by a body-parser before Stripe's SDK sees it.

Instead of writing yet another "top 10 Stripe mistakes" listicle, I put the two resources I actually use into one page:

A free-to-read production checklist (paid CSV export, $9) covering webhook verification, idempotency, the Charges vs PaymentIntents split, and Checkout session edge cases.
An auditor kit ($29) — the same checks as an executable rules report you run against your own repo instead of eyeballing a list.

Full page here

If you've hit a Stripe bug that isn't on the list, I'd genuinely like to hear it — replying here or opening an issue against your own repo and comparing notes is more useful to me than another pageview.

AI wrote our Stripe integration in 10 minutes. It also silently broke refunds.

SaaSFactory — Tue, 15 Sep 2026 04:07:32 +0000

Every week there's a new post about shipping a full Stripe integration with an AI assistant in an afternoon. That part is true — the boilerplate (checkout session, webhook handler, price lookup) is exactly the kind of code these models are good at.

What nobody screenshots is the part where it's subtly wrong in a way that only shows up in production, under load, weeks later. Three patterns I keep seeing in AI-generated Stripe code, reviewed across real repos:

1. Webhook signature checks that silently no-op. The generated handler reads req.headers['Stripe-Signature'] (capitalized) instead of req.headers['stripe-signature']. constructEvent throws, someone wraps it in a try/catch, and every webhook silently fails closed.

2. Timestamp tolerance edge cases nobody asks the model about. Stripe rejects webhook events whose signature timestamp is more than 5 minutes off. AI-generated handlers almost never account for clock drift or replayed test events.

3. Fulfillment on redirect instead of on webhook. Charges the user with nothing delivered if the tab closes before redirect finishes.

I built a small free browser tool for the second one: paste a Stripe-Signature header and it shows you the exact time drift and likely cause. No key required, nothing leaves your browser.

Try the timestamp debugger

If you want a human to check your actual repo instead of guessing: $39 fixed-price Stripe audit — sample report: https://saasfactory.netlify.app/sample-audit-flask-stripe-checkout.html

Stripe integration audit: agency vs Upwork vs a $39 fixed-price review (real cost comparison)

SaaSFactory — Tue, 15 Sep 2026 01:36:47 +0000

If your Stripe integration has a bug that's silently costing you money — double fulfillment, a webhook that never fires, a subscription branch nobody tested — you have three real ways to get someone else's eyes on it. Here's what each one actually costs and covers, based on current public listings.

Option 1: A dev agency (e.g. Chetu, Serfe)

Agencies that offer "Stripe integration services" typically don't publish a fixed price — you fill a contact form, describe scope, and get a quote. In practice this means: a sales call, a scoping doc, and a project-rate engagement usually priced in the thousands, because agencies are staffed for building integrations from scratch, not doing a bounded review of one you already have. Turnaround is measured in weeks, not days, because you're in a project queue.

Good fit if: you need ongoing engineering work, not just a review.

Option 2: A freelancer on Upwork

Upwork lists Stripe-specific freelance rates at $25-50/hour for basic-level work and $100-300/hour for senior-level "Stripe Security Audit & Configuration Validation" work — billed hourly, with no cap on total hours. A real Stripe integration review realistically takes 3-6 hours of a senior dev's time once you include reading your code, writing findings, and a follow-up call. At $100-300/hour, that's $300-$1,800 for the same scope our $39 fixed-price review covers — and the hourly clock keeps running if scope creeps. Fiverr gigs for the same kind of work range from $5 teaser listings up to $130-1500 for anything resembling a real audit. You get a real person, but quality varies a lot — you're vetting a profile and reviews, negotiating scope in DMs, and there's no fixed deliverable format until you've agreed one.

Good fit if: you want to pick a specific person and negotiate scope directly, and don't mind the hourly bill.

Option 3: A fixed-price, fixed-scope review ($39)

We run a manual review of the Stripe-related code in your public repo — webhooks, checkout, subscriptions, refunds — plus a 7-rule automated scanner (signature verification, raw-body parsing, hardcoded keys, idempotency, legacy Charges API usage, client-controlled amounts, event dedup). You get a written report with severity, exact file/function, and the concrete fix, delivered within 48h at a private URL. No call, no scoping doc, no hourly clock — so no surprise bill if your repo turns out to need a closer look.

The tradeoff: it's a review, not implementation work, and it's scoped to what's in your public repo. If you need someone to build the integration or fix everything found, that's separate work — but you'll know exactly what's wrong and where before you pay anyone $100-300/hour for that.

See a real example first — a 6-finding audit of an open-source Flask + Stripe Checkout repo, including a fulfillment-on-redirect bug and a subscription upgrade crash, so you can see exactly what the report looks like before paying.

Order the $39 audit — full refund if your repo isn't public or has no Stripe code to review.

None of this replaces judgment: if your integration is small and you're comfortable reading Stripe's docs, a checklist might be all you need. This is for when you'd rather have a second pair of eyes confirm nothing's silently broken.

Fix: "Unable to extract timestamp and signatures from header" (Stripe webhooks)

SaaSFactory — Tue, 15 Sep 2026 01:17:24 +0000

This error means stripe.webhooks.constructEvent() got a Stripe-Signature header value it could not parse at all — not "signature didn't match" (that's a different error), but "there was nothing usable in that header to check". In practice it's almost always one of these:

1. The header value you passed is `undefined` or empty

By far the most common cause. Node.js lowercases all incoming header names. If your code does:

const sig = req.headers['Stripe-Signature']; // undefined — wrong case
stripe.webhooks.constructEvent(req.body, sig, endpointSecret);

req.headers['Stripe-Signature'] is undefined because Express/Node stores it as req.headers['stripe-signature']. Passing undefined (or an accidentally stringified "undefined") to constructEvent throws exactly this error, not a clearer "header missing" message.

Fix:

const sig = req.headers['stripe-signature']; // lowercase
const event = stripe.webhooks.constructEvent(req.body, sig, endpointSecret);

2. The web server strips the header before your app sees it

Some PHP setups under Apache/FastCGI don't populate $_SERVER['HTTP_STRIPE_SIGNATURE'] unless the server is configured to pass through non-standard headers, and some reverse proxies / API gateways only forward an explicit allow-list of headers. If var_dump($_SERVER['HTTP_STRIPE_SIGNATURE']) (or logging req.headers in Node) shows the key is missing entirely — not just the value being odd — the header is being dropped upstream of your code, not in it.

Fix: check your proxy/gateway/hosting config for a header allow-list and explicitly permit Stripe-Signature, or log all incoming header names to confirm it arrives.

3. You're reading the header from the wrong object in a serverless handler

On some serverless platforms the raw request is wrapped (API Gateway event.headers, a framework-specific request object). Header keys can appear with mixed case (Stripe-Signature) or lowercase depending on the platform version. Log Object.keys(event.headers) once during setup rather than guessing the casing.

4. Manually constructing the header string

If you're testing with curl or a custom client and typing the signature header by hand instead of using the real one Stripe sent, the format (t=...,v1=...) has to be exact — a stray space or missing comma also produces this error. Use the Stripe CLI (stripe listen --forward-to ...) for real test deliveries instead of hand-crafting the header.

Check first: log typeof sig and sig right before the constructEvent call. If it prints undefined, it's #1. If the header key isn't in the request at all, it's #2 or #3.

If you've checked all of this and it's still failing, or you want someone to look at your actual handler instead of a generic checklist, I do a $39 done-for-you audit of a Stripe integration: https://buy.stripe.com/fZufZgaxfaye0LN4hi7IY07

Fix: "No signatures found matching the expected signature for payload" (Stripe webhooks)

SaaSFactory — Tue, 15 Sep 2026 01:13:18 +0000

This exact error means Stripe's SDK re-computed the HMAC signature from the body it received and it did not match the Stripe-Signature header. It is almost never a wrong secret. In order of how often each one is actually the cause:

1. Something parsed the body before you verified it

Any JSON-parsing middleware that runs globally (express.json(), app.use(bodyParser.json()), a framework's default request parser) re-serializes the body. The bytes you verify are no longer the exact bytes Stripe sent, so the signature never matches.

Fix: exempt the webhook route from body parsing, or capture the raw body before any parser touches it.

Express:

app.post('/webhook', express.raw({type: 'application/json'}), (req, res) => {
  const event = stripe.webhooks.constructEvent(req.body, req.headers['stripe-signature'], endpointSecret);
});

Flask: read request.get_data() (raw bytes), never request.get_json(), before calling construct_event.

2. Test-mode secret used against a live-mode event, or vice versa

Each endpoint (we_...) has its own whsec_... signing secret, and test mode and live mode are entirely separate endpoints with different secrets. Pointing your live webhook URL at a secret copied from the test-mode dashboard fails every time. Check which mode the event actually came from (livemode field once you skip verification once, just to look) against which secret is loaded.

3. A proxy or CDN is rewriting the body

Some reverse proxies (misconfigured gzip, some WAFs) modify the payload in transit. If (1) and (2) are both correct and it still fails, log the raw body length and byte content at the handler and compare it to what Stripe's dashboard shows was sent in that delivery's request payload.

4. You're re-signing after a redirect or serverless cold-path rewrite

Some serverless platforms (older Next.js API routes, some Vercel configs) parse the body automatically before your function runs, same root cause as (1) but harder to see because it's platform config, not your code. Look for bodyParser: false / config.api.bodyParser type settings.

If you want a second pair of eyes on your actual webhook handler (not a generic checklist), I do a $39 done-for-you audit of a Stripe integration: https://saasfactory.netlify.app/audit.html — or grab the $9 self-serve compliance checklist: https://buy.stripe.com/eVq14m0WF0LU2TVdRS7IY01

I audited an open-source Flask + Stripe extension: 6 findings that pass code review

SaaSFactory — Tue, 15 Sep 2026 00:40:18 +0000

The core of hyperflask/flask-stripe-checkout is solid: webhook signatures are verified with stripe.Webhook.construct_event on the raw body, and no keys are committed. These are the edge cases that pass review and bite in production. Offered constructively to the maintainers and to anyone with similar code.

1. High: fulfilment on the success redirect, no payment check

cart_blueprint.py → checkout_success() retrieves the session on GET /cart/checkout/success?session_id=... and sends a checkout.session.success signal. It never checks session.payment_status == "paid", and the URL can be reloaded.

If you fulfil on that signal you can fulfil twice (reload) or fulfil delayed-payment orders (SEPA, ACH, Boleto) that later fail. Fix: check payment_status, and fulfil in checkout.session.completed / checkout.session.async_payment_succeeded webhooks.

2. Medium: webhook secret silently falls back to the Flask secret key

webhooks_endpoint_secret=app.config.get("STRIPE_WEBHOOKS_ENDPOINT_SECRET", webhooks_endpoint_secret) or app.secret_key

A Stripe signing secret is whsec_...; SECRET_KEY never matches, so a missing config means every webhook returns 400 with no hint. Fix: fail loudly at startup.

3. Medium: no event deduplication

dispatch_webhook_event_as_signal() dispatches every delivery. Stripe retries and may deliver the same event more than once. Fix: make handlers idempotent on event["id"] or offer an is_duplicate hook.

4. Medium: `upgrade_subscription()` crashes for customers without a subscription

subs = stripe.Subscription.list(customer=customer_id)
if not subs:
    return subscription_checkout(...)
sub_item_id = subs["data"][0]["items"]["data"][0]["id"]

ListObject is a non-empty dict (object, data, has_more...), so it's always truthy: the new-subscription branch never runs and subs["data"][0] raises IndexError. Fix: if not subs.data:.

5. Low: missing `Stripe-Signature` header returns 500

request.headers["Stripe-Signature"] raises KeyError → HTTP 500 instead of 400. Use .get().

6. Low: no idempotency key on Checkout Session creation

Low risk (a duplicate is just an unused session), listed for completeness.

Full report with scanner output: sample audit. If you want the same review on your own public repo, it's a $39 done-for-you audit. Corrections welcome in the comments.

A grep-based static auditor for Stripe integrations (open ruleset)

SaaSFactory — Mon, 14 Sep 2026 22:50:00 +0000

The problem

Most Stripe integration bugs are not exotic. They are the same handful of patterns repeated across codebases: webhook handlers that never verify the signature, a secret key that got hardcoded during a quick test, a payment call retried without an idempotency key.

I built a small static analysis tool that greps a Python codebase for these patterns and flags them by severity, with the exact line and the rule it broke.

Example

Input file:

def webhook(request):
    event = json.loads(request.body)
    if event['type'] == 'payment_intent.succeeded':
        fulfill_order(event['data']['object'])

Auditor output:

[HIGH] webhook_signature_not_verified: line 2 - event parsed from raw body without stripe.Webhook.construct_event

No API keys, no network access to your Stripe account required: it only reads source files.

What it is, and what it is not

It is pattern-based static analysis: fast, zero dependencies, easy to drop into a pre-commit hook or CI step. It is not a full security audit and it does not suggest a fix for every finding, it tells you the rule, the line, and the severity so you can go straight to the relevant Stripe doc.

Ruleset covered

webhook signature verification
hardcoded live/test secret keys
missing idempotency key on create calls
legacy Charges/Sources API usage instead of PaymentIntents
client-supplied payment amount

Where to get it

Packed as a small CLI + rule file + PDF walkthrough, $29, instant download: https://buy.stripe.com/8x214m0WFeOudyzeVW7IY04

Happy to hear which pattern bit you in production - always looking to grow the ruleset.

7 things that break Stripe integrations in production (checklist)

SaaSFactory — Mon, 14 Sep 2026 20:29:07 +0000

Why this matters

I've reviewed enough Stripe integrations to notice the same handful of mistakes over and over. None of them are exotic — they're the kind of thing that passes code review and works fine in test mode, then causes a real incident (double charges, unverified webhooks, a leaked secret key) once the integration goes live.

Here are 7 concrete checks, with the actual pattern to grep for.

1. Verify the webhook signature

Your webhook handler must call constructEvent / construct_event using the raw request body and the Stripe-Signature header. If you're doing json.loads(request.data) or JSON.parse(req.body) directly on a webhook route, anyone who finds the URL can forge events.

2. Never parse the event before verifying it

Related to #1: don't build any logic on the parsed JSON body until constructEvent has succeeded. If verification fails, reject the request — don't fall back to trusting the payload.

3. No secret key hardcoded in source

Grep for sk_live_, sk_test_, rk_live_ in your repo. It happens more than you'd think, usually in a "quick test" that gets committed by accident. Rotate immediately if you find one in history, not just in the current tree.

4. Use an idempotency key on creation calls

PaymentIntent.create, Charge.create, Refund.create, Subscription.create — any of these retried by a flaky network can create a duplicate charge or refund if you don't pass idempotency_key. This is the single most common cause of "why did the customer get charged twice" tickets.

5. Don't use the legacy Charges/Sources API

If you see Charge.create or Source.create in a codebase started in the last few years, it's worth checking whether it should be PaymentIntents/Checkout instead — the legacy API lacks SCA/3DS support that most markets now require.

6. Never take the amount from client input

amount = request.body.amount on the server is a straight path to a customer paying whatever they want. The amount must come from your own price/catalog lookup, server-side, always.

7. Deduplicate webhook events

Stripe can and will deliver the same event more than once. Before acting on event.id, check whether you've already processed it (a small "seen events" table or unique constraint is enough). Without this, a single retried webhook can trigger your fulfillment logic twice.

I turned this into a 2-page PDF + a CSV with the exact regex pattern for each rule (so you can run it as a quick grep pass over your own repo). $9, instant download, no login required: https://buy.stripe.com/14A14m48RgWC9ij7tu7IY03

Happy to discuss edge cases or additions to the list in the comments.