Error codes
Soft decline
Stripe
transaction_not_allowed
The card was declined for an unknown reason.
What does transaction_not_allowed mean?
The transaction_not_allowed decline code is a catch-all used by issuing banks when a specific type of transaction is refused. The card is not necessarily blocked for all purchases — the issuer has determined that this particular transaction violates a rule on the account, card product, or merchant category.
Is it a soft or hard decline?
transaction_not_allowed is classified as a soft decline, but with important nuance: the underlying restriction may be temporary (and therefore recoverable) or permanent (requiring the customer to switch cards). Treating it as potentially recoverable is the right default.
Common root causes
The card does not permit recurring or subscription transactions
Merchant category code (MCC) blocking by the issuer
Card type restrictions (e.g., corporate cards not allowing personal purchases)
Geographic restrictions on international transactions
Temporary account-level restrictions applied by the issuer
Policy-based refusals unique to the issuing bank
Recommended recovery steps
Retry once after 24–48 hours — if the restriction is temporary, this often clears.
Use network tokens for recurring subscription charges to reduce false positives.
Try a backup payment method on file, since another card may not have the same restriction.
Only escalate to customer outreach after retries — and when doing so, explain that the customer may need to call their bank.
How FlyCode handles transaction_not_allowed
FlyCode's AI retry engine distinguishes between temporary and persistent transaction_not_allowed restrictions using network-level data from Visa and Mastercard. For temporary restrictions, FlyCode times retries to maximize recovery. For persistent restrictions where the card itself cannot be used for subscriptions, FlyCode automatically orchestrates backup payment methods stored on file, keeping the subscription active without customer involvement.
This combined approach recovers a significant portion of transaction_not_allowed declines that simple retry logic would miss — all operating on top of your existing Stripe integration with zero code changes.
What does transaction_not_allowed mean?
The transaction_not_allowed decline code is a catch-all used by issuing banks when a specific type of transaction is refused. The card is not necessarily blocked for all purchases — the issuer has determined that this particular transaction violates a rule on the account, card product, or merchant category.
Is it a soft or hard decline?
transaction_not_allowed is classified as a soft decline, but with important nuance: the underlying restriction may be temporary (and therefore recoverable) or permanent (requiring the customer to switch cards). Treating it as potentially recoverable is the right default.
Common root causes
The card does not permit recurring or subscription transactions
Merchant category code (MCC) blocking by the issuer
Card type restrictions (e.g., corporate cards not allowing personal purchases)
Geographic restrictions on international transactions
Temporary account-level restrictions applied by the issuer
Policy-based refusals unique to the issuing bank
Recommended recovery steps
Retry once after 24–48 hours — if the restriction is temporary, this often clears.
Use network tokens for recurring subscription charges to reduce false positives.
Try a backup payment method on file, since another card may not have the same restriction.
Only escalate to customer outreach after retries — and when doing so, explain that the customer may need to call their bank.
How FlyCode handles transaction_not_allowed
FlyCode's AI retry engine distinguishes between temporary and persistent transaction_not_allowed restrictions using network-level data from Visa and Mastercard. For temporary restrictions, FlyCode times retries to maximize recovery. For persistent restrictions where the card itself cannot be used for subscriptions, FlyCode automatically orchestrates backup payment methods stored on file, keeping the subscription active without customer involvement.
This combined approach recovers a significant portion of transaction_not_allowed declines that simple retry logic would miss — all operating on top of your existing Stripe integration with zero code changes.
What does transaction_not_allowed mean?
The transaction_not_allowed decline code is a catch-all used by issuing banks when a specific type of transaction is refused. The card is not necessarily blocked for all purchases — the issuer has determined that this particular transaction violates a rule on the account, card product, or merchant category.
Is it a soft or hard decline?
transaction_not_allowed is classified as a soft decline, but with important nuance: the underlying restriction may be temporary (and therefore recoverable) or permanent (requiring the customer to switch cards). Treating it as potentially recoverable is the right default.
Common root causes
The card does not permit recurring or subscription transactions
Merchant category code (MCC) blocking by the issuer
Card type restrictions (e.g., corporate cards not allowing personal purchases)
Geographic restrictions on international transactions
Temporary account-level restrictions applied by the issuer
Policy-based refusals unique to the issuing bank
Recommended recovery steps
Retry once after 24–48 hours — if the restriction is temporary, this often clears.
Use network tokens for recurring subscription charges to reduce false positives.
Try a backup payment method on file, since another card may not have the same restriction.
Only escalate to customer outreach after retries — and when doing so, explain that the customer may need to call their bank.
How FlyCode handles transaction_not_allowed
FlyCode's AI retry engine distinguishes between temporary and persistent transaction_not_allowed restrictions using network-level data from Visa and Mastercard. For temporary restrictions, FlyCode times retries to maximize recovery. For persistent restrictions where the card itself cannot be used for subscriptions, FlyCode automatically orchestrates backup payment methods stored on file, keeping the subscription active without customer involvement.
This combined approach recovers a significant portion of transaction_not_allowed declines that simple retry logic would miss — all operating on top of your existing Stripe integration with zero code changes.
Understanding This Decline Code
Extended content body
Frequently Asked Questions
What does transaction_not_allowed mean?
Is transaction_not_allowed a soft or hard decline?
Soft decline. The same card may work perfectly for other purchases — the issuer is refusing this specific transaction based on rules about merchant category, recurring billing, or account restrictions. Some restrictions lift after 24–48 hours.
How does FlyCode recover transaction_not_allowed?
FlyCode uses network-level data and intelligent retry timing to recover transaction_not_allowed declines where the restriction is temporary. For persistent restrictions, FlyCode orchestrates backup payment methods to keep the subscription active.
