StripeSignatureVerificationError: No signatures found matching the expected signature for payload. Are you passing the raw request body you received from Stripe? Stripe signs the exact bytes it sends. constructEvent recomputes an HMAC over the bytes you hand it, using your endpoint secret, and compares. Any change to either the bytes or the secret produces this same message, which is why it is so hard to debug from the error alone.

We generated a valid signature header with stripe-node 23.0.0 for a body shaped like a real Stripe delivery (indented, multi-line, with an escaped non-ASCII customer name), then passed variations of that body to constructEvent. The results are below. The middle rows are the important ones: parsing the JSON and turning it back into a string fails even when you match the indentation, because the escaping does not round-trip.

raw text (await req.text())                 PASS
raw Buffer                                  PASS
JSON.stringify(await req.json())            FAIL
JSON.stringify(parsed, null, 2)             FAIL
parsed object passed in directly            FAIL  (rejected before hashing)
right body, different whsec secret          FAIL
right body plus one trailing newline        FAIL

This is the common one. In the App Router, calling await req.json() and then JSON.stringify on the result gives you different bytes than Stripe sent: different whitespace, different escaping. Passing the parsed object straight in fails earlier with a clearer message. The fix is to read the body once with await req.text() and verify that string. App Router route handlers do not parse the body for you, so nothing else is needed.

Each endpoint has its own whsec secret. The secret printed by stripe listen is different from the one on the Dashboard endpoint, and test mode and live mode endpoints have different secrets again. With the correct body and the wrong secret you get exactly the same error as cause 1, so check this before rewriting code: compare the endpoint that delivered the event in the Dashboard with the secret your deployment actually has.

One added trailing newline is enough to fail, as the table shows. Middleware or a proxy that rewrites, decompresses or re-encodes the request body before your handler sees it will do this. If your handler code looks right and the secret matches, log the length of the body you received and compare it with the event payload Stripe shows in the Dashboard.

If the endpoint URL in Stripe redirects, for example from the bare domain to www, or from http to https, Stripe does not follow it and the delivery fails. This one usually shows as failed deliveries in the Dashboard rather than as a signature error in your logs, because your handler never runs. Register the final URL exactly as it serves.

In the Pages Router (pages/api), Next.js parses JSON bodies by default, which is cause 1 again. Disable it for the webhook route with export const config = { api: { bodyParser: false } } and read the raw stream into a Buffer before calling constructEvent.

Read the raw text, verify, then use the event Stripe's library returns. Return 400 on a bad signature so failed deliveries are visible and retried, and 200 quickly once the event is handled.

// app/api/stripe/webhook/route.ts
import Stripe from "stripe";

const stripe = new Stripe(process.env.STRIPE_SECRET_KEY!);

export async function POST(req: Request) {
  const body = await req.text(); // the raw bytes Stripe signed, untouched
  const signature = req.headers.get("stripe-signature");
  if (!signature) return new Response("missing signature", { status: 400 });

  let event: Stripe.Event;
  try {
    event = stripe.webhooks.constructEvent(
      body,
      signature,
      process.env.STRIPE_WEBHOOK_SECRET!, // the secret for THIS endpoint
    );
  } catch (err) {
    return new Response("bad signature", { status: 400 });
  }

  // Parse only after verifying: event is already the parsed object.
  if (event.type === "checkout.session.completed") {
    // fulfil the order
  }
  return new Response(null, { status: 200 });
}