Failed Payment Calculator

Most subscription businesses lose 5–15% of every month's charges to failed first payment attempts — expired cards, insufficient funds, bank declines. Put in two numbers below and see what that likely means for your business, and what a dedicated recovery layer could win back. No email, no signup, nothing stored: the estimate is calculated on this page from published industry benchmarks, with every assumption shown.

Calculator not loading? Open the failed payment calculator directly.

How this estimate works

This is a planning estimate from published industry benchmarks, not a measurement of your account. Assumption 1 — first attempts: 5%–15% of monthly recurring charge value fails on the first attempt (published card-failure range 5%–18%, GoCardless; PYMNTS Intelligence puts the average share of sales lost to failed payments at ~9%). Assumption 2 — recovery with a dedicated recovery layer: 45%–60% of failed value, with decline-aware smart retries, automatic card updates, dunning messages and a hosted card-update page (PYMNTS: top performers recover ~60%). Assumption 3 — baseline recovery depends on your current setup: no recovery process 5%–15%; processor native retries only 25%–40%; dedicated recovery tool 45%–60%. Assumption 4 — if you already use a dedicated recovery tool, remaining headroom is modeled as 0%–5% of failed value.

The real number for your business comes from your own billing history: connect your platform and Swipe Again loads your last 90 days of failed payments automatically — actual failures, actual decline codes, actual dollars. Swipe Again is failed-payment recovery plus cancel deflection for subscription businesses at one flat $179/mo: no percentage of recovered revenue, no per-seat pricing. Works with Stripe, Recharge, Chargebee, Recurly, Paddle, Seal, Skio, Braintree and Shopify. Recover $179 in 30 days, guaranteed — or Swipe Again is free the next 30 days.

The formula, in full

Recovered revenue = failed payments × average payment amount × your recovery-rate assumption. Nothing else is in the model — no churn-lifetime multiplier, no compounding. If you plan at a 30–40% recovery rate and reality beats it, the surprise is a pleasant one; published analysis of Stripe's data puts retries alone at roughly 51% of failed payments recovered, and a dedicated system adds decline-specific handling and outreach on top of that.

Calculator questions

Where do I find my failed-payment count? In your billing platform: Stripe's Billing reports, or your subscription app's failed-charge reporting on Recharge, Chargebee, Recurly, and the rest. Count distinct failed subscriptions in a typical month, not total failed attempts — one subscriber can fail four times and is still one recovery.

What recovery rate should I assume? Start conservative. The assumption picker above models the published ranges by setup; if you are typing your own number, 30–40% is the planning range most businesses use before they have their own measured rate.

How to read your estimate

The calculator gives you three things, and it helps to keep them separate. The first is the size of the leak: how much of the charge value you try to collect each month does not come through on the first attempt. That is not money lost for good. It is money stuck, waiting on a better-timed attempt, a card update, or a reminder that gets opened. It is the pool that recovery work draws from.

The second output is the baseline: what your current setup likely recovers from that pool today. If you have no process, that baseline is low, because most failed payments do not fix themselves. If your processor already retries on its own, the baseline is higher, and the honest question changes — not whether retries help, but how much room is left above them.

The third output is the headroom: the difference between your baseline and what a dedicated recovery layer is modeled to recover. Plan around that line, and compare it against price. Swipe Again is a flat $179 a month, with no percentage of recovered revenue, so the test is simple: does the modeled headroom, even at the low end, clear $179 by a margin you care about? If it does not, the calculator has done you a service before you paid anything. If it does, replace the model with your own billing history. Use the monthly figure for budgeting; the annual figure is context only.

The assumptions, in plain terms

Every number above rests on four assumptions. For a wider look at the published figures behind them, see our roundup of failed payment statistics.

Assumption one: how often first attempts fail. The calculator models first-attempt failure at 5–15% of monthly charge value. The published range behind it is 5–18%: the GoCardless SaaS payments datasheet reports failure in that band, PYMNTS Intelligence puts the average share of sales lost to failed payments at around 9%, and 2026 subscription benchmarks put the median first-attempt failure rate at around 14%. Where you sit depends on your prices and how old the cards on file are.

Assumption two: what no process recovers. With no recovery process, the model uses 5–15%. Some balances clear on their own, some customers update a card unprompted, and some failures are one-day glitches. Nothing is working the rest, so most of the pool drains away and the subscription ends without the customer deciding to leave.

Assumption three: what processor-native retries recover. With processor-native retries only, the model uses 25–40%. The processor will try again, and that alone rescues a meaningful share. What it generally does not do is read the decline, time attempts around paydays, or pair retries with branded reminders and an easy card-update route.

Assumption four: what a dedicated layer recovers. With a dedicated recovery layer, the model uses 45–60%. That band is an attributed estimate range, not a promise. PYMNTS Intelligence reports top-performing subscription merchants recovering around 60% of failed payments, while Access PaySuite reports around 44% across mixed practices — which is why the model stays a range.

What the estimate leaves out

The model is deliberately narrow, and three exclusions matter. First, voluntary churn is out. A customer who weighs your product and decides to cancel is a different problem, with a different fix. Swipe Again also works that moment, with cancel deflection at the cancel click, but none of that value is in this estimate — which makes the calculator conservative for a business whose cancel flow is a bare confirm button.

Second, new-sale failures are out. The model starts with recurring charge value from existing subscribers; a first purchase or trial conversion that fails belongs to a different report.

Third, seasonality is out. Balances tighten and loosen across the year, and a single monthly average smooths that away; size the problem over a quarter, not a single week. The model also adds no lifetime multiplier for a saved subscriber and subtracts no cost for attempts — keeping both sides out is the fairest simple model.

From estimate to recovered revenue: the first 30 days

An estimate becomes useful when it is replaced by evidence. First, you connect your billing platform. That turns ranges into records: the system sees actual failed payments, actual decline codes, and actual amounts, instead of percentages applied to a number you typed.

Second comes the 90-day backfill. On connection, Swipe Again loads your last 90 days of failed payments automatically. Most businesses start with a backlog of subscribers who failed recently and may still be reachable, with a card that can be fixed or retried well. That backlog is usually where the first recovered dollars appear.

Third, live recovery takes over for new failures. Each payment is classified by decline code. Soft, timing-driven failures enter the smart retry schedule, which weaves into the gaps of Stripe's native schedule where Stripe is the processor, holding a combined cap of 15 attempts and a ceiling of 8 attempts from Swipe Again per failed payment. Insufficient-funds cases follow a payday ladder out to around day 25. Hard declines stop retrying and route straight to a card update. Branded dunning emails go out on day 1, day 3, and day 7, with SMS as a further nudge — a maximum of 3 messages, each carrying “Reply STOP to opt out.” By day 30 you have counts of payments recovered and written off, with dollars attached to each, to compare against the range you started from.

More questions

How accurate is this estimate?

It is a planning estimate, accurate as a range and not as a prediction. It can tell you whether failed payments are a rounding error or a line worth paying to fix. It cannot tell you what you will recover next month, because that depends on your decline mix and current setup. The accurate version only exists in your billing history, which is why connecting and backfilling 90 days is the real measurement step.

What counts as a failed payment?

A failed payment is a charge your billing platform attempted that the issuer did not approve — an expired card, insufficient funds, a closed or replaced account, a bank-side error, or a hard refusal. Count each subscriber's failed renewal once when you size the pool, even if it was attempted more than once. One person whose card fails four times is one subscription to save, not four.

Why a range instead of a single number?

Because the inputs genuinely vary, and a single number would pretend otherwise. Failure rates vary by business, recovery rates vary by setup and decline mix, and the published sources report bands rather than points. A range forces the right habit: act if the low end still justifies the work, and be pleasantly surprised — not dependent — if you land near the high end.

What if I already have native retries turned on?

Then your baseline is the processor-native band, 25–40%, and the question is headroom. A dedicated layer earns its place in three ways: it reads decline codes and gives each family a different schedule, it stops hard declines immediately and asks for a new card, and it adds your voice — branded emails on day 1, 3, and 7, limited SMS, and a hosted card-update page. If the remaining headroom does not clear the flat fee comfortably, keep your native setup and revisit when you grow.

Updated November 2026

Go deeper: Failed Payment Response Checklist: First 24 Hours walks through the part of the picture this page only touches.

Related: Failed Payment Statistics covers the neighbouring case in full.

Go deeper: SMS Payment Reminders walks through the part of the picture this page only touches.

Related reading: Payment Retry Software: Retries That Read the Decline — the full breakdown, with the numbers behind it.

One more piece of the same puzzle: Failed Payment Support Macros: 15 Ready Replies.

For the full picture, pair this with Failed Payment Log Template: Track Every Failure.

Go deeper: Payment Recovery ROI: Math, Method, Proof walks through the part of the picture this page only touches.