← Decline Codes
Hard Decline

Stripe Decline Code · Glossary

service_not_allowed

service_not_allowed fires when the issuing bank has determined that the specific service type or transaction category being requested is not permitted for this card — the card is active, the account may have funds, but the bank has explicitly disabled the card from being used for this class of transaction.

Non-recoverable·20–35%·Updated May 2026

What It Means

What service_not_allowed actually means.

service_not_allowed fires when the issuing bank has determined that the specific service type or transaction category being requested is not permitted for this card — the card is active, the account may have funds, but the bank has explicitly disabled the card from being used for this class of transaction. It is a structural hard decline at the card-service level: not a temporary block, not a funds issue, not a fraud flag — the bank's policy simply does not allow this card to be used for what you're billing.

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

Why It Happens

The root causes.

  • 1Subscription / recurring billing disabled on the cardThe most common SaaS cause: the issuing bank has disabled recurring payment authorization for this specific card product — frequently seen on prepaid cards, student debit accounts, basic checking debit cards, and certain regional card products in India, Southeast Asia, and Latin America
  • 2Online or card-not-present transactions blockedThe customer's bank has disabled e-commerce or card-not-present (CNP) transactions on their card — the card works at physical POS terminals but is blocked from all online merchant charges
  • 3International / cross-border service blockThe card is restricted from transacting with foreign merchants or across currency borders — a domestic-only card type attempting to pay an internationally-billed SaaS product triggers this at the service level
  • 4Card product type incompatible with transaction classSome card products (payroll cards, benefits cards, government-issued debit) are programmatically limited to specific service categories — your merchant category code falls outside what the card product is authorized to service
  • 5Bank-side service suspensionThe customer's bank has suspended one or more card services — online payments, CNP authorization, or recurring billing — either as a security measure, account condition enforcement, or regulatory compliance action

What NOT to Do

Common mistakes that make it worse.

Don't retry the same card — this is a permanent service-level block

service_not_allowed is not a timing issue, not a temporary restriction, and not something a retry will ever resolve. The bank has disabled the specific service class your transaction falls under on this card — retrying 3 days later, 7 days later, or any time later produces the exact same decline. Zero retries, zero exceptions.

Don't ask the customer to "contact their bank to authorize the payment"

Unlike security_violation or do_not_honor where a bank call can lift a temporary hold, service_not_allowed is frequently a hard product-level restriction that bank customer support cannot override at the cardholder's request — it's baked into the card product policy, not the individual account settings. Routing customers down this path wastes their time and erodes trust without producing a resolution.

Don't send a generic "update your credit card" email

If the customer is using a basic debit card, prepaid card, or regional card product that triggered service_not_allowed, asking them to "update their credit card" will likely result in them entering the exact same card type again — generating another service_not_allowed failure. Your email must specifically explain that this card type doesn't support subscription billing and guide them to a payment method that does.

Retry Timing

Optimal retry schedule.

Zero retries. The entire recovery path for service_not_allowed is a payment method replacement sequence — not a retry schedule.

Recovery Benchmark

What good looks like.

MetricResult
Overall recovery rate20–35%
Recovery via alternate payment method (tailored email)30–45% of customers who engage
Recovery via generic card update email5–10%
Recovery with BIN-targeted email + specific alternate CTAs+20–25% lift over generic
Recovery with blind retries~0%
Prevention via BIN check at checkoutEliminates 60–70% of occurrences

A 30–35% overall recovery rate is achievable with BIN-targeted email copy and a payment update page that prominently features non-card alternatives. The real win, however, is on the prevention side — teams that implement BIN-based card compatibility checks at checkout reduce service_not_allowed failures by 60–70%, making post-failure recovery largely irrelevant for this code.

At Scale

How to handle it at scale.

Automated

  • Webhook trigger: invoice.payment_failed → check failure_code === 'service_not_allowed' → immediately run BIN lookup on the failed card → classify card type before any downstream action
  • Zero retries hard-coded: Add service_not_allowed to your no-retry blocklist — alongside restricted_card, lost_card, stolen_card — at the automation layer
  • Segmented email by BIN classification:
  • Prepaid card → "Prepaid cards can't be used for subscription billing — here's how to switch to a bank account or credit card"
  • Regional debit (India/SEA/LATAM) → prominently feature UPI, GrabPay, Boleto, or local bank transfer with step-by-step instructions
  • CNP-restricted debit → "Your card is set up for in-person purchases only — here's how to add a card or bank account that works online"
  • Corporate card → offer ACH, wire transfer, or Stripe Invoices as the primary solution
  • Checkout BIN detection (preventive): Implement BIN API lookup at card entry in your checkout — flag incompatible card types in real time with a non-alarming inline message before the customer completes signup; this is the highest-ROI engineering investment for this specific decline code
  • Payment page optimization: Ensure PayPal, bank transfer, UPI, and local payment methods are first-class options on your payment update page — not secondary footnotes; for service_not_allowed customers, these are the primary conversion path
  • Recurring decline cohort tag: Tag all service_not_allowed customers in your CRM as "card-incompatible" — track whether they switch to an alternate method or churn; this data reveals product gaps in your payment method coverage by region

Manual Escalation

  • High-ACV B2B accounts with service blocks: Offer Stripe Invoices, ACH transfer, or direct wire billing as an enterprise-grade alternative — many corporate accounts with service_not_allowed cards simply need a formal invoicing flow rather than an online card payment
  • International customers in underserved markets: Personal outreach for high-value international customers whose regional card triggered service_not_allowed — walk them through adding a local payment method (UPI for India, Boleto for Brazil, GrabPay for SEA) one-on-one; this high-touch approach converts 30–40% of accounts that drop off in automated flows
  • Product-level: recurring service_not_allowed by geography: If you see clustering by country or card BIN — e.g., a spike of service_not_allowed from Indian RuPay debit cardholders — this is a structural product signal: add UPI as a native checkout option; one payment method addition eliminates the entire failure cohort for that region

FAQs

Frequently asked questions.

What does the Stripe service_not_allowed decline code mean?

service_not_allowed means the issuing bank has disabled the specific service type or transaction class — such as subscription billing, online payments, or cross-border transactions — for this card. The card may be active and funded, but the bank's product policy does not permit it to be used for this type of charge. It is a structural decline, not a temporary block.

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

Common causes include the bank disabling recurring or subscription billing on prepaid, student, or basic debit cards, online and card-not-present transactions being blocked on the card, cross-border or international transaction restrictions on domestic-only card products, card product type limitations on payroll or government-issued cards, and bank-side suspension of specific card services for compliance reasons.

Should I retry a payment after a Stripe service_not_allowed decline?

Never. service_not_allowed is a permanent service-level block — no retry interval will change the outcome. Add it to your no-retry blocklist immediately and focus all recovery effort on getting the customer to switch to a compatible payment method such as a credit card, bank transfer, PayPal, or a local payment method like UPI.

How do I prevent service_not_allowed failures before they happen?

Implement a BIN API lookup at card entry in your checkout to identify incompatible card types — prepaid, debit-only, or CNP-restricted — in real time before the customer completes signup. Displaying a gentle inline warning at this stage eliminates 60–70% of service_not_allowed failures before they reach your billing system.

What is the recovery rate for Stripe service_not_allowed failures?

Overall recovery rates are 20–35%. With BIN-targeted email copy and a payment update page featuring prominent non-card alternatives, 30–45% of engaged customers switch to a compatible payment method. Generic card update emails without alternate method CTAs recover only 5–10%. The highest-ROI strategy is checkout-level BIN detection that prevents the failure entirely.

Before you retry

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

See what service_not_allowed costs me →

Stop leaving revenue on the table

service_not_allowed 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.