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.
To give another point of view on this: many times there are essential services I use and I just forget to update my credit card after switching it or for some reason the charge didn’t pass. I would much rather get proper emails (or even better to have the charge recovered) than losing the service
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.
It definitely depends on the type of customer and type of product. There is a % of recoveries that will churn in the following 1-2 billing cycles and there's a larger % that will stay longer. Ultimately increasing recovery rate across the board means more revenue, which is good for a business.
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).
> Ultimately increasing recovery rate across the board means more revenue, which is good for a business.
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?
Our Merchants can configure the recovery period and messaging to their liking and we ensure there's strict adherence to the compliance and regulatory rules set by card networks.
Ethics and honor are great things but keep in mind we're not a collections agency that's buying bad debt off companies for pennies on the dollar to chase, which sounds like the experience you're referring to.
It depends on their customers ("merchants"). I'm sure some of their customers will be fine. They could attract others like a foreign language teaching service that lures people in with a single price but somehow they're accidentally enrolled in something that has a 6 month commitment. It says subscription-based but it doesn't say anywhere that they exclude ones that have a commitment to multiple billing cycles, so "they have the option to cancel" probably won't even technically be the case with some services.
Having run a small (100K users) SaaS company and seen some of this first hand, this is interesting. We never automated any of this, rather just communicating with customers asking them to try another card, or in extreme cases getting them to send a bare PayPal transfer then manually provisioning the payment against their account. I also worked for a startup in the 2000's that had the exact same conceptual idea, but applied to a somewhat different specific use-case.
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.
It can start out as a business and then get acquired by a bigger business like Stripe, paypel, business, mercury. Either by purchasing the company whole, or by contracting to implement the feature on their systems.
I agree, that seems like the most reasonable exit strategy. From what we know of the model, it's something that could reasonably get built by Stripe into Stripe. I wouldn't be surprised if they're already working on something like that.
We make the integration process nearly effortless for our customers -- we've built apps for Stripe and Shopify and have plans to build out more. Pricing is a flat SaaS fee based on recovered revenue. If we help businesses recover 20%+ more on average the business model is a simple ROI equation.
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.
It's a diminishing returns problem... If they charge 2.9% + $.30 as their standard pricing, they are only keeping a small % of that as the issuer (Chase) gets the largest piece of the pie and the network (Visa) takes their cut too. If each declined authorization costs Stripe $.25, each attempt chips away at their margin.
Got anything for India's new rules against recurring charges? So many of our customers in India are having a very hard time paying us with credit cards because their banks no longer are allowed to accept subscription charges.
Yes while the regulations for e-mandates had good intentions it makes recurring transactions more difficult. They've relaxed it a bit by increasing e-mandate cap from INR 5k to 15k (~$180 USD). If the transaction is below ~$180 then it is the issuing bank's (HDFC, SBI, etc.) responsibility to notify the customer 24 hours in advance. If over ~$180 then the customer needs to essentially approve each payment.
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.
I highly recommend privacy.com (not sure if this works in your jurisdiction) but this is how I've been navigating subscriptions for the past few years. I create a new card (privacy.com linked to my bank account) with one click, can set spending limits ect and do this for every subscription I'm not sure I'm going to want to resubscribe too. I can set it as a one time authorization for a certain amount to meet sign-up requirements and then I don't have to worry about forgetting.
That's what I was thinking - it sounds welcome. I would love if every recurring charge I had required me to recieve a notification to approve it.
I have spent my entire adult life attempting to avoid subscriptions and only use services I pro-actively pay for, which has become rather impossible over the last decade.
Returning to that would be great! Of course, a large amount of SaaS companies would be very unhappy with this - recurring billing on customers who forget about the service is a major revenue source. There's an entire industry built around "not-quite-scamming" people in this way.
Lately I've taken to using whatever credit card I have that is going to expire the soonest, or a virtual card, and then not updating it on customer portals. In many cases, this allows me to use a different card to make a "one time payment" after the recurring payment fails, which prompts me to evaluate whether or not the service is still something I need every month.
Yea, my reaction was the same when I read the comment: Can we please have this in the USA, too? It should take my deliberate action to charge my credit card.
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.
> 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.
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.
We tailor our models specific to the Merchant as each varies in so many ways (customer demographic, transaction size, intervals, geo, payment methods, etc.). You'll also notice that their entire focus is on retries so all the 'flexibility' is pegged to retry count. In an ideal world customers don't have to do anything but the reality is that effective communication strategies are critical to recover valuable customers. The per Merchant approach and e2e flexibility will enable a continued competitive advantage.
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.
Sometimes. In the face of entrenched competition, you can't be just a little bit better. You have to be a lot better. And in a way that said competition can't easily match (or exceed).
It's fairly easy to measure performance. For companies with 100's of thousands or millions in failed payments each month 5-10% performance gains have a huge impact. On average we're improving recovery rate by 21%. To hold ourselves accountable we offer customers a full-refund if they're not satisfied with gains. We haven't had to give a refund yet.
> Our communications product coordinates transactional emails/sms with retries ensuring sent at an ideal local time and in the local language.
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.
More often than not we can resolve the payment issue without any customer involvement. That's the ideal path. In many cases the system will delay sending communications if the chances of a recovery by retry drop below a certain level. It's best to avoid asking customers to do something if it may already be fixed. Your bank still may notify you but that depends on your country and bank.
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.
A few key areas where our differences are advantages (in our pov):
1. We handle recovery e2e (both retries & communications)
2. We provide detailed real-time analytics on performance
3. Higher ROI (cost less and are directly responsible for more recoveries)
4. They're competing to be the card vault (replace Stripe, Adyen, Spreedly, etc. vault) whereas our vision is revenue optimization from initial authorization to recovery (complimentary to any stack)
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.
THey're happy with the increased revenue and reduced churn. Separate to powering the decisions we don't save any personal information and have a clear/transparent data processing agreement. For those with further restrictions, such as HIPAA compliance, we can limit certain inputs.
We do have a pricing page however it's geared towards giving an estimation on how much additional we can generate for a merchant with our average improvement against industry average failure and recovery rates.
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.
Could you make a comparison between FlyCode and Stripe Dunning / stunning.co [1]?
When should a B2B SaaS reach for FlyCode (an app on Stripe Marketplace) vs Stripe Dunning (I'm actually unsure if it's their own offering or not)?
The biggest difference is that we own the retries and communications e2e (transactional email/sms from your domain and dedicated #). This enables us to be far more configurable for each Merchant in terms of recovery period while ensuring that sufficient retry and communications are occurring prior to cancelling a subscription. Stunning is typically used alongside Stripe's retries to send customer emails, which means the two are disjointed. This often leads to too many communications or too few. By treating each customer and their payments individually we're taking a highly tailored approach that's fully automated.
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.
Revenue recovery is such a big problem for subscription based businesses and honestly I don’t know many companies who have the capacity to handle it properly, let alone devote engineering efforts for this. Seeing from first hand the impact of FlyCode on the bottom line of businesses has been really amazing.
We focus on MIT (merchant initiated transactions) vs. CIT (customer initiated transactions). Paze seems like a dupe of Shop pay and Stripe's Link. We support both since they support recurring. If paze allows for recurring (unclear) then we will support them too.
So the standard solution is:
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.
To give another point of view on this: many times there are essential services I use and I just forget to update my credit card after switching it or for some reason the charge didn’t pass. I would much rather get proper emails (or even better to have the charge recovered) than losing the service
> 1- Notify client of failed payment
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.
[1] https://corepay.net/articles/decline-codes/
It definitely depends on the type of customer and type of product. There is a % of recoveries that will churn in the following 1-2 billing cycles and there's a larger % that will stay longer. Ultimately increasing recovery rate across the board means more revenue, which is good for a business.
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).
> Ultimately increasing recovery rate across the board means more revenue, which is good for a business.
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?
Our Merchants can configure the recovery period and messaging to their liking and we ensure there's strict adherence to the compliance and regulatory rules set by card networks.
Ethics and honor are great things but keep in mind we're not a collections agency that's buying bad debt off companies for pennies on the dollar to chase, which sounds like the experience you're referring to.
You can choose not to be ethical, but you should advertise it loudly.
Or at the very least, stop protesting when people call it out.
It depends on their customers ("merchants"). I'm sure some of their customers will be fine. They could attract others like a foreign language teaching service that lures people in with a single price but somehow they're accidentally enrolled in something that has a 6 month commitment. It says subscription-based but it doesn't say anywhere that they exclude ones that have a commitment to multiple billing cycles, so "they have the option to cancel" probably won't even technically be the case with some services.
Having run a small (100K users) SaaS company and seen some of this first hand, this is interesting. We never automated any of this, rather just communicating with customers asking them to try another card, or in extreme cases getting them to send a bare PayPal transfer then manually provisioning the payment against their account. I also worked for a startup in the 2000's that had the exact same conceptual idea, but applied to a somewhat different specific use-case.
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.
It can start out as a business and then get acquired by a bigger business like Stripe, paypel, business, mercury. Either by purchasing the company whole, or by contracting to implement the feature on their systems.
I agree, that seems like the most reasonable exit strategy. From what we know of the model, it's something that could reasonably get built by Stripe into Stripe. I wouldn't be surprised if they're already working on something like that.
We make the integration process nearly effortless for our customers -- we've built apps for Stripe and Shopify and have plans to build out more. Pricing is a flat SaaS fee based on recovered revenue. If we help businesses recover 20%+ more on average the business model is a simple ROI equation.
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.
Profitwell does a version of this and they charge a percentage of the recovered funds.
We offer both -- those with seasonality like % vs. our largest like a flat SaaS fee so it's a clear line item in the budget.
doesn't Stripe have an interest in maximizing this revenue recovery? they earn a percentage of successful charges
It's a diminishing returns problem... If they charge 2.9% + $.30 as their standard pricing, they are only keeping a small % of that as the issuer (Chase) gets the largest piece of the pie and the network (Visa) takes their cut too. If each declined authorization costs Stripe $.25, each attempt chips away at their margin.
Got anything for India's new rules against recurring charges? So many of our customers in India are having a very hard time paying us with credit cards because their banks no longer are allowed to accept subscription charges.
Yes while the regulations for e-mandates had good intentions it makes recurring transactions more difficult. They've relaxed it a bit by increasing e-mandate cap from INR 5k to 15k (~$180 USD). If the transaction is below ~$180 then it is the issuing bank's (HDFC, SBI, etc.) responsibility to notify the customer 24 hours in advance. If over ~$180 then the customer needs to essentially approve each payment.
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.
This rule sounds crazy, do you have more info?
Sadly the way the subscription system is abused, this doesn't sound crazy at all.
I highly recommend privacy.com (not sure if this works in your jurisdiction) but this is how I've been navigating subscriptions for the past few years. I create a new card (privacy.com linked to my bank account) with one click, can set spending limits ect and do this for every subscription I'm not sure I'm going to want to resubscribe too. I can set it as a one time authorization for a certain amount to meet sign-up requirements and then I don't have to worry about forgetting.
That's what I was thinking - it sounds welcome. I would love if every recurring charge I had required me to recieve a notification to approve it.
I have spent my entire adult life attempting to avoid subscriptions and only use services I pro-actively pay for, which has become rather impossible over the last decade.
Returning to that would be great! Of course, a large amount of SaaS companies would be very unhappy with this - recurring billing on customers who forget about the service is a major revenue source. There's an entire industry built around "not-quite-scamming" people in this way.
Lately I've taken to using whatever credit card I have that is going to expire the soonest, or a virtual card, and then not updating it on customer portals. In many cases, this allows me to use a different card to make a "one time payment" after the recurring payment fails, which prompts me to evaluate whether or not the service is still something I need every month.
Yea, my reaction was the same when I read the comment: Can we please have this in the USA, too? It should take my deliberate action to charge my credit card.
Imagine if the subscriptions were opt in every month. You'd get an email: "Want to extend your subscription by a month? Click here."
That'd be wonderful for consumers and terrible for shitty companies. But it should be that way.
https://timesofindia.indiatimes.com/blogs/voices/new-recurri...
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.
We're happy to run an audit to see if there's a real opportunity to improve results for you.
> 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.
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.
Some details on the Stripe solution at https://stripe.com/blog/how-we-built-it-smart-retries
We tailor our models specific to the Merchant as each varies in so many ways (customer demographic, transaction size, intervals, geo, payment methods, etc.). You'll also notice that their entire focus is on retries so all the 'flexibility' is pegged to retry count. In an ideal world customers don't have to do anything but the reality is that effective communication strategies are critical to recover valuable customers. The per Merchant approach and e2e flexibility will enable a continued competitive advantage.
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.
A big company does it so no one else should try?
Sometimes. In the face of entrenched competition, you can't be just a little bit better. You have to be a lot better. And in a way that said competition can't easily match (or exceed).
It's fairly easy to measure performance. For companies with 100's of thousands or millions in failed payments each month 5-10% performance gains have a huge impact. On average we're improving recovery rate by 21%. To hold ourselves accountable we offer customers a full-refund if they're not satisfied with gains. We haven't had to give a refund yet.
> Our communications product coordinates transactional emails/sms with retries ensuring sent at an ideal local time and in the local language.
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.
More often than not we can resolve the payment issue without any customer involvement. That's the ideal path. In many cases the system will delay sending communications if the chances of a recovery by retry drop below a certain level. It's best to avoid asking customers to do something if it may already be fixed. Your bank still may notify you but that depends on your country and bank.
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.
How do you position FlyCode differently from Butter Payments [1]
[1] https://butterpayments.com
A few key areas where our differences are advantages (in our pov): 1. We handle recovery e2e (both retries & communications) 2. We provide detailed real-time analytics on performance 3. Higher ROI (cost less and are directly responsible for more recoveries) 4. They're competing to be the card vault (replace Stripe, Adyen, Spreedly, etc. vault) whereas our vision is revenue optimization from initial authorization to recovery (complimentary to any stack)
Little nitpick about your website.
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.
Good feedback - if a potential customer's first interaction with us makes them nauseous that's not great :)
> take into account 100’s of datapoints, such as customer and payment metadata as well as internal classifiers of error codes and messages
and your customers are happy with you using 100s of this data?
THey're happy with the increased revenue and reduced churn. Separate to powering the decisions we don't save any personal information and have a clear/transparent data processing agreement. For those with further restrictions, such as HIPAA compliance, we can limit certain inputs.
I couldn’t find the pricing page on the website. It might be because I’m looking at it on my phone and the nav item doesn’t show on small screens?
Is the pricing transparent and, if so, what is it?
We do have a pricing page however it's geared towards giving an estimation on how much additional we can generate for a merchant with our average improvement against industry average failure and recovery rates.
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.
Could you make a comparison between FlyCode and Stripe Dunning / stunning.co [1]? When should a B2B SaaS reach for FlyCode (an app on Stripe Marketplace) vs Stripe Dunning (I'm actually unsure if it's their own offering or not)?
[1]: https://stunning.co/
The biggest difference is that we own the retries and communications e2e (transactional email/sms from your domain and dedicated #). This enables us to be far more configurable for each Merchant in terms of recovery period while ensuring that sufficient retry and communications are occurring prior to cancelling a subscription. Stunning is typically used alongside Stripe's retries to send customer emails, which means the two are disjointed. This often leads to too many communications or too few. By treating each customer and their payments individually we're taking a highly tailored approach that's fully automated.
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.
I met the founders, great people. Any open-source tools to start out dealing with failed payments before we scale?
Not that I'm aware of. Depending on your size we can provide a solid start up discount :)
Revenue recovery is such a big problem for subscription based businesses and honestly I don’t know many companies who have the capacity to handle it properly, let alone devote engineering efforts for this. Seeing from first hand the impact of FlyCode on the bottom line of businesses has been really amazing.
How are you different from Flexpay.io who's been doing this for years?
Isn't paze.com a potential threat to this?
We focus on MIT (merchant initiated transactions) vs. CIT (customer initiated transactions). Paze seems like a dupe of Shop pay and Stripe's Link. We support both since they support recurring. If paze allows for recurring (unclear) then we will support them too.
When did you start and how long did it take you to reach 60+ customers?
In 2022 we launched our dev tool and then shifted to payments. It took us 1 year so far
Did you consider rebranding? Your name still says "dev tool".
Since we deal with error/auth codes we figured it could work -- you don't think so :)
What was the dev tool?
Git-based editor for web-apps.. we still see promise especially with AI capabilities but fintech is a much better founder-market-fit for us.