Account Updater Is Not a Dunning Strategy: A Braintree Checklist

Braintree's Account Updater proves beneficial, but it leads to issues as well, as teams enable it, fail cards fix themselves unnoticed, and assume payment failures are handled. The updater resolves only one cause of failure - changing cards. However, it neglects other causes and remains silent on all of them. Here is a checklist to understand what truly occurs behind that green checkmark.

Firstly, categorize the causes separately. Organize a month's failed transactions, sorting them by decline type rather than date. The updater primarily addresses reissued and expired cards. Insufficient funds, do-not-honor, authentication-required, and closed-account declines fall outside its scope. If this division cannot be achieved, it indicates an average situation, masking every fixable aspect.

Secondly, evaluate the updater's effectiveness. Of the payments failing due to a card-related decline, determine how many succeeded later without customer intervention. This figure - not the feature's existence - represents the updater's contribution. Teams frequently experience surprise outcomes, either in the form of noticeable success or misleading vault configurations causing updated credentials to be applied to payment methods not used by their subscriptions.

Thirdly, examine the retry logic operating in tandem with the updater. When a card is updated during a retry cycle, does the subsequent attempt use the new credentials? If a payment fails due to insufficient funds, does your scheduling strategy back off intelligently, or continue to contact the same days repeatedly, as many subscription businesses do? Braintree provides the framework; the timing and judgment remain in your hands.

Fourthly, analyze emails as a customer would. Initiate a failure on a test account and review every email that arrives, in order, on a phone. Ensure the card-update link is easily accessible without requiring the customer to sign into a product they may already have been locked out of. Confirm that a customer who resolves the issue no longer hears about it. This step recovers more than any retry algorithm could.

Fifthly, define "recovered" unambiguously in writing and apply the same definition every month. A payment recovered by the updater, one recovered after a customer update, and another that never posed a risk since the initial failure was transient are three distinct events requiring separate analyses. Combining them yields a statistic that only increases in presentations but fails to reflect reality accurately.

Lastly, determine the outcome at the end. Every dunning sequence must conclude somewhere: a final retry, a final email, a decision about access, and the customer's record. Teams that have failed to document this often discover that different parts of their system make varying decisions - one subscription cancelled while emails persist, or access revoked even while a retry is still scheduled for a closed account.

Therefore, the Account Updater plays a significant role in the overall billing system but cannot stand alone. The remaining aspects - timing, messages, measurement, and a purposefully chosen ending - constitute the broader dunning strategy, meticulously managed alongside the gateway, which is where we primarily focus our efforts. This checklist offers guidance to subscription billing teams.