Recovery Rate

15–30%

Hard Decline

Stripe Decline Code · Glossary

not_permitted

Non-recoverable·15–30%·Updated May 2026

What It Means

What not_permitted actually means.

not_permitted fires when the issuing bank or card network has determined that the cardholder is specifically not authorized to perform this type of transaction — a permission-level block targeting the cardholder's relationship with the card, not the card's general functionality or available funds. It sits one layer more specific than transaction_not_allowed: where transaction_not_allowed blocks a transaction feature, not_permitted blocks this specific cardholder from performing that specific transaction class — making it a targeted, identity-adjacent decline rather than a blanket card restriction.

Not sure if this code is recoverable for your specific situation? Use the Stripe Failure Lookup →

Why It Happens

The root causes.

1Cardholder-level permission restriction — The issuing bank has restricted this specific cardholder from initiating certain transaction types — such as online payments, subscription billing, or cross-border charges — based on their account tier, account standing, or KYC verification status
2Card account under review or restricted — The customer's bank has placed their account under a compliance, identity, or fraud review — all outgoing transactions requiring standard cardholder permission are blocked until the review clears
3Card not activated for online/CNP use — Some card products require the cardholder to explicitly activate online or card-not-present transaction permissions — a card that hasn't been enabled for digital use returns not_permitted when a CNP charge is attempted
4Merchant type not permitted for this cardholder — The bank has blocked this cardholder specifically from transacting with certain merchant categories — distinct from restricted_card (which is a card product policy) because not_permitted is applied at the individual account level by the bank
5Secondary cardholder or authorized user limit — On joint or multi-user accounts, authorized users may have restricted transaction permissions set by the primary cardholder — an authorized user attempting a subscription charge beyond their permitted transaction types triggers not_permitted at the bank level

What NOT to Do

Common mistakes that make it worse.

✕ Don't retry without a bank contact step

not_permitted requires cardholder-specific action at the bank level — the permission restriction is tied to the account, not the timing or funds. Retrying the same charge against the same card without the customer first resolving the permission issue with their bank produces identical failures every time and risks escalating the block severity.

✕ Don't treat it identically to transaction_not_allowed

The distinction matters operationally: transaction_not_allowed can sometimes be resolved by changing how you initiate the transaction (3DS, CIT vs. MIT). not_permitted cannot — it requires the cardholder to contact their bank and resolve a permission issue at the account level before any transaction type will succeed. Applying a 3DS re-auth flow to a not_permitted failure wastes engineering effort and customer goodwill.

✕ Don't send an alarming email — keep framing neutral and actionable

not_permitted on the customer side often feels confusing and arbitrary — they may not know their account has a restriction. Framing your email as "your bank has restricted this card" without a clear action path creates anxiety without resolution. Your copy must lead directly to the solution: call your bank, or use an alternate payment method — one clear CTA per email, not both simultaneously.

Retry Timing

Optimal retry schedule.

not_permitted is a bank-contact-required code before any retry — similar in structure to do_not_honor and security_violation but with a more specific resolution path focused on account-level permission restoration.

Recovery Benchmark

What good looks like.

Metric	Result
Overall recovery rate	15–30%
Recovery when customer contacts bank	40–55% of those who take action
Recovery via alternate payment method	+12–18% additional lift
Recovery with blind retries	~3–7%
Customer action rate on bank-contact email	~25–35%
Recovery within 7 days	~18–25%

A 25–30% recovery rate on not_permitted is the realistic ceiling — and the dominant lever is email specificity. Telling the customer exactly what to say to their bank ("Please activate online and recurring payments on my account") significantly outperforms vague "contact your bank" instructions. Pairing this with an immediate alternate payment method offer as a parallel track captures the segment that won't or can't resolve the bank restriction.

At Scale

How to handle it at scale.

Automated

✓Webhook trigger: invoice.payment_failed → check failure_code === 'not_permitted' → route to a bank-contact-required workflow — completely isolated from retry-first soft decline tracks
✓Zero immediate retries: Add not_permitted to your conditional no-retry list — retries only fire after customer confirmation of bank action; gate this with a simple confirmation link or form in the Day 0 email
✓Email Day 0 — bank activation script: Subject: "Your bank needs to activate this payment" — body includes exact script: "Call your bank and say: 'I need to activate online and subscription payments on my card, and remove any transaction restrictions on my account.'" — specificity here drives 2x higher action rates than generic bank-contact messaging
✓Confirmation-gated retry: Build a one-click "I've contacted my bank — retry my payment" link in the email → fires a conditional retry immediately when clicked → if it fails again, auto-route to alternate payment method flow without requiring another email
✓Alternate method parallel track — Day 3: Don't wait for bank resolution exclusively — simultaneously surface PayPal, bank transfer, UPI, or a second card option from Day 3 onward; not_permitted customers who can't resolve their bank restriction quickly convert well on alternate methods
✓BIN classification: Run a BIN check on the failed card — if it's a prepaid, student, or basic debit product, the permission restriction may be structural rather than resolvable; route these directly to alternate payment method email rather than bank-contact email to avoid sending customers on a fruitless call to their bank

Manual Escalation

→High-ACV accounts: Personal outreach Day 2 if no customer action — a direct human message with the bank activation script included recovers 25–30% of high-value accounts that don't respond to automated emails
→New customer + first charge fails with not_permitted: Cross-reference account signals before outreach — if the customer signed up from a regulated market (IN, NG, BR) with a card product known for online transaction restrictions, lead with alternate payment method options rather than bank contact — the restriction may be a permanent card product limitation, not a resolvable account setting
→Repeat not_permitted — same customer, consecutive months: Direct conversation about permanent payment method replacement — a card that returns not_permitted across two or more billing cycles has a persistent bank-level permission issue that will not self-resolve; the CSM conversation should be explicit: this card cannot be used for your subscription and here are three alternatives
→International customers in restricted markets: For customers in markets with strict bank-level online transaction controls (India RBI mandates, Nigerian CBN regulations, Brazilian Banco Central restrictions), not_permitted is frequently a regulatory compliance block — offer local payment methods (UPI, Pix, bank transfer) as the primary resolution path rather than directing customers through what may be a bureaucratic bank permission process

FAQs

Frequently asked questions.

What does the Stripe not_permitted decline code mean?

not_permitted means the issuing bank has determined that this specific cardholder is not authorized to perform this type of transaction — a permission-level block at the account level, not a card product restriction or funds issue. The card may be active and funded, but the bank has restricted this cardholder from initiating subscription, online, or cross-border transactions specifically.

What are the most common causes of a not_permitted error in Stripe?

Common causes include a bank-imposed cardholder-level permission restriction on online or recurring payments, an account under compliance or identity review, a card that hasn't been activated for card-not-present or digital transactions, a bank blocking this specific cardholder from certain merchant categories, or an authorized user on a joint account with restricted transaction permissions.

What should my customer do when Stripe returns not_permitted?

Ask them to contact their bank and say: 'I need to activate online and subscription payments on my card and remove any transaction restrictions on my account.' Providing this exact script in your email significantly increases the rate at which customers take action. If the bank restriction cannot be resolved, direct them to an alternate payment method such as PayPal, bank transfer, or a different card.

Should I retry a payment after a Stripe not_permitted decline?

Only after the customer confirms their bank has cleared the restriction. Gate all retries behind a customer confirmation step — a one-click confirmation link in your email that triggers an immediate retry when clicked. Limit total retries to 2 attempts. Blind retries without bank contact produce only 3–7% recovery and risk escalating the account-level restriction.

What is the recovery rate for Stripe not_permitted failures?

Overall recovery rates are 15–30%. Among customers who contact their bank and resolve the permission restriction, 40–55% recover successfully. Adding an alternate payment method offer from Day 3 alongside the bank-contact sequence adds 12–18% additional recovery lift. Blind retries without customer bank action recover only 3–7%.

What to do next

You are here

not_permitted

Decline code reference

↓→

Check recoverability

Stripe Failure Lookup

See what's recoverable — and what isn't →

↓→

Then

Automate recovery for every decline code →

Before you retry

Most not_permitted 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.

See what not_permitted costs me →

Stop leaving revenue on the table

not_permitted can't be retried — but it can be caught earlier.

Recurflux handles code-specific retry scheduling, adaptive dunning, and dispute intelligence across all 30 Stripe decline codes. Connect in under 5 minutes.

See what's leaking →All 30 decline codes →