> For the complete documentation index, see [llms.txt](https://help.flycode.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.flycode.com/decline-codes-explained/what-to-do-when-you-see-these-other-codes.md).

# What to Do When You See These Other Codes

What generic\_decline, do\_not\_honor, transaction\_not\_allowed and invalid\_account mean in Stripe, whether each should be retried, and what to tell the customer.

After `insufficient_funds`, a handful of codes account for most of the remaining subscription failures. Some are recoverable with retries, some need the customer to call their bank, and some mean the card is finished. This page gives the meaning and the right response for each.

## What is a generic\_decline?

`generic_decline` is Stripe's catch-all when the issuing bank refuses the charge without giving a specific reason, or when Stripe Radar blocks the payment on risk grounds. Behind it can sit a dozen different bank decisions: a temporary hold, a velocity limit, a risk score threshold, a restriction on international or recurring transactions, or an account under review.

Treat it as a soft decline. Retry with varied timing (a different day and time of day rather than the same slot), and if it keeps failing after optimized retries, ask the customer to contact their bank or provide another card. Because the code hides the real cause, this is where machine learning adds the most: FlyCode's models use the card type, issuer, geography, time and history of the account to infer the likely underlying reason and choose the retry pattern that matches it. If Radar blocked the charge, review the rule in the Stripe Dashboard before retrying.

## What does do\_not\_honor mean and should I retry?

`do_not_honor` (network response code `05`) is a blanket refusal from the issuing bank. It is the second most common code in subscription billing and sometimes fraud-related, but more often it reflects an issuer's internal rules: an unusual transaction time, a new card that has not settled, a cross-border charge or a soft balance issue the bank chooses not to disclose.

Yes, retry, but intelligently. A first retry 24 to 48 hours later at a different time of day recovers a meaningful share; repeated failures on the same day each month usually point to funds and respond to a post-payday retry; failures at unusual local hours often clear when retried in business hours. If it still fails after the model has exhausted good windows, request a different card. Do not retry the same second, and never exceed the card network retry limits.

## What does the transaction\_not\_allowed code indicate?

The issuer blocked the charge for policy reasons rather than for funds or fraud. Typical causes are a merchant category the card is not permitted to use, a card that does not allow recurring or online payments, corporate card spending controls, or a cross-border rule. Retrying the same card unchanged rarely helps.

Ask the customer to contact their bank and authorize the merchant or transaction type, then retry once they confirm. If the customer has a backup payment method on file, FlyCode can fall back to it instead of waiting.

## Why would Stripe return invalid\_account?

The card, or the bank account linked to it, has been closed or the number was entered incorrectly. It is a hard decline: no retry will succeed because the account no longer exists in a chargeable state.

Stop automatic retries, notify the customer with a clear request for a new payment method, and use a card update link or backup card on file. FlyCode classifies `invalid_account` as hard on arrival, so no retry attempts are wasted on it and outreach goes out immediately.

## Quick reference

| Code                                                          | Soft or hard | Retry?                                           | Customer action                    |
| ------------------------------------------------------------- | ------------ | ------------------------------------------------ | ---------------------------------- |
| `generic_decline`                                             | Soft         | Yes, varied timing                               | Only if retries fail               |
| `do_not_honor`                                                | Soft         | Yes, 24 to 48 hours later, different time of day | Only if retries fail               |
| `transaction_not_allowed`                                     | Soft, policy | After the customer contacts their bank           | Ask bank to permit the transaction |
| `invalid_account`                                             | Hard         | No                                               | New payment method                 |
| `lost_card`, `stolen_card`, `pickup_card`                     | Hard         | No                                               | New payment method                 |
| `try_again_later`, `issuer_not_available`, `processing_error` | Soft         | Yes, within hours                                | None                               |

Every other Stripe code, with its network equivalent, is covered in the [flycode.com decline codes reference](https://www.flycode.com/stripe/decline-codes).

## Related

* [How to Handle the Most Common Declines](https://help.flycode.com/decline-codes-explained/how-to-handle-the-most-common-declines)
* [Should I expose the raw decline code to customers?](https://help.flycode.com/handling-failed-payments/coordinating-messaging-with-recovery)
* [Does FlyCode support backup payment methods?](https://help.flycode.com/backup-payment-methods)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://help.flycode.com/decline-codes-explained/what-to-do-when-you-see-these-other-codes.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.