How to Manage Your Retries in Subscription Business
Subscription products tend to work around the same metrics — churn, retention, LTV — and the focus is usually directed toward the product itself: improve onboarding, add features, review pricing. That's justified, because your product genuinely is the primary factor in the purchase decision. But amid all these product improvements, technical question often gets unasked: what happens when the system simply fails to charge money from a customer who is already loyal and willing to pay?
That customer subscribed to your service by their own choice and made no active attempt to cancel, yet their scheduled payment failed, and they didn't rush to fix it. In that case, access to the service will likely be restricted, the company will lose an active subscriber it had been fighting competitors over, and no price cuts or product tweaks will help.
Today we'll break down why some payments fail and how you can influence them before and after failed attempts.
Why Not Every Decline Calls for a Retry
First, let's look at what a failed payment actually is. When a transaction doesn't go through, management usually see a single status — decline and treats it as one uniform event with a final outcome. But in subscription business, failed payment is a fundamentally different thing than in products built around one-time purchases. That's why it's worth examining the reasons behind failed charges in more detail, reading the signal card issuer is sending about card's state at that specific moment, and building your strategy around that.
Soft and hard declines are two fundamentally different categories of payment failure — one saying “not right now,” the other essentially “never” — and the difference between them comes down to exactly that dimension of time, not some classification invented by payment systems for reporting. Soft declines include things like insufficient funds, exceeds withdrawal limit, and issuer unavailable situations; while hard declines include lost or stolen card, closed account, pick up card, and in some cases do not honor. “Insufficient funds” isn't an endgame — it's the state of the account at the moment of attempted charge, and that state can change within a week. A stolen card or a closed account, on the other hand, is a structural state that no retry will change, no matter how many times you attempt it, because the problem is that the payment method no longer exists.
For one-time purchases, this distinction isn’t that heavy, since the customer decides whether to try payment again. They can top up their card if it was a soft decline, or use a different one if it was hard decline. In subscriptions, merchant has no direct access to the customer's account and can't top it up or change it without the account holder — but merchant can attempt the charge on its own, and that's exactly what recurring payments are for. A repeat charge in a subscription is always the merchant's decision, not customer's, because in the overwhelming majority of cases the person notices a failed payment late, if they notice it at all. They don't open their banking app every day to check whether money was charged for a service — they just live their life, until at some point access simply disappears on its own.
This is exactly where most companies lose money, stuck between two equally ineffective approaches. Some merchants understand that retries are necessary but build the retry logic on static ordinary rules. This leads to mass irrelevant retry attempts, because the system doesn't distinguish between soft and hard codes and just retries whatever comes its way. Beyond failing to produce the intended result, this also creates reputational and compliance risk: Visa and Mastercard monitor excessive charge attempts on invalid payment instruments and can penalize a merchant that systematically request charges on cards that will never be approved.
An even more common situation is the opposite: soft declines, most of which are retriable in the nearest term, get ignored entirely, and customers get written off as churn. The company then loses a paying customer simply because they didn't have enough money on their card on a particular day, and the system treated that as the end of the story instead of a temporary pause.
Against this backdrop, it becomes clear that only an adaptive system — one that can read and understand the underlying problem and respond to it accordingly — can produce the desired effect. That means flexible rules, tailored to specific products, markets, and decline types.
How to Build a Process Around Different Decline Codes
Once it's clear that soft and hard declines call for different approaches, the next step is categorization and building infrastructure around the “right” reaction to each event. Working with a soft decline starts from understanding that this state can change, and the entire retry strategy is built around a single question: when, with a highest degree of probability, will that change happen?
Different codes describe different mechanics, and the timing chosen should reflect that specific mechanic rather than some universal number of days borrowed from your competitor. It’s logical to retry “insufficient funds” with an eye on the specific customer's pay cycle: if a charge fails on the first day of the month, the odds of success the very next day are low, but a few days after a typical payday they're noticeably higher, as the cause of the decline is directly tied to the account balance. Issuer unavailable describes an entirely different mechanic: the bank is temporarily unreachable on its own end, and this has nothing to do with the customer's money, so a short interval makes sense here — an hour, a few hours — because as soon as banking infrastructure is back online, transaction is likely to go through on the first attempt. Exceeds withdrawal limit calls for a different approach: it may mean not just a temporary daily limit being hit, but also a reason to adjust the requested amount, where business logic allows for it.
A hard decline, by contrast, calls for a fundamentally different response, and that response isn't a retry — it's replacing payment method entirely. This is where Account Updater comes in: without any customer involvement, it pushes new card details through the Visa and Mastercard networks when a card has been reissued or its expiration date has passed but the account number stayed the same. This resolves a significant share of hard declines automatically, with no email to the customer and no lost transactions, because the new card data reaches the merchant before the customer even notices anything changed with their old card. That mechanism doesn't cover everything, though: if a card is blocked for fraud, an account is closed, or a customer has physically switched banks, automation can't help, and the only tool that works there is a direct message to the customer letting them know there's a problem with their card and the payment details need to be updated manually. The default approach should always be built around a seamless customer experience: if the merchant can resolve the issue on its own, that's the best path; if not, communication has to be brought into play.
The gap between what the industry offers by default and what payment systems and merchants that genuinely extract recovery from soft declines actually do comes down to how dynamic the logic is. The default setup for most systems is a fixed number of retries at fixed intervals — something like three attempts a day apart, with no connection to the decline code type or the individual card's history. That can work, but it's essentially relying on luck.
More advanced systems build a model that accounts for time of day and day of week, the history of previous attempts on that same card, and sometimes approval patterns specific to a given issuing bank, since different issuers respond differently to repeat requests. One capability that's rarely used but can meaningfully move the outcome is retrying through an alternative acquiring bank instead of the same routing chain. As practice shows, the same decline sometimes turns into a success simply because another acquirer's risk policy differs, and the decline turns out to be the result of that specific issuer-acquirer pairing rather than a property of the transaction itself.
What This Means for Your Subscription Business
Despite the complexity, this part of the billing process genuinely justifies the investment. If you calculate the share of declined recurring charges that are retriable in nature and compare it to how many of them actually get a retry, the gap usually turns out to be substantial. And the reason is often absence of a properly built process and in-house expertise.
According to industry figures, recovery on such declines can run thirty to forty percent, and that's the result achieved by companies that actually work on timing rather than leaving it on the payment system's default settings and hoping someone else will handle it for them.
When retries either don't happen at all or happen in a tiny fraction of cases, all of that potential revenue simply leaves the merchant's account. That loss hits customer LTV directly, and even their loyalty, because a customer whose subscription simply failed to charge overwhelmingly doesn't come back to pay on their own — but they do notice the absence of any notification from the service.
If the fact that retries need to happen is already common knowledge, how to do them well remains a matter of narrow expertise — and that's exactly where Monoup can help. We build hypotheses, run tests, and select the best approaches for your customer base, product, and target markets. Differentiating between soft and hard declines sits at the center of our approach to retention, one that most companies either don't use at all or run at half strength.
