In previous roles, we led payments teams at enterprises and startups, where we built payment recovery processes and optimized billing systems. We experienced firsthand how challenging it is to recover failed payments efficiently.
Many teams we’ve spoken to view failed payments as an unsolvable black box — a cost of doing business. But when a payment fails, it doesn’t just cost immediate revenue; it significantly impacts the customer’s lifetime value (LTV) and customer experience.
Teams are trying to handle it by (1) relying on the basic recovery of their payment provider (like Stripe basic smart recovery); (2) brute forcing or fixed-interval retry strategies, a legacy approach that ultimately reduces retry success rates and increases customer churn (3) sending too many or too few emails to customers (contact your bank..).
One of the biggest challenges is that payment providers, issuing banks, and card networks classify errors into different categories and have their own risk rules, which adds complexity and leads to many errors getting bucketed together, such as ‘Do not honor’.
To address this problem, we built decisioning models that take into account 100’s of datapoints, such as customer and payment metadata as well as internal classifiers of error codes and messages. The models determine the optimal time to retry a payment with current or backup payment methods and when to communicate with a customer. Our communications product coordinates transactional emails/sms with retries ensuring sent at an ideal local time and in the local language. With FlyCode you can recover more payments with (1) fewer payment retries (2) faster average days to recovery (3) less customer communications (4) compliant with the Card networks rules [we partnered with Visa] (5) and coordinate the communications with the retries automatically for each customer. On top of that, solutions like Card Account Updater (CAU) and Network Tokens help to automatically update card details when a new card is activated or an expired one is replaced.
Our 60+ customers range from mid-sized to large businesses. We built apps in Stripe and Shopify https://marketplace.stripe.com/apps/flycode-payments (featured in Stripe’s marketplace). Please let me know if you have more questions or feedback. We’ll do our best to answer them!
1- Notify client of failed payment 2- Activate a grace period 3- Notify of grace period. 4- Cut service after grace period. 5- Reinstate account after user corrects payment data. 6- Make sure there are no system bugs in the reinstatement.
In my personal preference, I like the system very much. It is the responsibility of the client to keep payment methods up to date, I don't think chasing a client to fix their credit issues is appropriate. But definitely not treating them like criminals and allowing them to fix the issue is due.
Going after this lost revenue is going after bad clients in a sense. Barring expired cards, usually what happens is that the client has low liquidity, high debt, or is spread too thin across multiple accounts, and is unlikely to have a high LTV.
Can say as a user that paid 12$ subscriptions on a month to month basis and was regularly late to the point of waiting until service is cut to move money around to pay it. Don't chase me, let me fix it, if at all, it's ok.
Which seldom includes the full error information from the transaction. There are about fifty error codes, and they can come from various places in the merchant to issuing bank chain.[1] Dumber web sites tend to assume it's the customer's problem. Once or twice I've had that happen. I call up the bank, and they usually tell me the transaction never reached them. This is sometimes a problem with low-end point of sale systems. Speedway Express gas stations seem to have a terrible system.
Error type is also not indicative of customer quality. For example, businesses and consumers set limits on their cards all the time so an insufficient funds error doesn't mean they have no money.
If the customer doesn't want the service they have the option to cancel. This is why the LTV of customers recovered after a payment failure (involuntary churn prevention) is significantly higher than those saved from cancellation prevention flows (active churn prevention).
Not if it isn't ethical. You're painting those with the failed payments who didn't cancel of being the ones in the wrong to justify the action taken against them, but heavy handed payment collection of a SaaS they likely weren't using doesn't sound great to me either. How about just doing the honorable thing that also isn't chasing bad clients?
> If the customer doesn't want the service they have the option to cancel.
Would you take Adobe as a customer, with their infamous cancellation dark patterns?
However, that's not what really makes me curious about this, which is: how do you make this a business? If someone explained this idea to me cold I'd immediately say "that's not a business, it's a feature of Stripe/PayPal et al". From a technical perspective the integration with the customer's (customer of FlyCode) systems seems challenging.
There's many opportunities to expand our value throughout a payments journey. Merchants rely heavily on rule based business logic for payments and continue to add more rules over time. The expansion opportunity we see is to provide dynamic logic/decision day 1 without all the internal development/iteration.
The ideal time is immediately after the payment fails. My bank would tell me about the failed payment immediately, and it would be useful to have a way to fix it without having to wait until whichever hour makes people 0.001% more likely to open e-mails.
I want e-mails in the same language as I use the service in, from the same e-mail server that already sends me transactional e-mails, and with the message content written by the people behind the service. An e-mail in the wrong language may be misunderstood or interpreted as a scam. An e-mail from a different server may end up in the spam folder.
Seeing your pricing should not require filling out a long survey and an e-mail address.
All in all, is it really a product? It seems like a feature that the payment providers would already offer, or maybe a slight improvement upon it.
We don't guess a customer's language. Typically our Merchants have a single default language but since our Merchants are global it's important that the various messages we send can be available in different languages. If they have multiple instances for different geo's we can segment by language.
Our transactional emails have incredible deliverability scores and extremely low spam rates. They come from the merchants domain and are lightweight to ensure they go to the right inbox vs. ending up in promotion. For transactional sms we handle the compliance and each Merchant get's their own dedicated #.
Regarding pricing, each Merchant has different volume, failure rates, and recovery rates. Since we guarantee our ROI we have to tailor our pricing to them. We're working to make it easier so this is helpful feedback.
We have two approaches to this (1) we implement custom communication plans to notify customers in advance, day of, and in the days after with a multi-channel approach [email/sms] and (2) to switch offering to multi-month, annual, or semi pre-paid. Solution ensures a consistent and proactive approach if above the e-mandate cap and (2) reduces the frequency of customer intervention.
We've not seen much of an impact until the last couple of months when nearly all the charges for our customers in India have begun to fail. They're all below the $180 limit so I don't know what's going on.
All well and good, but doesn't Stripe have much, much more data on this? Once they start doing all of the above (assuming they don't already), their data will give them a gigantic advantage. And that's only on top of being built-in.
Additionally but also very important -- Stripe and other PSPs platform strategies are to be the vault so they're enabling flexibility with forward APIs. This means having an independent decisioning engine for retries, cascading, and routing is even more important.
https://lifehacker.com/heres-why-everyone-already-has-your-n...
Because let's face it, half of your 'subscription-based companies' are banking on customer forgetfulness and high-effort cancellation flows to drive retention.
These are major factors that you _shouldn't_ attempt to 'solve' by successfully charging the customer for services they don't use or want.
If you do that, your whole business model will just be riding the underbelly of dark design patterns.
and your customers are happy with you using 100s of this data?
the " Trusted by" and "Backed and Advised by" scrolling marquee is WAY too fast.
I'm not sure if it's because they scroll in opposite directions or just the speed, but they make me pretty dizzy. I'm not particularly sensitive to these things so I imagine it's even worse for people with motion sensitivity.
[1]: https://stunning.co/
Stripe also caps retries at 8 attempts and while you don't want to over-attempt there are many payments left on the table that require more. It's the card networks (visa, mastercard, etc.) that set retry rules. Unless you're on an IC+ model Stripe is absorbing the declined authorization fees so there's a partial conflict of interest here.
Each business is different in terms of average transaction size, failure rate and recovery rate. Our primary value prop is increasing recovery rate but for others is our automation that's even more valuable to scale operations efficiently and move manual outreach efforts to other areas of the business.
See their old launch https://news.ycombinator.com/item?id=31166924
Is the pricing transparent and, if so, what is it?
We tailor pricing to provide a double digit ROI since there's a huge range between each businesses metrics. For example, take two businesses with $4M MRR and one has a payment failure rate of 25% ($1m/mo) and the other has 5% ($200k/mo). We've found that Merchants are happiest with this approach as we also provide a free payment audit upfront to benchmark historical performance, estimate our impact, and set price. This way the benchmark, targets, and ROI are completely transparent.
Today I learned the word "dunning" -- I'd never heard of it before. Except as the name of one of the researchers after whom the Dunning-Kruger effect was named. Per Wikipedia: "a cognitive bias in which people with limited competence in a particular domain overestimate their abilities." -- So, due to pattern-matching, the word "Dunning" immediately lit up the same neural network in my psyche that activates when I think of over-confident idiots.
Might want to avoid using a word that evokes over-confident idiots when selling your AI-based subscription billing recovery solution.
lol!
