RecoverGuide
The Visa excessive reattempts rule: 15 tries per card, per 30 days
Last updated 16 August 2026 · written by Bruce McGinley, who builds RecoverFlow
Visa's rules broadly prohibit more than 15 retries of a single payment over 30 calendar days. Because a subscription's retries all land on the same card for the same invoice, that is usually described as a budget of 15 reattempts per card per rolling 30 days.
Stripe enforces it. After the 15th retry attempt on a Visa transaction, Stripe automatically blocks subsequent retry attempts where it determines there is a low chance of a successful authorization.
For one group of declines the budget is not 15. It is zero, and the first reattempt is already one too many.
On this page
The rule, in the fewest words possible
| The limit | What it is | Where it comes from |
|---|---|---|
| Reattempts of one failed payment | No more than 15 in 30 calendar days | Visa's rules, quoted directly by Stripe |
| Reattempts after a Category 1 response | None, using the same account information | Visa's authorization response code categories |
| What Stripe does at the limit | Blocks subsequent retry attempts after the 15th on a Visa transaction, where it judges a low chance of authorization | Stripe support documentation |
| How a blocked attempt looks in the API | outcome.type of blocked, outcome.reason of previously_declined_do_not_retry, surfaced to you as card_declined with generic_decline | Stripe support documentation |
| Stripe Smart Retries recommended default | 8 tries within 2 weeks | Stripe Billing documentation |
Two things in that table are worth reading twice. The budget is counted over a rolling window, not a calendar month, so it does not reset on the 1st. And the last row is the interesting one: Stripe's own recommended default sits at roughly half the network ceiling, which is not an accident.
When it started, since the date is reported wrong constantly
The rule takes effect 17 April 2021. That date is in Visa's own bulletin, article AI10325, which says in its overview: "Effective 17 April 2021, Visa will update its rules for declined transaction resubmission and the use of authorization response codes." The same document is where the 15-in-30 figure comes from, in the passage moving four response codes into Category 2 "to allow merchants to reattempt up to 15 times in 30 days".
April 2022 is widely repeated as the start date and it refers to something else: a later phase of the associated fee schedule, not the reattempt cap. If you are reconciling a statement line, the fee timeline and the rule timeline are two different things.
What Stripe does when you cross it
You do not get a warning email. The attempt simply stops being an attempt.
Stripe's own description is that after the 15th retry attempt on a Visa transaction, it will automatically block subsequent retry attempts if it determines there is a low chance of a successful authorization for the given charge. The charge that comes back is not an issuer decline. It never reached the issuer. In the API it carries an outcome.type of blocked and an outcome.reason of previously_declined_do_not_retry, while the error your code sees is the ordinary card_declined with a decline_code of generic_decline.
Why this matters for your reporting: a blocked attempt shows up in your failed payments as generic_decline, which is the least informative code Stripe has. If you are counting decline codes to decide what to do next, budget exhaustion hides inside your generic_decline bucket wearing a disguise. Check outcome.reason on the charge, not just the decline code.
Stripe describes a related behaviour on its declines page for accounts on interchange plus pricing, where Adaptive Acceptance blocks certain payments to help avoid unnecessary network costs, giving an outcome.reason of low_probability_of_authorization and an advice_code of do_not_try_again. Different mechanism, same lesson: an attempt that the network would rather you did not send can be stopped before it is sent.
The declines where the budget is zero, not fifteen
Visa sorts its authorization response codes into categories. Category 1 is defined as the issuer will never approve, and a transaction that receives one should not be resubmitted using the same account information. Categories 2 and 3 are the ones the 15 in 30 days allowance applies to.
Category 1 is where the account is gone rather than temporarily unable to pay: a card reported lost, a card reported stolen, a closed account, an account that does not exist. In Stripe's vocabulary those arrive as codes like lost_card, stolen_card, pickup_card, incorrect_number and invalid_account.
So the arithmetic changes shape. On an ordinary soft decline you have a budget of 15 and Stripe's default spends 8 of it. On a Category 1 response you have a budget of zero, and the very first reattempt is already excessive. Nothing about the retry configuration in your Dashboard knows the difference.
This is the same population as the nine codes Stripe will not execute a retry for, but the two lists are not identical and they exist for different reasons, which is the next section.
Why Stripe's default is 8 and not 15
Smart Retries recommends 8 tries within 2 weeks. The network allows 15 over 30 days. Stripe is deliberately leaving room.
Part of that is the budget itself. Attempts are not free actions, and a schedule that spends the whole allowance leaves nothing for a manual retry, a customer-triggered payment from the hosted invoice page, or the attempt that follows once a new card is finally added. Part of it is that issuers watch attempt frequency: a card being hammered looks less like a subscription renewal and more like someone testing a stolen number, and the sensible issuer response to that is to decline more.
The practical read: 8 within 2 weeks is not a timid default you should raise to look thorough. It is a schedule that finishes with headroom, on purpose.
Two separate limits people keep merging into one
This is the point almost every article on failed payments gets wrong, and it is worth being pedantic about because the two limits behave completely differently.
| The nine code suppression | The reattempt budget | |
|---|---|---|
| Who imposes it | Stripe | Visa |
| What it limits | Whether a scheduled retry is executed at all | How many executed attempts one payment may have |
| Does the attempt reach the issuer | No, and no Charge is created | Yes, until the budget runs out |
| What clears it | Attaching a new payment method | Time, as the rolling 30 day window moves |
| What you see | attempt_count climbing with nothing happening | A blocked charge reported as generic_decline |
They are independent. An invoice can sit well inside its 15 and still be going nowhere because it is on one of the nine. Another can be clear of all nine and still be blocked because the budget is spent. Fixing one tells you nothing about the other.
The reason this gets expensive is that the two systems retrying your invoices cannot see each other's counters. Stripe's Smart Retries draw down the budget. A third-party recovery tool retrying on top of Stripe draws down the same budget. Your own manual retry from the Dashboard draws down the same budget. Nobody is keeping a running total on your behalf unless something is built to do it.
How to see where you stand
There is no dashboard number for this, which is the whole problem. You can get close from the API.
- On the invoice,
attempt_countis the number of payment attempts from the perspective of the retry schedule. Stripe documents that it keeps incrementing even when a hard decline means the retry does not execute, so it is an upper bound on real network attempts rather than a count of them. - On each failed charge,
outcome.network_statustells you whether the attempt actually went out.declined_by_networkmeans it did.not_sent_to_networkmeans it did not, and that one did not cost you budget. outcome.reasonofpreviously_declined_do_not_retryis the marker that you have already crossed the line on that card.
Count attempts per card rather than per invoice. A customer whose renewal failed in June and again in July is one card carrying two invoices worth of attempts inside the same rolling window, and the window does not care which invoice they belonged to.
If you want the money version of this rather than the count version, the retry waste calculator takes your decline code counts and returns what share of your failed revenue is sitting on cards that no attempt can collect from. It runs in the browser and uploads nothing.
Questions people actually ask
How many times can you retry a failed Visa payment?
Visa's rules broadly prohibit more than 15 retries of a single payment over 30 calendar days, and Stripe quotes that figure directly. In a subscription those retries all land on the same card for the same invoice, which is why the rule is usually described as 15 per card per 30 days. The window is rolling, so it does not reset at the start of a month.
What happens after the 15th retry?
Stripe automatically blocks subsequent retry attempts on a Visa transaction where it determines there is a low chance of a successful authorization. The attempt never reaches the issuer. In the API the charge carries an outcome type of blocked with a reason of previously_declined_do_not_retry, and it surfaces to your code as card_declined with a decline_code of generic_decline.
Do Stripe's own Smart Retries count towards the 15?
Every executed attempt on the card counts, whoever sent it. Stripe's scheduled retries, a manual retry you click in the Dashboard, and a third-party recovery tool's retries all draw on the same budget, and none of those systems can see the others' counters. That is why Stripe's recommended default of 8 tries in 2 weeks leaves room rather than filling the allowance.
Are there declines where even one retry is too many?
Yes. Visa's Category 1 responses mean the issuer will never approve, and the transaction should not be resubmitted using the same account information. A card reported lost, a card reported stolen, a closed account and an account that never existed all sit in that group. The permitted number of reattempts there is zero, not 15.
Is this the same thing as the nine codes Stripe will not retry?
No, and conflating them is the most common mistake in this area. The nine codes are a Stripe-side suppression: Stripe keeps the schedule running but does not send the charge until a new payment method exists. The reattempt rule is a network-side budget on attempts that do get sent. A payment can be well inside its 15 and still blocked by the nine, or clear of the nine and out of budget.
Where this came from
Checked against primary sources on 4 August 2026. If Stripe changes something and this page has not caught up, tell us and it gets fixed.
- Stripe Support: Payment blocked due to excessive retries — the source for the 15 in 30 calendar days figure, for what Stripe does after the 15th attempt, and for the blocked outcome fields.
- Visa: Updates to rules for declined transaction resubmission and use of authorization response codes — Visa's own document behind the reattempt rule and the response code categories.
- CardPointe: Visa decline rules and responses — a processor's published summary of Visa's four response code categories, used here for the Category 1 definition and nothing else.
- Stripe: Smart Retries — the source for the 8 tries in 2 weeks default, the configurable window, and the nine code list.
- Stripe: Declines
If you would rather not build this yourself
RecoverFlow watches your Stripe account for failed subscription payments, stops retrying the ones that cannot succeed, and emails the customers whose card simply needs replacing. It charges 25% of what it can attribute to a specific action it took, with a $29 monthly floor and a $299 monthly ceiling, and the floor is waived for the first 30 days.
Before any of that, you can find out whether it is worth doing at all. Answer three questions in a reply and I will send back what your failed payments are probably costing you, how much of it is genuinely recoverable, and whether Stripe's own free features already handle it. No Stripe connection, no account, no card.
It is early. It is run by one person. If Stripe's own free retry settings are enough for you, use those instead, and the pricing page says exactly when that is the right call.
Get the free audit