foxhound
Sign in

Decline code

Issuer Not Available

`issuer_not_available` is Stripe's decline code for a specific, well-defined situation: the card issuer couldn't be reached, so the payment couldn't be authorized. Stripe never got a yes or no answer from the bank. The charge didn't fail because the bank said no, it failed because the bank never responded at all.

Back to decline codes
issuer_not_availableRetries automatically
Draft content: this page's explanatory copy is Pass 3 template writing pending a dedicated content pass. The classification badge above and the recovery behavior described below are live, not draft: both come directly from the recovery engine.

Why it happens

This is an availability problem on the issuer's end. Banks run maintenance windows, have occasional system outages, or experience connectivity issues on their authorization networks, and any of those can leave Stripe's request unanswered. For subscription billing specifically, this means a perfectly healthy card with plenty of available balance can still fail a renewal charge purely because the bank's systems were briefly unreachable at the exact moment the charge went out. There's no signal here about the cardholder's creditworthiness, balance, or intent. It's purely a connectivity gap.

How to fix it

Yes, and it's one of the more clearly retryable codes in the network category precisely because the definition rules out any card-condition explanation. Once the issuer's systems are back online or reachable, a retry of the same charge typically goes through without issue. Treat it with the same tiered retry approach as other network declines: an early attempt a few hours out to catch short outages, and a second attempt around 24 hours later to catch longer maintenance windows. Because this decline says nothing about the card or the customer's account, there is no reason to contact the customer before retries have run. A dunning email asking someone to fix their payment method when their bank was simply offline for an hour creates unnecessary friction and looks like a mistake on the merchant's part.

How Foxhound recovers it

A Foxhound-scheduled silent retry runs first, timed for the specific decline pattern rather than an immediate repeat. If the retry succeeds, the customer never sees anything happened. If it does not, Foxhound moves to a dunning email sequence across the following weeks, written in the merchant's own brand voice, with a hosted card-update link on every email as a passive fallback channel.

Questions

  • No. It means Stripe's request never reached the bank, or the bank never responded. There was no yes or no answer from the issuer at all, so nothing about the card was actually evaluated.

  • No. It's a connectivity and availability issue on the issuing bank's side, unrelated to whether the customer has enough funds or good standing on the account.

  • Most instances clear within a few hours as the bank's systems come back online. A small number take closer to a day if the outage or maintenance window runs long.

  • No. Since the cause sits entirely on the bank's side, there's no reason to treat the account as risky or the card as invalid. Retry and move on.

  • Yes. Foxhound's classifier routes it into the network bucket rather than the card-condition bucket, which means faster automatic retries and no customer email while those retries are in progress.

See what this looks like on your account

The free audit shows what Stripe already recovered and what is still dying, no signup required.

Run your free audit