Transaction Not Permitted: What This Decline Code Means and How to Actually Fix It

Transaction not permitted means the customer's bank allows the card to exist but not to do this. The card is active, the money might be there, and the charge still fails because this specific type of transaction is switched off at the card level. It is one of the most misunderstood decline codes in Stripe, and one of the most common on subscription renewals.

If you run a subscription business, this code deserves your attention for a simple reason: it almost never fixes itself, and retrying the same charge is a waste of a retry. But the recovery rate is high once the customer takes one specific action. This post is the playbook.

What the bank is actually saying

Most decline codes describe a state: no money, expired card, suspected fraud. Transaction not permitted describes a rule. The issuer has a policy attached to that card, and your charge violates it. The card is fine. The transaction type is not.

Stripe surfaces it as transaction_not_permitted. Older card-present systems show it as code 57 (transaction not permitted to cardholder) or code 58 (not permitted to terminal). Same idea, different plumbing: the card network passed your request through, the issuer checked its rules, and the rules said no.

The 6 blocks behind this code

Issuers do not publish their rulebooks, but after enough of these you see the same six causes over and over:

• •Online transactions disabled. Plenty of debit cards, especially outside the US, ship with e-commerce switched off by default. The card works at an ATM and a supermarket, fails on your checkout page.
• •Recurring charges not enabled. The card allows one-off online purchases but not merchant-initiated subscription charges. This is the classic renewal killer.
• •International charges blocked. The card is domestic-only and you are charging across a border, even if your customer does not think of you as foreign.
• •Merchant category restrictions. Corporate cards are often limited to approved spending categories. If your MCC is not on the list, every charge bounces.
• •Prepaid and gift cards. Many do not support recurring billing or address verification at all.
• •Special-purpose cards. HSA, FSA, and similar cards only work at merchants in their designated category by law.

Notice what is missing from that list: insufficient funds. That is a different code entirely. Your customer can have a healthy balance and still hit this wall, which is why telling them to add money does nothing.

Why it shows up at renewal, not signup

Here is the pattern that confuses every founder the first time: the customer's first payment went through cleanly, sometimes with 3D Secure, and then month two or three fails with transaction not permitted. Same card, same customer, same amount.

The first charge was customer-initiated. The cardholder was present, typed the numbers, maybe completed an authentication challenge. The renewal is merchant-initiated, and issuers treat those as a separate transaction class with separate permissions. A card can be allowed to buy things online while simultaneously not being allowed to be charged by a merchant on a schedule.

India is the extreme example: RBI rules require explicit mandates for recurring card charges, and renewals above certain amounts need per-transaction approval. But the same mechanic exists in quieter form at banks everywhere. If your subscriber count grows internationally, expect this code to grow with it.

Why retries barely work here

With a soft decline like do_not_honor, patient retries are your best friend. With transaction not permitted, the bank's rule does not care what day it is. Retry on day 1, day 3, day 7, and you get the same answer, because nothing about the card's permissions changed between attempts.

There is also a cost to stubbornness. Card networks cap total retry attempts, roughly 15 in 30 days for Visa and about 35 for Mastercard, and issuers notice merchants who hammer blocked charges. Save your retries for the decline codes where timing actually changes the outcome.

The recovery playbook that works

This decline recovers through the customer, not through timing. That makes it an email problem, and the email has one job: get the cardholder to say a specific sentence to their bank.

• •Email within hours, not days. Unlike soft declines, waiting buys you nothing here.
• •Name the real cause in plain words: your bank is blocking this type of charge, not declining for funds.
• •Give them the exact sentence to say to their bank: please enable online and recurring transactions on my card.
• •Offer the alternate path in the same email: a link to update to a different card if the first one stays stubborn.
• •Retry once, immediately, when they confirm the bank lifted the block. That retry usually succeeds.

That last point is where most recovery flows leak money. The customer calls their bank, the block lifts, and then nobody charges them for five more days because the retry schedule was designed for soft declines. When the fix is a permissions change, the retry should fire as soon as the customer replies.

And if they go quiet? Follow up twice, then switch the ask. The final email in the sequence should drop the bank errand entirely and lead with the alternate card link. Some customers will never call their bank about a subscription charge. Nearly all of them will type different card numbers if you make it easy enough.

How to find these in your own data

Open your Stripe dashboard, go to the payments list, and filter by failed status. Export or scan the decline codes and count the transaction_not_permitted rows, then look at the dates. What you are looking for is the gap between failure and recovery, and whether those customers ever came back at all. In most small SaaS accounts I have seen, this code is a top-three failure reason, and the customers either churn silently or sit in limbo for weeks because the recovery flow assumed a retry would save them.

Also watch where these customers live. If your subscriber base is spreading into Europe, India, or Latin America, expect the rate to climb. Card-level permission rules are far more common outside the US, where banks tend to ship cards with more restrictions switched on.

What this means for your dunning setup

If your recovery system treats every decline code identically, same retry cadence, same email timing, you are leaving recoverable revenue on the table. Transaction not permitted wants a fast email and a human-sounding nudge, because the customer has to do something and will not do it for a message that reads like a bank notification.

This is the philosophy behind how I built StayPaid. The mechanics are automated, detecting the failure, reading the decline code, timing the retry. But the message that goes to your customer sounds like you wrote it, because you approved it. A founder asking personally gets the bank call made. A no-reply robot gets archived.

"Transaction not permitted is not a payment problem. It is a permissions problem, and permissions only change when a human makes a phone call."

So check your Stripe dashboard this week. Filter your failed payments by decline code, find the transaction_not_permitted rows, and look at how long those customers sat untouched. Every one of them is a subscriber who probably still wants your product and just needs to say one sentence to their bank.