Stripe Updates Expired Cards, and Your Books Never Say So

A customer's card expired in March. Their subscription renewed in April anyway, and nobody at your company did anything to make that happen.

That is Stripe's automatic card updater working as designed. It is one of the few pieces of payments plumbing that quietly protects revenue, and it is also one that leaves no trace whatsoever in your accounting records. Both facts matter at month end, and the second one is why the first is so often mistaken for a data problem.

This post covers what Stripe actually does when an issuing bank replaces a card, how to tell an automatic update apart from a customer re-entering their details, and why the "cards expiring next month" report that nearly every subscription business builds is not the churn forecast it looks like.

Start a free trial of Acodei if you want Stripe charges and their fees landing in QuickBooks without the retyping.

What Stripe does when a bank reissues a card

The mechanism is simpler than most people assume, and it does not involve your integration at all.

Stripe's documentation on how cards work states it plainly: "Saved payment method details can continue to work even if the issuing bank replaces the physical card. Stripe works with card networks and automatically attempts to update saved card details whenever a customer receives a new card (for example, replacing an expired card or one that was reported lost or stolen)."

Read the parenthetical carefully, because it is broader than "expired". A card reported lost or stolen gets the same treatment. So does a card replaced because the bank changed its BIN ranges or merged with another bank. The trigger is reissuance, not expiry, and expiry is simply the most common reason a card gets reissued.

The purpose, in Stripe's words, is to let "your customers continue using your service without interruption" and to reduce "the need for you to collect new card details whenever a card is replaced". That is the whole feature. There is no dashboard switch to describe and no integration work to do, which is exactly why so few finance teams know it is running.

It is worth separating this from the other thing called a card update. Updating a saved card through the API is a narrow operation: Stripe says it "can only change its name, billing address, expiration date, or metadata", and that "to make any other changes, you must delete the card and create a new one". The network-driven update is not bound by that restriction, because it is not an API call. It can replace the number.

The coverage question, and the sentence that closes it

The first thing a finance person asks once they understand the feature is which customers are protected by it. The answer is genuinely unsatisfying, and Stripe says so directly.

Automatic updates "require card issuers to participate with the network and provide this information". Where that participation exists, coverage is strong: Stripe says it is "widely supported in the United States, allowing Stripe to automatically update most American Express, Visa, Mastercard, and Discover cards issued there". Outside the US it thins out, and Stripe puts it as "international support varies from country to country".

Then comes the sentence that ends the analysis: "It isn't possible to identify cards that support automatic updates."

Not difficult. Not undocumented. Not possible. There is no field on the card object that tells you whether this particular customer's card will be repaired when their bank reissues it. You cannot segment your customer base into covered and uncovered, you cannot forecast from it, and you cannot build a dashboard that tracks it.

That single limitation is the reason everything downstream in this post is about observing what happened rather than predicting what will. You are working with an after-the-fact signal, and the rest of this is about reading that signal correctly.

Two events that look alike and mean opposite things

Stripe emits a webhook for card update activity, and there are two of them. The distinction between them is the single most useful thing in this post, because it is the only clean way to answer the question your retention numbers depend on: did the network fix this, or did the customer?

Stripe documents them as a pair:

• The payment_method.updated event "notifies you of updates to a card through an API call".
• The payment_method.automatically_updated event "notifies you of automatic card updates from the network".

One means somebody acted. A customer went to your billing page and typed in new details, or your support team did it on their behalf, or your own code wrote to the payment method. The other means nobody acted and the card networks repaired the credential in the background.

Those two situations have opposite implications for how you read a renewal. A customer who logged in and re-entered a card has demonstrated intent to keep paying you. A customer whose card was silently fixed has demonstrated nothing at all. They may not know their subscription is still running. Treating both as the same "payment method updated" line in your data is how a retention metric ends up measuring your bank's diligence rather than your customers' enthusiasm.

Both events carry useful payload. Stripe notes they "include the card's new expiration date and last four digits, so you can update your own records as needed". If you display a card on file anywhere in your product or on a receipt template, this is the event that keeps that display honest.

The fingerprint is the field that tells you what really happened

There is a second signal, and it answers a different question: was this the same card number, or a genuinely new one?

Stripe's card object carries a fingerprint, documented in the PaymentMethod API reference as a value that "uniquely identifies this particular card number", with the obvious use spelled out: "You can use this attribute to check whether two customers who've signed up with you are using the same card number, for example."

The relevant behaviour for card updates is stated on the cards overview page in a single line: "If the card update includes a new card number, the fingerprint changes."

That makes the fingerprint a discriminator that the last four digits cannot provide. A reissued card frequently keeps the same number and only moves the expiry, in which case the fingerprint holds steady. A card replaced after fraud gets a new number, and the fingerprint moves with it. Same customer, same subscription, same uninterrupted revenue, different underlying instrument.

This matters beyond curiosity if any of your internal logic keys on the fingerprint. Deduplication, fraud rules, "is this the same payer" checks and customer-matching heuristics all commonly use it, and all of them will silently see a fraud-replacement card as a stranger. Nothing errors. The record simply stops matching. If you have built anything that treats a stable fingerprint as an identity guarantee, a reissuance wave at one large bank is the event that finds the bug. For the separate and more common question of how a Stripe customer is matched to a QuickBooks customer, customer matching between Stripe and QuickBooks is the one to read.

Two caveats on the fingerprint are worth carrying. For wallets, Stripe says that "for payment methods that tokenize card information (Apple Pay, Google Pay), the tokenized number might be provided instead of the underlying card number", so a wallet fingerprint is not the card fingerprint. And the field is not globally singular: Stripe records that "as of May 1, 2021, card fingerprint in India for Connect changed to allow two fingerprints for the same card, one for India and one for the rest of the world".

Related, and a frequent source of confusion when someone tries to reconcile a wallet payment against a card on file: for tokenized numbers the wallet carries a dynamic_last4, which Stripe defines as "the last four digits of the device account number". The digits your customer sees in Apple Pay are the device's, not the card's, so a last-four comparison between a wallet charge and a saved card can legitimately fail.

What a card update does to your books

Nothing, and that is the correct outcome rather than a gap.

No money moves when a card is updated. A credential is replaced, and a credential is not a transaction. There is no amount, no fee, no balance transaction and therefore nothing for any accounting system to record. The next renewal arrives as an ordinary successful charge, indistinguishable in your ledger from one taken on a card that was never touched.

This is worth stating explicitly because the absence is what people find suspicious. The sequence a bookkeeper actually observes is: a customer whose card they know expired, followed by revenue from that customer in the following month, with no intervening event of any kind. That looks like a reconciliation error. It is not. It is a charge that succeeded, and the reason it succeeded lives entirely in Stripe and the card networks, where your accounting system has no visibility and no business having any.

The practical version of this is short. Do not go looking in your books for the explanation of a renewal you did not expect. The books are the wrong place to look, because nothing accounting-shaped happened. Look at the payment method's event history in Stripe instead.

Why your expiring-cards report is not a churn forecast

Almost every subscription business eventually builds the same report: customers whose card on file expires in the next sixty or ninety days. It gets used two ways, and only one of them is sound.

As a prompt for outreach, it is fine. Asking customers to refresh a card before it lapses is reasonable and costs nothing.

As a forecast of involuntary churn, it is close to meaningless, and the reason is the coverage sentence from earlier. A large share of those cards, most of them if your customers are US-based, will be repaired by the networks without anyone doing anything. You cannot tell which ones, because Stripe has told you that identifying them is not possible. So the report is a list of cards that will expire, mixed in unknown proportion with cards that will be fixed, presented as though it were a list of subscriptions at risk.

The failure mode is not that the number is wrong. It is that the number is wrong in a direction that changes behaviour. Teams forecast a churn spike that does not arrive, and then either take credit for a save campaign that did nothing or quietly stop trusting the forecast altogether.

The measurement that does work runs backwards. Count the renewals that actually failed for a card reason, and count the automatic update events you received. Those are both observed facts. A forward-looking count of expiring cards is an input to neither.

When the updater does not fire

The feature has a failure mode, and it is the ordinary one: the card is not repaired, the renewal is attempted against a dead credential, and the charge declines.

At that point you have left the territory of this post and entered the territory of failed payments, which behave the way any other decline behaves. The charge does not succeed, no revenue is recognised, and whatever retry and notification behaviour you have configured takes over. If you want the accounting side of that, what a declined Stripe payment does to your QuickBooks records is the one to read, and for bank-debit rather than card failures, failed ACH payments in QuickBooks covers a timing problem that catches people out.

The populations most exposed are the ones the coverage note implies: customers outside the United States, and customers on cards from smaller issuers that do not participate with the networks. If you have a meaningful non-US subscriber base, the updater is doing less for you than your US-centric intuition suggests, and proactive card refresh prompts are worth more.

One useful adjacent control is letting customers fix their own cards before you have to ask. The Stripe customer portal is the built-in route for that, and it covers what else changes in your books when customers manage their own subscriptions.

What to actually check

Four things, in the order that pays off fastest.

1. Subscribe to the right event. If you handle only payment_method.updated, you are seeing customer-initiated changes and missing every network update. Add payment_method.automatically_updated.
2. Store the fingerprint alongside the last four. It is the only field that tells you whether the underlying card number changed, and you cannot reconstruct it after the fact.
3. Audit anything keyed on the fingerprint. Deduplication and identity logic that assumes stability will break silently on fraud replacements rather than erroring.
4. Stop forecasting churn from expiry dates. Measure failed renewals and received update events instead. Both are observable; coverage is not.

The short version

Stripe works with the card networks to repair saved cards when banks reissue them, and it covers most US-issued Amex, Visa, Mastercard and Discover cards. You cannot find out which of your customers are protected, because Stripe says identifying those cards is not possible. Two separate webhooks tell you whether an update came from the network or from a person, and that distinction is the difference between a customer who chose to stay and one who simply was not interrupted. The card fingerprint changes only when the underlying number changes, which makes it the field to watch and the field most likely to break your matching logic. And none of it produces an accounting entry, because replacing a credential is not a transaction.

If the part you care about is the transactions that do produce entries, start a free trial of Acodei and let the charges, fees and payouts arrive in QuickBooks on their own.

Frequently asked questions

Does Stripe update expired cards automatically?

Often, yes. Stripe works with the card networks and "automatically attempts to update saved card details whenever a customer receives a new card", including replacements for expired, lost or stolen cards. It depends on the issuer participating with the network, and Stripe describes support as wide in the United States and varying by country elsewhere.

Can I see which of my customers have cards that support automatic updates?

No. Stripe states directly that "it isn't possible to identify cards that support automatic updates". There is no field to filter on and no report to build, which is why coverage cannot be forecast and can only be observed after the fact through update events.

What is the difference between payment_method.updated and payment_method.automatically_updated?

The first fires for updates made through an API call, which in practice means a person or your own code changed the card. The second fires for automatic updates that came from the card network. Only the second one tells you the card was repaired without anyone acting.

Does the card number change when Stripe updates a card?

Sometimes. A reissued card often keeps the same number and only changes the expiry. When the number does change, Stripe says the fingerprint changes with it, so comparing the fingerprint before and after is how you tell the two cases apart.

Does an automatic card update create a record in QuickBooks?

No, and it should not. No money moves when a credential is replaced, so there is no charge, no fee and no balance transaction. The next renewal posts as an ordinary successful charge. If a renewal you expected to fail succeeded instead, the explanation is in the payment method's history in Stripe, not in your accounting records.

Why does my customer's Apple Pay last four not match their card?

Because it is a different number. For tokenized payment methods Stripe exposes a dynamic_last4, defined as "the last four digits of the device account number". Wallets also report a tokenized fingerprint rather than the underlying card's, so neither field is a reliable way to match a wallet charge to a saved card.