About 3% of cards in your Stripe customer base silently go stale every month. Someone loses a wallet and gets a replacement. A card expires and the bank issues a new one. A customer reports fraud and the issuer swaps the PAN. The customer never tells you, because from their perspective nothing happened. Their next subscription renewal lands, Stripe tries to charge the old card, and you get an invoice.payment_failed webhook for what is essentially an administrative issue.
Visa Account Updater (VAU), and its Mastercard equivalent Automatic Billing Updater (ABU), exist to fix this before it becomes a dunning problem. If you are a UK merchant on Stripe and you have not enabled them, you are burning recoverable revenue on failed payments that never needed to fail in the first place. But VAU is not a silver bullet, and understanding its limits matters as much as understanding how to turn it on.
What Visa Account Updater actually does
VAU is a Visa service that sits between card issuers and merchants. When a Visa card is reissued, replaced, or updated, the issuer pushes the new card details into VAU's central database. Merchants who subscribe to VAU can then query it, usually in a batch, and receive updated PANs and expiry dates for the cards on file.
In practice, for a SaaS merchant, the flow looks like this.
- You store a card in Stripe and charge it monthly
- The customer's bank reissues the card (lost, stolen, expired, fraud reset)
- The issuer sends the new card details to Visa's VAU database
- Stripe queries VAU on your behalf before retrying the subscription
- Stripe updates the saved payment method automatically
- The next charge goes through on the new card, with no customer action
Mastercard runs the same service under the name Automatic Billing Updater. American Express has its own equivalent. Stripe exposes all three as a single feature called "Card account updater" in the dashboard.
When it works, the customer never sees a failed payment. You never send a dunning email. Your recovery rate on that failure mode effectively becomes 100%, because the failure never happens.
How to enable it on Stripe
Stripe makes this refreshingly simple for UK merchants. There is no separate contract with Visa or Mastercard, no integration work, and no additional webhook handling.
- Log into the Stripe Dashboard
- Go to Settings, then Payments, then Payment methods
- Find "Card account updater" (sometimes listed as "Automatic card updates")
- Toggle it on
That is the whole setup. Stripe automatically queries VAU, ABU, and Amex's updater when it attempts to charge a saved card, and applies any updates it receives. The updates also propagate to your Customer object in Stripe, so if you read payment_method.card.last4 it will show the new last four digits after an update.
Pricing varies slightly by region and Stripe plan. For most UK merchants on standard Stripe pricing, there is either no additional fee or a small per-update charge in the region of a few pence. Compared to the fully loaded cost of a failed payment cycle (dunning emails, SMS, support time, involuntary churn risk), it pays for itself an order of magnitude over.
What VAU catches
VAU is most effective on four specific failure modes.
Card expiry. A card expires on its printed date and the issuer sends a new one. VAU gets the new expiry (and sometimes a new PAN). This is the single biggest win, because expired-card declines are both frequent and 100% preventable with updater data.
Reissued cards. The issuer replaces a card for any reason (damage, lost, stolen, fraud). The PAN changes. VAU has the new number.
Account number changes. The bank migrates a customer to a new card product (for example, upgrading from standard to premium) and issues a new PAN. VAU catches this.
Card brand updates. Rare but real. A customer's co-branded card converts to a plain Visa. VAU handles it.
Stripe publishes internal metrics showing that card updater enrollment can eliminate a double-digit percentage of would-be declines on subscription portfolios. Your mileage depends on your customer demographic (consumer vs B2B), card mix (more consumer cards means more reissues), and geography.
What VAU misses
This is where merchants get into trouble. VAU is not a universal fix, and treating it as one will leave revenue on the table.
Insufficient funds. The card is valid and up to date. There is just no money in the account. VAU cannot help. This is a dunning problem.
Issuer declines for risk reasons. The issuer's fraud model blocks the charge even though the card is active. VAU does not know. Dunning problem.
Cards not enrolled in VAU. Not every issuer participates in VAU. UK coverage is good but not universal. Some challenger banks, prepaid cards, and smaller issuers do not push updates into the database. For those cards, you are back to the old "decline, reissue, customer does not tell you, next charge fails" cycle.
Non-Visa, non-Mastercard cards. Amex has its own updater with good coverage in the UK, but it is a separate service. Diners, JCB, and other schemes have limited or no updater coverage. If your customer base leans international, this matters.
Direct Debit and other non-card payments. VAU is strictly a card network service. If you take GoCardless Bacs payments (see our Stripe and GoCardless guide), VAU does nothing for them.
Cancelled cards with no reissue. A customer closes their account and no replacement is issued. The card simply does not exist any more. VAU marks it as closed if it gets the update at all, but there is no new PAN to swap in. You still need the customer to add a new payment method.
3D Secure and SCA declines. If the issuer demands Strong Customer Authentication under PSD2 and Stripe cannot satisfy it off-session, the charge fails regardless of card validity. VAU cannot help because the card itself is fine.
Add all of these together and you get a rough picture. VAU might prevent somewhere between 20% and 40% of your failed payments depending on customer mix. The rest still need a proper dunning sequence.
VAU as the first line of defense, not the only one
The right way to think about VAU is as no-code revenue protection. It costs nothing to turn on, it requires no integration, it has no customer-facing impact, and it silently prevents a material chunk of failures before they reach your dunning pipeline. If you are a UK SaaS merchant on Stripe and you have not enabled it, do it this afternoon.
But do not stop there. The failures VAU cannot prevent are the ones where dunning earns its keep. Insufficient funds declines need a sequence that gives the customer time to move money around. Risk declines need a message that explains what to do (usually "contact your bank"). SCA declines need an authenticated payment update link the customer can click from their phone. Closed cards need a clear prompt to add a new one.
Those are dunning sequences, not updater database lookups. The two layers are complementary.
A realistic recovery stack for UK Stripe merchants
Here is the layered approach we recommend.
- Layer one: Card account updater (VAU, ABU, Amex). Toggle on in Stripe settings. Catches expiry and reissue failures silently. Zero customer friction.
- Layer two: Smart retries. Stripe's built-in retry schedule or a tool that handles retry logic. Catches transient declines and insufficient funds after a few days.
- Layer three: Automated dunning sequences. Email plus SMS, triggered on failed payment webhooks, with contract-based lawful basis. Catches the remaining failures where customer action is required.
- Layer four: Human touch for high-value accounts. For customers above a revenue threshold, flag failures to your CSM team so someone can reach out personally.
Rekko sits at layer three. It reads Stripe webhooks, runs GDPR-compliant email and SMS sequences, and hands off to your support or CSM team for the accounts where automation is not enough. VAU lives upstream at layer one, preventing a chunk of failures from ever reaching Rekko in the first place. That is the point. The cheaper layers handle the easy cases so your dunning tool only has to work on the genuinely stuck ones.
Compliance note
VAU is a card-scheme service, not a data protection question, but the PANs flowing through it are still personal data under UK GDPR. Stripe's privacy notice and DPA cover the VAU flow as part of their card processing. You do not need a separate lawful basis or customer consent to enable it, because it is a technical payment-processing step covered by the same contract and processor agreement you already have with Stripe. If you want to reference it in your own privacy notice, a line like "we use Stripe's card account updater service to keep stored card details current" is enough.
Try Rekko for the failures VAU cannot fix
VAU will save you maybe a third of your failed payments. Dunning saves another half. Together they get you close to the recovery rate ceiling.
Rekko is built for the second half. Flat-fee pricing, Stripe-native setup, email plus SMS sequences, contractual necessity baked in, and opt-out handling that keeps you on the right side of PECR.
Start your 14-day free trial, no credit card required. See how Rekko stacks up against Stunning and Churnkey on pricing.