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.
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.
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.
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.
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.
Isn't paze.com a potential threat to this?
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.
Profitwell does a version of this and they charge a percentage of the recovered funds.
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?
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.
Sadly the way the subscription system is abused, this doesn't sound crazy at all.
> 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.
I met the founders, great people. Any open-source tools to start out dealing with failed payments before we scale?
> 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.
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.
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