#nachofranco14-sub-schedule
1 messages ยท Page 1 of 1 (latest)
you cannot create a subscription that runs for more than 20years
Got it, in that case the start date will have no impact on that as the schedule won't actually create the subscription until the start date
Request req_m8L9aK1x3yOF6V: You cannot create a subscription schedule that ends more than 20 years in the future.
I think it's better to check the logs ๐
in that case, I created a subscription schedule that start 2022-01-01 and runs monthly 240 iterations (20 years)
I don't think the start date is the issue
Request req_oJ8C21YjE7Amjm: You cannot create a subscription schedule that ends more than 20 years in the future.
check that one
I made a mistake in the first one
I guess that answers your original question then. Doesn't seem like its possible
I'd be really happy if you help me to find a nice workaround
have you faced this constraint before?
I have not! Help me understand your use case
we need to run subscriptions that are exactly of 20 years, but we want to kick them off "the 1st of next month"
so, as far as I understand, it should be a subscription schedule
What do you mean by 'kick them off'? The initial paid billing cycle?
yes
A couple of options then I guess:
โข Create a subscription immediately with a free trial period set so the first paid billing cycle begins on 1st of next month. You can also set cancel_at at the required date (20 years).
โข Create a subscription schedule for less iterations, and then update the schedule say 1 year into the subscription to 'bump' the iterations.
It's a bit if a nuanced use case so there's no perfect way to do it unfortunately ๐ฆ
hmmm
okay, did you tested the options?
I'm not sure whether the first one will work
I have not, no. Pretty hard to test the 2nd options due to the required length!
How come?
because that will still be more than 20y
How come?
if I create the subscription today, with a free trial until 2022-01-01 and then put cancel_at="2042-01-01" it will be 20y and 16d
If you need the subscription to be created on a specific date (as opposed to using the trial) then scheduling is the only option (outside of deferring the API call with your own logic)
Got it โ I assumed you meant 20 yearly paid billing cycles which was why I asked
yeah, that could be another option, to create them in a batch every 1st of the month but I don't really like the idea
okay, one more, let's say that I don't put the "cancel_at" field, what would happen after the 20y run?
will be canceled, released, changed to inactive or will it keep deducting the customer?
depends on the end_behavior you pass
or ok, we are not using Schedules now, just a Subscription?
then if you don't use cancel_at then the subscription just continues forever
right, I wanted to double check, maybe the restriction of 20y remains the same
thanks for the help @livid spruce and @shadow girder , if I have more doubts I'll come back here ๐
have a nice Friday
Np!
quick one!
what would happen with the invoice if I create the subscription today with the free trial until the 1st of next month?
is the customer going to receive an invoice of 0 at the moment the subscription is created?
you'd get a $0 invoice yes
it's not sent to the customer though via a receipt etc(that only happens when there's an actual payment), it's just for bookkeeping
ah okay! that's what I wanted to know
so, no notification to the customer
awesome!
so I can do the following
sub_1K7HyKBEDYDqpisu1dljZlpV (check the params from there)
I don't know if you can see the req_id using the subscription id but, basically what I've done was:
- create a trial until 1st of next month
- set the cancel_at to 2042-01-01
will it run for 240 months or less? would the last month be computed completely or should I set the cancel_at to 2042-01-31?
maybe an important point to make here is that we don't prorate, it's not usage, it's a single payment per month
it will end at the exact UTC timestamp you specified in cancel_at (I mean in theory, but this is 20 years in the future so it's hard to predict :p . I'm just going to mentally assume dates in the next year instead).
so it cancels at Tuesday, 31 December 2041 23:00:00Z.
The billing cycle you set is Saturday, 1 January 2022 10:35:04 which means it will try to invoice on the 1st of each month at 10:35.
So what might happen (in 20 years, in theory) is the subscription will cancel and a small proration discount would be added (because the time up until the 1st at 1035 was already paid for in December's invoice so that ~11 hours of time has to be returned back)
But I'm not sure if that's what happens when using cancel_at , I'd have to test it(which I'm doing now so we'll have to wait a few minutes)
but yeah overall I don't see the point of setting up a subscription to explicitly cancel in 20 years like this, it would be easier to just create the subscription normally (repeats forever) since 20 years is basically infinity; you can handle cancelling it as a normal support request for your business or so on
well, because I won't be around in 20y and I want the stuff to be done properly ^^
anyway, I'll wait for your tests
hmm, but your company and customers will be around and their payment methods will be valid?
and I REALLY appreciate this support
I really think you're over-optimising here
ofc
they are supposed to pay
so
and well, for the payment methods, they could change but that's an easy thing to do
just let me know the results of your tests please ๐
and also, regarding the proration discounted, I could deactivate the proration to avoid it right?
ack
well I'm running a test with cancel_at:now+10 minutes to see what invoice if any happens at the end
well that's what I'm trying to figure out, since generally proration is not a "mode", it's an option on each update so not sure how it works here for cancel_at
cool, thank you
note you can test all this too
I'm not sure how to emulate the 20y ๐ฆ
you don't have to do 20 years, you can do a shorter period to test the underlying principles
ah, right
but one of the most important things is to know whether the customer will be charged all the 240 times or not
I think that the best "date range" approach should be with cancel_at="2042-01-31", since the customer is also paying for the entire month
but then if the customer doesn't pay I don't want the subscription to be automatically cancelled..
would that be the case? (so let's say that the customer doesn't pay the last month and we cancel the subscription the 31st, the invoice not paid remains there right? it's not like the customer will skip that last month)
ok I tested the cancel_at thing.
If you have this :
The subscription cancels at Tuesday, 31 December 2041 23:00:00Z.
The billing cycle you set is Saturday, 1 January 2022 10:35:04 which means, it will try to invoice on the 1st of each month at 10:35.
What happens is on 1st December, there is a prorated invoice from 1st Dec-31 Dec 23:00, so basically that last month is a little less than all the others. To avoid that you'd need to cancel_at directly on a billing anchor.
Dropping in here. To prevent the prorations, can you not pass proration_behaviour: 'none' on subscription creation? cancel_at adheres to that parameter (which by default is create_prorations): https://stripe.com/docs/api/subscriptions/create#create_subscription-cancel_at
as far as I can tell that doesn't change anything
๐ฆ
I would expect that it did
okay, no worries at all, I will put the cancel at at the very end of the billing anchor of the last month I want to charge the customer
thank you both for your help
is there a place to say: "Hey, these two guys helped me a lot today!" and maybe after that you receive some kudos from Stripe?
and by Kudos I mean bonus haha
thank you for the kind words! We'll mention it to our manager ๐