#patrick-subscription-schedules
lilac quail
Hi there 👋 it is expected for Subscriptions to start immediately, you would need to use a Subscription Schedule to start one in the future.
However, I'm curious to hear more about why you've elected to have the customer first pay via a Payment Intent and then create a Subscription for them? Typically with Subscription integrations, you create a Subscription, which creates an Invoice immediately for the first payment, and then use the Payment Intent from that first Invoice to process the initial payment. You definitely don't have to do things that way if you have a good reason not to, but it is likely easier than incorporating Subscription Schedules into your flow.
rotund birch
I found it a bit easier and more convinient, since the customer have to make the first payment before an EC2 instance will be opened on their behalf. I could listen to a webhook but that would add more complexity to it...
How do I attach the subscription schedule? Can I specify everything like before and only add a schedule paremeter to the object for subscriptions.create?
lilac quail
Nope, the other way around, you need to create a Subscription Schedule and pass it everything you would have passed to the Subscription creation request.
The Subscription Schedule will then create the Subscription in the future, based on what you set for start_date :
https://stripe.com/docs/api/subscription_schedules/create#create_subscription_schedule-start_date
A sample of that, in several languages, can be found here:
https://stripe.com/docs/billing/subscriptions/subscription-schedules/use-cases#start-subscription-future
rotund birch
I'll try it out, thanks @lilac quail !
lilac quail
Any time! Let me know if it gives you any trouble.
rotund birch
Sorry to bother you again, I am not following the iterations part. I want the scheduler to trigger an invoice for two items, once per month. Is it possible to also make it to run infinetly as long as the customer doesnt cancle the subscription?
lilac quail
The Subscription will do that, you don't need the Subscription Schedule to run indefinitely. Set the end_behavior on the Subscription Schedule to release (as shown in the sample) and the Subscription Schedule will release the Subscription at the end of it's lifecycle. The Subscription will then continue indefinitely until canceled.
Subscription Schedules are used to wrap Subscriptions and allow you to schedule changes that will automatically be applied to the Subscription in the future.
But the Subscription is actually the indefinitely recurring object.
rotund birch
So what should I specify in iterations? Does 1 suffice?
lilac quail
Yup, 1 will work
rotund birch
Thank you very much!
lilac quail
While you're playing around with those, I'd also recommend using Test Clocks:
https://stripe.com/docs/billing/testing/test-clocks
They let you put customers and subscriptions inside of small sandboxes where you can advance time, so you can see exactly how those objects will behave throughout their lifecycle.
rotund birch
Ok I'll do that, thanks for that tip as well. But now that I have the subscription_schedule created, how do I create a subscription with that schedule?
lilac quail
You don't, that happens automatically.
rotund birch
Really? That's it? So I dont have to make a subscription.create call and attach the scheduler?
If that is the case, then I wont be able to get the subscription_id until the we have reached the start_date I guess?
lilac quail
Exactly, there won't be an active Subscription until the start_date (part of why starting with a Subscription from the beginning may be easier if you're planning to use the state of the Subscription to determine whether a customer should have access to your service)
rotund birch
Ahh ok I understand, thanks for the help Toby!
lilac quail
Happy to help!
rotund birch
Last thing, so it gives me an error on start_date, how should I pass currentdate + 1 month to that key in javascript? I thought it used UNIX time?
lilac quail
Yup, second-precise unix timestamp is right. What is the error?
rotund birch
This value must be less than or equal to 9999999999 (it currently is '1705941490000').
lilac quail
Ah, I think that's a millisecond-precise timestamp, can you try dividing by 1000?
lilac quail
Awesome! Any time!
harsh fableBOT
rotund birch
Hey toby, I found an easier solution, I simply kept the billing_cycle_anchor to the same timestamp, and then added proration_behavior: 'none'
to subscriptions.create().
In the events it seems to be correct so far, are you aware of this solution?
lilac quail
Yup, but at that point, you're creating a Subscription up front, so I'd go back to suggesting you create a Subscription initially instead of a one-off Payment Intent followed by a Subscription.