Stripe decline code: issuer_not_available
Stripe's wording: "The card issuer couldn't be reached, so the payment couldn't be authorised." Attempt the payment again; if it still fails, the customer needs to contact their card issuer.
issuer_not_availableRetryable
The same request can succeed later. Retry with backoff.
What it means
The issuer's authorisation system was unreachable, so no decision could be obtained and the payment failed by default. Nothing is wrong with the card or your request. This is Stripe's counterpart to the ISO 8583 field 39 value 91, and like it, it is transient — a retry after a short delay frequently succeeds, because bank outages end.
Common causes
- The issuing bank's authorisation host is down or in a maintenance window.
- A network failure between the card network and the issuer.
- A timeout: the issuer responded, but too late for the network to use the answer.
- An outage affecting one bank, which shows up as failures clustered on a single BIN range.
How to fix it
- Retry with backoff and an idempotency key, which is Stripe's documented first step.
- If retries keep failing for the same card, follow Stripe's second step and have the customer contact their issuer.
- Check whether failures cluster on one card range. If they do, it is one bank's outage and there is nothing on your side to fix.
- Exclude these from your decline metrics. An issuer outage is not a decline and should not be measured as one.
Tools that help
Frequently asked questions
- How is this different from processing_error?
- The location of the failure. `issuer_not_available` means the issuer specifically could not be reached; `processing_error` means something went wrong somewhere in the processing path, which may be nowhere near the issuer. Both are transient and both call for the same response — retry with backoff and an idempotency key.