Resources

Hard Declines vs Soft Declines: Response Guide

Every declined payment arrives with a code, and the first job in recovery is not retrying or emailing — it is classification. Declines split into two families, hard and soft, and they call for opposite handling. Retry a soft decline patiently and you will often get paid. Retry a hard decline at all and you are charging a card that no longer exists in any usable form, while the customer who could fix it hears nothing.

This guide teaches the classification and the policy that follows from it: which failures to retry and how, which to route straight to a card-update request, and which need the customer to talk to their bank first. It deliberately does not reproduce the full code-by-code table — that reference lives in a sibling guide, linked below. You rarely need the whole table; you need to know which family a failure belongs to, and what your system should do next.

The two families, defined plainly

A soft decline is a temporary no. The card is still a real, open payment method; the charge failed because of the circumstances of that attempt. The classic example is insufficient funds — the money was not in the account at that moment. The defining test: the same card, presented again under different circumstances, could plausibly succeed without the customer changing anything.

A hard decline is a permanent no for that card as presented. The card has expired, was reported lost or stolen, or the account behind it is closed. The defining test is the mirror image: the same card, presented again at any time, will fail again for the same reason. Only new payment details can move the subscription forward.

One nuance keeps operators honest: the family is a property of the failure, not of the customer. A reliable, long-tenured subscriber can produce a hard decline the week their bank reissues their card. Classify the decline, respond to the decline, and let the customer's history adjust your tone — never the other way around.

The response guide at a glance

Class	Examples	Correct action	Retry?
Soft — temporary funds or bank condition	Insufficient funds; temporary issuer or processing issue	Timed retries spaced across different moments, with light supporting outreach	Yes — on a spaced schedule, inside a capped window
Hard — card no longer valid	Expired card; lost or stolen card; closed account	Ask for a new card once, clearly, through a secure update page; no retry language	No — never on the same card
Customer action required	Bank block or do-not-honor; bank wants cardholder approval	Tell the customer a call to their bank usually clears it, then retry or collect updated details after they act	Not until the customer has acted
Authentication required	Issuer requires the cardholder to confirm the charge	Guide the customer to complete the confirmation step with their bank	Only as part of completing the authenticated charge, per your platform's flow

The last two rows are where real operations get messy, because many declines arrive wearing a generic label. Policy for that grey zone comes later in this guide; the table is the spine everything else hangs from.

Soft declines: retry with patience and a plan

Soft declines are where retry logic earns its keep. According to Churnkey's published analysis of Stripe data, across 5.4M failed payments, insufficient funds is the largest decline category at 40.6% — so the soft-decline policy is not an edge case; it is the main event. And a soft decline describes a moment. The correct response to a moment is to try different moments.

In practice that means attempts spaced widely enough for circumstances to change — for a pay cycle to turn over, for a temporary bank issue to clear — rather than a burst of attempts in the first days that all sample the same conditions. It means a firm cap on attempts and a defined recovery window, so persistence never becomes pestering. And it means outreach that supports the schedule instead of racing it: a light, unembarrassed note early, naming the subscription and the secure update link in case the customer would rather switch cards, without daily pressure while the account is simply empty.

What soft-decline handling must never do is shame. A shortfall is a timing problem. The operators who recover these payments well sound bored by the whole thing — routine, factual, easy to act on.

Hard declines: never retry, ask once and well

Hard declines have exactly one productive move: get a new card. Every retry of an expired, lost, stolen, or closed card cannot succeed, adds pointless declines to the card's history with its issuer, and delays the only message that matters while the recovery window burns down.

So the sequence for a hard decline inverts the soft-decline sequence. Outreach goes first, immediately, and retries do not happen at all. The message should be short and specific: the card on file can no longer be used, here is the secure page to add a new one, here is the date the subscription will pause if no new card arrives. One link, your branding, no language about "trying again" — because you are not trying again, and saying so plainly is what makes the final deadline believable.

Ask well, but with restraint. A small number of clear touches beats a long drip of identical requests. If the window closes with no new card, pause the subscription as promised, preserve the customer's settings and rate, and leave a clean path back. Many hard-decline losses are administrative, not intentional — the customer replaced a card and forgot one subscription among many.

Expired cards deserve one footnote: before the first ask, a card updater service may already have refreshed the details silently, in which case the charge can proceed on the updated card and no message is needed at all. Ask only when the silent route has not solved it.

The grey zone: generic refusals and bank blocks

Not every decline announces its family. Issuers sometimes return a generic refusal — a do-not-honor or an unspecified no — that could be a temporary block, a fraud precaution, or the bank quietly telling the customer to call. Treating it as soft wastes attempts if the bank is waiting on the customer; treating it as hard wastes a perfectly good card if the block would have cleared with one phone call.

The policy that resolves the grey zone is escalation in steps. Give a generic refusal, at most, a small number of spaced attempts — banks do clear some blocks on their own. If it persists, change the ask: tell the customer, plainly and without blame, that their bank is declining the charge and that a quick call to the number on their card usually clears it, with the update link ready in case they would rather use a different card.

Authentication-required declines get the same respect for the customer's role. When the issuer wants the cardholder to confirm the charge, the next step belongs to the customer and their bank, in whatever flow your platform supports. Your job is a clear, calm prompt that this step is normal and expected.

For the individual codes behind every class in this guide, the full reference is our guide to Stripe decline codes explained, and the one-page summary is the decline code cheat sheet. Keep the cheat sheet where whoever answers billing support can see it.

Classification is a system property, not a support skill

It is tempting to treat all of this as knowledge your support team should hold. Resist that. By the time a human is classifying a decline, the automated system has usually already done the wrong thing — retried the dead card, or sat silent on the saveable one. Classification has to live inside the recovery system itself, branching before any attempt or email is scheduled.

That is how Swipe Again is built. It is failed-payment recovery software for subscription businesses: decline-code-aware smart retries run up to 6 attempts over about 16 days for the failures worth retrying, hard declines are never retried and go straight to a card-update request through branded card-update pages, and branded dunning emails and SMS carry the asks only a customer can answer. A 90-day backfill on connect applies the same classification to your existing backlog. Cancel deflection with Discount, Pause, and Service offers is included.

Swipe Again connects to Stripe, Recharge, Seal Subscriptions, Skio, Loop Subscriptions, Chargebee, Recurly, Braintree, and Paddle. It costs $179/mo flat ($1,799/yr), with no percentage of recovered revenue and no MRR tiers, and starts with a 14-day trial, card upfront, self-serve, with connect in about 2 minutes. The guarantee is: Recover $179 in 30 days, guaranteed — or Swipe Again is free the next 30 days. For the end-to-end picture, see the complete failed payment recovery guide.

The bottom line

Hard versus soft is the first and most consequential decision in payment recovery. Soft declines get patient, spaced, capped retries and a light touch. Hard declines get no retries at all and one clear, early request for a new card. Generic blocks get a couple of chances, then an honest message asking the customer to call their bank. Get the classification right inside the system, automatically, and most of recovery is already handled — you cannot out-email a retry policy that is charging dead cards.

Frequently asked questions

What is the difference between a hard decline and a soft decline?

A soft decline is a temporary refusal where the same card could succeed later under different circumstances, such as when funds arrive after an insufficient-funds failure. A hard decline is a permanent refusal for that card as presented, such as an expired, lost, stolen, or closed card, which no retry can fix. Timed retries for soft declines, a new-card request for hard declines — the response follows from the class.

Why should hard declines never be retried?

Because the card itself is the problem, so every retry is certain to fail for the same reason. Retrying wastes the recovery window, adds pointless declines to the card's record with its issuer, and delays the one action that can save the subscription: asking the customer for a new card, early and clearly.

How should an expired-card decline be handled?

First, check whether a card updater service has already refreshed the details silently; if it has, the charge can proceed without bothering the customer. If it has not, send a prompt request for a new card through a secure, branded update page, with no retry language and a clear pause date.

What should you do about a generic do-not-honor decline?

Treat it as a grey-zone case. Allow at most a small number of spaced attempts in case the bank clears the block on its own, then change strategy: tell the customer their bank is declining the charge, that a quick call to the number on their card usually clears it, and include the secure update link in case they prefer a different card.

Can a good customer get a hard decline?

Yes, routinely. Hard declines describe the card, not the customer. Banks reissue cards after fraud alerts and cards expire, all without the subscriber telling every merchant. That is why the response should be administrative and unembarrassed: a simple request for the new card, with the subscription and its settings preserved for an easy return.