Bubble Stripe webhook broke in live mode? Check these seven things first.
If your Bubble checkout worked in development and Stripe webhooks failed after launch, you are usually looking at a URL, key, event-type, or workflow-exposure mismatch — payments succeed in Stripe while orders stop syncing into Bubble. Here is the fast triage list Nightlamp engineers run first, written so you can follow it with no developer on hand.
Seven live-mode checks
The Stripe endpoint still includes /version-test
Symptom: Test events work, live events silently miss your Bubble workflow.
Fix: Use the live workflow URL for live Stripe events. Bubble's main branch uses version-test for development; deployed live endpoints drop that segment.
Stripe is pointing at /initialize
Symptom: Detection worked once, then real checkout events never trigger the workflow.
Fix: Initialize only teaches Bubble the payload shape. After detection, remove /initialize and send Stripe events to the real workflow endpoint.
Test keys, live keys, and webhook secrets are mixed
Symptom: Stripe says it delivered, but your workflow rejects or ignores the event.
Fix: Keep separate test and live webhook endpoints and store the matching endpoint signing secret for each.
The event type is missing
Symptom: checkout.session.completed is expected, but Stripe never sends it to this endpoint.
Fix: Open the Stripe event destination and confirm it subscribes to the exact event type your Bubble workflow expects.
The Bubble backend workflow requires authentication
Symptom: Stripe reaches Bubble, but Bubble returns a non-2xx or refuses the request.
Fix: Stripe cannot log in as a user. Make the receiving workflow publicly callable, then validate the payload and signing secret inside your workflow.
The domain changed after launch
Symptom: Everything worked on bubbleapps.io, then broke after connecting a custom domain.
Fix: Regenerate the live endpoint URL from Bubble settings and update Stripe. Custom domains change the host portion of the workflow URL.
The workflow does too much before returning success
Symptom: Stripe retries the same event and customers see duplicate side effects.
Fix: Return a 2xx quickly, then do slow work in a scheduled backend workflow. Stripe treats non-2xx responses as failed deliveries.
Paste this into your incident notes
Bubble + Stripe webhook triage
[ ] Confirm Stripe live endpoint URL does not include /version-test.
[ ] Confirm Stripe endpoint URL does not end in /initialize.
[ ] Confirm live endpoint subscribes to checkout.session.completed.
[ ] Confirm Bubble backend workflow is deployed to live.
[ ] Confirm workflow can receive external POST requests.
[ ] Confirm live Stripe key and endpoint signing secret match this endpoint.
[ ] Check Stripe delivery attempt status and Bubble server logs.
[ ] Replay the Stripe event after the URL/key fix.The failure usually starts before checkout looks broken
Nightlamp does not wait for someone to write "payment failed" in your support form. We probe the checkout path, watch the webhook response code, keep the last-known-good endpoint shape, and send a plain-English diagnosis when the contract changes.
Want this caught before a customer emails you?
Start a trial, point us at your Bubble app and the checkout workflow, and we will turn the fragile path into a monitored flow.
Start 14-day trial · no cardNewsletter
One real no-code incident + the fix, monthly
A post-mortem from a real no-code outage — what broke, how it was found, and the fix — once a month. Confirming also gets you the no-code incident runbook pack.
Double opt-in. One-click unsubscribe. No spam, ever.