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.
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.
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.
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.
It's hard to believe customers are happy with it. I find it shady if you were to try all the cards I added to the product without my permission.
I'm okay with you sending me an email before you try, as long as explicit consent is given. However, if I don't care to change my primary card after the first attempt, that means I don't really care about continuing the subscription.
Happy to be wrong if you prove it with the data, though.
Sure, we email customers about failed payments. They can always cancel but please remember that those are payments that should have gone through anyway
I agree with unmole that it seems AI generated. The original comment (which was later edited to the one we see now) had even more clearly an LLM style to it:
That’s a fair concern — we definitely thought about the ethics side when building this. What we’ve seen in practice is that most “failed payment” churn isn’t intentional churn. Customers still want the service, but their primary card expired, was replaced due to fraud, or hit a temporary limit.
When we tested this, refunds and chargebacks were actually lower for the recovered cohort compared to baseline. That suggests customers were happy the service continued, rather than surprised or upset.
So while it might sound like “rifling through a wallet,” the reality is we’re just using Stripe’s stored, valid payment methods (with the same PCI and authorization framework) that the customer added for this merchant. For customers who really don’t want the subscription anymore, they can still cancel as usual — this doesn’t override cancellations.
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.
The service didn't stop. You subscribe to a product that you're using but the bank declines the payment (happens every time to almost 30%+ of customers). The customer never intended to churn.. they can always go and cancel. It's good customers with legitimate payments.
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.
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.
