Show HN: FlyCode – Recover Stripe payments by automatically using backup cards
20 comments
·September 23, 2025cut_un
If customers aren't renewing then they probably don't need the service and forgot they're being charged. It feels unethical to rifle through their online wallet and look for another card to charge.
JakeVacovec
That’s a fair concern — we definitely thought about the ethics side. In practice is that most “failed payment” churn isn’t intentional churn. Customers still want the service, but their primary card expired, was replaced, or hit a limit.
When we tested this, refunds and chargebacks were actually lower for the recovered cohort compared to baseline.
For customers who really don’t want the subscription anymore, they can still cancel as usual.
cut_un
What about cancellation rates? That's another option many may prefer to take when they notice this.
Are customers notified when their payment details are changed unexpectedly by your service?
unmole
[flagged]
loloquwowndueo
You’re not wrong but -- what makes you think the message you replied to was AI-written?
typpilol
Lmao this whole product is shady.
If a customer was actively using a service and it stopped, they would resubscribe themselves.
whiplash451
I am surprised Stripe does not offer this feature to their customers. There is probably a reason why they don’t. What is their feedback?
flessner
Out of curiosity, what made you pivot from a web/translation editor to recovering stripe payments? Was it primarily because of the teams prior experience in payment recovery or something else?
iddan
Congrats of the launch! For which types of companies did you see the FlyCode model most successful? What are the results for the average SaaS? I’ve been evaluating a few solutions but it seems like some of em are mostly focused on e-commerce
peekypeeky008
Thanks for the comment. We help subscription-based businesses in SaaS and eCommerce. The average results show a boost of 20-25% in the recovery rate
typpilol
How many of those "recovered" payments actually have the user coming back to use the product? I'm going to guess almost 0%
JakeVacovec
It's actually the opposite, we see about 50% of a customers LTV happens after a recovery event. Many services leveraging backup payment methods stem from customer feedback of not wanting downtime (e.g. losing access to wireless or your internet, etc.) it's inefficient and backups are an easy way to address.
thoyles
Is there a concern that the reduction in chargebacks is stemming from using cards that may not be monitored as closely as a customer’s “primary” card?
typpilol
This seems like a way to squeeze money from users who forgot about their sub with unsuspecting payments.
If the service is declined and they use it, they would just resubscribe.
This is just basically a tool for businesses to scam unsuspecting customers?
Also - do the customers agree for you to charge their other payment method? If not, how is that legal? It's also seems like it would be against stripes terms of service
I reported this to stripe to see what they have to say
peekypeeky008
Thanks for the comment. Happy that someone brought this up. Before it works, our merchants complete the full process of making sure their terms are up to date and they notify their customers. It's all from cards the customers have on file. Try to look at it from the customer's point of view: they didn't actively want to cancel their subscription. The bank declined a good transaction
null
Daniel160791
[dead]
We built FlyCode after seeing subscription businesses lose ~35% of recurring revenue each year to failed payments — even when customers had other valid cards on file.
*The problem:* When a customer's primary card fails, Stripe retries a few times then cancels the subscription. If that customer has a backup card, it isn’t tried. At least 20% of active customers have more than one card on file, which means a lot of preventable churn.
*Our solution:* FlyCode automatically identifies if a customer has other valid cards on file and retries them when a subscription payment fails. You can configure when these retries happen during the dunning period (beginning, middle, end) and define validity rules (e.g. “card was used in last 180 days”). It’s a Stripe app — no code changes needed.
We've seen 18%-20% higher recovery rates from our core retry engine, plus another 5–10% from using backup cards. Importantly, there was no increase in refunds or chargebacks — in fact, rates were lower than merchant averages. Big companies like Microsoft and Amazon already do this internally; we wanted to make the same capability accessible to smaller SaaS teams.
*Under the hood:* FlyCode monitors for failed invoices, checks for available backup methods via Stripe’s PaymentMethod API, and systematically retries in a way that avoids service disruption or manual workflows.
We’re Jake, Etai, and Tzachi — we previously built payment recovery systems at startups and enterprises, which is how we discovered this gap.
You can try it here: [https://www.flycode.com/stripe]
We’d love feedback from anyone dealing with subscription payment failures. What’s been your experience with involuntary churn? Have you considered leveraging backup payment methods?