#DeliveryTiem-cancel-subscription-future
1 messages ยท Page 1 of 1 (latest)
Hi ๐ can you share the ID of the Subscription that you used for your testing?
Hi toby, yep it is sub_1MNFzEIUwLvVicLYUEmAIYcB
Thank you, working on pulling that up.
Hm, first pass through it does look like the date you're setting aligns with the end of the period. Have you tried using cancel_at_period_end rather than cancel_at?
https://stripe.com/docs/api/subscriptions/update#update_subscription-cancel_at_period_end
Complete reference documentation for the Stripe API. Includes code snippets and examples for our Python, Java, PHP, Node.js, Go, Ruby, and .NET libraries.
We don't use cancel_at_period_end because we set the cancellation date when we create the subscription
Can you elaborate on that, because the creation request for that Subscription doesn't seem to align with that:
https://dashboard.stripe.com/test/logs/req_tCMHDyU5mTZ4eC
Yep can help you understand, this test clock subscription has 10 instalments (first is a trial)... realized halfway through advancing time that the cancel date was not set. I set the cancel at date before the final instalment was done.
For the sake of sanity I can re-create this scenario with the cancel at set at subscription creation
I actually think the approach used here with Subscription Schedules would be more consistent, you can set the desired number of iterations for a phase and then set the end behavior for the Subscription Schedule to cancel the associated Subscription.
Complete reference documentation for the Stripe API. Includes code snippets and examples for our Python, Java, PHP, Node.js, Go, Ruby, and .NET libraries.
DeliveryTiem-cancel-subscription-future
oooooh
I haven't looked at this yet but this sound like the right way to go, i'll check it
The concept of schedule subscriptions is good however we have no type of implementation for this and we will have an issue with retrospectively applying this to thousands of active subscriptions. I would like to be able to use the cancel_at for now as it is the least invasive approach. I have made a new subscription using the test clock and this time i made the cancel_at date at subscription creation... yet still getting a different amount at the last instalment
Subscription is sub_1MNHnWIUwLvVicLYVNFQecWy
Thank you for the ID, will check in to that and get back to you
Thanks Pompey
Hi there. I'm helping Pompey with this. The cancel at date in this case was set to 4:00 UTC on 11/05, but the billing cycle anchor is set to 15:21:50 UTC. Can you try again, matching the cancel at timestamp to the billing cycle anchor's timestamp?
But to respond to your earlier point about converting existing subscriptions to subscription schedules, this can be done with this api call (if you decide to go that route): https://stripe.com/docs/billing/subscriptions/subscription-schedules/use-cases#existing-subscription
Hey duchess, I will try that with the billing cycle anchor set. that's fair with the schedule attachment. Regarding the schedule, I'll provide an example case we would need to cover. We have an existing subscription that is set to have 10 instalments, currently they currently at instalment #6's period... that means there are 4 future instalments. I can attach the schedule to it but how do I update the schedule to make it so the subscription cancels when the 4 future instalments are completed. Do I update the phase iterations to 4?
Oh I see. Yeah that's a bit tricky since you'll be partially through an iteration
It might be easier to just keep existing ones as is but use subscription schedules for future subscriptions
That being said, there's nothing wrong with your current approach of using cancel_at with normal Subscriptions
It's just a matter of getting the timestamp right
Yeah it's an interesting case, i'll work on that billing cycle anchor... i'm close to EOB here with no space to work overtime so it may be tomorrow I get to complete this... can this thread be kept live or do you advise making another one
Yeah we archive threads after a bit of inactivity just to keep our list of opened threads maintainable. Just message again in the main channel and we'll open up a new thread for you when you're ready