Stripe decline code: generic_decline

Two quite different situations share this code. Either the issuer declined without giving a reason, or Stripe's own risk tooling — Radar rules, or Adaptive Acceptance — stopped the payment before or independently of the issuer. That second possibility matters, because it is the one you can do something about: a Radar rule is yours to inspect and change, whereas an issuer decision is not.

• A Radar rule blocked the payment — including rules you wrote yourself, and the default rules on a new account.
• Adaptive Acceptance declined a payment it predicted would fail.
• The issuer declined without disclosing a reason.
• A card on your own block list, which Stripe reports separately as `merchant_blacklist` but which is easy to confuse with this.

1. Check the payment in the Stripe Dashboard first. If Radar blocked it, the rule that fired is named there and no amount of customer-side troubleshooting will help.
2. Review your Radar rules if the rate is high. An over-broad rule looks exactly like a run of issuer declines from the API alone.
3. Where the issuer declined, Stripe's documented next step applies: the customer needs to contact their card issuer.
4. Present it to the customer the same way as any other decline — do not surface Radar's involvement, which tells a fraudster what tripped.

• Stripe do_not_honordo_not_honor
• Stripe card_declinedcard_declined
• Stripe fraudulentfraudulent

• Card test toolkit

How do I tell a Radar block from an issuer decline?

Open the payment in the Dashboard. A Radar block names the rule that fired and shows the risk evaluation; an issuer decline shows the network's response instead. The API alone gives you the same `generic_decline` either way, which is why this one is worth checking in the Dashboard rather than reasoning about from logs.