Protect your Stripe account before launch

Stripe is usually the first production integration a SaaS founder trusts with real money. That also makes it one of the worst places to discover a bad permission, stale redirect URL, or broken webhook handler after launch traffic starts.

Use restricted keys deliberately

A restricted key is safer than a full secret key, but only if the permissions match the work your app actually performs. Before launch, confirm the key can read the resources your checkout flow depends on and can access the webhook or checkout operations your backend needs.

If a key was pasted into a browser, chat, issue tracker, or local file that should not hold secrets, rotate it before running another check. PreFlight can tell you whether a key works, but key exposure still needs a credential rotation.

Verify webhook delivery

Checkout success pages are not proof that your backend saw the payment. The webhook route must accept Stripe events, verify the signing secret, return a success status, and update your app state without relying on the customer returning to the browser.

PreFlight checks endpoint reachability and highlights permission or routing failures so you can fix them before a customer pays and never receives access.

Check success and cancel redirects

Redirect URLs often break when a staging domain becomes production, a preview deploy URL is copied into Stripe, or a checkout route moves during a frontend cleanup. Test the exact success and cancel URLs that production customers will hit.

Run a shadow checkout check

A safe Stripe launch rehearsal should prove more than API connectivity. It should confirm that checkout can be created in test mode, the webhook route is reachable, and the expected backend side effect can be verified without charging a real card.

The important detail is the side effect. A SaaS checkout usually needs to write an order, subscription, entitlement, workspace upgrade, invoice record, or audit event. If that row is missing, support will see a customer who paid but cannot access the product. That is why a launch check should follow the trace ID all the way into the database instead of stopping at "Checkout session created."

Watch scripts and source maps

Payment keys are not always leaked in obvious HTML. They can appear in a route that only signed-in users visit, a bundled JavaScript chunk, or a source map published by the build system. Before launch, scan the public origin broadly enough to catch those mistakes and rotate anything that was ever exposed.

The safest pattern is simple: publishable keys may live in the browser, secret keys stay behind server routes, and webhook signing secrets never leave backend runtime configuration. If a source map contains private configuration, remove the map from production or make sure it contains no secret-bearing sources.

That is the work PreFlight is designed to automate: connect Stripe, run the probe, inspect the failed row if something breaks, then rerun before opening the launch tab.