Resources

Lost or Stolen Card Declines: The Right Response

A lost or stolen card decline is the clearest message in all of dunning. The card is gone, the issuer has blocked it, and no charge on those details will ever succeed again. There is no timing trick, no spacing strategy, and no retry schedule that changes that answer. And yet operations waste attempts on these codes every month, because their sequences treat every decline as retryable until proven otherwise. This one arrives proven.

This guide covers why lost_card and stolen_card are definitive hard declines, the role card updater services play, and how fast, well-judged outreach to the customer turns a dead card into a saved subscription.

What lost_card and stolen_card mean

When a cardholder reports a card lost or stolen, the issuer cancels that card number and issues a replacement with new details. Any subsequent charge attempted on the old details returns a lost_card or stolen_card decline. The two codes are operationally identical for the merchant: the distinction matters to the issuer, not to your recovery play. Both mean the payment instrument itself no longer exists.

These codes sit at the hardest end of the hard-decline family. The issuer will never approve a charge on a card its own customer reported stolen, and asking repeatedly does not soften that position — it merely generates refusals. The decline code cheat sheet maps these codes to their single correct action: do not retry, request new payment details.

Never retry: the rule and the reasons

Every retry of a lost or stolen card is a known failure purchased at full price. The costs stack up quietly:

• Wasted attempts. Your retry budget is finite in any sane sequence. Attempts spent on a dead card are attempts unavailable for the soft declines in the same window that time could actually cure.
• Noise in your data. Repeated guaranteed failures inflate your decline counts and distort the recovery picture, making healthy sequences look weaker than they are.
• Issuer and network signal. Persistently presenting charges on cards reported stolen is exactly the behaviour pattern payment networks watch for. Even absent any penalty, it is a reputation you gain nothing by building.
• Customer experience. Each failed attempt can generate another notice, another alert, another moment where a customer who has already dealt with a lost card gets chased about a payment instrument they no longer have.

The correct sequence behaviour is immediate and simple: on the first lost or stolen response, retries on that card stop permanently, and the case moves wholly to the card-replacement track. Any system — native or layered — that retries these codes is misconfigured, and fixing that one rule is among the highest-value audits an operator can run.

The hidden good news: this customer usually wants to stay

Step back from the code and consider the customer. They did not cancel. They did not run out of money. They lost a wallet, or spotted a suspicious transaction, and their bank did the right thing quickly. In the great majority of these cases, the subscriber fully intends to keep the subscription — they simply have a new card and a long list of places to update it. According to Recurly research, 20–40% of subscriber churn is involuntary, and lost-card failures are involuntary churn in its purest form: a loyal customer ejected by an administrative event.

That framing changes the tone of everything that follows. You are not dunning a reluctant payer. You are helping a willing customer complete a chore, in competition with every other subscription, account, and service on their update list. The businesses that win that race are the ones that ask early, ask clearly, and make updating take seconds. The businesses that lose are the ones whose first email arrives after the customer has forgotten the subscription existed.

Card updater services: the silent first line

Before outreach even begins, one mechanism may already have solved the problem. Card updater services — run through the card networks and offered by processors — refresh stored card details automatically when an issuer replaces a card, passing the new number and expiry to merchants holding the old credentials, where the cardholder account relationship qualifies. When an updater works, the next charge simply succeeds on the new details and neither you nor the customer notices anything happened.

Updaters are not total coverage. Coverage depends on the issuing bank participating and on the replacement being the kind of reissue the service handles; a card replaced after fraud may move to a new account relationship an updater cannot follow. Treat updaters as a valuable first line that silently resolves a share of cases, never as a reason to skip outreach for the rest. Our guide to card updater services explains how they work, where they apply, and where they stop.

Fast card-replacement outreach: winning the update race

For every case the updater does not resolve, speed and clarity decide the outcome.

Ask immediately

The first message should go out as soon as the decline is classified — not after a retry schedule runs its course, because for this code there is no retry schedule. The customer is actively updating their card across their accounts in the days right after a loss. A request that lands in that window gets actioned as part of the chore. A request that lands weeks later lands after the chore is done and forgotten, competing with everything newer in the inbox.

Make the message specific and safe

Name what happened in plain terms: the card on file was reported lost or stolen, so it can no longer be charged, and a new payment method is needed to keep the subscription running. Link to a secure, branded card-update page and make the task visibly small — one card, one form, under a minute. Specificity matters doubly here because customers are, correctly, on high alert for fraud after a card loss. A vague payment message from an unexpected sender reads as a scam attempt to someone whose card was just stolen. Your brand, your domain, and a message that matches what they see when they log in are what make the request trustworthy enough to click.

Give a clear deadline and a held subscription

Tell the customer their subscription is held and until when. A defined grace window converts an abstract request into a completable task and reassures the customer they are not being charged for a service in limbo. When the deadline approaches without an update, a final reminder and then a clean cancellation with an easy rejoin path respects the customer better than an indefinite half-alive subscription. Customers who churn out this way with goodwill return; customers chased indefinitely do not.

The choreography resembles the handling for expiry, and our guide on expired card payments covers the adjacent case — details that time has invalidated rather than a bank block — with the same update-first logic.

What good handling looks like as a sequence

Put together, a lost or stolen case should run like this: the decline is classified instantly and retries are cancelled; updater services resolve what they can; outreach fires immediately with a specific, branded, secure update request and a clear hold deadline; one or two reminders follow inside the window; and the subscription either resumes on the new card or closes cleanly with a rejoin path. No drama, and no wasted attempts.

The card-replacement moment is a forced audit of every recurring charge the customer holds. Subscriptions worth keeping get updated; subscriptions that were coasting get quietly dropped. Your outreach is your pitch to survive that audit — one more reason it should be prompt, clear, and easy to act on.

How Swipe Again handles lost and stolen cards

Swipe Again is failed-payment recovery software built for subscription businesses. Lost_card and stolen_card responses are classified as hard declines on arrival, and hard declines are never retried — the case moves straight to branded dunning emails, a branded card-update page, and SMS in the sequence, asking for a new payment method while the subscription is held. The wider decline-code-aware system still runs up to 6 attempts over ~16 days for the soft declines where retries belong; this family simply is not one of them. On connect, Swipe Again runs a 90-day backfill on your existing backlog of failed payments, including older lost and stolen cases that never got a proper update request, and cancel deflection with Discount, Pause, and Service offers is included for subscriptions that reach a save conversation.

Swipe Again works with nine platforms: Stripe, Recharge, Seal Subscriptions, Skio, Loop Subscriptions, Chargebee, Recurly, Braintree, and Paddle. Pricing is $179/mo flat ($1,799/yr), with no percentage of recovered revenue and no MRR tiers. There is a 14-day trial with a card upfront, and connecting takes about 2 minutes. The guarantee is stated in exactly one form: "Recover $179 in 30 days, guaranteed — or Swipe Again is free the next 30 days".

The bottom line

A lost or stolen card decline is final about the card and silent about the customer. Never retry the dead details, let updater services resolve what they can, and move fast with a specific, trustworthy update request while the customer is still working through their replacement-card chores. Win that race and an administrative accident stays an accident, instead of becoming churn you talk yourself into calling inevitable.

Frequently asked questions

Should you ever retry a lost or stolen card decline?

No. The issuer has cancelled that card and will never approve a charge on it. Retrying wastes attempts, distorts your recovery data, and can generate repeated failure notices for the customer. The only correct action is to stop retries on those details immediately and ask the customer for a new payment method.

What is the difference between lost_card and stolen_card for merchants?

Operationally, none. The distinction matters to the issuer and the cardholder, but both codes mean the card has been cancelled and replaced, the old details are permanently dead, and recovery depends entirely on collecting new payment details. Both are hard declines and both follow the same no-retry, fast-outreach playbook.

What are card updater services and do they solve this?

Card updater services refresh stored card details automatically through the card networks when an issuer replaces a card, where the bank and account qualify. They silently resolve a share of lost and replaced card cases. Coverage is not total, particularly where a replacement involves a new account relationship, so updaters are a first line, not a substitute for outreach.

How quickly should you contact a customer after a lost card decline?

Immediately. Customers update their payment details across accounts in the days right after a card is replaced, and a prompt, specific request joins that round of chores. Waiting until a retry schedule would have ended means asking weeks later, when the update round is finished and your request is far more likely to be ignored.

Why do customers ignore card update requests after a card loss?

Usually because the request looks untrustworthy or arrives too late. After a card theft, customers are alert for scams, so vague messages from unclear senders get deleted. A branded message that names what happened, links to a secure update page on your own domain, and states a clear hold deadline is far more likely to be acted on.