Account Updater: The 91x Payments Decision Nobody Looks At | HL Hunt

Account Updater: The 91x Payments Decision Nobody Looks At | HL Hunt
Payments & AI

Account Updater: The 91x Payments Decision Nobody Looks At

A business with 6,000 cards on file loses 204 of them every month to expiry, reissue and closure, which is 34% of the file a year, and not one of those customers decided to leave. An account updater at a 78% hit rate takes involuntary losses from 92 a month to 20, preserving about $505,000 of lifetime value a year for $461 a month. It also has one serious objection, and it is not the cost.

By the HL Hunt Research Desk · 16 min read · Updated September 2026

Stored cards decay faster than anyone plans for

A business with 6,000 cards on file does not have 6,000 working cards. Cards expire, get reissued after a breach, get replaced when lost, and get closed when the customer changes bank.

At a 3.4% monthly rate of becoming unusable, that is 204 cards a month and roughly 34% of the file in a year.

204 a month
Stored cards that stop working on a 6,000-card file, before any customer has decided to leave. Around a third of the file turns over annually, and none of that is churn in the usual sense.

The important feature is that none of these customers decided anything. Per our involuntary churn analysis, a payment that fails because the card was reissued is a billing event being read as a cancellation, and the customer frequently does not find out until the service stops.

The decay rate is also not uniform across a file. Cards issued on three-year cycles contribute a predictable expiry wave, while reissues after a breach arrive in clusters and can take a visible share of a file in a single month. Per our card on file analysis, a business that models decay as a smooth 3.4% will be wrong in exactly the month it matters.

What the updater is worth

An account updater is a network service: the merchant submits its stored card references, participating issuers return the replacement credentials, and the file is refreshed without contacting anyone.

StepWithout updaterWith updater
Cards invalid each month204204
Refreshed automatically0159 at a 78% hit rate
Left to a dunning sequence20445
Recovered by the customer re-entering a card, at 55%11225
Lost9220

At an ARPU of $42 and a remaining expected tenure of 14 months, each retained subscriber is worth $588. The 72 saved each month is therefore $42,103 of preserved lifetime value a month, or about $505,000 a year.

Against that, a platform fee of $400 a month plus $0.30 per update query on 204 queries is $461.

91x
Preserved lifetime value against the monthly cost of running an account updater on this file. Few payments decisions have a ratio in this range, which is why the usual reason it is not running is that nobody has looked rather than that someone decided against it.

The ratio is unusual enough to be worth stating carefully. It holds because the cost is per query while the benefit is a retained subscription, and per our proration analysis the same asymmetry appears across billing infrastructure generally: the operational cost of getting the mechanics right is small relative to the revenue the mechanics decide.

A third of a stored card file turns over every year

At 204 invalid cards a month, the difference between automatic refresh and a dunning sequence is 72 retained subscribers. HL Hunt AI Payment Processing runs account updater against the networks, handles the credentials it cannot refresh, and keeps the stored credential record the rules require.

See How HL Hunt AI Payment Processing Works

Why it is 78% and not 100%

A 78% hit rate looks like a product failure. Mostly it is not, and understanding why determines what to do about the remainder.

Reason for a missIs it fixable?
The issuer does not participateNo. Coverage depends on participating issuers, and smaller institutions are less often enrolled
The network is a different onePartly. Visa and Mastercard services do not cover other networks, which have their own arrangements
The account was closed with no successorNo, and this is the correct result. There is no card to update to
The customer changed bank entirelyNo. The new credential has no relationship to the old one
The stored reference is wrong or staleYes. Per our reconciliation analysis, a token that does not match anything is a data problem
The merchant is not enrolled for that card typeYes, and it is the first thing to check

The third row matters because it reframes the metric. A portion of the misses are accounts that genuinely no longer exist, and an updater reporting them as misses is giving the correct answer. The useful target is not a 100% hit rate but a correct disposition for every card: refreshed, confirmed closed, or escalated to the customer.

The remainder is what the dunning sequence is for, and it should be built on the assumption that it is handling real cases. Per our recurring billing analysis, a retry and notification sequence applied to 45 genuinely unreachable credentials performs very differently from the same sequence applied to 204 cards most of which could have been refreshed silently.

The case against account updaters

It makes cancelling by card replacement stop working

A substantial number of people end a subscription by cancelling or replacing the card, because the cancellation flow was hard to find, the support line did not answer, or they did not trust that clicking cancel would work. An account updater defeats that method precisely: the charge follows them onto the new credential, which from their position looks like a merchant that cannot be stopped. This objection is correct and it is not a minor one. Per our subscription analysis, the practice of making cancellation harder than signup is the subject of active regulatory attention in several jurisdictions, and a business running an updater while operating a difficult cancellation flow has built a combination that will be examined. The resolution is not to turn the updater off. It is that the updater is defensible only alongside a cancellation path that is at least as easy as the signup path, because then card replacement is not the only exit and the updater is doing what it is meant to do, which is preventing accidental loss of a subscription the customer wants.

There is a narrower version of the objection that also holds. A refreshed credential does not refresh the customer's consent, and per our descriptor analysis a customer who sees a charge on a card they only just received, from a name they do not recognize, has every reason to dispute it. The updater prevents an involuntary cancellation and can create a dispute in its place if nothing else changes.

What the rules require alongside it

Running an updater is not a license to charge a credential. The network frameworks for stored credentials carry obligations that sit around it.

  1. The original transaction must have been flagged as establishing a stored credential, and subsequent charges identified against it. Per our card on file analysis, getting this wrong affects both authorization rates and dispute outcomes.
  2. Consent has to be recorded and retrievable, including what the customer agreed to and when.
  3. Notice obligations survive the refresh. Advance notice requirements for recurring charges and for price changes are not satisfied by the fact that the card updated.
  4. A credential confirmed closed should be retired, not retried indefinitely. Per our contact operations analysis, repeated attempts against a dead endpoint generate cost and complaint with no recovery.
  5. The descriptor has to be recognizable, which matters more after a card change than before it.
  6. Updater results should be reconciled, because a refresh that silently fails leaves the merchant believing it has a working credential. Per our reconciliation analysis, this is the failure mode nobody tests for.

Item six is the quiet one. An updater that returns a response the merchant does not process leaves the file unchanged while the dashboard reports a successful run, and the problem surfaces as an unexplained rise in declines a month later. Per our data source analysis, a dependency whose failure is silent is worse than one that fails loudly.

What to track

MetricWhy
Monthly credential decay rateThe denominator for everything, and it is rarely measured
Updater hit rate, split by network and reasonSeparates coverage gaps from data problems
Share of misses that are confirmed closed accountsThe correct result, and it should not count against the hit rate
Involuntary churn, separately from voluntaryPer our involuntary churn analysis, the figure the updater moves
Disputes within 30 days of a credential refreshThe cost the updater can create, and the one nobody looks for
Cancellation completion rate and time to cancelWhat makes running an updater defensible
Authorization rate before and after refreshPer our statement analysis, a refreshed credential should approve at a higher rate

The fifth row is the measurement that is almost never taken. Disputes shortly after a refresh are the signature of the objection in the previous section, and a business that tracks only the saved subscriptions is measuring one side of its own intervention.

The updater is only defensible next to a working exit

A refreshed credential prevents an accidental cancellation and should never prevent a deliberate one. HL Hunt AI Payment Processing pairs credential refresh with recorded consent, recognizable descriptors and a cancellation path that is as easy as the signup.

Talk to HL Hunt About Payment Processing

Frequently asked questions

How fast do stored card credentials go stale?

About 3.4% a month, which is 204 cards on a 6,000-card file and roughly 34% of the file a year, and none of it is a customer decision.

Is an account updater worth the cost?

On these figures about $42,103 a month of preserved value against $461 of cost, a 91x ratio. Involuntary losses fall from 92 a month to 20.

Why do account updater hit rates stop around 78%?

Because issuer participation, network scope and genuinely closed accounts account for most misses. Only stale references and enrolment gaps are fixable.

Is there a legitimate objection to running an account updater?

Yes. It defeats cancelling by card replacement, so it is only defensible alongside a cancellation path as easy as the signup path.

Key takeaways

  • A 3.4% monthly decay rate means 204 of 6,000 stored cards stop working each month, about 34% a year.
  • None of that is a customer decision, so it shows up as churn without anyone choosing to leave.
  • An updater at a 78% hit rate cuts monthly losses from 92 to 20, preserving about $42,103 a month.
  • Against $461 a month of cost, that is a 91x ratio, which is unusual enough to be worth checking.
  • Hit rates stop near 78% because of issuer participation, network scope and genuinely closed accounts.
  • A confirmed closed account is a correct miss; the right target is a correct disposition, not 100%.
  • The real objection is that an updater defeats cancelling by card replacement, which many people rely on.
  • That makes it defensible only alongside a cancellation path at least as easy as the signup path.

This guide is educational and does not constitute financial, legal, or compliance advice. All figures are stylized illustrations using assumed file sizes, decay rates, hit rates, manual recovery rates, ARPU, tenure, and service pricing, and do not describe any particular business or service. Account updater coverage, stored credential framework requirements, transaction flagging rules, advance notice obligations for recurring charges, and cancellation requirements are set by the card networks and by federal and state law, vary by network and jurisdiction, and change over time; consult your processor, the applicable network rules, and qualified counsel before changing billing practices.