JakeVacovec

Part of our process is to ensure this is covered in the terms and we encourage all merchants to explicitly show this in the product for visibility but also because a significant percentage of customers will add a backup to avoid risk of downtime.

Love the actionable feedback! Thank you

The truth is, they probably will in the future. Recurly is one of the leading subscription billing platforms global/enterprise businesses offering more advanced workflows that businesses cannot get from Stripe billing: orchestration, backup payment methods, etc.

https://docs.recurly.com/recurly-subscriptions/docs/backup-p...

It's actually the opposite, we see about 50% of a customers LTV happens after a recovery event. Many services leveraging backup payment methods stem from customer feedback of not wanting downtime (e.g. losing access to wireless or your internet, etc.) it's inefficient and backups are an easy way to address.

Intuitively you'd think that would be the case but in practice once a subscription stops, a large share of customers don’t come back even if they were active. We see three buckets: 1. Customer shops and finds an alternative (Claude instead of ChatGPT) 2. Customer is pissed off about downtime and leaves 3. Nice to have and customer may reactivate later or must have and reactivates/shops

Ultimately, you want to retain customers that want to use your product. If they don't they will actively cancel. We don't prevent or get involved with customers that actively cancel.

That’s a fair concern — we definitely thought about the ethics side. In practice is that most “failed payment” churn isn’t intentional churn. Customers still want the service, but their primary card expired, was replaced, or hit a limit.

When we tested this, refunds and chargebacks were actually lower for the recovered cohort compared to baseline.

For customers who really don’t want the subscription anymore, they can still cancel as usual.

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.

Good feedback - if a potential customer's first interaction with us makes them nauseous that's not great :)

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.

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)

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.

Not that I'm aware of. Depending on your size we can provide a solid start up discount :)

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

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.

Since we deal with error/auth codes we figured it could work -- you don't think so :)

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.

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

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

We're happy to run an audit to see if there's a real opportunity to improve results for you.

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

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.

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're happy to field any questions or opinions without judgement :) if one person shares theirs we assume others may think similar... that's why we love HN

We're strong believers in a BYOI(infra) model where FlyCode works within your stack and tooling instead of making you change to support us. With that we are exploring integrations with experimentation platforms like Split.io, Amplitude and others to enable product teams to add/modify variants, select cohorts, etc. directly from FlyCode's interface. We then make adjustments in the code w/o involving dev.

That's what we're here for - thank you for the support. If they're still in need we'd love to support.

Appreciate the summary! There are a handful of new players building around react components - really interesting space. We believe this is one aspect of a broader movement so educating the market is a group effort :)

> Treating translations as code completely leaves out translators, who in most cases can not code.

It's a big lift to extract all hardcoded strings for a future state where localization will be 'required', especially for large companies. There's no question non-technical teams need the ability to edit strings/translations but if it means changing your infra or the way eng prefers to build it's a tough argument.

We've been building https://www.flycode.com as a platform to make strings/translations and static assets (hardcoded or in resource files) editable by connecting existing repos.