A broken checkout needs evidence before another prompt. Save the failing steps, environment, request IDs and expected result. If you keep asking the builder to rewrite broad parts of the app, you can lose the reproducible failure and introduce a second problem.
This is a diagnostic checklist, not a claim that every Bolt app has these bugs. The symptoms below can occur in many web applications. Check what your project actually uses: a Bolt database, Supabase or another backend; test or live payment credentials; and the current deployed version.
Build one repeatable buying-path test
Use a test account and payment sandbox where possible. Record browser, deployment, product and steps. Do not paste passwords, live payment secrets or customer records into a prompt. Keep logs redacted.
| Symptom | Evidence to collect | What a useful fix must prove |
|---|---|---|
| Login disappears on refresh | Session state and auth response before/after reload | Access survives the intended flow without exposing another user |
| Payment success but no order | Checkout/session ID and server event outcome | One paid event creates the right order exactly once |
| Buyer sees another user's record | Two-account authorization test | Server and database deny the cross-account request |
| Stock differs between screens | Source inventory and update timing | Agreed inventory source is used consistently |
| Works locally, fails in production | Deploy logs and environment configuration | Production uses the correct settings without exposing secrets |
Test one change at a time and keep a known-good version to compare. A page loading without errors is not proof the transaction works.
Check session handling without weakening access
A refresh logout can have several causes: expiry, redirect configuration, missing session restoration or incorrect server/client integration. Inspect the actual auth provider and follow its current guidance. Do not 'fix' it by removing authorization checks or making a private table public.
Use two test accounts. Confirm each can read its own data and cannot read the other's. Test signed-out access as well. Keep the test in the project so a later AI edit cannot silently undo the boundary.
Verify payments on the server
Stripe's fulfillment guide explains reliable order fulfillment around Checkout events. A shopper may close the browser before reaching the success page, so do not make that redirect the only trigger.
Check webhook signature verification, event handling and duplicate delivery. Stripe's signature guidance explains that verification needs the correct endpoint secret and unmodified request body. Confirm the handler records payment and order states safely when the same event arrives again.
Use test mode first. Do not create real charges just to debug. Review refunds, failed payments and fulfillment separately; a payment and a shipped order are different states.
Use security checks, then verify the behavior
Bolt's project security documentation distinguishes the full project audit from a database security check. At this check, the full audit is available on paid plans and the database check on all plans. Verify current access in your own account before relying on a button.
The database security page explains warnings such as overly open permissions and missing row-level security. Review the proposed changes; do not assume an automatic fix preserves the intended business access rules. Repeat the two-account tests afterward.
Reconcile inventory and production configuration
Name the inventory source of truth. Trace an order from checkout to the stock update and fulfillment system. Decide how your system handles simultaneous purchases and failed updates. Do not rely on a displayed stock count without checking the underlying update path.
For production-only failures, compare environment names, callback URLs, database access and deployment logs. Rotate a secret if it was exposed; deleting it from the visible page does not revoke it. Keep secrets on the server and check what the browser bundle contains.
Repair or migrate based on scope
Repair is easier to justify when the failure is reproducible, localized and covered by a test. A broader assessment is useful when nobody can explain the payment or authorization model, or when repeated fixes break other flows.
Use the inherited-code checklist for that assessment. If Shopify fits the required buying path, compare the migration steps and budget worksheet. Meetanshi's rescue service is a route to a scoped review, not a guarantee that a particular bug can be fixed in a set time.