By NUMUS editorial team
When a renewal payment fails, the next question is not simply “How many times should we try again?” Your team needs to know whether another attempt is appropriate, which system controls it, what the customer should do, and how the result reaches the people managing the account.
A useful retry plan connects those decisions. It also gives staff a way to distinguish an unsuccessful payment from an unclear result, a scheduled retry from an executed attempt, and a changed card from a paid invoice.
Use the questions and worksheet below with the provider and tools you actually use. They are an operating review, not a universal retry schedule. If you have not yet mapped the wider setup, start with subscription account, gateway and billing responsibilities.
Find the record behind the failure message
Start with one affected renewal and record its invoice or billing reference, payment reference, amount, attempt time and current provider status. Keep the time zone with the timestamp. A customer account name alone is not enough to distinguish this month's renewal from an earlier unpaid invoice.
Ask your provider or integration owner:
- Does this label describe a declined payment, a processing error, a missing payment method, or an outcome we have not confirmed?
- Which underlying response or record determines what happens next?
- Is another attempt eligible under the current provider instructions, or is customer action required first?
- Where can support see an executed attempt and its result?
- If the customer paid through another route, how does that payment close the original collection task?
Provider details matter. Stripe's retry documentation identifies circumstances where it does not retry, including missing payment methods and specified hard-decline responses. It also distinguishes scheduled retries from attempts that actually execute. Those are Stripe-specific behaviors, not instructions to apply its settings to another provider. Stripe payment retry documentation
Build a provider-confirmed failure matrix
Complete this worksheet with the person who owns your billing configuration. The suggested next checks are questions to resolve; they are not a list of decline-code instructions.
| Situation to investigate | Evidence to find | Retry decision to confirm | Customer handoff | Accountable owner |
|---|---|---|---|---|
| A decline with an available response code | Exact response and current invoice status | Is another attempt permitted and useful, or must something change first? | Explain the supported next step without guessing why the issuer declined | Billing owner |
| No usable saved payment method | The payment-method reference used by this renewal | What must be updated before collection can resume? | Direct the customer to the approved payment-update route | Support and integration owner |
| Customer action is required | Provider instructions associated with the payment | Does the customer need to complete a separate step? | Provide the supported action link or support route | Support owner |
| Result is missing or unclear | Provider transaction search and integration logs | How will staff confirm the original outcome before another collection action? | Acknowledge the investigation without claiming payment succeeded or failed | Integration owner |
| Retry process has ended | Final attempt result and configured end state | What happens to this invoice and the next billing cycle? | Explain the verified account state and available next steps | Billing and support owners |
| Customer says the balance is already paid | Payment reference matched to the correct invoice | How will duplicate collection be prevented? | Confirm after the records agree | Reconciliation owner |
Add the actual system name, configuration location and last review date beside each answer. “Automatic” is not a complete answer if staff cannot identify what triggers the action or where an exception is recorded.
If the failure happens at the end of a trial, check the first paid renewal journey as well.
Bring this completed matrix to a conversation about subscription payment processing.
Decide who controls another attempt
Ask whether the billing application, gateway, another recovery tool, or a staff member can initiate collection. Then identify which one is responsible for the next action on an unpaid renewal.
Do not assume a manual action replaces an automatic one. Braintree documents that an unsuccessful manual subscription retry does not count as an automatic retry; the automatic schedule still runs. Its recurring-billing settings also determine what happens after the configured retries fail. Confirm the behavior of your own setup before giving staff a manual retry procedure. Braintree recurring-billing advanced settings
Write down who may initiate a manual collection, what they must check first, and where they record its result. The point is to prevent two people or systems from treating the same unpaid renewal as separate work.
For integrations that exchange payment events, ask how repeated or delayed notifications are handled. Stripe documents that webhook events can arrive more than once and are not guaranteed to arrive in creation order. That makes a received notification a record to reconcile, not a reason for staff to improvise an additional charge. Stripe webhook delivery guidance
Give customers a clear next step
A recovery message should identify your business, the relevant renewal and the action the customer can take. Route payment-method changes through the supported secure flow. Keep the message accurate about the result: “We could not complete this renewal” communicates something different from “Your subscription is canceled.”
Check these communication details in your actual configuration:
- Which event sends the message, and who owns the wording?
- Does it link to the correct account and supported update route?
- Where can staff see whether a message was sent or delivery failed?
- What happens if the account is canceled while a message is waiting to send?
- Which message tells the customer that a later payment succeeded?
Do not presume that every state change sends an email. Braintree's recurring notifications depend on the event and subscription state; its documentation describes cases where a cancellation does not generate an automatic cancellation notification. Braintree recurring-billing email notifications
Separately record the business's access or fulfillment decision. A payment-retry configuration does not explain the terms you communicated to the customer or prove that your membership or shipping system received an update.
When the outcome includes cancellation or a refund, use the reconciliation worksheet to confirm the separate billing and payment states.
Rehearse one failed renewal before relying on the process
Consider a fictional business, Cedar Learning Club, with a $49 renewal. These invented details illustrate a review exercise, not a price recommendation or a NUMUS merchant result.
In a supported test environment, its team walks through a failure, a customer payment-method update and the eventual payment result. They keep one worksheet with these fields:
| Checkpoint | What the team records |
|---|---|
| Original renewal | One billing reference and the $49 obligation |
| First attempt | Payment reference, actual result and timestamp |
| Planned next action | Controlling system, eligibility and any customer action required |
| Customer update | Which saved-method record changed and whether this renewal uses it |
| Collection outcome | The provider-confirmed result linked to the original renewal |
| Operational closeout | Customer message, access decision and staff owner of any remaining exception |
A changed payment method is not the closeout condition. The team must find the payment result and reconcile it to that renewal. If the outcome remains unclear, keep it in the exception queue with a named owner rather than marking it recovered.
Use the review to leave with a documented process your staff can explain. Bring the actual retry settings, sample messages and unresolved handoffs when discussing your recurring setup with NUMUS.