#krizanfil_unexpected
west glenBOT
👋 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/1445439412161876038
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.
- krizanfil_docs, 14 hours ago, 7 messages
white plinth
hi there, can you give me an ID for a subscription where you noticed this happening? it should look like sub_1234
karmic minnow
Example id from our test mode: sub_1SZuFvHBbQpI2OUJf8o3UlwG
Sets cancel_at, but not cancel_at_period_end.
white plinth
thanks, investigating this now
ok, so looking at internal docs, it looks like flexible billing mode subscriptions cancelled via the billing portal will only set cancel_at. this is related to changes made to support mixed interval subscriptions https://docs.stripe.com/changelog/basil/2025-07-30/cancel-at-enums
I don't think this is explicitly called out in our public docs however, so I'm going to file internal feedback to make this more clear
karmic minnow
-
Hmm, but is that not incorrect ? Since current_period_end matches cancel_at and yet cancel_at_period_end is set to false on the subscription, seems to me like there is no reason for cancel_at_period_end to not get updated as the status of the actual subscription is changing. Could you raise some appeal to investigate if this is actually not a better design ?
-
Then is having cancel_at being set a clear indication that the subscription is not going to start ? Or which data point should I be looking for to be able to tell if the subscription is going to start or not ?
Thank you, for the fast responses and help!
white plinth
you should look at the cancel_at attribute for flexible billing mode subscriptions. classic mode subscriptions will still set cancel_at_period_end when cancelled from the portal. I agree that it's confusing and I will be raising this with our internal product team
karmic minnow
Okay, thank you very much. Helped tons. 😇