Subscription Dunning API

A subscription dunning API for teams that need configurable retry-day behavior, dunning end actions, and better recurring failure handling than ad hoc cron jobs.

Flint exposes subscription dunning settings on the public settings surface instead of leaving retry behavior as an opaque processor-side default.

Recurring billing already fits payment methods, subscriptions, and webhook lifecycle events on one public model, so dunning settings attach to the rest of the subscription flow cleanly.

That makes failure handling easier to reason about because retry timing and end action live beside the recurring billing surface instead of only in app glue.

Workflow Outline

Recurring billing is already live, but failed renewals still trigger ad hoc retries and operator guesswork.

Your team needs explicit retry timing and end-action controls instead of inheriting whatever the processor does by default.

Support and lifecycle automation need subscription-failure state to line up with saved cards, webhooks, and billing settings.

What This Solves

Teams searching subscription dunning APIs usually already have recurring billing. The gap is what happens after renewal failure: retry timing, final end action, and a cleaner model for recurring recovery than one-off scripts and support playbooks.

Step 1

Configurable renewal retries

Control how many retry days Flint should use when a recurring payment fails instead of hiding that logic in worker code.

Step 2

End-action clarity

Choose what should happen after retries are exhausted so failed renewals stop drifting between ops tooling and subscription state.

Step 3

Webhook-driven follow-up

Let subscription failure events drive customer communication and support workflows once the dunning policy is explicit.

Step 4

Recurring recovery without cron glue

Keep renewal retry behavior on the Flint billing model instead of scattering it across processor settings and app-side jobs.

Why Flint Fits

Flint exposes subscription dunning settings on the public settings surface instead of leaving retry behavior as an opaque processor-side default.

Recurring billing already fits payment methods, subscriptions, and webhook lifecycle events on one public model, so dunning settings attach to the rest of the subscription flow cleanly.

That makes failure handling easier to reason about because retry timing and end action live beside the recurring billing surface instead of only in app glue.

Choose Another Path When

Use the broader subscriptions page when the current evaluation is plan creation, hosted signup, and recurring billing primitives overall.

Use saved payment methods when the missing piece is billing credential setup rather than renewal failure policy.

Use payment retry and recovery when the problem is one-off payment failures, not recurring renewal behavior specifically.

Implementation References

Reference the exact flow surfaces

Settings API

Configure subscription dunning settings such as retry days and end actions on the public settings surface.

Subscription Billing Guide

Review the recurring billing flow that dunning policy sits on top of.

Subscriptions API

Inspect subscription status and lifecycle fields that your dunning behavior ultimately affects.

Explore recurring billing, saved methods, and failure handling

These pages connect dunning policy to the rest of Flint's recurring billing and recovery model.

Subscriptions API with Trials and Setup Fees

Start here when the current evaluation is the broader recurring billing model rather than renewal failure handling specifically.

Saved Payment Methods API for Platforms

Useful when dunning policy and saved billing credentials need to be designed together.

Payment Retry and Recovery API

Go here when the problem extends beyond subscriptions into one-off payment failure and recovery paths.

Next Step

Ship the workflow before polishing the edge cases

Start with the underlying Flint flow, then layer your product-specific UX and recovery paths on top.