The card failed. The customer did not cancel.
July 12, 2026
A customer’s SAR 499 renewal is due on Monday. The charge fails because the card expired last week.
The customer did not cancel. They did not reject your price. They may not even know the card failed.
What happens next decides whether a minor payment problem becomes lost revenue.
Treat it as a recovery, not a cancellation
A failed payment is a state between active and cancelled. The invoice is unpaid, but the customer still intends to continue.
Payment recovery—often called dunning—is the sequence that resolves that state:
- record why the payment failed;
- tell the customer what happened;
- give them a direct way to fix it;
- retry when another attempt has a real chance of working;
- close the case as paid or move to the stated end-of-service policy.
The goal is not to send more reminders. It is to remove the reason payment is stuck.
From failed card to SAR 499 recovered
Renewal invoice · SAR 499In this case, the customer opens the first message, updates the expired card, and the scheduled retry succeeds on day three. The SAR 499 is recovered and the subscription continues.
The failure reason should change the next step
Not every failed payment needs the same response.
| Failure | Useful next step | Bad next step |
|---|---|---|
| Expired card | Ask for a new card | Retry the same card every hour |
| Insufficient funds | Retry after a few days | Declare the subscription cancelled immediately |
| Bank declined | Ask the customer to contact the bank or use another method | Keep retrying without explaining why |
| Technical gateway error | Retry automatically soon | Tell the customer their card is invalid |
A retry is useful only if something may have changed. Retrying an expired card ten times is not persistence; it is ten copies of the same failure.
One message should lead to one fix
The first message does not need to sound like debt collection. It needs to answer three questions:
- What happened? We could not collect SAR 499 for your renewal.
- What changes now? Your subscription is still active during the recovery period.
- What should I do? Update the payment method and pay the invoice.
Then give the customer one payment link. Do not make them sign in, find Billing, open the invoice, and guess which button resolves it.
Avoid vague messages such as “There is a problem with your account.” The customer cannot act on them. Avoid blame as well: payment networks fail for reasons outside the customer’s control.
Space retries around a reason
A retry one minute after failure usually meets the same card, limit, and bank decision. A retry a few days later may land after payday, after a temporary bank restriction clears, or after the customer updates the card.
A practical sequence might be:
- Day 0: record the failure and send the payment link;
- Day 3: retry and send a short reminder if it still fails;
- Day 7: retry again and explain the approaching deadline;
- Final day: send the outcome and apply the access policy.
The exact days can change. What matters is that every attempt has a purpose and the customer always knows what happens next.
Recovery needs a clear end
Some payments will not recover. The card remains invalid, messages go unanswered, or the customer has chosen to leave without cancelling first.
Your process still needs a clean result: a final notice, an unpaid invoice with the correct status, and a known date when access changes. That access decision belongs to the grace-period policy, not to an improvised support decision.
In Tirdad, every payment attempt and invoice status stays attached to the same invoice. A failed-payment event can trigger your customer message, the public invoice link gives them a direct way to pay, and the subscription moves forward according to the recovery and grace rules you set.
A failed card is not a cancellation. Treat it as a payment that needs a clear path back to success.
Eight connected decisions—from the first usage event to recurring revenue.
Set the rule once. Tirdad applies it every time.
Keep the policy, effective date, customer agreement, and invoice calculation in one billing system instead of rebuilding the decision in every product surface.