[HN Gopher] Launch HN: FlyCode (YC S22) - Stop losing revenue du...
___________________________________________________________________
Launch HN: FlyCode (YC S22) - Stop losing revenue due to failed
payments
Hi HN community, we are Jake, Tzachi and Etai, co-founders of
FlyCode (https://www.flycode.com). FlyCode makes it easy for
subscription-based companies to recover lost revenue due to failed
payments and involuntary churn - a major hidden revenue killer for
b2b & b2c SaaS merchants and dtc subscription brands. 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!
Author : JakeVacovec
Score : 63 points
Date : 2024-10-30 13:45 UTC (9 hours ago)
| sparrish wrote:
| 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.
| TechDebtDevin wrote:
| This rule sounds crazy, do you have more info?
| sparrish wrote:
| 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.
| JakeVacovec wrote:
| We're happy to run an audit to see if there's a real
| opportunity to improve results for you.
| deskr wrote:
| Sadly the way the subscription system is abused, this doesn't
| sound crazy at all.
| devmor wrote:
| 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.
| ryandrake wrote:
| 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.
| deskr wrote:
| 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.
| TechDebtDevin wrote:
| 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.
| JakeVacovec wrote:
| 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.
| oesa wrote:
| 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/
| JakeVacovec wrote:
| 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.
| Veuxdo wrote:
| > 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.
| mathgeek wrote:
| Some details on the Stripe solution at
| https://stripe.com/blog/how-we-built-it-smart-retries
| JakeVacovec wrote:
| 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.
| aaronax wrote:
| A big company does it so no one else should try?
| Veuxdo wrote:
| 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).
| JakeVacovec wrote:
| 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.
| zabzonk wrote:
| > 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?
| JakeVacovec wrote:
| 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.
| funerr wrote:
| I met the founders, great people. Any open-source tools to start
| out dealing with failed payments before we scale?
| JakeVacovec wrote:
| Not that I'm aware of. Depending on your size we can provide a
| solid start up discount :)
| dboreham wrote:
| 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.
| justchad wrote:
| Profitwell does a version of this and they charge a percentage
| of the recovered funds.
| JakeVacovec wrote:
| 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.
| TZubiri wrote:
| 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.
| freedomben wrote:
| 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.
| JakeVacovec wrote:
| 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.
| npollock wrote:
| doesn't Stripe have an interest in maximizing this revenue
| recovery? they earn a percentage of successful charges
| JakeVacovec wrote:
| 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.
| ilrwbwrkhv wrote:
| When did you start and how long did it take you to reach 60+
| customers?
| peekypeeky008 wrote:
| In 2022 we launched our dev tool and then shifted to payments.
| It took us 1 year so far
| ilrwbwrkhv wrote:
| What was the dev tool?
| JakeVacovec wrote:
| 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.
| Kwpolska wrote:
| Did you consider rebranding? Your name still says "dev tool".
| JakeVacovec wrote:
| Since we deal with error/auth codes we figured it could
| work -- you don't think so :)
| jglmn90 wrote:
| Isn't paze.com a potential threat to this?
| JakeVacovec wrote:
| 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.
| TZubiri wrote:
| 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.
| iddan wrote:
| 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
| JakeVacovec wrote:
| 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).
| benatkin wrote:
| > 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?
| JakeVacovec wrote:
| 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.
| chowells wrote:
| 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.
| benatkin wrote:
| 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.
| iddan wrote:
| 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.
| chasebank wrote:
| How are you different from Flexpay.io who's been doing this for
| years?
| Kwpolska wrote:
| > 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.
| JakeVacovec wrote:
| 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.
| S0y wrote:
| 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.
| JakeVacovec wrote:
| Good feedback - if a potential customer's first interaction
| with us makes them nauseous that's not great :)
| happyllama wrote:
| How do you position FlyCode differently from Butter Payments [1]
|
| [1] https://butterpayments.com
| JakeVacovec wrote:
| 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)
___________________________________________________________________
(page generated 2024-10-30 23:00 UTC)