Braintree merchants tend to discover their dunning gaps in a specific order. First they learn the vault is doing quiet, competent work: stored credentials, account updater coverage on participating issuers, a payment method that may already carry the replacement card. Then they learn the retry logic does not always know what the vault knows. A renewal attempt fires against stale details while fresher credentials sit one system over, the failure is recorded as a customer problem, and the dunning email asks the subscriber to update a card that, in a meaningful sense, was already updated.
That space between vault and retry is the first item on any honest gap inventory. The second is visibility. Braintree reports transactions faithfully, but a faithful transaction log is not a recovery queue: nobody gets a daily list that says these twelve renewals failed, these four codes are soft, these two cards were replaced last week, and this account healed the last time on the third attempt. Without that list, recovery depends on someone remembering to go looking, and subscription businesses are rarely short of other things to remember.
The third gap is sequencing around the native tools rather than through them. Braintree's own retry facilities handle a baseline cadence; what they cannot do is coordinate that cadence with subscriber contact, pause attempts while an update link is in flight, or change the plan when a decline code says the problem is timing rather than credentials. Merchants end up with two systems politely ignoring each other — retries firing during the exact days an email sequence is asking the customer to act, doubling the noise around a single failure.
The fourth gap is endings. When a Braintree renewal ultimately fails, the subscription state, the customer's access, and the winback clock are three separate decisions that often collapse into one accidental default. An account cancelled by drift is hard to win back; an account closed deliberately, counted honestly, and re-approached at the right interval is a future subscriber with a known history.
For the full working version, guide to running dunning on Braintree, from vault behaviour to final attempt walks each of these gaps with the merchant-side fixes in order. Its central claim is unfashionable but durable: Braintree is not the problem. The problem is the unowned space around it, and unowned space is fixable without migrating anything.
A practical inventory exercise takes an afternoon. Export a month of declined renewals. For each, note the code, whether the vault held newer credentials than the attempt used, how many attempts followed, whether the subscriber was contacted and when, and how the case ended. Four columns in, the pattern names itself — most teams find one gap accounts for the majority of preventable losses, and it is rarely the one they expected to fix first.
Fix that gap first, measure a full cycle, then take the next one. Recovery programs built as inventories improve steadily; recovery programs bought as overhauls tend to be re-bought within the year. The inventory also protects the migration question from being asked prematurely: once the gaps are named and measured, it usually turns out the processor was never the bottleneck, and the money earmarked for a painful platform switch can stay where it belongs — in the business the renewals were supposed to fund in the first place.
Swipe Again supplies the missing layer around Braintree and the other major billing platforms: a real recovery queue, code-aware sequencing coordinated with subscriber contact, and endings that are decided rather than drifted into — all at one flat monthly price, with no migration of the payments stack underneath.
Top comments (0)