A failed renewal needs a billing decision before a retention campaign

AI-generated conceptual illustration: an interrupted renewal may need a carefully chosen retry, while a final stop needs a different response.

A member's renewal fails. Before sending a discount or a "we miss you" email, check whether they've actually left. They may still want the subscription and believe they've paid for it.

Some failures need the customer's help; others may succeed on retry. Stripe's subscription webhook documentation explains the distinction. There's also an easy detail to miss: a customer can update their payment method while the subscription still points to the old one. Neither case should be treated as an intentional cancellation.

Check the invoice, subscription, access entitlement and support conversation together before choosing a response. The examples here use Stripe. Adapt them to your provider, payment methods and account settings rather than copying a retry schedule.

Find out what failed

Start with the invoice and the provider's current record. Note the failure category, last attempted payment, whether another attempt is eligible and which payment method the subscription will use. Authorized staff need the raw provider details, but those details don't all belong in a customer email.

Stripe provides events including invoice.payment_failed and invoice.payment_action_required. An event tells your integration that something happened. It doesn't replace checking the current record or the customer's access terms before deciding how to help.

Use this table to assign the next action, replacing the access rules and owners with your own agreed policy.

Situation: Eligible temporary failure

Billing response: Use the configured provider retry policy

Customer contact: Explain the unpaid renewal and any known next step

Access and owner: Apply the agreed grace rule; billing owns review

Situation: Missing or unusable payment method

Billing response: Request an update through the approved payment flow

Customer contact: Give one secure route to update details

Access and owner: State the applicable access deadline; support handles questions

Situation: Authentication required

Billing response: Follow the provider's authentication flow

Customer contact: Ask the member to complete the required action

Access and owner: Track completion; technical owner handles broken flows

Situation: Invoice cannot finalize

Billing response: Investigate the finalization error

Customer contact: Ask for information only when the diagnosis requires it

Access and owner: Billing or technical owner resolves the invoice problem

Situation: Recovery exhausted

Billing response: Apply the configured final state

Customer contact: Explain the result and permitted route to resume

Access and owner: Enforce the agreed access policy; reconcile exceptions

Situation: Intentional cancellation

Billing response: Respect the cancellation and remaining obligations

Customer contact: Confirm the paid-through position

Access and owner: Do not restart renewal through a recovery campaign

An invoice that fails finalization cannot be collected, even though the subscription can remain active. Asking that member to replace their card may waste their time while leaving an internal configuration problem untouched.

View full-size image

Check which payment method the subscription will use

Stripe's payment retry documentation lists payment methods in priority order: subscription default payment method, subscription default source, customer default payment method and legacy customer default source.

The subscription-level override is worth checking when a member says, "I've already updated my card." Updating customer.invoice_settings.default_payment_method does not replace a failed subscription.default_payment_method. Stripe warns that retries can continue using the subscription's method.

Don't immediately send the same update link again. Ask the authorized billing owner to confirm where the new method was saved and which record the next collection will use.

Never ask the member to email card details. Send them through the approved hosted or authenticated payment-update flow, then verify the payment method reference and invoice state internally. Record the outcome in the support note, not the credentials.

A scheduled retry may never have run

For some hard declines, Stripe cannot retry payment without a new payment method. Its retry documentation notes that scheduled retries and attempt_count can continue, but unexecuted retries do not create a new Charge. Translating that counter into "your bank declined us again" can give the member a false account of what happened.

Check the execution evidence before describing another attempt. Check where your integration gets the next attempt time, too: Stripe says automation users receive next_payment_attempt in invoice.updated, rather than in invoice.payment_failed.

Waiting won't solve every failure, and an overdue invoice isn't a reason to build your own rapid retry loop. Use the provider's supported configuration for the payment method. Stripe treats local payment-method retries separately and says those automatic retries are not enabled by default.

When reporting recovery results, count eligible invoices and their actual outcomes under the policy you used. Separate card and bank-debit results if their retry rules differ. A single recovery percentage can hide the distinction you need to decide what to change.

Write down what happens to access

Decide whether access continues after a failed renewal, what ends the grace period and who can approve an exception. Include how a successful late payment restores the correct benefits. These rules need to follow the customer agreement and applicable requirements; there isn't a grace period that fits every membership offer.

Don't use the billing system's display label as a substitute for that policy. Stripe's subscription overview explains that active does not mean every outstanding invoice is paid, and past_due does not guarantee another payment attempt. A support agent looking at one badge could easily draw the wrong conclusion.

When recovery is unsuccessful, Stripe supports configured outcomes such as cancellation, unpaid status or remaining past due. Review your actual setting alongside the application's response, then check access in the content application. The billing record can be correct while sign-in or an entitlement update is broken.

View full-size image

Test both directions. A failed payment should trigger the agreed access rule. A later successful payment should restore or extend the right benefit without reviving an unrelated canceled plan or granting every product in the catalog.

Leave support a record they can act on

Keep a restricted case record with the invoice and subscription references, diagnosis, next action, access position and owner. Add the last customer message and whether it needs a reply. Be specific about ownership: platform support, your customer-service staff and the payment provider have different responsibilities. Make those boundaries clear when scoping a Stackmodo setup, too.

The customer message can be plain. Identify the unpaid renewal, explain what the member needs to do, link to the approved account flow and state their actual access position. Include a retry date or deadline only when the system has confirmed it. Don't imply deliberate non-payment or threaten access changes that the terms don't support.

Before another reminder goes out, check whether the invoice has been paid or the member is already talking to support. If the systems don't pause obsolete reminders automatically, someone needs to own that job.

Close the case when the invoice is resolved, the intended subscription and access states are correct, and obsolete recovery messages have stopped. If payment succeeded but the member is still locked out, the access owner still has work to do.

One useful test is a payment that succeeds after the first reminder is prepared but before it's sent. Confirm that the member has the right access and that the outdated reminder never goes out. Repeat the test when billing, access or messaging rules change. It checks whether those systems agree at the moment a member needs them to.