DEV Community: WebhookProof

Customer paid in your Lovable or Bolt app but nothing unlocked? Where to look first

WebhookProof — Mon, 19 Oct 2026 11:53:09 +0000

A customer writes in: they paid, and they still can't get in. Stripe shows a successful payment. Your app shows a locked screen.

In apps built with Lovable or Bolt, the fix depends on how the builder connected Stripe, because the two take different routes. This post covers how each one decides a customer has paid, where that breaks, and what to paste back into the builder. Every claim links to the doc it comes from (see Sources at the end).

Step 0: find out which setup you have

Lovable offers two routes. Its docs say "most projects should use built-in payments", where "Lovable provisions the Stripe or Paddle account and manages keys, webhooks, and test and live environments for you." The other route is "Connect your own Stripe account", where you supply the API key. A project "can use one or the other, not both at the same time."

Bolt has a single Stripe integration that "requires Supabase as your database provider". When you apply it, Bolt "automatically creates the Supabase edge functions to handle" checkout session creation, "payment webhook processing", and subscription management.

If you're on Lovable built-in payments, Lovable runs the webhook side, so start in its Payments view. The rest of this post is about the setups where the payment wiring sits in your project: Lovable with your own Stripe account, and Bolt.

Lovable with your own Stripe account: no webhooks by default

Lovable's docs are explicit: "By default, the integration does not use webhooks: your app checks payment and subscription status directly with Stripe."

That gives two common failure modes.

1. One-time purchases granted only on the success page

For a one-time purchase, the buyer pays in Stripe Checkout and then "returns to a payment success page in your app". If the code that grants access only runs when that page loads, a buyer who closes the tab never gets access.

Stripe warns about exactly this: "You can't rely on triggering fulfillment only from your checkout landing page, because it's not guaranteed customers visit that page. For example, a customer can pay successfully and then lose their internet connection before your landing page loads." Stripe's fix is a webhook that calls the same fulfillment function, with the landing page as a second, faster path.

Lovable supports that when you ask for it. It "writes the webhook function, and you finish the setup in your Stripe dashboard": create an event destination for the function's URL, choose the events, and add the signing secret when Lovable asks.

Prompt to paste into Lovable:

Add a Stripe webhook function that handles checkout.session.completed and checkout.session.async_payment_succeeded, verifies the Stripe-Signature header against the signing secret, and grants access through the same function the success page uses. Make that function safe to run twice for the same Checkout Session ID.

2. Subscriptions matched by email

For subscriptions, "subscriptions are matched to users by email address. A user's subscription is recognized when the email they sign in with matches the email on their Stripe customer record." If a customer pays as jane@work.com and logs in as jane@gmail.com, the check finds no subscription.

Check: in Stripe, open the customer record and compare its email with the one the user signs in with. If they differ, change one of them, or ask Lovable to link the Stripe customer ID to the user at checkout rather than relying on the email match.

Bolt: the webhook function exists, so check that it runs

Bolt's docs say it "automatically handles webhook endpoint registration and signature verification. You don't need to manually configure webhook endpoints in your Stripe dashboard." With the plumbing generated for you, the useful question is whether events are actually arriving and succeeding.

Check: in Stripe, open Workbench → Webhooks, select the endpoint, and open Event deliveries. Stripe's docs say this tab lists each event as Delivered, Pending or Failed, along with "the HTTP status code of the delivery attempt".

Then work from the status code.

Reading the status code (both builders)

These apply whenever your webhook is a Supabase Edge Function, which is how Bolt builds it, and how Lovable builds it on your own Supabase project.

401 with "Missing authorization header" or "Invalid Token...": Supabase's troubleshooting guide says these messages "come from the legacy auth verification check", which "runs before your code. When it fails, your function never executes." Stripe sends no Supabase token, so the platform rejects the event. Fix: turn off JWT verification for the webhook function only, then verify the Stripe signature inside it.

The Stripe webhook Edge Function returns 401 before it runs. Set verify_jwt = false for that function only in supabase/config.toml, keep Stripe signature verification with constructEventAsync on the raw body (await req.text()), and redeploy.

400 with a signature error: the function runs but the signature doesn't match. The most common cause, per Stripe, is "using the wrong endpoint secret", for example a test secret on the live endpoint (next section).

200, but still no access: the event arrived and your function returned success without granting access. Check that the endpoint subscribes to the event your code handles (checkout.session.completed for one-time payments), and look in the function logs for the database write.

No delivery at all: the live-mode endpoint may not exist, or may not subscribe to that event type.

Test vs live: the go-live trap

Both builders tell you to start with test keys. Bolt: "Use test keys for development. Test keys start with sk_test_." Stripe's docs explain why switching modes takes more than a new key: "Each mode has its own set of API keys, and objects in one mode aren't accessible to the other." Webhook secrets differ too: "If you use the same endpoint for both test and live API keys, the secret is different for each one."

Lovable's go-live steps cover the price side: "Price IDs differ between test and live mode, so ask Lovable to switch your app to the live price IDs." If you added a webhook, also paste in the live endpoint's whsec_ secret. The test one won't verify live events.

Fixing customers who already paid

Once the endpoint works, recover the missed events. Stripe's docs say a Dashboard Resend works "for up to 15 days after the event creation", and the CLI's stripe events resend works for 30. In live mode Stripe also retries failed events "for up to three days". Make sure the grant is safe to run twice before you resend, because Stripe says your fulfillment function "might be called multiple times, possibly concurrently, for the same Checkout Session."

Checklist

[ ] Know which route you're on: Lovable built-in, Lovable with your own Stripe, or Bolt
[ ] Access is granted from a webhook, not only from the success page
[ ] Subscriptions: the login email matches the Stripe customer email (or you match on customer ID)
[ ] Event deliveries show 200, not 401 or 400
[ ] Live mode: live key, live price IDs, live endpoint, live whsec_
[ ] Granting access twice for the same Checkout Session does nothing extra

WebhookProof's free checker sends 3 harmless requests to your webhook URL and tells you whether Stripe can reach it (401s, redirects, login walls) and whether it accepts unsigned events. Each issue comes with a prompt to paste into your builder. More detail in the guide: Stripe webhooks with Supabase, Lovable and Bolt.

WebhookProof is an independent tool, not affiliated with Stripe, Inc., Lovable, Bolt or Supabase, Inc. Quotes are from the linked documentation as read on 2026-10-18.

Sources

Lovable, Connect your own Stripe account (built-in vs own account, no webhooks by default, success page, email matching, webhook setup, live price IDs): https://docs.lovable.dev/integrations/stripe
Bolt, Stripe for payments (Supabase requirement, auto-created edge functions, automatic webhook registration and verification, sk_test_ keys): https://support.bolt.new/integrations/stripe
Stripe, Fulfill orders, hosted Checkout (don't rely on the landing page, fulfill_checkout may be called multiple times, async payment events): https://docs.stripe.com/checkout/fulfillment?payment-ui=stripe-hosted
Stripe, Receive Stripe events in your webhook endpoint (Event deliveries tab, per-mode secrets, retries, resend windows): https://docs.stripe.com/webhooks
Stripe, Manage webhook endpoints (wrong endpoint secret is the most common signature error): https://docs.stripe.com/webhooks/signature
Stripe, API keys (sandbox vs live mode, objects not shared across modes): https://docs.stripe.com/keys
Supabase, Edge Function 401 error response (legacy JWT check runs before your code): https://supabase.com/docs/guides/troubleshooting/edge-function-401-error-response
Supabase, Function Configuration (verify_jwt = false per function): https://supabase.com/docs/guides/functions/function-configuration

Stripe webhook shows 307 or 308 on Vercel / Next.js? It's a redirect, and Stripe won't follow it

WebhookProof — Mon, 19 Oct 2026 03:57:37 +0000

The checkout works and the money arrives, but your app never finds out. Open the webhook endpoint in Stripe and every delivery attempt says 307 or 308. Your route handler logs are empty.

That's not a bug in your handler. Something in front of it answered with a redirect, and Stripe doesn't follow redirects. This post covers where those redirects come from on Next.js and Vercel, how to find the exact URL Stripe should call, and how to check the fix. Every claim links to the doc it comes from (see Sources at the end).

Why a redirect counts as a failure

Stripe's webhook docs list this under delivery errors: "302 ERR (or other 3xx status)... The destination server attempted to redirect the request to another location. We consider redirect responses to webhook requests as failures." Stripe's recommended fix is short: "Set the webhook endpoint destination to the URL resolved by the redirect."

In other words, don't fight the redirect. Find where it ends up, and register that URL.

The same docs say a registered endpoint must be a "publicly accessible HTTPS URL", and in live mode Stripe retries a failed event "for up to three days with an exponential back off". So a redirect doesn't lose the event right away, but every retry hits the same redirect until the URL is corrected.

Why 307 and 308 specifically

Next.js explains its choice in the redirects reference. Older 301/302 redirects let many browsers switch a POST to a GET, so "Next.js uses the 307 temporary redirect, and 308 permanent redirect status codes to explicitly preserve the request method used." Vercel's redirect docs recommend 307 or 308 for the same reason.

When you see a 307 or 308 in Stripe's delivery log, the response came from a Next.js or Vercel redirect rule, not from your code. There are four usual sources.

Cause 1: the trailing slash

From the Next.js trailingSlash docs: "By default Next.js will redirect URLs with trailing slashes to their counterpart without a trailing slash. For example /about/ will redirect to /about." If you set trailingSlash: true, it works the other way round.

The skipTrailingSlashRedirect reference spells out the status codes:

`trailingSlash`	Request	Response
`false` (default)	`/api/webhooks/stripe/`	`308` to `/api/webhooks/stripe`
`true`	`/api/webhooks/stripe`	`308` to `/api/webhooks/stripe/`

Fix: copy the endpoint URL from Stripe, compare the end of it with your trailingSlash setting, and edit the endpoint URL to match. You don't need to change your Next.js config for this.

Cause 2: apex vs www (domain redirect)

Vercel's domain docs say that if a visitor uses your domain with or without www, Vercel "will attempt to redirect automatically", and you can also add the redirect yourself under Domains in Project Settings. Vercel recommends "using the www subdomain as your primary domain, with a redirect from the non-www domain to it."

So if your project's primary domain is www.example.com and the Stripe endpoint says https://example.com/api/webhooks/stripe, every delivery gets redirected before it reaches your function. The reverse happens if apex is primary and Stripe has the www URL.

Fix: in Vercel, open Project Settings → Domains and see which domain is primary and which one redirects. Put the primary host in the Stripe endpoint URL.

Cause 3: a `redirects()` rule that matches the webhook path

In the redirects reference, permanent: true "will use the 308 status code" and permanent: false "will use the 307 status code". Redirects are also "checked before the filesystem", so a wide rule beats your route handler. A catch-all like source: '/:path*' that moves traffic to a new domain or locale will catch /api/webhooks/stripe too.

The same goes for redirects in vercel.json, and for Vercel Firewall redirects. Vercel says a dashboard firewall redirect "creates a temporary 307 redirect", and that firewall redirects run "before CDN configuration redirects".

Fix: narrow the rule so it skips the webhook path, or point Stripe at the destination the rule sends traffic to.

Cause 4: Proxy (formerly Middleware) redirecting to login

Next.js renamed middleware to proxy in v16. Its docs say it's commonly used "for implementing custom server-side logic like authentication", and that "without a matcher, Proxy runs on every request". Auth middleware that sends logged-out visitors to /login with NextResponse.redirect(...) treats Stripe as a logged-out visitor. Stripe has no session cookie, so it gets redirected.

The docs' own negative-matcher example leaves out api:

// proxy.ts (or middleware.ts on Next.js 15 and earlier)
export const config = {
  matcher: ['/((?!api|_next/static|_next/image|favicon.ico|sitemap.xml|robots.txt).*)'],
}

Fix: exclude the webhook route from the matcher, or return early for that path. In either case, the handler itself still has to verify the Stripe-Signature header, as Stripe's docs require.

One more: double slashes

Vercel's CDN "normalizes URLs containing consecutive slashes (e.g., //) to single slashes and redirects with a 308 status code." An endpoint pasted as https://www.example.com//api/webhooks/stripe fails for that reason alone.

How to find the real URL

curl shows the redirect and where it points. Send a POST, since that's what Stripe sends:

curl -i -X POST -H 'content-type: application/json' -d '{}' \
  https://example.com/api/webhooks/stripe/

If the first line is HTTP/2 307 or HTTP/2 308, the location: header is where the request is meant to go. Run the command again against that URL, and repeat until the response is no longer a 3xx. Vercel's redirect docs use the same method (curl -I and look for the Location).

When you reach the final URL, an unsigned POST like the one above should get a 400, because your handler rejected a request with no valid signature. If it gets a 200, your endpoint accepts unsigned events, which is a separate and worse problem.

Then:

Edit the endpoint in Stripe (Workbench → Webhooks) and paste the final URL.
Open a failed event and click Resend. Stripe's docs say Dashboard resends work "for up to 15 days after the event creation" (or 30 days with stripe events resend in the CLI).
Check that the event delivery now shows 200.

The same mistake can happen locally. If stripe listen --forward-to localhost:3000/api/webhooks/stripe/ uses a trailing slash your app redirects away from, the CLI shows the same 308.

Checklist

[ ] Host in the Stripe endpoint = the primary domain in Vercel (apex vs www)
[ ] Trailing slash in the Stripe endpoint matches trailingSlash in next.config.js
[ ] No redirects(), vercel.json or Firewall rule matches the webhook path
[ ] Proxy/Middleware matcher excludes the webhook route
[ ] curl -i -X POST to the registered URL returns a non-3xx (ideally 400 for an unsigned request)
[ ] A resent event shows 200 in Event deliveries

If you'd rather not follow redirects by hand, WebhookProof's free checker sends 3 harmless requests to your webhook URL and reports redirects, auth walls, and whether the endpoint accepts unsigned events. The guide for this case is here: Stripe webhook 307 / 308 redirect error (Vercel, Next.js).

WebhookProof is an independent tool, not affiliated with Stripe, Inc. or Vercel Inc. Quotes are from the linked documentation as read on 2026-10-18.

Sources

Stripe, Receive Stripe events in your webhook endpoint (3xx counted as failures, "URL resolved by the redirect", public HTTPS, retries, resend windows, signature verification): https://docs.stripe.com/webhooks
Next.js, trailingSlash (default redirect behavior): https://nextjs.org/docs/app/api-reference/config/next-config-js/trailingSlash
Next.js, skipTrailingSlashRedirect (308 status table): https://nextjs.org/docs/app/api-reference/config/next-config-js/skipTrailingSlashRedirect
Next.js, redirects (permanent → 308/307, why 307/308, checked before the filesystem): https://nextjs.org/docs/app/api-reference/config/next-config-js/redirects
Next.js, proxy.js file convention (rename from middleware in v16, matcher behavior, negative matcher example): https://nextjs.org/docs/app/api-reference/file-conventions/proxy
Vercel, Deploying & Redirecting Domains (automatic www/apex redirect, www recommended as primary): https://vercel.com/docs/domains/working-with-domains/deploying-and-redirecting
Vercel, Redirects (307/308 recommendation, firewall 307, double-slash 308 normalization, curl verification): https://vercel.com/docs/redirects

Stripe webhook returns 401 on a Supabase Edge Function? Here's the fix (and the step after it)

WebhookProof — Sun, 18 Oct 2026 23:56:07 +0000

Checkout works. The customer pays. Stripe's delivery log for your webhook shows 401 on every attempt, and your Edge Function logs show nothing at all.

That combination is almost always Supabase's built-in JWT check, not your Stripe code. This post covers why it happens, how to turn it off for the webhook function only, and the step you must take right after, because once the function is public, the Stripe signature is the only thing protecting it. Every claim links to the doc it comes from (see Sources at the end).

What the 401 looks like

Open the endpoint in the Stripe Dashboard and look at a failed delivery. If the response body is one of these, the request never reached your handler:

{ "code": 401, "message": "Missing authorization header" }

{ "code": 401, "message": "Invalid Token or Protected Header formatting" }

Supabase's troubleshooting guide says both messages "come from the legacy auth verification check", which "runs before your code. When it fails, your function never executes." If the body is a message you wrote yourself (or empty), your own code returned the 401 and you should look there instead.

Stripe's side agrees: its webhook docs list 4xx responses, including 401 and 403 "when the destination URL has access restrictions", as failed deliveries, and ask that your endpoint be "publicly accessible to the internet".

Why it happens

Supabase's function configuration docs: "By default, Edge Functions require a valid JWT in the authorization header." Stripe sends a Stripe-Signature header and a JSON body. It has no Supabase user token, so the platform rejects it with a 401 before Deno.serve (or your exported fetch) ever runs.

Supabase calls this out directly: "Stripe webhooks need to be publicly accessible (Stripe doesn't have your user tokens)."

Fix 1: turn off JWT verification for the webhook function only

In `config.toml` (sticks across deploys)

This is the exact example in Supabase's function configuration docs:

# supabase/config.toml
# Disables authentication for the Stripe webhook.
[functions.stripe-webhook]
verify_jwt = false

The key after functions. is your function's name. Leave every other function on the default.

On the CLI

The supabase functions deploy reference lists --no-verify-jwt ("Disable JWT verification for the Function"), and Supabase's own Stripe example deploys with it:

supabase functions deploy stripe-webhook --no-verify-jwt

For local testing, the same flag works on serve, and the example pairs it with stripe listen:

# terminal 1
supabase functions serve --no-verify-jwt --env-file ./supabase/.env.local
# terminal 2
stripe listen --forward-to localhost:54321/functions/v1/stripe-webhook

In the Dashboard

Supabase's 401 troubleshooting guide also lists a Dashboard route: open the function's detail tab and toggle off JWT verification. If your function gets redeployed by a tool (an AI app builder, a CI job), put the setting in config.toml as well so a redeploy doesn't quietly turn it back on. Users have reported exactly that in a Supabase CLI issue (linked below), where "Enforce JWT verification" was enabled again after a push.

Fix 2: verify the Stripe signature, the Deno way

Supabase's docs carry a warning with the flag: it "will allow anyone to invoke your Edge Function without a valid JWT." Your webhook URL is now public. If the handler trusts the JSON body, anyone who knows the URL can POST a hand-written checkout.session.completed and unlock your product.

Supabase's "Securing Edge Functions" page says the same for external webhooks: providers like Stripe "sign the request body with their own shared secret", so skip the credential check, "then verify the provider's signature inside the handler. Keep verify_jwt = false."

Two details matter in Deno:

Use the raw body. Stripe: "Stripe requires the raw body of the request to perform signature verification... Any manipulation to the raw body of the request causes the verification to fail." Read it with await req.text(). Don't call req.json() first.
Use the async verifier with a Web Crypto provider. stripe-node's SubtleCryptoProvider "only supports asynchronous operations". Its synchronous path throws SubtleCryptoProvider cannot be used in a synchronous context. So use constructEventAsync with Stripe.createSubtleCryptoProvider(), not constructEvent.

This is the shape of Supabase's official Stripe webhook example:

// supabase/functions/stripe-webhook/index.ts
import Stripe from 'npm:stripe@^22'
import { withSupabase } from 'npm:@supabase/server@^1'

const stripe = new Stripe(Deno.env.get('STRIPE_API_KEY') as string)
// Needed to use the Web Crypto API in Deno
const cryptoProvider = Stripe.createSubtleCryptoProvider()

// Stripe verifies the request via its signature, so deploy with verify_jwt = false.
export default {
  fetch: withSupabase({ auth: 'none' }, async (req) => {
    const signature = req.headers.get('Stripe-Signature')
    const body = await req.text() // raw body, not req.json()

    let event
    try {
      event = await stripe.webhooks.constructEventAsync(
        body,
        signature!,
        Deno.env.get('STRIPE_WEBHOOK_SIGNING_SECRET')!,
        undefined,
        cryptoProvider,
      )
    } catch (err) {
      return new Response((err as Error).message, { status: 400 })
    }

    // handle event.type here (e.g. checkout.session.completed)
    return Response.json({ ok: true })
  }),
}

If you're on a plain Deno.serve(async (req) => { ... }) handler instead of the withSupabase wrapper, the three lines that matter are the same: await req.text(), constructEventAsync(...) with cryptoProvider, and a 400 when it throws.

Fix 3: the right signing secret for the right endpoint

A 401 that turns into a 400 after Fix 1 usually means your code is now running but the signature doesn't match. Check which whsec_ value the function has.

From Stripe's webhook docs: "Stripe generates a unique secret key for each endpoint. If you use the same endpoint for both test and live API keys, the secret is different for each one. Additionally, if you use multiple endpoints, you must obtain a secret for each one." The stripe listen command prints its own signing secret too ("Your webhook signing secret is ..."), which is for local forwarding, not your deployed endpoint.

Set the secret for the deployed function with the Supabase CLI (or under Edge Function Secrets in the Dashboard):

supabase secrets set STRIPE_WEBHOOK_SIGNING_SECRET=whsec_...

Supabase's secrets docs note that functions "read a new secret immediately, so you don't need to redeploy." When you go live, swap in the live endpoint's secret. The test one won't verify live events.

How to check

Two curl calls tell you most of what you need. Replace the URL with your function's (https://<project-ref>.supabase.co/functions/v1/<name>).

# 1) Unsigned POST, no Authorization header (this is what Stripe "looks like" to the platform)
curl -i -X POST -H 'content-type: application/json' -d '{}' \
  https://<project-ref>.supabase.co/functions/v1/stripe-webhook

401 with "Missing authorization header": JWT verification is still on. Go back to Fix 1.
400 (with the official example, stripe-node's message is No stripe-signature header value was provided.): good. The function is reachable and rejects unsigned events.
200: the function is reachable but accepts unsigned events. Go to Fix 2 now.

Then, in the Stripe Dashboard, resend a failed event and confirm the delivery shows a 2xx. Stripe's docs say Dashboard resends work "for up to 15 days after the event creation", and in live mode Stripe itself keeps retrying for up to three days.

If you'd rather not run the curls by hand, WebhookProof's free checker runs the reachability and unsigned-event checks against your URL with 3 harmless requests: Stripe webhooks on Supabase Edge Functions: 401s and signature errors.

Checklist

[ ] verify_jwt = false for the webhook function only, in supabase/config.toml (and/or deployed with --no-verify-jwt)
[ ] Handler reads await req.text() before anything else touches the body
[ ] Verification uses constructEventAsync + Stripe.createSubtleCryptoProvider() and returns 400 on failure
[ ] STRIPE_WEBHOOK_SIGNING_SECRET is the whsec_ for this endpoint in this mode (not the stripe listen one in production)
[ ] An unsigned curl gets 400, and a resent Dashboard event gets 2xx

WebhookProof is an independent tool, not affiliated with Stripe, Inc. or Supabase, Inc. Quotes are from the linked documentation as read on 2026-10-18.

Sources

Supabase, Function Configuration (default JWT requirement, verify_jwt = false example for stripe-webhook, --no-verify-jwt caution): https://supabase.com/docs/guides/functions/function-configuration
Supabase, Edge Function 401 error response (error bodies, "runs before your code", Dashboard / CLI / Management API fixes): https://supabase.com/docs/guides/troubleshooting/edge-function-401-error-response
Supabase, Securing Edge Functions (external webhooks: auth: 'none', verify signature, keep verify_jwt = false): https://supabase.com/docs/guides/functions/auth
Supabase, Handling Stripe Webhooks example: https://supabase.com/docs/guides/functions/examples/stripe-webhooks
Supabase example source (constructEventAsync, createSubtleCryptoProvider, req.text()): https://github.com/supabase/supabase/blob/master/examples/edge-functions/supabase/functions/stripe-webhooks/index.ts
Supabase example README (serve --no-verify-jwt, deploy --no-verify-jwt, stripe listen): https://github.com/supabase/supabase/blob/master/examples/edge-functions/supabase/functions/stripe-webhooks/README.md
Supabase CLI reference, supabase functions deploy (--no-verify-jwt flag): https://supabase.com/docs/reference/cli/supabase-functions-deploy
Supabase, Environment variables / secrets (supabase secrets set, no redeploy needed): https://supabase.com/docs/guides/functions/secrets
Supabase CLI issue #3397 (users reporting verify_jwt = false not applied / JWT enforcement re-enabled after a push): https://github.com/supabase/cli/issues/3397
Stripe, Receive Stripe events in your webhook endpoint (raw body, per-endpoint and per-mode secrets, 4xx delivery errors, retries, resend window): https://docs.stripe.com/webhooks
stripe-node, SubtleCryptoProvider source (async-only): https://github.com/stripe/stripe-node/blob/master/src/crypto/SubtleCryptoProvider.ts
stripe-node, Webhooks.ts source (error messages): https://github.com/stripe/stripe-node/blob/master/src/Webhooks.ts

Customer paid but didn't get access? 4 reasons your Stripe webhook is silently failing

WebhookProof — Sun, 18 Oct 2026 23:38:57 +0000

A customer emails you: "I paid, but I still can't log in." Stripe shows a successful payment. Your app shows nothing. No exception, no log line. The webhook that should have unlocked their account either never arrived or arrived and was handled wrong.

Below are the four most common causes, how to confirm each one, and a short fix for Node/Next.js and Supabase. Every claim links to the docs it comes from.

If you'd rather check first and read later, WebhookProof is a free tool that sends your webhook URL 3 harmless requests and tells you whether Stripe can reach it and whether it rejects unsigned events. (Not affiliated with Stripe, Inc.)

Before anything: read the delivery log

In the Stripe Dashboard, open your webhook endpoint and look at its event deliveries. Each attempt records the HTTP status your server returned, and that status usually points straight at one of the causes below:

Status in the log	Most likely cause
301 / 302 / 307 / 308	#1 Redirect
401 / 403	#2 Auth wall
200, but anyone can trigger it	#3 No signature verification
400 "No signatures found matching the expected signature"	#4 Body was parsed before verification

Stripe documents these delivery errors on its Receive events / webhooks page.

1. The endpoint redirects (www, https, trailing slash)

Stripe does not follow redirects on webhook deliveries. From the Stripe webhooks docs:

We consider redirect responses to webhook requests as failures. Set the webhook endpoint destination to the URL resolved by the redirect.

Common sources of a surprise redirect:

Apex vs www. Vercel lets you redirect between example.com and www.example.com (Vercel docs). If Stripe is pointed at the non-canonical host, every event bounces.
Trailing slash. "By default Next.js will redirect URLs with trailing slashes to their counterpart without a trailing slash" (Next.js trailingSlash docs). So /api/webhooks/stripe/ gets a redirect. With trailingSlash: true it's the reverse.
Redirect rules. In Next.js redirects(), permanent: true returns 308 and permanent: false returns 307 (Next.js redirects docs). A broad rule can catch your webhook path.
http to https. Always register the https URL.

Confirm it:

curl -i -X POST https://example.com/api/webhooks/stripe

If the response is a 3xx with a location: header, that header is your real URL.

Fix: paste the exact final URL (host, scheme, slash and all) into the endpoint settings in the Dashboard, then resend a failed event from the Dashboard. Don't try to "fix" it by adding more redirects.

2. An auth wall is asking Stripe to log in

Stripe can't send a session cookie, a Supabase JWT or a Vercel login. If anything in front of your handler requires one, Stripe gets a 401/403 and your code never runs.

Supabase Edge Functions: JWT verification

Edge Functions check for a Supabase JWT by default. Supabase's own Stripe webhook example says: "Stripe verifies the request via its signature, so deploy with verify_jwt = false." The function configuration docs show how to do it for just that function:

# supabase/config.toml
[functions.stripe-webhook]
verify_jwt = false

That makes the function publicly callable, which is exactly why cause #3 (signature verification) is not optional.

Vercel Deployment Protection

If Deployment Protection covers the URL Stripe calls (often a preview or *.vercel.app URL), Stripe hits a login wall. The simplest fix is to point Stripe at your production domain. If you really need a protected deployment to receive webhooks, Vercel's Protection Bypass for Automation supports an x-vercel-protection-bypass query parameter, and the docs name Stripe as a case for it:

https://your-deployment.vercel.app/api/webhooks/stripe?x-vercel-protection-bypass=YOUR_SECRET

Your own middleware / proxy

Auth middleware that runs on every route will run on your webhook route too. Without a matcher, Next.js "Proxy runs on every request" (Next.js proxy docs; middleware has been renamed to proxy, same idea). Exclude the webhook path:

// proxy.ts (or middleware.ts on older Next.js)
export const config = {
  matcher: ['/((?!api/webhooks/stripe|_next/static|_next/image|favicon.ico).*)'],
};

Same idea in Express: register the webhook route before your auth middleware, or skip that path in it.

3. No signature verification: anyone can fake a payment

This one doesn't show up as a failure at all, which is what makes it dangerous. If your handler does something like this:

// Don't do this
const event = await req.json();
if (event.type === 'checkout.session.completed') grantAccess(event.data.object);

then anyone who knows the URL can POST a hand-written checkout.session.completed and unlock your product. Webhook paths are predictable (/api/webhooks/stripe is in half the tutorials out there), so treat the URL as public.

Stripe signs every event with the endpoint's secret in the Stripe-Signature header and tells you to verify it with the official library (Stripe docs: verify events). The signed payload includes a timestamp, and "our libraries have a default tolerance of 5 minutes between the timestamp and the current time," which limits replays (Stripe webhooks docs).

Two extra guards worth adding:

Re-check with the API before granting access. Stripe's fulfillment guide retrieves the Checkout Session and checks payment_status isn't unpaid. A forged event can't fake the API's answer.
Make fulfillment idempotent. The same guide warns your fulfill function "might be called multiple times, possibly concurrently, for the same Checkout Session."

async function fulfill(sessionId: string) {
  const session = await stripe.checkout.sessions.retrieve(sessionId);
  if (session.payment_status === 'unpaid') return;
  // Use a unique constraint on session.id so a second call is a no-op
  await db.grantAccessOnce(session.id, session.customer_details?.email);
}

Also watch the secret itself: "if you use the same endpoint for both test and live API keys, the secret is different for each one" (Stripe webhooks docs). Shipping to production with the test whsec_ (or the stripe listen secret) makes every live event fail verification.

Confirm it: send an unsigned request to your own endpoint.

curl -i -X POST -H 'content-type: application/json' -d '{}' \
  https://example.com/api/webhooks/stripe

A correctly protected endpoint answers 400. A 200 means it accepts unsigned events.

4. Your framework parsed the body before you verified it

From the Stripe webhooks docs:

Stripe requires the raw body of the request to perform signature verification. If you're using a framework, make sure it doesn't manipulate the raw body. Any manipulation to the raw body of the request causes the verification to fail.

Parsing JSON and stringifying it again changes whitespace and key order, so the signature no longer matches. The Node library then throws "No signatures found matching the expected signature for payload." The tempting "fix" is deleting the check, which takes you straight back to cause #3.

Next.js App Router

Read the body as text and pass that exact string in. Don't call req.json() first. Route handlers give you a standard Request:

// app/api/webhooks/stripe/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();                      // raw body
  const signature = req.headers.get('stripe-signature') ?? '';

  let event: Stripe.Event;
  try {
    event = stripe.webhooks.constructEvent(body, signature, process.env.STRIPE_WEBHOOK_SECRET!);
  } catch {
    return new Response('Invalid signature', { status: 400 });
  }

  if (
    event.type === 'checkout.session.completed' ||
    event.type === 'checkout.session.async_payment_succeeded'
  ) {
    await fulfill((event.data.object as Stripe.Checkout.Session).id);
  }

  return new Response(null, { status: 200 });
}

Those two event types are the ones Stripe's fulfillment guide handles for Checkout. The second one covers delayed payment methods.

Next.js Pages Router

The API routes docs list webhook signature checks as the reason to turn off the body parser:

// pages/api/webhooks/stripe.js
export const config = { api: { bodyParser: false } };

async function rawBody(req) {
  const chunks = [];
  for await (const chunk of req) chunks.push(typeof chunk === 'string' ? Buffer.from(chunk) : chunk);
  return Buffer.concat(chunks);
}

export default async function handler(req, res) {
  const buf = await rawBody(req);
  try {
    const event = stripe.webhooks.constructEvent(buf, req.headers['stripe-signature'], process.env.STRIPE_WEBHOOK_SECRET);
    // ...handle event
    res.status(200).end();
  } catch {
    res.status(400).send('Invalid signature');
  }
}

Express

Give the webhook route express.raw() and register it before any global express.json():

app.post('/api/webhooks/stripe', express.raw({ type: 'application/json' }), (req, res) => {
  let event;
  try {
    event = stripe.webhooks.constructEvent(req.body, req.headers['stripe-signature'], process.env.STRIPE_WEBHOOK_SECRET);
  } catch {
    return res.status(400).send('Invalid signature');
  }
  // ...handle event
  res.sendStatus(200);
});

app.use(express.json()); // everything else

Supabase Edge Functions (Deno)

Deno needs the async verifier and a Web Crypto provider, as in Supabase's Stripe example:

import Stripe from 'npm:stripe';

const stripe = new Stripe(Deno.env.get('STRIPE_API_KEY')!);
const cryptoProvider = Stripe.createSubtleCryptoProvider();

Deno.serve(async (req) => {
  const signature = req.headers.get('Stripe-Signature') ?? '';
  const body = await req.text(); // raw body

  let event;
  try {
    event = await stripe.webhooks.constructEventAsync(
      body, signature, Deno.env.get('STRIPE_WEBHOOK_SIGNING_SECRET')!, undefined, cryptoProvider,
    );
  } catch (err) {
    return new Response((err as Error).message, { status: 400 });
  }

  // ...handle event
  return new Response(JSON.stringify({ received: true }), { status: 200 });
});

The synchronous constructEvent doesn't work there, and neither does parsing JSON first.

One more thing: don't rely on the success page

Even with a perfect webhook, fulfilling only on the redirect page will eventually miss someone. Stripe says: "You can't rely on triggering fulfillment only from your checkout landing page, because it's not guaranteed customers visit that page" (Stripe fulfillment docs). Call the same idempotent fulfill() from both the webhook and the success page.

And once it's fixed, you don't have to wait for retries. In live mode Stripe retries failed deliveries for up to three days (Stripe webhooks docs), and you can resend a failed event from the Dashboard right away. For the customers who already paid, run fulfill() for their Checkout Session IDs.

Quick checklist

[ ] The URL in Stripe is the final URL: no 3xx from curl -i -X POST
[ ] No JWT, login, deployment protection or auth middleware in front of the route
[ ] An unsigned POST gets a 400, not a 200
[ ] Verification uses the raw body and the right whsec_ for the mode
[ ] Fulfillment re-checks the session via the API and is safe to run twice

If you want a second opinion on the first three, the free check at webhookproof.com runs them against your URL with 3 harmless requests and shows the results. WebhookProof is an independent tool, not affiliated with Stripe, Inc.

DEV Community: WebhookProof

Customer paid in your Lovable or Bolt app but nothing unlocked? Where to look first

Step 0: find out which setup you have

Lovable with your own Stripe account: no webhooks by default

1. One-time purchases granted only on the success page

2. Subscriptions matched by email

Bolt: the webhook function exists, so check that it runs

Reading the status code (both builders)

Test vs live: the go-live trap

Fixing customers who already paid

Checklist

Sources

Stripe webhook shows 307 or 308 on Vercel / Next.js? It's a redirect, and Stripe won't follow it

Why a redirect counts as a failure

Why 307 and 308 specifically

Cause 1: the trailing slash

Cause 2: apex vs www (domain redirect)

Cause 3: a redirects() rule that matches the webhook path

Cause 4: Proxy (formerly Middleware) redirecting to login

One more: double slashes

How to find the real URL

Checklist

Sources

Stripe webhook returns 401 on a Supabase Edge Function? Here's the fix (and the step after it)

What the 401 looks like

Why it happens

Fix 1: turn off JWT verification for the webhook function only

In config.toml (sticks across deploys)

On the CLI

In the Dashboard

Fix 2: verify the Stripe signature, the Deno way

Fix 3: the right signing secret for the right endpoint

How to check

Checklist

Sources

Customer paid but didn't get access? 4 reasons your Stripe webhook is silently failing

Before anything: read the delivery log

1. The endpoint redirects (www, https, trailing slash)

2. An auth wall is asking Stripe to log in

Supabase Edge Functions: JWT verification

Vercel Deployment Protection

Your own middleware / proxy

3. No signature verification: anyone can fake a payment

4. Your framework parsed the body before you verified it

Next.js App Router

Next.js Pages Router

Express

Supabase Edge Functions (Deno)

One more thing: don't rely on the success page

Quick checklist

Cause 3: a `redirects()` rule that matches the webhook path

In `config.toml` (sticks across deploys)