hckrnws

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.

Why on earth would it be unethical? They are creating a process for retrying a payment for which the customer is already responsible. Maybe the customer ultimately decides to cancel, maybe not, but a business is free to take into account whether a user is “active.”

California introduced a 'click to cancel' law a month or two back - because a large number of subscription companies engage in a lot of sketchy behaviour, like making it almost impossible to cancel.

So this is already a pretty seedy area of business.

Now add to that the fact that the customer has ignored the payment-failed e-mail, and ignored the warning banners on the site during the grace period, and doesn't mind when they get cut off entirely. Clearly, this subscription isn't producing much value for the customer.

And then consider the ethics of offering expensive services to people who can't afford them. If a person lives in such abject poverty that their bank account has literally zero dollars in it, should I be pushing them to keep their subscription? Even when the service has so little value to them?

It's not technically illegal though.

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.

I worked in Ecommerce with a company that built sophisticated subscription solutions well before Shopify had a real offering. We took significant VC money, then watched Shopify build out their own solution to service the now proven market. I'd expect them or Stripe to do the same thing here; it's way more common than buying the first mover or hiring them to build it, plus YC has no interest in this sort of business model.

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.

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.

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.

We use them for this and it pays for itself.

> 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.

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.

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.

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.

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.

I was struggling to cancel a service, thankfully the card on file was expiring. So, I just left it. Surprisingly the company found some way to bill a card I didn't give them and sent me product. I complained and the company refunded me the amount and I had no obligation to return the product because I didn't order it. Be careful what you recover or you might end up putting your service or reputation at risk.

I was surprised to learn about credit card automatic updater services, which ”conveniently” don’t allow a card to expire with merchants.

https://lifehacker.com/heres-why-everyone-already-has-your-n...

You should probably put a one-click "I don't want to be charged anymore" button in any communications to the customer, to make sure you're not pushing them into a payment loop they don't want.

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.

> 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.

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 :)

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.

Why did you pivot away from localization?

See their old launch https://news.ycombinator.com/item?id=31166924

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.

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.

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?

This is a really good idea. Who are your competitors?

Text on the homepage hero: "Boost Revenue and Reduce Churn with AI-Powered Dunning"

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!

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.