Audit and tune how my app recovers failed subscription renewals. Separate from the dunning emails, this is the retry machinery itself. Configure deliberately: the provider's smart retry schedule is enabled and understood (Stripe retries on an optimized schedule over roughly 2-4 weeks; know what mine is set to and why); automatic card updater is enabled (card networks tell the provider when a card is reissued, so expired-card churn often fixes itself; confirm it's on); my subscription state during the retry window matches the dunning flow (past_due with the documented access policy, not instant cancellation and not indefinite free access); retry success immediately restores normal state and sends the recovery confirmation; and final failure after the retry window triggers the deliberate end state (cancel with notice, downgrade to free), executed by the webhook, not a cron that guesses. Don't retry charges on my own schedule with a custom job on top of the provider's retries; stacked retries look like card testing to banks and make declines worse. Don't treat hard declines (stolen card, closed account) the same as soft ones (insufficient funds); hard declines won't recover and should skip straight to the end state when the provider says so. Deliver: the retry configuration with reasoning, the state handling per decline type, and verification in test mode: fail a renewal with a soft-decline test card, confirm retries proceed and state stays past_due, then succeed on update and confirm full recovery.