Ask a Shopify merchant using Recharge where a failed renewal goes to die, and most will point at a dashboard they half understand. The honest answer is more interesting: it dies in the handover. Recharge runs the subscription, a payment processor attempts the charge, and each system assumes the other is watching what happens next. Retries follow a schedule, notices follow another, and the customer — whose card was replaced last month by their bank, without ceremony — hears about none of it until the subscription is already gone.
The walk-through in recharge dunning traces the specific seams. Recharge's native retry logic is a reasonable default, but a default is all it is: the same cadence applied to a customer whose funds arrive on Fridays and a customer whose card was stolen and reissued. Those are different problems wearing the same decline label, and a schedule that cannot tell them apart will mistreat both — retrying the stolen card hopefully while the payday customer's money sits waiting for a correctly timed attempt.
The card-update path is the second seam. When a customer does respond to a notice and saves a new card, what happens next is a configuration detail with revenue attached: does the failed charge retry promptly on the new details, or does it wait for the next scheduled pass days later? Merchants rarely test this, because testing it requires failing on purpose. It is worth failing on purpose — in a test account, with your own card — because the difference between an immediate retry and a three-day wait is measured in customers who meant to stay and drifted.
The third seam is delegation. Recharge allows recovery work to be handed to a third-party tool, but the handover has to be set deliberately: native retries and external retries running at once can double-attempt a customer, while a handover half-configured can leave attempts owned by nobody. Merchants should be able to answer, in one sentence, who retries a failed Recharge charge on day one, day three, and day seven — and many cannot, which is itself the finding.
There is also the quiet question of what counts as recovered. A customer who updates a card after a notice, a retry that succeeds on its fourth attempt, a subscription reactivated by support — each lands in a different report, or in none. Merchants who cannot reconcile those numbers end up judging their recovery by feel, usually pessimistically in a bad month and optimistically in a good one, with no way to tell whether a change helped.
A fourth seam hides in the notices themselves. The email a customer receives about a failed renewal is sent by one system, branded by another setting, and linked to a card-update page whose address the merchant may never have opened on a phone. Open it on a phone. If the page is slow, confusing, or asks for information the customer does not have at hand, the most elegant retry schedule behind it is irrelevant — the recovery was decided at that screen, by friction, in the customer's favour of doing nothing. Merchants routinely discover at this step that the page still carries an old logo, a predecessor's business name, or wording that promises a discount nobody configured.
None of this is an indictment of the platform; it is the normal condition of systems composed from parts. The merchant's job is to walk the seams once — the retry schedule, the card-update trigger, the delegation setting, the reporting — and write down what they find. Renewals will still fail; cards see to that. But they will stop failing in the dark, which is where involuntary churn does nearly all of its damage.
Published by Swipe Again, the flat-fee failed payment recovery service for subscription businesses.
Top comments (0)