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.

▲

buremba 2 days ago | parent | next [-]

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.

	▲	peekypeeky008 2 days ago \| parent [-]
		We do prove it with the data but as mentioned the merchants notify customers before. Thanks

▲

cut_un 2 days ago | parent | prev | next [-]

What about cancellation rates? That's another option many may prefer to take when they notice this.

Are customers notified when their payment details are changed unexpectedly by your service?

	▲	peekypeeky008 2 days ago \| parent [-]
		Sure, we email customers about failed payments. They can always cancel but please remember that those are payments that should have gone through anyway

▲

unmole 2 days ago | parent | prev [-]

[flagged]

▲

loloquwowndueo 2 days ago | parent | next [-]

You’re not wrong but -- what makes you think the message you replied to was AI-written?

▲

cut_un 2 days ago | parent [-]

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.

That plus the em dashes feels very ChatGPT.

	▲	loloquwowndueo 2 days ago \| parent [-]
		Just remember in its default configuration iOS will turn double dashes into an em dash — vs - (single dash).

▲

typpilol 2 days ago | parent | prev [-]

Lmao this whole product is shady.

If a customer was actively using a service and it stopped, they would resubscribe themselves.

	▲	JakeVacovec 2 days ago \| parent \| next [-]
		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.
	▲	peekypeeky008 2 days ago \| parent \| prev \| next [-]
		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.
	▲	2 days ago \| parent \| prev [-]
		[deleted]