Account Updater Services for DTC Subscription Stores
Account updater services quietly refresh stored card credentials before they expire — the single most under-used involuntary-churn lever for subscription stores. Here's how Visa Account Updater and Mastercard ABU actually work, where they fail, and when to turn them on.
Quick answer
Visa Account Updater (VAU) and Mastercard Automatic Billing Updater (ABU) are network services that refresh expired or reissued card numbers on file before your next charge attempt. Enable them on your PSP (Stripe, Adyen, Braintree) and expect to recover 30-60% of cards that would otherwise fail at renewal — but coverage is much weaker in the EU than the US, and Amex/local schemes are excluded entirely.
Account Updater Services
Card-network services (Visa VAU, Mastercard ABU) that automatically refresh stored card credentials when issuers reissue or re-expire them.
Account updater services are batch lookup services run by Visa and Mastercard that let merchants of record submit their stored card-on-file numbers and get back updated PAN, expiry date, or 'account closed' responses — without the cardholder ever knowing. For a subscription store, this means a customer whose bank quietly reissued their card last month still renews next Tuesday instead of churning involuntarily.
The service is invoked by your payment processor — Stripe, Adyen, Braintree, Recurly — not by you directly. Each PSP wraps the network feeds differently: some run daily, some weekly, some only on charge attempt. Coverage depends on whether the issuing bank participates, which is near-universal in the US and patchy across European markets.
Involuntary churn — customers who didn't want to leave but whose card declined — typically accounts for 20-40% of total subscription churn. For a store doing €2M ARR, that's €400-800k a year leaking through expired and reissued cards. Account updaters plug the largest single hole in that bucket.
Why expired cards silently kill subscription revenue
When a card expires or gets reissued (fraud replacement, lost card, scheduled rotation), the cardholder rarely thinks to update it on every subscription they hold. Industry data suggests an average consumer has 6-10 active recurring charges; they update maybe two.
The result on your end is a renewal attempt that returns a hard decline — code 54 (expired card) or 14 (invalid card number). Without an updater service, your only fallback is email-based dunning, which recovers 15-25% of failed charges at best. With VAU/ABU running upstream, most of those declines never happen in the first place.
The Shopify Payments trap
If you run subscriptions on Shopify Payments, you cannot configure account updater behaviour directly — it's bundled into Stripe's defaults and there's no merchant-side toggle. Stores moving to a dedicated Stripe Billing or Recharge setup typically see a step-change in renewal success rates for exactly this reason.
Coverage by network, issuer, and region
Visa and Mastercard cover the bulk of card volume in most Western markets, and their updater services are mandatory for most US issuers. That's why US-heavy subscription stores tend to quote 50-65% successful update rates on expiring cards.
In the EU, participation is voluntary and uneven — German and French issuers participate at materially lower rates than UK or Dutch ones, and local schemes like Cartes Bancaires, Bancontact, and iDEAL bypass the system entirely. Amex runs its own (much narrower) updater on the US side and effectively nothing in Europe.
Approximate account updater hit rates by region and network
| Segment | Visa VAU | Mastercard ABU | Amex | Local schemes |
|---|---|---|---|---|
| US subscriptions | 55-65% | 55-65% | 20-30% | n/a |
| UK / Nordics | 45-55% | 45-55% | <10% | n/a |
| DE / FR / IT | 25-40% | 25-40% | <5% | 0% (CB, Girocard) |
| Rest of EU | 30-45% | 30-45% | <10% | 0% |
How to detect whether yours is actually working
The most common failure mode isn't 'updater disabled' — it's 'updater enabled but silently no-op for half your book'. On Stripe, the signal lives in the PaymentMethod object: look for `card.exp_month` and `card.exp_year` values that changed without a customer-initiated update event. If those fields are stale on cards older than 18 months, the feed isn't reaching you.
On Adyen and Braintree the equivalent signals are `recurring.detail.updated` webhooks and the `payment_method.updated` event respectively. Pull a 90-day sample, count refresh events as a percentage of cards that crossed an expiry boundary in that window, and you have your real hit rate — not the marketing number on your PSP's pricing page.
Network tokens are doing a different job
Network tokens (Visa Token Service, Mastercard MDES) often get pitched alongside account updaters but they solve a different problem — they replace the raw PAN with a tokenised reference that the issuer updates automatically when the underlying card changes. In practice, network tokens give you a higher floor of always-fresh credentials, while account updater services patch the gaps for non-tokenised cards still on file. Most mature subscription stacks run both.
Turning it on: Stripe, Adyen, Braintree
Stripe enables card updater by default on Stripe Billing for US-issued Visa and Mastercard at no per-update fee, but you have to explicitly opt in via the Dashboard for non-US schemes and confirm your account is configured as a recurring merchant. Adyen charges a per-update fee (typically €0.25-0.40) and requires you to flag your tokens as `recurring.contract: RECURRING` to be eligible — easy to miss in initial integration.
Braintree includes account updater in its vault product but only runs it on charge attempt by default, not on a scheduled batch — so a card that expires in the middle of a 30-day cycle won't get refreshed until your renewal hits and declines once. Switching Braintree to scheduled updates is a one-line config change but recovers an extra 5-10 percentage points of involuntary churn for stores with longer billing cycles.
Whichever processor you're on, layer smart retries on top: when an account updater refresh fails or the card is genuinely closed, a retry schedule timed to payday cycles (1, 3, 7, 14 days) recovers a meaningful slice of what's left. Updater plus retries plus dunning email is the full three-layer recovery stack.
Frequently asked questions
On Stripe Billing, VAU and ABU updates for US-issued cards are included in standard processing fees with no per-update charge. For some non-US regions and for the standalone Stripe Issuing/Connect setups, per-update fees may apply — check your account's pricing page or contact support to confirm.
Functionally they're equivalent — each network runs its own service for its own cards. Visa's is called VAU; Mastercard's is ABU. Your PSP queries both on your behalf, so you usually don't interact with them separately. Coverage and issuer participation differ slightly by region but not by enough to matter operationally.
Amex runs a separate, much narrower updater service called Cardrefresher, available primarily in the US and only through certain processors. In Europe Amex effectively doesn't offer this, which is why Amex-heavy subscription books see worse renewal rates than Visa/Mastercard-heavy ones. For local schemes (Cartes Bancaires, iDEAL, Bancontact, Girocard) there's no updater equivalent at all.
Take your monthly involuntary churn rate, multiply by the share of failures attributable to expired or reissued cards (typically 40-60%), then multiply by your expected updater hit rate for your region. A US-heavy store at €100k MRR with 3% involuntary churn typically recovers €800-1,500 MRR per month — meaningful but not transformative on its own.
Partially. Shopify Payments runs on Stripe under the hood and inherits the default updater behaviour, but you cannot configure thresholds, scheduling, or coverage flags directly. Stores running native Shopify Subscriptions on Shopify Payments typically see a lower effective hit rate than stores using Recharge or Bold with a dedicated Stripe Billing account.
No. If the issuer marks the account as closed (response code 'account closed' rather than 'updated PAN'), the updater returns that status and your PSP should automatically suspend or fail the subscription. This is actually useful — it lets you stop wasting retries on dead cards and trigger a winback email instead.
Visa runs VAU batches daily and Mastercard runs ABU on a similar cadence, but your PSP controls how often it submits your vault. Stripe submits on a rolling daily basis. Adyen runs scheduled batches plus on-demand on charge attempts. Braintree defaults to on-charge only unless you enable scheduled updates explicitly.
Yes — the lawful basis is contract performance for the active subscription, and the data flow is between the merchant's PSP and the cardholder's issuer through the card network, both of which are already processors in the original transaction. You should still mention card updating in your privacy notice's payment-processing section.
Use both. Network tokens (Visa Token Service, Mastercard MDES) give you a self-refreshing reference for newly tokenised cards going forward; account updater patches the existing vault of raw PAN-based stored cards. Tokens are the better long-term architecture; updater is the immediate-recovery lever on the cards you already have.
Watch your card-expiry-failure rate as a share of total renewal failures. If it climbs above 25-30% of involuntary churn over a rolling 30 days, your updater pipeline likely has a configuration drift — a token contract flag, a webhook that stopped processing, or a region that was never enabled. Pull a sample of recently expired cards from your PSP and check whether any of them received refresh events.
See Metricuno on your data
Bring your stack — Google Analytics, Stripe, a CRM, anything — and we'll walk through the metric tree that turns your funnel into one number.