Customer says checkout is broken — which of the 6 failure modes is it?
When a customer says checkout is broken, work through six failure modes in order: the route changed or was removed, a blocking third-party script, a CSP or CORS change breaking the payment iframe, a login wall bouncing anonymous buyers, a 200 that's actually a placeholder page, and a client-side error after render. The checks below take about ten minutes and don't require a developer — plus where each one hides on Bubble, Lovable, and Webflow.
A page that loads is not a page that sells.
Most monitors stop at “did the server answer?” Your checkout can answer 200 while serving a maintenance placeholder, a login wall, or a shell whose payment script was blocked at render. The buyer doesn’t see your status page — they see a dead button and leave. Catching this means asserting the page is the real checkout, then proving the buy flow actually reaches payment.
The 6 failure modes, in the order to check them
A deploy changed or removed the checkout route
Symptom: The buy link now 404s, or silently redirects somewhere that isn't checkout.
Fix: Compare the live checkout URL against the last-known-good route and your recent deploys; roll back the deploy if the timing lines up.
A blocking third-party script never finishes loading
Symptom: The page renders but the buy button spins forever and the payment box never appears.
Fix: Open the console on the live page; look for a blocked or failed Stripe.js, analytics, or font request, and unblock or defer it so render isn't held hostage.
A CSP or CORS change broke the payment SDK iframe
Symptom: Everything looks fine until checkout, where the embedded payment frame stays blank.
Fix: Allowlist the payment provider's domains (e.g. js.stripe.com) in your script-src / connect-src / frame-src directives after any header or security change.
The page now requires login and redirects anonymous buyers
Symptom: Logged-in testing passes, but real first-time visitors get bounced to a sign-in screen.
Fix: Always test checkout in incognito; if an auth gate crept in, make the buy path reachable without an account.
It returns 200 but the body is a placeholder
Symptom: Status is green, yet the page shows a "we'll be right back" message or an empty shell.
Fix: Assert a known checkout marker is present and a maintenance string is absent; if a maintenance keyword fired, confirm it was intentional before clearing it.
A client-side error breaks the button after render
Symptom: The page paints correctly, but clicking buy does nothing and no payment step opens.
Fix: Reproduce the click in a real browser session, read the console error, and ship the fix; assert the payment iframe becomes visible as your pass condition.
Where checkout breaks on your platform
Where does checkout break on Bubble?
On Bubble, checkout usually breaks at the workflow or webhook seam, not the page: the buy workflow's conditions stop matching, a privacy rule hides the data the page needs, or the Stripe webhook fails in live mode so payments succeed but orders stop syncing into your database. If you have no developer, start with the Stripe event log and our Bubble webhook guide — both are readable without code.
Where does checkout break on Lovable?
On Lovable, checkout mostly breaks in the publish seam: Stripe only works on the deployed app — in preview the buy button does nothing by design — and webhook secrets live in Supabase edge functions, where a missed secret means payments complete but orders never sync. A blank checkout after publish usually traces to a stale snapshot or a missing environment variable, not your product. The Lovable hub walks each check.
Where does checkout break on Webflow?
On Webflow, checkout usually means an embedded payment — a Stripe buy button, a third-party cart, or custom code — and that embed is where it breaks: a script change blocks it, the embed's keys go stale, or it renders in the Designer but not on the published site. Test the published URL in incognito with the console open, and confirm a test order is actually recorded on the payment side, not just on the page.
Paste this into your incident notes
Checkout page triage
[ ] Open the checkout URL in incognito — does the payment box render?
[ ] Confirm the page body contains the payment SDK marker (e.g. js.stripe.com).
[ ] Confirm the body does NOT contain a maintenance/"be right back" string.
[ ] Open the console; look for blocked scripts (CSP), CORS, or failed SDK loads.
[ ] Compare the live route to the last-known-good URL + recent deploys.
[ ] Click the buy button; confirm the payment iframe actually appears.
[ ] If a maintenance keyword fired, confirm it was intentional.
[ ] Roll back the last deploy if it correlates, then re-test the buy flow.Three checks that walk the buy path, not just ping the URL
Nightlamp layers three probes so a green status can’t hide a dead checkout. An http_status check confirms the URL still exists. An http_keyword check asserts the payment SDK marker is present and a maintenance string is absent — that is what catches “200 but broken.” And a browser_journey check clicks the buy button and asserts the payment iframe actually renders, catching the client-side breakage no status code will ever show.
Want a blank checkout caught before the next buyer does?
Start a trial, point Nightlamp at your checkout URL and the buy button, and we will walk the path on a schedule — status, content, and a real click — then page you in plain English with the fix the moment payment stops loading.
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.