Stripe dunning: retries versus customer authentication

Stripe dunning needs different responses for different payment failures: retry a retryable decline, but send the customer through authentication when the payment requires it. Another background attempt does not complete an authentication challenge; check the failed invoice and its payment details before choosing the next action.

Why this matters

Dunning means the work of collecting failed subscription payments: retries, customer messages, payment updates, and follow-up. Those actions are not interchangeable. An email asking for a different card sends the wrong instruction when the customer needs to authenticate the existing payment.

For your 2026 recovery review, start with the unresolved invoice rather than the number of emails sent. The Stripe failed-payment recovery audit checklist provides a starting point for organizing that review.

Recovery is complete when the outstanding invoice is paid—not when an email is delivered or a card is updated. Keep that distinction visible in support conversations and recovery reporting.

Stripe dunning: retries versus customer authentication

Use the failure reason and the underlying payment state together. Stripe invoice status describes the billing outcome; the associated PaymentIntent, where present, gives more detail about the payment attempt. A PaymentIntent tracks a payment through its required steps.

These are routes through recovery, not competing products. A customer can authenticate and still receive a decline afterward. A new card can also require authentication.

Do not classify every failed renewal as an authentication problem. Inspect the actual failure before sending instructions.

When should Stripe retry the payment?

A retry is appropriate when the payment can be attempted again without first collecting missing customer action or replacing an unusable payment method. Temporary payment problems can fit this route. A failure that explicitly requires a new payment method does not become recoverable simply because another attempt is scheduled.

Check your Stripe configuration before assuming a retry will happen. Review the invoice, its payment attempt history, and the recovery settings that apply to the subscription. Keep scheduled attempts separate from completed attempts in your notes.

For a 2026 settings review, record what is configured now rather than relying on an old implementation document. Configuration changes and additional billing tools can make that document inaccurate.

Keep a background retry on the retry route only while the payment remains eligible for it. When the payment needs customer action, the next useful step is a customer-facing recovery path.

When does the customer need to authenticate?

Customer authentication is required when the payment enters a state that asks the customer to complete an additional verification step. In Stripe, a PaymentIntent with requires_action needs further action before the payment can finish. Inspect its next_action information to understand the required step.

Card authentication can involve 3-D Secure, which allows the card issuer to verify the customer. Not every authentication flow displays an interactive challenge. When a challenge is required, an unattended server-side retry cannot answer it for the customer.

Use a payment flow that supports the outstanding invoice and its authentication requirement. Stripe's Hosted Invoice Page supports payment collection and required authentication; a custom integration needs to handle the required payment actions correctly.

Your message should explain the action without promising approval: the payment needs verification, and the customer must open the payment page to continue. Do not ask customers to send card details, security codes, or authentication codes by email.

How do you choose the right recovery action?

Use this sequence for an unresolved renewal. It separates diagnosis from communication and gives support a clear handoff to billing or engineering.

1. Inspect invoice. Identify the unpaid renewal and confirm its current status. Check whether it has already been paid, voided, or otherwise resolved before contacting the customer.
2. Read payment state. Review the latest payment attempt, failure information, and any required next action. Do not rely on the email subject line as your diagnosis.
3. Choose action. Select a retry, authentication request, payment-method update, or manual investigation based on the evidence.
4. Contact customer. Send instructions that match the action. Include the appropriate secure payment destination rather than a generic account-login instruction that leaves the customer searching.
5. Confirm payment. Recheck the invoice after the customer acts. Close the recovery case only when the billing outcome supports it.

Keep the same invoice reference throughout this sequence. Otherwise, a successful payment on a different invoice can be mistaken for recovery of the renewal you are investigating.

For your 2026 operating checklist, document who handles each step. Software can trigger an action, but someone still needs to investigate exceptions and incorrect messages.

Why Stripe dunning outcomes vary

Recovery outcomes depend on what prevented payment and what happens afterward. Review these factors separately rather than treating every unresolved invoice as evidence that retries failed.

• Failure reason. A temporary decline, an authentication requirement, and an unusable payment method call for different actions.
• Payment state. A scheduled attempt is not a successful payment. Read the latest state before deciding what to do next.
• Customer instructions. A generic card-update email does not explain an authentication requirement. Tell the customer which action is needed.
• Billing contact. The person receiving the message needs access to the payment flow or a clear way to reach the authorized payer.
• Recovery ownership. Unreviewed exceptions remain unresolved even when automated retries and emails are configured.
• Subscription handling. Your cancellation and access rules affect what happens while an invoice remains unpaid. Review those rules alongside collection settings.

These factors also explain why email engagement is not a recovery result. An opened message tells you nothing conclusive about whether the invoice was paid.

Should you change the card or authenticate the payment?

Authenticate the payment when authentication is the outstanding requirement; request a replacement method when the existing method cannot complete collection. Do not make every customer replace a card before checking the failure.

A card update and authentication solve different problems. Replacing a method changes what you can charge. Authentication verifies a payment when the issuer requires it.

After either action, check the invoice again. If payment still fails, use the latest failure information rather than repeating the original instruction. The next failure can require a different response.

Can Stripe's built-in recovery handle this?

Stripe provides built-in recovery settings, including retry and customer-email controls. Start by checking which controls your account uses and whether your payment flow handles authentication correctly. Do not buy another system to compensate for an unexamined configuration.

Built-in recovery is a reasonable operating choice when your team can configure it, review unresolved payments, maintain messages, and handle exceptions. Its limitation is organizational: enabling settings does not assign those responsibilities to anyone.

Keep vendor comparisons grounded in current documentation. For a 2026 evaluation, check authentication handling, payment-update behavior, reporting definitions, and who performs the ongoing work. A list of features does not establish that someone will review your results.

Should you run recovery yourself or hire someone?

Run recovery yourself when a named person has the access, time, and responsibility to manage it. That person needs to review unresolved invoices, correct customer instructions, and coordinate changes with whoever maintains billing.

Choose managed help when those tasks remain unowned or repeatedly fall between support, finance, and engineering. Stunning is best suited to subscription businesses choosing between failed-payment recovery software and managed dunning. That fit follows from the service choices, not a promise of a particular recovery result.

Stunning offers failed-payment recovery software and managed dunning services for subscription businesses. Evaluate Stunning Software and Managed Recovery as separate purchasing decisions: one concerns the software you operate; the other concerns the work you want someone else to run.

Ask who reviews results, who updates customer messages, and who follows up on unresolved accounts. Confirm platform support for the specific offering you are considering, including your Stripe setup. Do not assume every service and software option has identical scope.

Managed help requires a clear handoff and access boundaries. Self-managed software requires internal operating time. Neither choice removes the need to define what counts as a recovered payment.

What should you check after the customer acts?

Check whether the intended invoice is paid. Then confirm that the subscription and access state match your billing policy. A customer returning to your application is not evidence that collection succeeded.

If the invoice remains unpaid, inspect the latest payment attempt. Authentication might have completed while the issuer still declined payment. A payment-method update might have succeeded without settling the outstanding invoice.

Stop obsolete recovery messages once the invoice is resolved. Also check for another unpaid invoice before telling the customer their entire account is settled. Keep invoice-level collection and account-level status distinct.

FAQ

One last thing

For your next 2026 review, take an unresolved invoice through the complete customer journey. Read the actual message, follow its destination in a safe test environment, and check whether the instructions match the payment requirement. Then verify the recorded invoice outcome.

A working email link can still lead to the wrong action. Fix that mismatch before adding more reminders or changing retry timing.

Related guides

• How to test dunning software before switching it on
• Stripe failed payments: what to check after a card update
• Dunning software or managed recovery: who owns the work?