generic_decline: what this Stripe decline code means and how to tell whose decision it was

What it means

This is Stripe's bucket for declines it can't explain. The issuer answered with its network's default, or with a response Stripe's mapping doesn't translate, and what reaches you is generic_decline. Stripe's own docs note that issuers categorise most declines as generic, so this is the decline_code you will see more than any other. Getting one doesn't mean something unusual happened; it means the ordinary thing happened and nobody wrote down why.

The same value has a second, unrelated source. When Stripe Radar or Adaptive Acceptance blocks a payment, the decline_code is also generic_decline, so that whoever submitted the card can't tell your fraud rules from a bank refusal. The issuer never saw those payments. Before reading a generic_decline as the bank's decision, check outcome.type on the Charge: issuer_declined means it went to the bank and came back, blocked means your own tooling stopped it, and outcome.rule names the rule when one fired.

It is worth separating from its neighbours. do_not_honor is also a no-reason decline, but it is a specific answer the issuer chose to send, the network's response code 05. generic_decline is the absence of an answer Stripe could use. And card_declined is one level up entirely: the error code this value arrives inside. If you are holding a generic_decline, you already did what the card_declined page says to do, and this is what was underneath.

There is still signal nearby. outcome.network_decline_code carries the raw response from the card's network, which is occasionally more specific than the mapped code, and advice_code carries the issuer's own view on retrying when one was supplied. Past that, Stripe's guidance for generic declines matches its guidance for do_not_honor: if the card details are right, the reason lives with the issuer, and only the cardholder can ask.

Why it happens

1. The issuer sent the network default

   Plenty of issuers, and the processors behind smaller ones, answer anything they haven't classified with their network's catch-all response. Stripe can't translate what was never specific.

2. A response Stripe doesn't map

   Networks and issuers use codes Stripe's tables don't cover, including regional and processor-specific ones. Whatever came back lands here, and the raw value survives in outcome.network_decline_code.

3. Radar or Adaptive Acceptance blocked it

   Your rules or Stripe's risk tooling stopped the payment before authorisation. outcome.type reads blocked, and the issuer was never asked.

4. A reason the issuer kept

   Fraud scoring, account state, controls the cardholder set. Where do_not_honor is the issuer choosing the explicit no-comment response, this is the issuer not sending anything Stripe can use. From your side the two are hard to tell apart.

Common mistakes

• Reading it as the bank's decision without checking

  A Radar block and an issuer decline share this code on purpose. Retrying a blocked payment replays it into the same rule, and emailing a customer about a bank problem that never involved a bank wastes the email. One look at outcome.type settles it.

• Guessing a reason for the customer

  With nothing to go on, any specific explanation you send is invented. The bank declined the charge is the whole truth, and Stripe's customer-facing message is written for this case. Anything more precise is a guess the customer may act on.

• Retrying it like a transient error

  A processing_error is a hiccup and worth a quick follow-up. A generic_decline is a refusal with the reason withheld, and refusals repeat when nothing has changed. Fast reattempts into an unknown reason are how a cautious issuer becomes a hostile one.

• Ignoring the fields beside it

  network_decline_code and advice_code sit on the same outcome object. One holds the raw network response, the other the issuer's stance on retrying. Reading them costs nothing and occasionally turns an unknown into a known.

How Lirova handles it

Lirova routes generic_decline to retry_gentle, the spaced-out retry lane. The lane is about pacing and nothing else: the reason is withheld, so each later attempt is a fresh question to the issuer, and the spacing keeps a run of fresh questions from reading as pressure. The schedule itself differs by decline reason.

The code's lane is not the whole routing. An advice code from the issuer outranks it, and a case whose outcome says Radar blocked it has nothing a retry could fix, whatever the decline_code says.

FAQ

Related codes

• do_not_honor
• card_declined
• fraudulent