I found $2,840 in my Stripe
that I didn’t know was missing.
For two years, Stripe quietly fumbled one in five of my payments. No alert. No email. Just lost revenue. Here’s the simple machine I built to catch them all, and a few prompts you can use to start figuring out yours.
A small machine for every declined payment.
It opens four doors the customer can still walk through, then sends the easiest one. Here is who it’s for, what goes wrong without it, how it works under the hood, and what you get back.
Who failed payment recovery is for
Anyone selling online with Stripe, PayPal, or Shopify. Coaches, course creators, agencies, e-commerce. If you process more than 20 payments a month, this is leaking money for you right now.
What goes wrong without failed payment recovery
Cards expire. Banks block international charges. Networks time out. Stripe attempts, fails, sends a thin email, moves on. About 17% of all card payments fail on first attempt. Most of that money is yours to lose.
How the failed payment recovery automation works
The instant a customer’s card gets declined, the machine notices. It reaches out to that customer in three friendly ways at the same time: a warm email, a quick text, and a simple page where they can pay with a different card, PayPal, or Apple Pay in one tap.
What failed payment recovery gives back each month
Most of the lost sale. In my own business, 78% of failed payments now end up paid within 48 hours (vs. ~12% if you do nothing). The customer experience also improves, they get told what happened.
The problem failed payment recovery solves
I run a few different products. A membership, a couple of courses, one or two one-off offers. The cheapest is around $27 a month, the most expensive a few thousand a year. Money comes in, money goes out, life is good.
Then one Sunday a buyer emailed me. “Hey, your link didn’t work last night, can you resend it?” Just a normal customer-service line. I opened Stripe to find his charge so I could send him a new one.
While I was in there, I sorted by “Failed” out of curiosity. There were 23 declined payments in the last 30 days. Not one of them had triggered an alert on my side. Not one had been retried. Nobody on my team or in my inbox knew they had happened.
I added them up. The 23 failures came to $3,620 of would-be revenue. Some were $27 monthly renewals. One was a $497 program. One was a $1,997 mastermind seat. The only thing those 23 customers had received from me was Stripe’s default declined-card email, which most banks dump into the spam folder.
I sat there for ten minutes, just looking at the screen. For two years I had been losing more money to silent declined payments than I was paying in ad spend. Quietly. Without anyone telling me.
Proof point: Stripe’s own payment failure recovery guide breaks down the main reasons cards fail (network timeouts, insufficient funds, expired cards, bank fraud blocks). Across their network, 12-17% of card payments fail on first attempt. Most business owners never see the breakdown because nothing surfaces it.
Three decisions that turn declined payments back into paid ones
What worked wasn’t a clever tool. It was a clear way of thinking about failed payments. Three decisions, made in order. Together they recover most of the money. Skip any one and the system collapses back into manual chasing.
See every failure the second it happens
You cannot fix a leak you cannot see. Most business owners only learn a payment failed when the customer emails to complain, or when they spot it in next month’s payment summary, or never at all. The first decision is to set up something simple that quietly watches every payment in your business. The moment one fails, you know about it. No dashboards to open, no daily checking, no spreadsheets. It just works in the background and notices for you.
Offer a different door, not the same one again
If a customer’s card got declined once, retrying the same card a few minutes later usually fails again. That’s what most payment processors do by default, and it only recovers about 18% of payments. The second decision is to offer the customer a different way to pay. A fresh link, a PayPal option, an Apple Pay button. People who genuinely meant to buy will happily walk through one of them. You’re not chasing them, you’re just opening another door.
Close the loop in one place
The recovery isn’t done when the email goes out. It’s done when you know whether the payment came back. The third decision is to keep a simple record of everything: which payment failed, what the machine tried, who paid in the end, who didn’t. One single view. Now you can see what works, tweak what doesn’t, and never wonder if a customer slipped through the cracks. Most people skip this step and lose visibility of the leak all over again the next month.
Decision one gets the failure to the surface. Decision two gives the customer a way to finish what they started. Decision three turns the whole thing into a measured, improvable system, not a one-off fix.
The upside compounds. Once the machine exists, every product you launch from then on is automatically wrapped in it. The $27 renewal you would have lost, the $1,997 mastermind that almost ghosted, the new offer you haven’t built yet: all of them caught by the same machine, with no additional work.
How most owners handle it
- Find out from a customer complaint, days later
- Manually open Stripe, copy the email, write an apology
- Send the same Stripe link, hope the same card works
- Lose track of who paid and who silently disappeared
- Recovery rate: 10-18% on a good month
What this machine does
- Notices every failed payment instantly
- Sends a warm email, a friendly text, and a one-tap payment page in under 60 seconds
- Three easy ways to pay, not just the same card again
- Tracks every recovery so you always know what’s working
- Recovery rate: 78% within 48 hours
How I found the leak that failed payment recovery closes
Before building anything, I wanted to know the real number. Not a vague feeling. An actual dollar amount of silent losses I could justify against the time of building the machine. Here’s the prompt I used to dig it out of Stripe.
Find your silent payment leaks
I take online payments through [Stripe / Shopify / PayPal / other]. I want to figure out how much money my business is losing every month to customer payments that quietly failed without me knowing. Help me with three things: 1. The most common reasons a customer's payment fails (in plain English, no jargon). 2. Where in my payment account I can look to see every failed payment from the last 30 days. 3. A simple way to count how many failed and add up the total dollar value of those lost sales. Then estimate roughly how much of that money I could realistically get back if I set up a friendly automatic recovery system. Output as a short table I can paste into Notion. Specific numbers, no fluff.
I ran this prompt, dug into Stripe’s “Failed” filter, and got the $3,620 number in 15 minutes. Once you see your own version of that number, the case for building the machine makes itself. You can do the same calculation by hand in a spreadsheet. The prompt just shortcuts the part where you keep forgetting which Stripe filter to use.
How I wrote the recovery email
Stripe’s default decline email reads like a parking ticket from a robot. Half the recoveries come down to whether your email feels like it was written by a human who actually noticed what happened. This is the prompt I use to draft the recovery email for any product.
Recovery email that sounds like a human
Write me a friendly recovery email for a customer whose card just got declined at checkout. Tone rules: - Sound like a real human, not a billing department. - Don't blame them. Don't blame the bank. Just acknowledge it happened. - Offer them one other easy way to pay (PayPal, Apple Pay, or a fresh link). - Mention I've saved their order so they don't have to start over. - Soft urgency: "I'll hold your spot for 24 hours." - Sign off as a real person with my real first name, not "the team." Subject line: max 6 words, no caps, no exclamation marks. The product they were buying: [PRODUCT NAME, PRICE]. The customer's first name: [NAME]. Give me three subject line options and the full body. Under 90 words.
You can write this by hand. After the tenth one, you’ll start sounding like a template, which is exactly what you want to avoid. The prompt gives you a fresh draft every time, with the customer’s name and product baked in so the email feels personal even when 80 of them go out a week.
The 3-minute overview of how this works
Before we get into week 1 numbers, watch this short overview. It’s the exact video I use on the Automations Made Easy page itself, and it walks through the mechanics behind machines like the one in this case study. 1,000+ students have used these mechanics to save two hours a day, with zero coding.
Want to build machines like this in your business?
1,000+ students. Save 2 hours a day. No coding required. In Automations Made Easy, you’ll learn the simple skills to build little machines that do the boring work for you, including a recovery machine just like this one. Most students have theirs running by the end of week one.
Week 1: $2,840 caught in the net
I built the machine over a weekend. About nine hours from blank canvas to a clean test. Switched it on Sunday night and went to bed.
The first 30 days, the machine caught 18 failed payments. Of those, 14 ended up paid. Of the four that didn’t, two were stolen-card flags (good, I don’t want that money) and two were genuinely abandoned. The customer changed their mind, and no email on Earth is going to bring those back.
14 recovered payments × $203 average value = $2,840 back in my account
Cost of running the machine: basically nothing
Time I spent on each recovery: zero minutes, the machine handled it
Recovery rate vs leaving it to my payment processor: 4.3× higher
That number doesn’t disappear at the end of the month. The machine is still running today. Every product I launch from now on is automatically wrapped in it. That’s the part nobody talks about: build it once, and it keeps catching money forever.
I wrote a longer essay on the “build once, recover forever” approach in my Substack, including two other small machines that work the same way (abandoned cart, subscription churn) and how I keep them all running with a few hours a month.
How I designed the recovery page
The recovery email points the customer to a simple page made just for them. That page is what closes most of the sale. It needs to remind them what they were buying, reassure them that nothing was charged yet, and let them pay in one tap with whatever method they prefer. Here’s the prompt I used to draft the copy.
Recovery landing page copy
Write the copy for a simple page that my customer lands on after their payment didn't go through. I want it to feel personal and easy, not corporate. What the page needs: - A friendly headline confirming what they were buying. Not "Welcome back", something like "Let's finish your [Product] order." - A short reassurance that nothing was charged yet and their order is held. - A line telling them I'll hold their spot for 24 hours. - Three easy ways to pay: card, PayPal, Apple Pay. - One short quote from a happy customer for reassurance. - One small question and answer: "Why did my card fail?", keep it 2 sentences. Tone: warm, slightly playful, zero corporate. The product is: [PRODUCT NAME, PRICE]. Customer's first name: [NAME]. Output: full page copy, ready to paste anywhere I want to build the page.
The recovery page closes about 62% of the customers who land on it. That’s higher than my regular checkout page, which makes sense: by the time they click through, they’ve already decided. The page just has to make paying easy. You can build the page anywhere. The prompt just keeps the words fresh for each product instead of one stale page for everything.
How I measure whether failed payment recovery is working
Decision three from the playbook. Every recovery the machine handles gets noted down in one simple place, so I can see at a glance which payments came back and which didn’t. Without this, you slowly lose track and the leak comes back. With it, you can keep improving, try a softer subject line, send the text earlier, tweak the page, and watch the recovery rate climb.
The simple recovery tracker
Help me design a simple tracker for my failed-payment recovery system. For every payment that fails, I want one row that shows: - The customer's name and what they were buying - Why their payment didn't go through (in plain English) - Whether the recovery email got opened - Whether they clicked through and paid - How long it took them to come back and pay - How much I recovered this month so far Keep it dead simple. I just want one screen that tells me at a glance: which recoveries worked, which didn't, and how much money I caught this month. No fancy fields, no charts I won't use. Output the column list, then explain in two short paragraphs how I'd update each row as the recovery moves along.
Once this is set up, you can answer the only two questions that actually matter: “How much money did the machine save me this month?” and “What can I tweak to save even more next month?” Most people skip this step because it feels like overhead. It’s actually the part that lets you keep improving the machine instead of just running it.
How to build failed payment recovery, step by step
Set up the machine to listen for failed payments
First, I set up a little signal that fires the moment any payment in my business fails. One-time setup, completely free. From that moment on, the machine hears about every failed payment within seconds, including subscription renewals that fail quietly.
How the automation reads what just happened
Decision 1 from the playbook becomes real here. The machine instantly grabs what it needs from the failed payment: who the customer is, what they were buying, and why their payment didn’t go through. Now it has everything to write them a personal email and reach out.
Reach out to the customer three friendly ways
Decision 2 in action. The machine reaches out to the customer in three friendly ways at the same time. A warm email lands in their inbox right away. A short text message arrives on their phone a couple of hours later. And a simple personal page is ready and waiting for them with three easy ways to pay.
Give them the friendliest checkout they’ve ever seen
The page is the friendliest, most personal checkout your customer has ever seen. It greets them by name, reminds them what they were buying, and gives them three easy ways to pay. There’s also a soft countdown letting them know you’ll hold their spot for 24 hours. It loads in under half a second.
Keep score in one simple place
Decision 3 (close the loop). Every step gets quietly written down in one simple place. When the email went out, when the customer clicked, when they finally paid. You end up with one clean view that tells you exactly how much money the machine caught this month, without you having to do any math.
Close the loop when they finally pay
The moment the customer pays through one of the easier options, the machine knows. It marks the recovery as a win, makes sure their order goes through, and updates your tracker. You didn’t touch anything end to end. The customer never knew there was a problem.
A customer’s payment fails
It happens automatically, every business has this
The machine catches it instantly
Within seconds it knows who, what, and why
The customer hears from you in under a minute
A friendly email, a quick text, and a simple page to finish their order
They pay, you get notified, life moves on
The machine updates your tracker and fulfils the order without you lifting a finger
Want to build this in your own business?
Automations Made Easy teaches you, step by step, how to build little machines like the one you just read about. Zero coding. Plain English. 1,000+ students have already used it to save themselves hours every day and catch money they were losing without knowing.
Six months in: it kept catching money
Month 1 was $2,840 recovered on 18 failed payments. The interesting part is what happened after, because the volume of failures isn’t constant. New product launches, ad pushes, and price test windows all create payment-failure spikes. The machine catches them all at the same recovery rate, with no extra work from me.
Month 2: a launch spike. 31 failures, $4,520 recovered. Month 3: quiet month, 14 failures, $1,980 recovered. Month 4: a price test window pushed the average transaction up, 22 failures but $5,140 recovered. Month 5: $3,920. Month 6: $4,610.
Six months in, the machine had recovered $23,010 on payments that would have silently expired. Build cost: 9 hours of my time, once.
Monthly $ recovered · 6 months
Recovery rate stayed remarkably stable: 74-82% across all six months. That’s the part that surprised me. I assumed failures earlier in a product’s life would be easier to recover (fresh enthusiasm) and later ones harder (cooler interest). The data said no, the recovery rate is mostly about whether the email reads like a human within 60 seconds of the failure. Speed and tone, not enthusiasm.
What other students built with failed payment recovery
I teach the simple skills behind machines like this in Automations Made Easy. Students who built their own recovery machine sent back numbers from their first month.
“Built this exact machine over a weekend after Module 4. Caught $890 the first week. Honestly the easiest ROI I’ve ever pulled out of a course.”
“I didn’t think I had a payment problem. Set up the simple tracker, found 17 silent fails in 60 days. $2,200 recovered. That money was just sitting there.”
“I’m not technical at all. AME made the whole thing click for me. The recovery sequence is running on autopilot, I check it once a week.”
“The three pillars Martin teaches transfer to literally any business automation. I’ve now built six of these for different parts of my business.”
What’s inside Automations Made Easy
AME isn’t a library of pre-built automations like this one. Every business is slightly different, you might use Stripe, your friend uses Shopify, your client uses PayPal. What’s reusable across all of them is the underlying mechanics: how to notice events the second they happen, how to chain a few friendly steps together, how to design a page that closes the sale, and how to keep score so you keep getting better.
The program walks you through six modules: The Right Tools (the cost-effective, no-code stack I actually use), Task Selection Mastery (which automations are worth building first), Design Secrets (mapping an automation before you build it), Zero to Hero (complete beginner to confident automator), Real-World Application (we build a full automation together, end to end), and Monetization Mastery (turn the skill into a side-business).
It also includes done-for-you templates you import in two clicks, over-the-shoulder training videos, and the same playbook 1,000+ students have used to save two hours a day. No coding required. No technical background needed. If you can copy and paste, you can build this.
If you want a free taste of how I think about automation, my Growth Hacking playlist on YouTube walks through the full stack and the systems behind machines like this one.
Failed payment recovery: common questions
Pulled from what readers and Automations Made Easy students ask most.
What is failed payment recovery?
Failed payment recovery is a simple system that quietly reaches out to customers whose card got declined and offers them an easy way to finish paying, usually with a different card, PayPal, or Apple Pay. The best ones reach the customer within a minute of the failure, by both email and text, with one simple page that lets them pay in a single tap.
How much money do businesses lose to failed payments?
About 17% of card payments fail on the first try across all online businesses. In my own business I found 23 silent failures totalling $3,620 in a single 30-day window. For most businesses processing more than 20 payments a month, failed payments are quietly the biggest leak in the funnel, bigger than wasted ad spend in many cases.
Doesn’t my payment processor already retry failed payments for me?
Most payment processors do retry the failed card a few times over the next week. It helps a little, but it’s the same card and same bank that declined in the first place, so it usually fails again. That recovers about 18% of payments. Add a friendly email and text offering the customer a different way to pay, and you’ll catch 70-80% instead.
How do you recover failed payments automatically?
Three things in plain English. (1) Set up something that quietly watches your payments and notices the moment one fails. (2) Have it reach out to the customer in three friendly ways at the same time, a warm email, a short text a couple of hours later, and a simple personal page where they can pay with a different method in one tap. (3) Keep a simple log so you can see what’s working and improve it over time. That’s the whole thing. No coding required.
What recovery rate should I expect from a failed payment automation?
In my own business over six months, the recovery rate has stayed between 74% and 82% regardless of product, season, or traffic source. Speed and tone of the recovery email matter most: an email that sounds like a real human within 60 seconds of the failure recovers significantly more than a generic billing-department template sent hours later.
More Money Makers like this one
Built from the same five mechanics. Each one recovers, retains, or earns money that would have walked out the door.
Build the Recovery Machine yourself, or work with me directly.
If you want to learn the mechanics and build it on your own stack over a weekend, Automations Made Easy is the playbook. If you’d rather work with me one-on-one to plan it for your specific business, I take a small number of consulting clients each month.
€497 one-time · Lifetime access · 1,000+ students
