How to Find and Size Failed Payments in Stripe (Step-by-Step)

Why "How Many Payments Failed?" Is Harder Than It Looks

Every SaaS founder on Stripe eventually asks the same question: how much money am I actually losing to failed payments?

Stripe has the data. The problem is that the obvious places to look give you the wrong number:

• The Payments list shows every attempt. One card that fails four times across Smart Retries shows up as four failed payments — so the total overstates your problem.
• The Revenue recovery overview only covers recurring subscription payments and excludes the first invoice payment following a trial — so it can understate it.
• Neither view tells you directly how much MRR is sitting in past_due subscriptions right now, which is the number that matters for planning.

Stripe's own docs acknowledge the first issue: to get a clear picture, you should "analyze unique declines and exclude failed retries from your analysis".

This guide walks through the manual process to get a trustworthy number in about an hour. At the end, there's a shortcut if you'd rather not do it by hand.

What You're Actually Trying to Measure

Before touching the Dashboard, be clear about the four numbers you want:

| Metric | What it answers | Where it comes from | |---|---|---| | Unique failed payments | How many invoices failed (not how many attempts)? | Payments export, deduplicated | | Failed volume | How much money those invoices represent | Sum of unique failed amounts | | MRR at risk | How much recurring revenue is in subscriptions that are currently behind | past_due subscriptions, normalized to monthly | | Failure mix | Why payments fail (decline codes) | Decline reason per unique failure |

The first two tell you the size of the leak. The third tells you what's still recoverable today. The fourth tells you what to do about it.

Step 1: Pull Failed Payments from the Dashboard

In your Stripe Dashboard, open the Payments / Transactions page.

1. Click Filters and set a date range. Use the last 30 days for an operational snapshot, or 90 days for a more stable picture.
2. Filter by Status. Uncheck the default statuses and select Failed.
3. Review the list. Hovering over the status shows the failure reason, and opening a payment shows the full decline detail and Stripe's advice.

For a quick gut check, the list count is fine. For anything you'll base decisions on, export it.

Step 2: Export to CSV (With All Columns)

With the failed filter applied, click Export. Choose your time zone and date range, and select all columns rather than the default set. As Gravy Solutions points out, the default columns leave out much of what you need to understand why payments are failing.

The columns you care about:

• Amount and Currency
• Customer (ID and email)
• Invoice (if present in your export)
• Decline reason / failure message
• Card brand, card funding (credit/debit/prepaid), card country
• Card expiration month/year — useful for spotting expired cards
• Created date

Step 3: Remove Retry Duplicates

This is the step most people skip — and the reason their failed payment number looks alarming.

With Smart Retries on, Stripe retries a failed subscription payment multiple times over your configured window. Each attempt is a separate failed payment in the export. You want one row per invoice.

If your export includes the invoice ID:

1. Sort by invoice ID, then by created date.
2. Keep one row per invoice. Keep the latest attempt if you want the most recent decline reason, or the first attempt if you want the original cause.
3. Check whether that invoice was eventually paid (a later successful payment for the same invoice means it was recovered).

If it doesn't: Use customer + amount within a short window as the duplicate key. It's less precise — a customer with two subscriptions at the same price will collapse into one row — but it's close enough for sizing.

After deduplication, you'll typically find the number of unique failures is a fraction of the raw row count. That smaller number is your real problem.

Step 4: Split Recovered from Still-Failing

Not every unique failure is lost revenue. Some were recovered by a later retry or because the customer updated their card.

For each unique invoice, mark it as:

• Recovered — a later payment on the same invoice succeeded
• In recovery — still within your retry window
• Lost — retries exhausted, invoice still unpaid (or the subscription was canceled)

This split tells you how well your current setup performs. If most failures end up recovered, your retry and email settings are working. If most end up lost, there's money on the table — see how Stripe's recovery rate compares to benchmarks.

Step 5: Find Past-Due Subscriptions (Your MRR at Risk)

The payments export tells you about the past. For what's recoverable right now, go to the subscriptions list.

1. Open Subscriptions in the Dashboard.
2. Filter by status Past due. If you've configured failed payments to end in unpaid, check that status too.
3. Export the list.

Per Stripe's subscription docs, past_due means payment on the latest finalized invoice failed or wasn't attempted. The subscription still exists and keeps creating invoices, and paying the latest invoice returns it to active. That's what makes these customers recoverable: they haven't left, their payment just isn't going through.

unpaid subscriptions are still in place, but Stripe no longer attempts payment. canceled is terminal. Once a subscription is canceled, the customer has to subscribe again with new payment details. If you're not sure which ending your account uses, read past_due vs. unpaid vs. canceled.

Calculating MRR at risk

For each past-due subscription, normalize the price to monthly:

| Billing interval | Monthly value | |---|---| | Monthly | price × quantity | | Yearly | (price × quantity) ÷ 12 | | Weekly | (price × quantity) × 52 ÷ 12 | | Quarterly (every 3 months) | (price × quantity) ÷ 3 |

Sum the column. That's your MRR at risk: recurring revenue you'll lose if these customers never fix their payment.

Step 6: Group by Decline Code

Now pivot your deduplicated failures by decline reason. This is where the numbers become actionable, because each reason calls for a different response.

| Decline reason | What it usually means | Best response | |---|---|---| | insufficient_funds | Temporary lack of funds | Retry near paydays + a friendly email | | expired_card | Card on file is out of date | Customer must update the card — retries won't help | | do_not_honor / generic_decline | Issuer declined without a reason | Space out retries, ask the customer to contact their bank if it persists | | authentication_required | Bank wants 3D Secure | Customer needs to complete authentication on-session | | lost_card / stolen_card | Card is blocked | New card required — don't retry |

The underlying split is soft vs. hard declines. Soft declines (like insufficient funds) can succeed on a later retry. Hard declines (expired, lost, stolen) never will, however many times you retry. For those, the customer has to act, which means sending an email with a card update link.

If hard declines make up a large share of your failures, better retry settings won't fix it. You need better customer communication.

Two more cuts worth making

• By card brand and country. A concentration in one issuing country or card type (prepaid, for example) often explains an unusually high failure rate.
• By card expiration. Count how many active customers have cards expiring in the next 60 days. That's next month's expired_card problem, and you can see it coming. More on this in credit card expiration churn.

Step 7: Put It Together

You should now have a one-page summary:

Last 30 days
  Unique failed invoices:     42        (raw failed attempts: 118)
  Failed volume:              $3,860
  Recovered so far:           $1,720    (45%)
  Still at risk:              $2,140

Right now
  Past-due subscriptions:     19
  MRR at risk:                $1,310

Top failure reasons
  insufficient_funds          38%
  expired_card                24%
  do_not_honor                17%

(Illustrative numbers. Yours will differ.)

This is enough to decide whether failed payments deserve attention. To estimate what closing the gap is worth over a year, plug your numbers into the ROI calculator. For context on what your numbers mean for the business, see the true cost of failed payments.

Why Not Just Use Stripe's Revenue Recovery Page?

Stripe's revenue recovery overview is a good starting point. It shows failed payments, failure rate, recovered volume, recovery rate, a breakdown by recovery method (retries, emails, other), the top five decline codes, and the customers currently in recovery.

It has gaps, though:

• It covers recurring subscription payments only and leaves out the first payment after a trial, which is exactly where many failures happen.
• It shows the top five decline codes, not the full mix.
• It doesn't turn past_due subscriptions into an MRR at risk figure.
• There's no card brand or country breakdown, and no playbook for what to do next.

We cover these gaps in detail in what Stripe's recovery analytics doesn't tell you.

The Shortcut: A Free Audit in About 3 Minutes

Everything above is doable by hand. It just takes an hour of exporting, deduplicating and pivoting, and you have to redo it every time you want a fresh number.

The free Rechurn audit does the same analysis automatically:

• No account needed. You provide an email and a restricted, read-only Stripe key (or upload a Stripe CSV export, or connect via OAuth).
• The key is checked to be read-only before anything is read, and discarded after the report is generated.
• The report covers MRR at risk from past-due subscriptions, failed payment volume over the last 30 days, recoverable subscriptions, a failure reasons breakdown by decline code, retry pattern analysis, a card brand and country breakdown, an estimated recovery range, and a playbook for your top failure reason.
• Everything is exportable to CSV. There's no paywall.

If the numbers show a real leak, Rechurn can run the recovery for you: a 6-email, decline-aware sequence over 14 days, with one-click card updates through the Stripe Billing Portal. You pay 15% of what those emails recover and no fixed fee. Stripe's own retries are never billed. If the numbers are small, you've lost three minutes and gained a baseline.

For a comparison with other free audits (Churnkey, Churnbot and others), see free Stripe churn audit tools compared.

Key Takeaways

1. Raw failed payment counts overstate the problem. Smart Retries creates one failed row per attempt, so deduplicate by invoice before you count anything
2. Stripe's recovery overview can understate it. It covers recurring payments only and excludes the first payment after a trial
3. MRR at risk comes from past_due subscriptions, not from the payments list. Normalize every interval to monthly and sum
4. Group failures by decline code. Soft declines respond to retries; hard declines need the customer to update their card
5. Split recovered, in-recovery and lost to see whether your current setup works
6. Card brand, country and expiration dates often explain unusual failure rates, and expirations can be predicted
7. If you'd rather not do it by hand, the free audit produces the same numbers from a read-only key in about 3 minutes