Show HN: FlyCode – Recover Stripe payments by automatically using backup cards
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? 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. 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. It's hard to believe customers are happy with it. I find it shady if you were to try all the cards I added to the product without my permission. I'm okay with you sending me an email before you try, as long as explicit consent is given. However, if I don't care to change my primary card after the first attempt, that means I don't really care about continuing the subscription. Happy to be wrong if you prove it with the data, though. We do prove it with the data but as mentioned the merchants notify customers before. Thanks 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? Sure, we email customers about failed payments. They can always cancel but please remember that those are payments that should have gone through anyway 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 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 I can't imagine this is in accordance with the terms of service nor legal. You need explicit authorization to charge the card, but you don't have it. Part of our process is to ensure this is covered in the terms and we encourage all merchants to explicitly show this in the product for visibility but also because a significant percentage of customers will add a backup to avoid risk of downtime. 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? Not at all. SaaS customers are doing the full process in notify their customers first. The reduce chargebacks is happening because those are "good" payments that should go through anyway. The customer never intended to cancel the subscription from a failed payment 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? The truth is, they probably will in the future. Recurly is one of the leading subscription billing platforms global/enterprise businesses offering more advanced workflows that businesses cannot get from Stripe billing: orchestration, backup payment methods, etc. https://docs.recurly.com/recurly-subscriptions/docs/backup-p... Stripe offer a basic payment recovery, it's up to the merchants to offer more advanced way for their customers to pay. You can check out our Stripe app Thank you I’m Tzachi, one of the cofounders here at FlyCode. It’s great to see the discussion here. It’s really helpful for us and we’re taking everything under consideration. It’s interesting for me to see the “consumer” perspective vs. the merchants (our customers) perspective that use this product at scale for failed payments. Thanks 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? Yeah, we're all coming from a FinTech background so it was a better fit for us If your "service" happened to me I'd be very, Very, VERY ANGRY and if possible (and most of my (online) subscriptions luckily are a "want" and not a "need"),
I'd CANCEL the subscription manually (+ look into legal action if your customer would not comply due to periods... which would make me even ANGRIER if not possible and eating up my time), send a VERY ANFRY email to your customer, send them a GDPR deletion demand and (after hopefully having been told after many weeks of simmering waiting time why the &_+@^=~ that happened in the first place) look VERY HARD into cancelling all my other subscriptions in Stripe or moving them to a different payment method. Not all credit cards are linked to the same account, or have the same conditions. I usually when possible take advantage of yearly over monthly payments with the associated discounts.
That means that it is VERY BAD for me if suddenly without warning possibly HUNDREDS OF EUROS/DOLLARS are siphoned off from the wrong place. (again, not all credit cards have ideal terms!) Even if I have the funds and buffers, it could potentially wreck some important mandatory payment, which I might not notice in time maybe because of the same meatspace $REASONS I couldn't update the credit card details in the first place!!! Thanks for the PSA to stay away as possible from Stripe handled subscriptions and that this is even possible, as well as a reminder to review all my subscriptions and my Worst Case Infos for family members. (throwaway account for privacy reasons) One thing that I never see brought up in these kinds of discussions is that payment of subscription fees is almost orthagonal to the subscription itself. Stripe eventually gives up, which seems like a fair default, but Stripe is also ignorant as to the legal agreements customers and merchants have made. There's a whole industry around managing subscription-related debts and debt collecting that folks often forget about. That is to say that there are alternatives to cancelling after a few failed payments, other than trying other cards in the customer's wallet. They may be worth exploring. Our goal as a product is never to reach the stage of subscription cancellation, and definitely not debt collection. We’re saving failed payments from being canceled. Our merchants have thousands of customers. This is not a debt collection use case. It is about saving good payments that should go through. It is about fighting broken bank models with our models for payment recovery I disagree that the bank models are broken. At face value, a more effective method is to pay the fee to the issue to get the updated card, if it exists. Nearly every issuer supports this nowadays. If you've ever wondered why your subscription magically updated to your new card after your old one expired, then this is precisely what they did. It's easy to do this with Stripe as well. If customers care deeply about their subscription and you support adding multiple cards to ensure payments don't fail, then great. I'm not sure this makes sense as a product, though. It's very easy to implement this sort of dunning, roll over to next card, rinse-repeat strategy. The TCO of an additional vendor in this critical path is unlikely to be worth it, especially with the direction the merchant-of-record-as-a-service industry is headed. In any case, one path I was insinuating is that these failure cases are good opportunities for customer engagement. Often times it can be as simple as the card-holding manager left a the company and no one realizes the sub is on their account. Depending on your response, this sort of event can make a huge difference to your funnel/lifecycle. I wish you luck but I just don't think the market is there. If, however, you also have an off-ramp to debt collecting then I think this is a viable product when targeting certain markets. 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 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 How many of those "recovered" payments actually have the user coming back to use the product? I'm going to guess almost 0% 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. One small suggestion for the landing page, switch the columns “with flycode” and “without flycode” so “without” appears first, on the left. Love the actionable feedback! Thank you I reported the app to stripe as well. Reviewing the website and seeing the endorsements makes me question the legitimacy of this in many ways. Thanks for the feedback. We have strict compliance and legal terms in place to prevent any misuse of this. This is being used by Amazon, Netflix and other top merchants. It’s all a matter of user communication and terms you have with your customers. Thanks Thank you for reminding me about a subscription i accidentally signed up for and need to go cancel. If a card i didn't explicitly authorize for a recurring charge was charged like this, I'd be livid. Different cards are used for different things for real reasons.