#jdraiv_sub-cycles-schedule
1 messages ยท Page 1 of 1 (latest)
๐ Welcome to your new thread!
โฒ๏ธ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.
โฑ๏ธ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.
๐ This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1336033509470634015
๐ Have more to share? Add more details, code, screenshots, videos, etc. below.
Hi ๐
I'm taking a look at that event you provided. Let me spend a little time digging into this.
Hi! Sure, no problem, feel free to take your time. Here's the subscription ID btw: sub_1QlzlVHa8lMqdc2usWua6yXC
This invoice appears to be covering the time between 1/29 - 1/30
I'm looking at the request that created the Subscripton now.
It was created on 2025-01-27 21:22:41 UTC and set to cancel on 2025-01-30 21:12:41.
It looks like the the timestamp for cancelation did not match the natural billing period by ~10m
If your goal is to charge a customer for 3 days, with each day representing a new payment cycle, then I recommend using Subscription Schedules.
You would create a single phase that represented your daily price and specify the iterations: 3
This would ensure that the subscription cancels at exactly the 3rd iteration with no prorations
Oh got it, I think we substract 10 minutes from the calculated end date to avoid some dates to collide in our end. I will take a look at your suggestion. Thank you so much for your help! ๐
Doing the math to get the timestamps accurate can be tricky, especially if the code you are using applies a timezone (we use UTC for everything).
That's why we recommend using schedules. If you want your customers to have 3 iterations of the billing cycle, it makes more sense to just let you say that in your API call.
I see! And you know if there's a way to set the cancel_at and don't apply prorations for all periods of the subscription, or if possible adjust that directly in account settings?
What you would need to do is ensure you specify proration_behavior: "none" for any request that creates/updates the Subscription.