The renewal, minute by minute
Consider a composite renewal — the kind support teams reconstruct from logs after a good customer quietly disappears.
Day 0, 02:14. A $49 monthly subscription comes due. The payment method attached to it is a Visa ending in 4417. The issuer declines it: that card was replaced, and the old number is no longer valid. It is a clean, explainable failure.
Day 0, later. In Braintree's vault, the story is already different. Account updater has done its quiet work. The vaulted payment method now points to a replacement card, with a new number and a later expiry. No customer email was needed. Nobody had to click anything.
Day 1, 02:14. The retry fires exactly twenty-four hours later, because that is what the schedule says. It presents the stale picture of the credential that the subscription job captured when it started, not the payment method the vault holds now. Decline again.
Day 3. Another retry, same assumption, same result. This time a dunning email goes out asking the customer to update a card they never replaced in your system — the bank replaced it for them. Confused, they ignore it. Who wouldn't?
Day 7. The subscription cancels for non-payment. In the post-mortem someone says, “We had the new card the whole time.” They are right, and that is the uncomfortable part.
What the vault knew, and when
Account updater is not a message your retry logic automatically hears. It is a change of state. An issuer reports a replacement, the network passes it along, and the vaulted payment method is refreshed. If your renewal flow reads a snapshot taken when the invoice was created, caches a token and its metadata at subscription start, or checks the payment method once and then loops on a timer, that refresh might as well not have happened. The vault and the retry are looking at the same customer and seeing two different cards. Neither system is broken. They are simply not talking at the moment it matters — the second before an attempt is submitted.
That gap is why we describe failed payment recovery built around Braintree subscriptions as a sequencing problem, not a reminder problem. Sending more email about a card the vault has already fixed does not repair the sequence.
What the retry schedule did instead
A default retry clock is indifferent. It retries at fixed intervals regardless of why the attempt failed, what changed since, or whether waiting would help. For an insufficient-funds decline, timing matters in one way: you are waiting for money to arrive. For a replaced card, timing matters in a completely different way: you are waiting for information to arrive. Treating both as “try again tomorrow, then in three days” wastes attempts on the first problem and never pauses to check for a solution to the second. Worse, repeated declines against a dead credential teach nobody anything, while each one nudges the customer closer to cancellation.
A practical checklist
- Re-read the payment method before every retry. Fetch the current vaulted method at attempt time, not at invoice time. Log a fingerprint of what you presented, so a post-mortem can prove which card was actually used.
- Separate updater events from retry events. Keep two timelines in your logs: when the credential changed, and when you tried. If you cannot overlay them, you cannot diagnose this failure class at all.
- Time retries to issuer behavior, not to your defaults. Space attempts so an updater cycle has a chance to land, and so soft declines have a chance to clear. A retry five minutes after a decline rarely learns anything new.
- Hold the email while silent recovery is still plausible. A customer should not be asked to fix a problem your systems may already have fixed. Check the vault first, then decide whether a message is warranted.
- Escalate to a card-update request only after silent retries are exhausted. When you do ask, ask plainly, explain what happened, and link directly to a secure update page — not to a generic account screen.
The fix, in one sentence
Build the retry as a fresh decision — what do we hold now, why did the last attempt fail, and is another silent attempt likely to work? — rather than as a replay of the first attempt. Teams that make that change stop losing customers to a bookkeeping gap, and their dunning becomes shorter, rarer, and more honest.
Top comments (0)