Hey Ozzie,
Use Stripe to start the subscription in the future. We tried using Subscription Schedules but those don’t seem to sync over to RevenueCat, since the subscription technically hasn’t started yet.
Will look into this to see if it’s a gap. I’m not sure how we’d represent a subscription that will happen in the future or if it makes sense. Curious what your expectations would be here.
All of these solutions are kind of hacky. This has always been a tricky thing to try and square. Solution #3 seems pretty good if it works as expected, but I don’t know if we need to add some sort of support to make it work better.
#2 isn’t terrible either. But, without a somewhat complicated billing display setup, it may be hard to communicate to the user the state of their billing.
I’d really consider the ROI vs the implementation and customer experience challenges. It might be easier and better ROI just to market to customers who have already lapsed.
Thanks Jacob! Yea after thinking a little more, we agree it’s not trivial for RC to handle, given the way Stripe handles these “future subscriptions” (the “subscription schedule” is a separate entity from the subscription, and it creates or modifies subscriptions).
In an ideal world (which doesn’t seem possible), we would just create a subscription with Stripe with a future start_date, but they don’t allow that—we’d have to use a subscription schedule that would then create the subscription in the future.
The free_trial thing is a hack, and that’s what we’ve been using, but it adds a lot of complexity because we then have to distinguish between “real” trials (when a user signs up) and these “pseudo-trials”, which are just padding to adjust the start date.
We might end up just not supporting this flow, but the reason we want to support this use case is because it ends up being surprisingly common. Users who have paid via the App Store want to switch to Stripe to redeem some promotional offer (discount, free period, etc), and so if we don’t allow a flow like this we’d have to tell them to wait until their App Store subscription actually expires (which could be many months for folks on an annual plan).
Would be curious if any other folks have figured a way around this. Perhaps the most “proper” way would be for us to use the Subscription Schedule, which we’d have to manage on our side (since RC doesn’t have it), then when it does materialize the new subscription, send that over to RC… it just adds some complexity because now we have this extra thing that needs to be created/edited/deleted by users.
@Ozzie Osman - In the same boat - intrigued as to whether you have any updates / solutions?
Only workaround I can think of right now is:
- If someone is a long way away from their expiry date, send a custom offer code. Payment goes through Apple and Apple will handle the complication of adding the offer at the end of the current subscription period.
- Only send payment links via Stripe if the person is close to their expiry date.
This doesn’t seem ideal and as you say I imagine this is a very common scenario.