new·The score now tells you which way it movedA brain's exam only ever grows: its own material writes questions, and so does every question a real caller asked and did not get answered. The score is a percentage over that growing set, so a brain that learned more could post a smaller number — and this week three did. One of them answered two MORE questions than the week before and showed eighteen points less. Printed as a single percentage, that reads as decline to a reader and as punishment to anyone who contributes material.all news →
mozg.beta
Sign in

Stripe in Production · all subjects

Testing and going live

4 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

How do I test a subscription renewal without waiting a month?

Use test clocks (as of early 2026 available via the API and Dashboard). Create a test clock, attach a customer to it when creating them, create the subscription, then advance the clock: Stripe fast-forwards time and emits the full webhook sequence — invoice.upcoming, invoice.created, payment attempts, payment_failed on failure cards — exactly as if time really passed. You can simulate an entire dunning cycle or trial expiry in minutes. Limits: a test clock has a cap on attached customers, and clocks only advance forward. Alternative quick checks: Dashboard 'send test webhook' for handler smoke tests, and card 4000 0000 0000 0341 for attach-fails, 4000 0000 0000 9995 for insufficient funds on charge.

We tested everything in test mode — what still breaks in live mode?

The usual suspects: webhook endpoints exist only in test mode (you must register the live-mode endpoint separately, with its own whsec_ secret); restricted API keys scoped to test; SCA/3DS behavior (test cards simulate it, live issuers enforce it unpredictably); Radar rules that only run in live; bank-specific decline codes your test cards never produced; and webhook volume — live mode delivers bursts (renewal days, incident replays) that expose handler timeouts your staging never saw. Also: livemode flag on every object is your only guard against mixing test and live data — always check it in webhooks and ignore events whose livemode doesn't match your environment, or you'll corrupt production state with test events.

Should I store Stripe webhook secrets and keys per environment?

Yes, and keep them strictly separated. You need at minimum: live secret key (sk_live_...), live webhook signing secret(s) (whsec_... per endpoint), and the test-mode pair. Webhook secrets are PER ENDPOINT, not per account — two endpoints means two secrets. Use restricted keys (rk_...) with least privilege for services that only need e.g. read access to subscriptions; keep the full secret key off anything internet-facing. Never ship secret keys to the client — publishable keys (pk_...) only. Rotate on suspicion via Dashboard (rolling rotation keeps the old key valid briefly). And don't hardcode: pull from env/secret manager, because a leaked sk_live_ in a repo is a 'drain the account via payouts-to-fraudsters' incident.

How do I replay webhooks locally during development?

Use the Stripe CLI: `stripe listen --forward-to localhost:3000/api/webhooks` gives you a temporary signing secret and streams live test-mode events to your machine. `stripe trigger checkout.session.completed` (and other event types) synthesizes events on demand — fast for handler iteration, though triggered fixtures are shallower than real flows, so also do at least one real Checkout run against the listener. For production incidents, the Dashboard lets you resend individual past events to an endpoint — useful after your endpoint recovers from an outage, but resends can duplicate events your handler already processed, which is another reason event-id dedupe is non-negotiable. Never disable signature verification 'temporarily' to make local testing easier.

Give your agent this brain