Key Takeaways
- • The split — Most payment recovery runs retries in the billing system and messages in a separate email tool, each on its own clock.
- • The cost — Split systems can't retry at a lower amount or offer an incentive for a card update, because neither side controls both the charge and the message.
- • The fix — Put retry logic and communication in one system so every retry and every message is planned together.
A failed subscription payment is two problems at once. There is a charge that needs to go through, and there is a customer who may need to do something about it. Almost every recovery setup on the market hands those two problems to two different systems, and that is the biggest reason recovery rates stall in the 20s and 30s.
How most payment recovery is built
Look at how a typical subscription brand handles a failed payment today:
- Retries live in billing. The subscription platform or a dunning tool decides when to charge the card again, using a schedule or a set of rules.
- Messages live somewhere else. A failed charge fires an event, and an email or SMS flow listens for it. Sometimes the platform sends its own transactional emails; often the brand builds a flow in its email tool.
- The two talk through a single signal. "Payment failed" goes from billing to messaging. Very little comes back the other way.
The split is built in on purpose. Billing teams own the charge, marketing teams own the inbox, and an event is the easiest way to connect two products. Some platforms go further and tell you to switch off any other dunning tool before you turn on theirs, so the two halves can never overlap. That avoids double emails. It also guarantees the two halves can never cooperate.
What decoupling costs you
When retries and messages run separately, each one is planned without knowing what the other will do next. In practice that shows up in four ways.
1. Messages don't know what the next retry will do
The email tool sends "please update your card" on day 3 because that is when the flow says to. It doesn't know a retry is scheduled for Friday morning, right after payday, that would probably have cleared on its own. You've asked a customer to do work they didn't need to do, and trained them to ignore the next email.
2. Retries don't know what the messages said
The opposite happens too. A customer replies to an email saying they'll update the card this weekend, or clicks through and abandons the update page. The retry engine keeps firing on its schedule anyway, piling up declines on a card that was never going to clear.
3. You can't change the charge
Some failed payments fail on amount, not on the card. An account with a thin balance won't clear a $68 charge but will clear a smaller one. A retry engine can try a lower amount, but if nobody tells the customer, a different number on the statement just looks like an error. Without a message to go with it, the tactic is off the table.
4. You can't pay for the card update
The fastest way to recover a dead card is to give the customer a reason to fix it today. But an offer like "update your card and take 15% off this order" only works if the system sending the email can also make sure the next charge actually comes through at the discounted amount, and stop retrying the old card while the offer is open. Split systems can't promise that, so they don't make the offer.
What changes when retries and messaging run in sync
Put the charge and the conversation in one system and every decision can use both. The sum is bigger than the parts, because the tactics that move recovery the most are the ones that need a retry and a message working together.
A smaller charge, framed as taking care of the customer
After repeated soft declines, retry at a reduced amount and tell the customer in the same moment: "Your payment didn't go through, so we sent this month's order anyway and took $10 off. Nothing you need to do." The customer gets their product and a gesture of goodwill instead of a warning. You keep a subscriber who was a few days from being cancelled, at a small discount rather than a total loss.
A card-update incentive the retries honor
For hard declines, where no retry will ever clear, skip the retries and lead with an offer: update your card in the next 48 hours and your next order is discounted. Because the same system owns the charge, the discount is applied to the next attempt the moment the new card is saved, and the offer can expire in step with the last retry window instead of on an unrelated email schedule.
Every message knows where the retry stands
Soft declines get quiet retries timed to when the card is most likely to clear, and messaging holds back until it's actually needed. The moment a retry succeeds or the card is updated, every pending email, SMS and on-site prompt stops. Nobody gets reminded about a payment that already went through.
Example: one failed payment, run in sync
| When | Retry | Message |
|---|---|---|
| Day 0 | Soft decline: insufficient funds | None yet |
| Day 2 | Retry timed to the next likely payday | None yet |
| Day 5 | Retry fails again | Friendly heads-up with a one-click card update link |
| Day 9 | Retry at a reduced amount | "We sent your order and took $10 off. Nothing to do." |
| Any day | Hard decline detected: retries stop | Card-update offer, discount applied to the next charge |
| On success | Charge clears | Every pending message and prompt is cancelled |
Illustrative timing. Real schedules depend on the decline reason and the subscriber.
Is your recovery coupled? Five questions to ask
- When a retry is scheduled for tomorrow, does today's email know about it?
- Can your system retry at a lower amount and tell the customer why in the same step?
- Can you offer an incentive for a card update and guarantee the next charge applies it?
- Do retries stop on a hard decline and hand straight off to a card-update message?
- When a payment recovers, does every pending email, SMS and on-site prompt stop immediately?
If the answer to most of these is no, your retries and messages are running separately, and the tactics above aren't available to you.
Retry logic decides when to ask the bank. Messaging decides when to ask the customer. Recovery goes up when one system decides both, because the best answer to either question depends on the other.
How MaxLTV handles it
MaxLTV runs retries, incentives, email, SMS and on-site prompts as one system on top of your existing subscription platform. Retries are placed by decline code, reduced-amount retries come with a message that explains them, card-update incentives are honored on the next charge, and every channel stops the moment the payment clears. See the payment recovery overview for how it works, and the case studies for what it does to the numbers: Bonafide went from about 24% to roughly 55% recovery, and Colorescience from 27% to 46%.