foxhound
Sign in

Decline code

Transaction Not Allowed

`transaction_not_allowed` is Stripe's label for a decline the issuing bank returned without a specific stated reason, though in practice this code shows up more often than most for a particular pattern: the cardholder's bank has restricted the type of transaction being attempted, or the card itself doesn't support it. It's a soft decline, not a sign of a closed account.

Back to decline codes
transaction_not_allowedRetries automatically
Draft content: this page's explanatory copy is Pass 3 template writing pending a dedicated content pass. The classification badge above and the recovery behavior described below are live, not draft: both come directly from the recovery engine.

Why it happens

This code carries a stronger subscription-specific signal than most soft declines. Some banks apply restrictions to recurring or online transactions specifically, meaning a card that works fine for an in-person purchase or even a one-time online checkout can still get blocked when the same card is charged as part of a recurring billing arrangement. Certain card types compound this: some prepaid cards, some debit cards, and some corporate or virtual cards are issued without recurring-payment support enabled at all, either by design or because the cardholder never opted in to that transaction type with their bank. A charge that would succeed as a one-time purchase can fail every time as a subscription renewal on the exact same card.

How to fix it

Yes, generally, though the odds of a plain retry succeeding are lower here than with a pure timing-driven code like `insufficient_funds`. If the underlying cause is a bank-side restriction on recurring charges specifically, retrying the identical charge type again will often hit the same wall. If the cause is closer to a temporary flag or a one-off restriction, a delayed retry has a real chance. Because the code doesn't distinguish between these two situations, the safe default is still to retry rather than give up immediately. Treat the first attempt as a soft decline and retry on a delay, same as other codes in this category. If repeated retries keep failing, that's a stronger signal than usual that the issue may be structural (a card that genuinely doesn't support recurring billing with that bank) rather than transient, which makes a direct customer message asking for an alternate payment method more useful here than with codes that are purely timing-related.

How Foxhound recovers it

A Foxhound-scheduled silent retry runs first, timed for the specific decline pattern rather than an immediate repeat. If the retry succeeds, the customer never sees anything happened. If it does not, Foxhound moves to a dunning email sequence across the following weeks, written in the merchant's own brand voice, with a hosted card-update link on every email as a passive fallback channel.

Questions

  • Not necessarily. It often means the specific transaction type (recurring or online billing) isn't permitted on that card by the issuing bank, while other transaction types on the same card work fine.

  • Some banks and some card types (certain prepaid or debit cards in particular) restrict or exclude recurring transaction support even when general purchases go through without issue.

  • Yes, at least once with a delay. If it keeps failing on repeated retries, that's a signal the restriction may be structural rather than temporary.

  • Try a different card, ideally a standard credit or full-service debit card, since some restrictions are tied to the card type rather than the account holder.

  • The retry-then-email mechanism is the same as other soft codes. Silent background retry first, merchant-branded email only if retries don't resolve the charge.

See what this looks like on your account

The free audit shows what Stripe already recovered and what is still dying, no signup required.

Run your free audit