Stripe subscription with future start date

  • 27 July 2022
  • 3 replies

Userlevel 1
Badge +5

We run into a use-case that seems like an edge case but ends up being more common that you’d expect.

  1. User subscribes via App Store, let’s say an annual plan that ends on 2023-01-01.
  2. In the middle of the subscription, user now wants to be billed through Stripe (receiving a promo code or something like that). It is too late for a refund.
  3. User cancels their App Store subscription, though it is still active until 2023-01-01.
  4. User wants to purchase their new Stripe subscription but only get billed once their App Store one ends in the future.

There are a few ways to do this:

  1. Just not support this at all, and force users to wait until their App Store subscription expires before they purchase their Stripe subscription (less than ideal).
  2. Let the user purchase their new Stripe subscription, but with a really long trial duration so that during the overlap period, they have the canceled (but non-expired App Store), then on 2023-01-01 when the first one expires, their Stripe trial ends and they get billed. This seems like kind of a hack, because they will have an active subscription and a trial subscription at the same time.
  3. 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.

Curious if anyone has any advice.

3 replies

Userlevel 3
Badge +5

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. 

Userlevel 1
Badge +5

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.

Badge +6

@Ozzie Osman - In the same boat - intrigued as to whether you have any updates / solutions?

Only workaround I can think of right now is:

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