Restricted Card Decline: What It Means and Why Retrying Won't Fix It

A restricted card decline means the issuing bank has put a block on the card that prevents your type of charge from going through. It is a hard decline in practice: the same retry will fail again until the customer talks to their bank or gives you a different card.

This one frustrates founders more than almost any other code, because the customer usually has money, the card usually works at the grocery store, and yet your $29 renewal keeps bouncing. Here's what is actually going on, and the playbook that recovers these.

What the restriction actually is

Banks can restrict a card at several levels, and the customer often has no idea any of them exist:

• •Online transaction blocks. Some debit cards ship with card-not-present purchases disabled by default. The card swipes fine in stores and declines every subscription charge.
• •International blocks. Your Stripe account settles in a different country than the card was issued in, and the bank blocks cross-border charges. Very common if you sell globally from a US or EU entity.
• •Merchant category blocks. Banks and corporate card policies block entire MCC ranges: gambling, crypto, cash-like instruments, sometimes anything coded as digital services.
• •Security freezes. The bank flagged something, froze the card's online usage, and forgot to make that obvious to the customer. A fraud alert the customer waved off in an app notification is a classic cause.
• •Corporate card policy. The employee's company card allows travel and office supplies, full stop. Your SaaS charge is outside policy and the card declines it no matter how healthy the account is.

Notice what every one of these has in common: the restriction is a rule sitting on the issuer's side. It does not expire, it does not care what time of month it is, and it does not care how politely Stripe asks. The retry will hit the same rule and bounce.

Why you should not retry this one

I am normally the guy telling you to retry soft declines patiently. This is the opposite case. Retrying a restricted card does three bad things at once:

• •It burns attempts against network retry limits (Visa roughly 15 per 30 days, Mastercard about 35) that you want to save for codes where retries actually work.
• •It can train the issuer's fraud model to distrust your merchant descriptor, making future declines on other customers marginally more likely.
• •It delays the only fix that works, which is the customer contacting their bank. Every day you spend retrying silently is a day closer to the subscription lapsing for good.

So the strategy for restricted_card is: detect it, stop the retry machine, go straight to email. Speed matters here because the customer has a task to do, and tasks get procrastinated.

The email that recovers these

The key to the email is naming the problem correctly. If you say "your payment failed", the customer checks their balance, sees money, and concludes your billing is broken. You have to tell them it is a bank-side restriction, which tells them exactly who to call:

"Your last payment didn't go through, and it's not a balance issue: your bank has a restriction on the card that's blocking our charges (this usually means online or international purchases are disabled on the card). A quick call to your bank asking them to allow charges from us fixes it, or you can add a different card here in about 30 seconds: [link]"

Why this works: it pre-answers the customer's confusion ("but I have money"), it gives them the exact sentence to say to their bank, and it offers the 30-second escape hatch (new card) for the people who would rather not call anyone. Both paths recover the payment. The wrong email, a generic "update your payment method", only offers the second path and confuses the customer into re-entering the same restricted card.

The corporate card wrinkle

If you sell B2B, a chunk of your restricted declines are corporate card policies, and those customers often cannot lift the restriction themselves. The employee has to ask their finance team, which means your email is really a request for them to start an internal process. Give that process time: follow up every 3 to 4 days instead of daily, keep the account active during the conversation, and make the backup-card path prominent. A lot of employees will just drop in a personal card and expense it rather than fight their own finance department.

How much of your churn this actually is

Run your decline code breakdown for the last 90 days. Restricted card usually shows up as a small single-digit percentage of declines, but here is the thing: it converts to churn at a much higher rate than soft codes because most founders treat it like every other failure. They retry it into the ground, send one generic email, and lose the customer. A decline that was always recoverable-by-conversation becomes a cancellation by neglect.

The follow-up cadence for this code

Because the fix depends entirely on the customer doing something, your email cadence is the whole recovery plan. What works: the first email within 24 hours of the decline, a second at day 3 to 4 with a slightly different framing (lead with the backup-card option this time), and a third at day 7 to 8 that is honest about the stakes ("your account is still active, but it will lapse soon if we can't collect"). Three touches, each with one clear ask, spaced enough that each feels like a person following up rather than an automation nagging.

Two things that kill recovery on this code. First, sending the same email three times. The customer who did not act on email one is not waiting for an identical copy; change the angle. Second, cutting off access too early. A restricted card is a solvable admin problem, and the customer solving it needs the product to still feel alive. Keep the account running through the sequence, warn before any cutoff, and you will recover people who would have churned silently under a stricter policy.

One special case worth knowing: prepaid cards. If your product attracts a prepaid-heavy audience, restricted declines will be overrepresented in your data, because many prepaid products block recurring charges by design. These customers are not being difficult and their banks will not lift anything. For them, the backup-card ask in your first email is not a fallback, it is the whole play, and an ACH or PayPal option converts better than any card conversation.

Last thing: log these. When a restricted decline recovers, note which path did it (bank call vs backup card). Over a few months you will learn whether your audience leans corporate-policy or online-blocked, and that answer tells you whether to invest in better emails or in a second payment method. Recovery data is product research in disguise.

The fix is not more automation, it is the right message at the right moment. That is the philosophy I built StayPaid around: the tool watches the decline code, picks the right play (retry patience for soft codes, immediate human-sounding email for hard ones like this), and sends it from your real address so the customer actually reads it. Restricted card is the code where that philosophy pays for itself fastest.