ChatGPT Plus Payment Failures: Reading the Decline Code

Why a charge works one month and fails the next

When a charge arrives, the issuer’s automated systems decide whether to authorise it using signals such as spending habits, account balance and card data including expiry date, address information and CVC [2]. The same subscription succeeding last month and failing this month usually means one of those signals changed, not that the card broke.

For subscription charges, a few signals matter more than the rest:

• Billing address— whether it matches the one on file with your issuer;
• How many times the same charge has been submitted in a short window;
• Whether the issuing country and the network environment’s location conflict — Stripe notes that a card issued in one country used from an IP address in another may be declined as possible unauthorised use, while acknowledging that travelling internationally is a legitimate exception [2];
• Your issuer’s default blocking rules: some issuers block online transactions, cross-border transactions or certain merchant categories by default [2].

Only by separating these can you tell what to change next. Changing the wrong thing adds failures, and the failure count is itself a risk signal.

When you can see the code: use this table

Stripe normalises the reasons issuers return into a fixed set of decline codes. Cardholders rarely see them, but they do appear in virtual-card apps, banking apps and payment debugging views. The table below picks out the codes most relevant to subscription charges; both the meaning and the next step are taken from Stripe’s own documentation [1] [2].

Two things to watch when reading this table. First,a code tells you who declined, not always why: do_not_honor, generic_decline, transaction_not_allowed all three carry the official description “declined for an unknown reason”. Second, Stripe states plainly that issuers categorise most declines as generic and that, for privacy and security reasons,an issuer discusses the specifics of a decline only with its own cardholder [2]. So “the code doesn’t explain it” is the normal outcome, not a gap in the information.

When all you see is “card was declined”

This is the most common case: the page shows one generic line. That is not laziness on the page’s part but a direct result of the rule above — the issuer did not hand over the detail, so the merchant has nothing to show.

There is exactly one correct next step:contact your issuer and ask why this charge was declined. Swapping cards, changing addresses and resubmitting are all changes made without knowing the cause: the result is uninterpretable and the failure count keeps climbing.

The OpenAI help centre directs failed renewals to three places: whether the issuer blocked the charge, whether the billing details match the issuer’s records, and whether a regional payment restriction applies [3]. That order matches the one here: ask the issuer first, check the details second, and treat regional factors last.

Three causes whose remedies conflict

The codes above fall into three groups, each with its own set of actions. Mixing them cancels the effort out.

The third group has an easily missed branch:generic_decline is officially described as including payments blocked by Stripe Radar or Adaptive Acceptance [1]. In that case the charge may never have reached the issuer, which is why the bank’s support team finds no record — not because they are stonewalling, but because the request genuinely did not get that far. The tell is this: if the bank has no authorisation record at all, the problem is more likely on the acquirer side than the issuer side.

Retry or not: read the advice code

Alongside the decline code, Stripe returns an advice code that states directly whether the charge can be retried [2]:

• do_not_try_again— do not use this card again for the same transaction;
• try_again_later— you can retry later;
• confirm_card_data— the information provided is wrong, so check the card details first.

With no code to read, work from this principle:do not submit the same charge on the same card more than once or twice in a row. Stripe notes that the card networks limit how often a single charge may be reattempted, suggests a maximum of eight, and warns that issuers may read extra retries as potential fraud — making legitimate charges more likely to be declined, not less [2].

Subscriptions add another layer: an automatic renewal is an off-session charge, so when it triggers authentication_required there is no way to surface an authentication page for the cardholder to complete 3DS. Stripe’s guidance is to complete authentication on-session first and save it, then use that for later charges [1]. That is why “the first manual subscription went through but the renewal failed” keeps happening.

A step-by-step checklist

Work through these in order, submitting once after each change. Do not change several variables at the same time.

1. Check the card details digit by digit: card number, expiry date, CVC. Copy from the app rather than typing from memory.
2. Billing address and postal code: what counts is the one recorded in your issuer’s system, not one that merely looks plausible. A random local address will not pass verification.
3. Balance and limit: confirm there is enough for this charge, and check whether an existing pre-authorisation hold is occupying part of the limit.
4. The card’s feature switches: some cards ship with online, cross-border or subscription charges switched off, and they must be enabled in the app.
5. Submission frequency: resubmitting the same charge in a short window is itself a risk signal.
6. Network and device environment: Stripe lists a mismatch between issuing country and IP location as a possible cause of decline [2]. Switching environments frequently makes that signal worse.

If it still fails after all six, stop retrying and contact the issuer. The most useful things you can give them are the time of the failure, the amount, the merchant name, and any code you saw.

When you must contact the issuer

In any of the following cases, the next step belongs to the issuer, not the merchant’s page:

• The code is do_not_honor, generic_decline, transaction_not_allowed, security_violation, service_not_allowed — the official next step for each of these is that the cardholder contacts the issuer [1];
• The code is card_not_supported or currency_not_supported, and you need to confirm whether the card is permitted for this type of purchase or this currency;
• The code is card_velocity_exceeded, pickup_card or restricted_card;
• the same card works at other merchants and only this one fails;
• you have already failed more than three times on the same card.

When you call, ask three questions directly: did this charge reach your authorisation system; if it did, what was the decline reason code; and does this card carry any extra restriction on online, cross-border or subscription transactions.

What not to do

• Do not retry repeatedly on the same card. See the retry limit and fraud-assessment notes above.
• Do not open a new account because a payment failed. A failed payment and an account deactivated for policy violations are two different things, and treating them as one adds risk. See ChatGPT and Claude Account Bans: Preventing and Appealing Them Under the Official Rules.
• Do not “get it through” with someone else’s card or a payment agent. Sharing accounts and payment credentials are both grounds for deactivation under the two platforms’ terms.
• Do not trust “internal channel” or “guaranteed approval” services. A decline is decided by the issuer and the acquirer; no third party can change it on your behalf, and this site does not offer ways to evade risk controls.

A failed payment does not by itself change your account status or prevent a later subscription. What makes things worse is retrying repeatedly without knowing why.

Frequently asked questions