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

Dunning and failed payments

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

invoice.payment_failed — what do I do with it?

It's your dunning trigger. It fires when a charge for an invoice fails — for subscriptions that includes renewal attempts. The invoice's attempt_count and next_payment_attempt fields tell you where you are in the retry sequence. Your app should: email the customer, set an internal grace-period timer, and point them at a self-serve card-update page (a fresh Checkout Session in setup mode, or the customer portal). Do NOT immediately revoke access on the first failure — most failures are transient (insufficient funds timing, bank declines) and Smart Retries recover a large share. Revoke when the subscription transitions to unpaid/canceled per your Billing retry settings, i.e. on customer.subscription.updated with a terminal-ish status.

How do Smart Retries actually work?

Stripe's Smart Retries (the default dunning mode) uses machine learning to pick retry times within a configurable window, rather than fixed intervals, because decline types respond differently to timing (payday effects, card velocity limits). You can instead define custom retry rules (e.g. retry after 3, 5, 7 days) in Dashboard → Settings → Billing → Subscriptions and emails. There you also set the final outcome when retries are exhausted: mark subscription unpaid, cancel it, or leave it past_due. As of early 2026 this is configured in the Dashboard (and partially via the API on accounts with Billing features enabled), not per-subscription by default. Hard declines (stolen card, closed account) aren't retried regardless.

Customer's card expired at renewal — can I prevent that failure?

Mostly yes, for free. Stripe automatically works with card networks' account updater services: when an issuer replaces or expires a card, Stripe often receives the new details and updates the saved payment method without customer involvement — this silently prevents a large fraction of renewal failures. You still must handle the remainder. Watch invoice.upcoming (fires ~3 days before renewal) to warn users with expiring cards, and on invoice.payment_failed route them to update their card. Note the failure code: 'expired_card' and hard declines warrant immediate outreach; 'insufficient_funds' warrants patience and retries. Never auto-retry aggressively from your own code on top of Smart Retries — issuers may flag the merchant for excessive attempts.

Should past_due subscribers keep access during dunning?

Decide explicitly — Stripe won't decide for you. Statuses past_due and unpaid still bill the customer when a retry eventually succeeds, so cutting access on day one means users who get recovered by Smart Retries churn angrily; keeping full access indefinitely means free riders. Standard SaaS pattern: full access for a grace period (commonly 3–14 days) after the first invoice.payment_failed, with escalating in-app banners and emails; downgrade to read-only or locked after that; fully revoke on unpaid/canceled. Encode the grace deadline yourself (first_failure_time + N days) — Stripe has no 'grace period' concept. And always restore access instantly when invoice.paid arrives; delayed restoration generates the worst support tickets.

Renewal fails — what does Stripe do automatically, and what's on me?

Stripe's automatic side: it generates the renewal invoice, attempts the charge, transitions the subscription to past_due on failure, and runs dunning per your Billing settings — Smart Retries (the default) uses ML to pick retry times rather than fixed intervals, and a custom schedule is available; check your Dashboard for the exact days rather than hardcoding any pattern. When retries are exhausted, Stripe applies your configured final action: mark the subscription unpaid, cancel it, or leave it past_due. Your three duties: (1) notify — emails and in-app warnings on invoice.payment_failed with a self-serve card-update link; (2) access policy — define the grace window during past_due and enforce revocation on unpaid/canceled; (3) watch — handle customer.subscription.updated and reconcile, because Stripe keeps retrying whether you notice or not.

Give your agent this brain