Key points of this lesson, in order.
Recurring Payment Failure Handling
What you will learn
Your objective. By the end of this lesson, you will be able to explain recurring payment failure handling. The most common cause of recurring payment failure is an expired card.
Why it matters. Dunning is the process of communicating with a customer whose payment has failed, and it is a mix of messaging, timing, and tone.
Chapter objective: Learner designs recurring payments, including mandates, merchant-initiated transactions, and 3RI flows, and explains authentication, consent, and failure handling for repeat charges. Learner applies this skill in realistic banking scenarios, with clear examples and correct terminology throughout.
Key learning points
- Common cause of recurring payment failure
- Dunning: process of communicating
- Retry schedule
- Account updater services
- Full failure handling
- Card expiry failure
Key terms
Issuer: A bank or licensed institution that issues payment cards to customers and holds their accounts. It authorises transactions, debits cardholder accounts, and manages credit limits and fraud controls.
Retry: Repeating a failed request or message delivery after a delay, usually with a limit on attempts and a back off period.
Break: A difference found during reconciliation between two records that should agree, such as a bank statement and a ledger.
Payment flow diagram showing Recurring Payment Failure Handling.
Practise this lesson
Exercise
Trace the card payment in this lesson through authorisation, clearing and settlement.
Use the four-party model and the stage timings in this lesson.
- What to do. State what happens at each stage, who pays whom, and when the merchant is actually credited.
Correct result. Authorisation holds the funds and returns a response code. Clearing sends the transaction in a batch file. Settlement moves the net amount between banks, and the acquirer credits the merchant after deducting interchange, scheme fees and its margin.
Why. A card payment is not one event. The customer sees it on Monday, the merchant gets it on Wednesday, and the difference is the clearing and settlement cycle.
Check your understanding
Practice question
Which of the following best describes recurring payment failure handling?
Takeaway and next step
What to remember
The subscription continues without a break, and the customer receives a confirmation that the payment went through.
Follow 1,000 rupees through every stage, from instruction to beneficiary credit, and note where it can stop.
Open the Payment Lifecycle Simulator →
Builds on "Writing a Use-Case Document for System-Triggered Payments".
Transcript and full text
Show transcript
The most common cause of recurring payment failure is an expired card. Cards typically expire every three to five years, so a long running subscription will eventually hit an expiry date. The second most common cause is insufficient funds, which happens when the billing date falls just before the customer's salary arrives. The third is a generic decline, where the issuer refuses the transaction without giving a specific reason, often because of fraud rules. The fourth is a lost or stolen card, which means the stored credential is no longer valid at all. Each cause needs a different response, and a system that treats them all the same way will recover far less revenue. Dunning is the process of communicating with a customer whose payment has failed, and it is a mix of messaging, timing, and tone. A good dunning sequence starts with a friendly message on the day of the failure, explaining what happened and asking the customer to check the card or update the details. A second message follows after two or three days, and a third after a week, each one slightly more direct. The best subscription companies test the wording, the timing, and the channel, because a message that feels like a threat will push the customer to cancel, while a helpful message will save the subscription. The BA documents the full dunning schedule, including the message templates and the rules for stopping messages when the payment succeeds. A retry schedule defines when the system attempts the payment again after a failure, and it is one of the highest value requirements a BA can write. The simplest schedule retries after 24 hours, then after three days, then after seven days. Smarter schedules vary by failure type, so an insufficient funds decline is retried just after the typical salary date, while a generic decline is retried after a longer gap. Some merchants use machine learning to pick the best retry time for each customer based on past payment behaviour. The BA must specify the maximum number of retries, the gap between them, and the final action when all retries fail, which is usually suspension of the subscription. Account updater services are provided by Visa and Mastercard, and they automatically update stored card details when a card is replaced or renewed. When a bank issues a new card with a new expiry date or a new card number, the account updater service tells the merchant's payment provider about the change, so the next recurring payment uses the new details. This single service can recover a large share of the revenue that would otherwise be lost to expired and replaced cards. The BA should specify that the merchant enables account updater, how often the stored credentials are refreshed, and what happens when the updater reports that the card is closed rather than replaced. The full failure handling design brings all of these pieces together into one lifecycle. When a payment fails, the system classifies the decline code, decides whether the failure is recoverable, and picks the retry schedule. At the same time, the dunning process starts, and the account updater is checked for new card details. If the payment succeeds on a retry, the subscription continues and the customer gets a confirmation. If all retries fail, the subscription is suspended, the customer is told how to reactivate it, and finance is given a report on the lost revenue. The BA documents this as a state machine, because the subscription moves between active, past due, suspended, and cancelled, and every transition needs a clear rule. For example, a customer pays 1,000 rupees a month for a gym membership, and the card expires in the middle of the year. The next charge fails, so the merchant sends a friendly message on the same day, asking the customer to update the card. The account updater service then supplies the new expiry date, and the retry on the third day succeeds for 1,000 rupees. The subscription continues without a break, and the customer receives a confirmation that the payment went through.
The most common cause of recurring payment failure is an expired card. Cards typically expire every three to five years, so a long running subscription will eventually hit an expiry date. The second most common cause is insufficient funds, which happens when the billing date falls just before the customer's salary arrives. The third is a generic decline, where the issuer refuses the transaction without giving a specific reason, often because of fraud rules. The fourth is a lost or stolen card, which means the stored credential is no longer valid at all. Each cause needs a different response, and a system that treats them all the same way will recover far less revenue.
Dunning is the process of communicating with a customer whose payment has failed, and it is a mix of messaging, timing, and tone. A good dunning sequence starts with a friendly message on the day of the failure, explaining what happened and asking the customer to check the card or update the details. A second message follows after two or three days, and a third after a week, each one slightly more direct. The best subscription companies test the wording, the timing, and the channel, because a message that feels like a threat will push the customer to cancel, while a helpful message will save the subscription. The BA documents the full dunning schedule, including the message templates and the rules for stopping messages when the payment succeeds.
A retry schedule defines when the system attempts the payment again after a failure, and it is one of the highest value requirements a BA can write. The simplest schedule retries after 24 hours, then after three days, then after seven days. Smarter schedules vary by failure type, so an insufficient funds decline is retried just after the typical salary date, while a generic decline is retried after a longer gap. Some merchants use machine learning to pick the best retry time for each customer based on past payment behaviour. The BA must specify the maximum number of retries, the gap between them, and the final action when all retries fail, which is usually suspension of the subscription.
Account updater services are provided by Visa and Mastercard, and they automatically update stored card details when a card is replaced or renewed. When a bank issues a new card with a new expiry date or a new card number, the account updater service tells the merchant's payment provider about the change, so the next recurring payment uses the new details. This single service can recover a large share of the revenue that would otherwise be lost to expired and replaced cards. The BA should specify that the merchant enables account updater, how often the stored credentials are refreshed, and what happens when the updater reports that the card is closed rather than replaced.
The full failure handling design brings all of these pieces together into one lifecycle. When a payment fails, the system classifies the decline code, decides whether the failure is recoverable, and picks the retry schedule. At the same time, the dunning process starts, and the account updater is checked for new card details. If the payment succeeds on a retry, the subscription continues and the customer gets a confirmation. If all retries fail, the subscription is suspended, the customer is told how to reactivate it, and finance is given a report on the lost revenue. The BA documents this as a state machine, because the subscription moves between active, past due, suspended, and cancelled, and every transition needs a clear rule.
For example, a customer pays 1,000 rupees a month for a gym membership, and the card expires in the middle of the year. The next charge fails, so the merchant sends a friendly message on the same day, asking the customer to update the card. The account updater service then supplies the new expiry date, and the retry on the third day succeeds for 1,000 rupees. The subscription continues without a break, and the customer receives a confirmation that the payment went through.
Full lesson text (all scenes)
Completing a lesson updates your progress dashboard on the homepage.
Scene timestamps are estimated by allocating the narration text proportionally across the real audio length. The audio playback position is the source of truth: pause freezes the visual, seeking restores the correct scene, replay restarts the scene animation.