What is dunning management?
Dunning management is the coordinated process a business uses after a recurring payment or invoice is not collected as expected. It usually brings together payment-status monitoring, eligible retry attempts, customer notifications, a secure way to update payment details, internal follow-up, and a defined outcome when recovery does not succeed.
The term describes a workflow rather than one universal schedule. Billing platforms differ in how they classify failures, time retries, send notices, and change invoice or subscription status. A business should use the controls and current documentation for its actual provider instead of applying a generic sequence to every payment.
What a dunning workflow coordinates
Payment events
The workflow begins with a reliable record of the failed collection event and its current status. Teams need to know whether another attempt is eligible, whether customer action is required, and when the billing platform expects the next event.
Customer communication
A useful notice explains that the payment needs attention, identifies the affected invoice or subscription in a privacy-safe way, and directs the customer to an authenticated billing page. It should never ask a customer to send complete payment credentials by ordinary email or a general contact form.
Account outcomes
The process also defines what happens after the configured recovery window. Depending on the platform and business policy, an invoice or subscription may remain overdue, move to another status, or require staff review. The billing record and service-access process should stay aligned.
Retries are only one part of dunning
Automated retry logic can reattempt eligible failed payments, but another attempt cannot solve every failure. An outdated payment method, missing billing information, or a provider response that requires customer action needs a clear update path. Repeating attempts without considering the failure status can create confusion and unnecessary customer contacts.
Stripe's current Billing documentation presents retries, customer emails, payment-method updates, automations, and recovery analytics as related revenue-recovery tools. Its retry documentation distinguishes automated timing from custom schedules and notes that some failures cannot be retried without a usable payment method. PayPal's current subscription documentation uses its own retry and failure-threshold behavior. These differences show why dunning rules must be verified for the billing system actually handling the subscription.
A practical dunning review
- Map the starting event. Identify the invoice or renewal event that opens the recovery workflow and the status information available from the provider.
- Separate retry from customer action. Document which outcomes may receive another attempt and which require a new or updated payment method.
- Coordinate notices. Decide when the customer receives a message, what the message explains, and where the authenticated update link leads.
- Define ownership. Assign responsibility for automated events, customer questions, exceptional accounts, and any manual follow-up.
- Set the final state. Specify what the billing and service systems should show after the recovery sequence ends without payment.
- Test both paths. Confirm a successful recovery and an unsuccessful final outcome using provider test tools where available.
What teams should measure
Useful operational reporting separates initial failures, retry attempts, customer payment-method updates, recovered invoices, unresolved invoices, and accounts that reached the end of the workflow. Looking at each stage helps a team find missing notices, delayed status updates, duplicate messages, or customers who cannot reach the correct update page.
Recovery results should be interpreted alongside the mix of failure reasons and the configured recovery window. A single headline rate does not explain whether a problem comes from payment quality, a broken communication step, an unavailable update path, or a mismatch between billing and account systems. Teams should compare like periods and document configuration changes before drawing conclusions.
Questions to ask before enabling automation
Does every failed payment enter the same sequence?
Not necessarily. The provider's failure status, payment method, invoice collection method, and available account settings can affect whether another attempt occurs or the customer must act first.
Where should customers update payment details?
Use an authenticated billing portal or another provider-supported secure flow. General email, chat, and contact forms should not collect complete card numbers, bank credentials, passwords, or secret account information.
How should service access be handled?
That decision belongs to the business's documented customer and service policy. Whatever outcome is chosen, the customer-facing status, billing record, and internal support view should communicate the same current state.
Related Payments Max resources
Read what a failed-payment retry schedule is for a closer look at retry timing. The guide to reducing involuntary churn covers the broader customer lifecycle. You can also browse the Payments Max FAQ library and resource center for additional payment-workflow guidance.
Document the complete recovery path
Before turning on a dunning workflow, record the triggering event, retry boundaries, customer message, secure update route, internal owner, final billing status, and service response. Then compare that map with the current controls offered by the provider you use.
If you want help organizing payment-processing requirements, contact Payments Max with a high-level description of your billing workflow. Do not submit cardholder data, bank credentials, passwords, complete account numbers, or secret API keys through the general contact form.
To learn more about how TSYS can help improve the way your organization accepts payments, markets to new customers, or manages its HR responsibilities, get in touch by calling 585-981-8463 to get started.
CONTACT US