Free tool
How close is each card to Visa's 15 attempt ceiling?
Visa's rules cap reattempts of a failed payment at 15 per card per rolling 30 days, and Stripe blocks further attempts once you cross it. Stripe's retries and any third-party tool's retries draw down the same budget, and neither system can see the other's count.
Paste one attempt per line and this returns the peak number of attempts against each card in any 30 day window, which is the number the rule is actually measured on.
Do not paste card numbers. This page does not want them and will refuse to run on them. Use Stripe's card fingerprint, the payment method id, or any label of your own that is the same for one card and different for another. If a line's identifier looks like a card number, the whole run stops and nothing is calculated.
Nothing you paste leaves your browser. There is no fetch, no XMLHttpRequest, no form action and no analytics anywhere in this page. The only request it makes to anywhere is for the two web fonts the rest of the site uses. View the source before you paste and check for yourself, rather than taking the sentence above on trust.
Paste your attempts
One attempt per line, as card-identifier, YYYY-MM-DD. Every failed attempt counts, whichever system made it. Lines starting with # are ignored.
What the three numbers mean
The count that matters is not attempts this calendar month. It is the highest number of attempts that ever sat inside a single 30 day window, because the window rolls and does not reset on the 1st.
| Number | Value | What it is |
|---|---|---|
| Cap | 15 | Reattempts of one payment allowed per card in 30 calendar days. Past it, Stripe blocks the attempt before it reaches the issuer. |
| Window | 30 days | Rolling, not calendar. An attempt stops counting 30 days after it happened, not on the 1st of the month. |
| Reporting floor | 10 | Cards below this are not listed. It is the same floor RecoverFlow's own audit uses, so this page and the product cannot give you different answers. |
Those three constants are read from the same service that builds the retry waste audit inside RecoverFlow, RetryWasteAuditService. If one changes, both change together.
Where the rule comes from
The full picture, including what a blocked attempt looks like in the Stripe API and the group of declines where the budget is zero rather than fifteen, is in the guide: the Visa excessive reattempts rule. Every figure there is sourced to Visa or to Stripe's own documentation, so this tool does not restate them second hand.
The short version worth carrying around: Stripe's recommended Smart Retries default of 8 tries within 2 weeks sits at roughly half the network ceiling. That leaves room for a second system to retry on top. It does not leave much.
What counts as an attempt
Every charge that actually reached the card network against that card, including the ones you did not schedule. Stripe's own Smart Retries, a third-party recovery tool, a manual retry from the Dashboard, and the customer clicking pay on the hosted invoice page all draw down the same budget.
Scheduled retries that never executed do not count, because nothing was attempted. That distinction matters more than it sounds: on the nine decline codes Stripe will not retry, the invoice keeps incrementing attempt_count while no charge is created. Those are in the published decline code dataset and in the decline code reference.
Want this counted from your real Stripe history?
RecoverFlow's retry waste audit runs the same calculation over your last 90 days of failed invoices, using the card fingerprint Stripe already gives it, so nothing has to be pasted anywhere. It also splits your failures into the ones a retry can reach and the ones it cannot.
If the answer is that Stripe's free settings already cover you, that is what it will say.
See what the free audit coversCommon questions
What is the Visa retry budget?
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, it is usually described as 15 reattempts per card per rolling 30 days. Stripe enforces it by blocking further retry attempts once you pass the 15th.
Why does this ask for a fingerprint instead of a card number?
The budget is counted per card, so the tool only needs something that is stable per card and different between cards. Stripe's card fingerprint does that, and so does any opaque label of your own. Card numbers are not wanted here and the page refuses to run on anything that looks like one.
Does anything I paste get uploaded?
No. There is no fetch, no XMLHttpRequest, no form action and no analytics anywhere on this page, and the only external request it makes is for the site's two web fonts. You can confirm all of that from view-source before you paste anything, which is the only kind of privacy promise worth making.
Why does the tool only report cards at 10 attempts or more?
Because that is the same reporting floor RecoverFlow's own retry waste audit uses. A card at three attempts in a month is not close to anything and listing it buries the cards that are. The cap of 15, the window of 30 days and the floor of 10 are the same three constants in both places.
Related
- The Visa excessive reattempts rule, the sourced explanation of the cap and what Stripe does at it.
- Retry waste calculator, for how much of your failed revenue sits on cards no retry can collect.
- All five other free tools, none of which need a signup.
Recover