Stripe Decline Code · Glossary
transaction_not_allowed fires when the issuing bank or card network has determined that the specific type of transaction being attempted is not permitted for this card — the card is active, the account may have funds, but a feature-level or transaction-class restriction is blocking this particular charge.
What It Means
What It Means
transaction_not_allowed fires when the issuing bank or card network has determined that the specific type of transaction being attempted is not permitted for this card — the card is active, the account may have funds, but a feature-level or transaction-class restriction is blocking this particular charge. It is a structural hard decline that sits one layer below service_not_allowed in specificity: where service_not_allowed blocks a service category, transaction_not_allowed blocks a specific transaction feature — recurring billing, CNP authorization, cross-currency charging, or a specific merchant type interaction.
Not sure if this code is recoverable for your specific situation? Use the Stripe Failure Lookup →
Why It Happens
Why It Happens
What NOT to Do
What NOT to Do
✕ Don't retry the same transaction type on the same card
transaction_not_allowed is a feature-level structural block — the transaction type itself is forbidden on this card, not the timing or the funds. Retrying an MIT-flagged recurring charge against a card that doesn't allow MITs will fail every single time, indefinitely, regardless of how much time passes between attempts. Zero retries on identical transaction parameters.
✕ Don't conflate it with restricted_card and use the same recovery flow
While transaction_not_allowed and restricted_card are siblings, they require different diagnostic steps. restricted_card is a card-level policy block; transaction_not_allowed is a transaction-feature block that may sometimes be resolved by changing how you initiate the charge — switching from MIT to CIT, enabling 3DS, or adjusting your transaction flags — without requiring the customer to change their payment method at all.
✕ Don't skip the 3DS/SCA audit before escalating to the customer
A significant portion of transaction_not_allowed failures in EU, UK, and Indian markets are caused by missing or failed 3D Secure authentication — a technical issue on your integration side, not the customer's card. Sending a customer email asking them to update their payment method before you've checked whether your 3DS implementation is correctly passing authentication is the most avoidable mistake for this code.
Retry Timing
Retry Timing
transaction_not_allowed requires a technical triage-first approach before any customer-facing action — the recovery path splits based on whether the issue is on your integration side or the customer's card.
Recovery Benchmark
Recovery Benchmark
| Metric | Result |
|---|---|
| Overall recovery rate | 20–40% |
| Recovery via 3DS fix / CIT re-auth (technical cases) | 50–65% of the technical subset |
| Recovery via alternate payment method (structural cases) | 25–35% |
| Recovery with blind retry (no triage) | ~5–8% |
| Recovery with generic card update email | 8–12% |
| 3DS / SCA root cause as % of all occurrences (EU/IN) | 25–40% in regulated markets |
A 35%+ overall recovery rate is achievable when you split the technical (3DS/MIT) and structural (card incompatibility) sub-types and handle them separately. Teams that route all transaction_not_allowed failures into a generic payment method update email miss the 3DS-fixable subset entirely and underperform by 15–20 percentage points versus triage-first workflows.
At Scale
At Scale
Automated
Manual Escalation
FAQs
FAQs
What does the Stripe transaction_not_allowed decline code mean?
transaction_not_allowed means the issuing bank or card network has blocked the specific type of transaction being attempted — such as recurring billing, card-not-present charges, cross-currency transactions, or merchant category interactions — for this card. The card may be active and funded, but the transaction feature itself is not permitted on this card product.
What are the most common causes of a transaction_not_allowed error in Stripe?
Common causes include the card issuer disabling recurring MIT billing on the card, card-not-present or online transactions being blocked, a currency or cross-border transaction restriction, merchant category incompatibility with the card product, and missing or failed 3D Secure authentication on regulated market transactions — particularly common in EU, UK, and Indian markets under SCA and RBI mandates.
Can transaction_not_allowed be caused by a 3DS integration issue?
Yes, and this is one of the most common causes in EU, UK, and Indian markets. If your Stripe integration doesn't correctly pass 3D Secure authentication on recurring charges, issuers in regulated markets return transaction_not_allowed instead of approving the payment. Always audit your 3DS implementation before sending customers a payment method update email — the fix may be on your integration side, not the customer's card.
Should I retry a payment after a transaction_not_allowed decline?
Not with the same transaction parameters. For 3DS failures, fix your integration and re-attempt via a customer authentication link. For MIT rejections, send a Stripe-hosted payment link to trigger a fresh CIT authorization. For structural blocks like CNP restrictions or MCC incompatibility, add the card to your no-retry list and focus on alternate payment method capture instead.
What is the recovery rate for Stripe transaction_not_allowed failures?
Overall recovery rates are 20–40%. For the 3DS and MIT re-authorization subset, recovery rates of 50–65% are achievable with a technical fix and CIT re-auth flow. For structural card incompatibility cases, alternate payment method conversion achieves 25–35%. Blind retries without triage recover only 5–8%.
What to do next
You are here
transaction_not_allowed
Decline code reference
Check recoverability
Stripe Failure Lookup
See what's recoverable — and what isn't →
Then
Sign up for Recurflux
Automate recovery for every decline code →
Before you retry
Before you retry
Most transaction_not_allowed failures are retried on the wrong schedule — which recovers the payment about 30% of the time. The other 70% leaves permanently. See what this code is actually costing at your MRR before deciding how to handle it.
Stop leaving revenue on the table
Recurflux handles code-specific retry scheduling, adaptive dunning, and dispute intelligence across all 30 Stripe decline codes. Connect in under 5 minutes.