teelu_api

[dawn crypt]

👋 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/1265793144193028247

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

[waxen meadow]

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.

• teelu_api, 2 days ago, 43 messages

[opal schooner]

Hi there

[static wing]

Hi @opal schooner 👋

This is not related to the issue 2 days ago, that bug was resolved during the chat, this is from another thread a few weeks back which directed me to support, but that has not proven to be of any help. I have spoke to 8 different agents with not a single one answering any questions or providing any insight into this issue.

sco_QP8HzxhGYVnxqA is the case number but there is not anything helpful in there sadly

[opal schooner]

Okay, let's focus on the two Schedules

[static wing]

sure thing! those request id's show what is going on

This is the working request that doesn't alter the billing anchor, req_f3edGXjX4n7EIu

this is the request altering the billing cycle anchor, req_YBZQWi0bi5PhRp, which is problematic

[opal schooner]

Okay, it looks like our engineering team dug into this and confirmed this issue should no longer affect any Subscriptions created/migrated after May 21. If you have any examples of Subscriptions that were created/migrated after that date, can you share those IDs here?

[static wing]

We halted our migrations due to this issue so let me see if there is any that that were created after May 21

found one from May 22 😢 req_vXOEM0V70Qb9jY

i'll try to find some more

[opal schooner]

Thanks! I suspect that one from May 22 still occurred while we were deploying the fix more broadly

Give me a few minutes

[static wing]

Fair, timezones probably play a part in it appearing on May 22nd. Do you have any details of what the fix is?

I dont have a fast way to identify these as I can only filter the subscription on Stripes UI by one 'yearly' price

another one from May 22, req_Xe2el2naXTRCK5

[opal schooner]

Okay, so the fix resolved an issue where we weren't preserving the original billing cycle anchor on the Subscription if a managing Schedule was updated to remove or extend the cancel date

[static wing]

Okay, that gives me a bit more confidence. It looks like anything created post May 22nd, doesn't seem to have that issue, although only a small % of customers have "renewed" or extended their phase which is set to be cancelled. that sounds inline with the bug mentioned

[opal schooner]

In the example you shared (https://dashboard.stripe.com/logs/req_YBZQWi0bi5PhRp) the end_date was extended to July 2025, so that changed the billing cycle anchor to the Subscription created date instead of keeping the originally-used July 2024

[static wing]

Are there any suggestions on how to fix subscriptions created prior to that date? Our original process is to provide a credit for the previewed subscription, and then create the subscription so that there is a net 0 charge

Correct, and that subscription was created on May 14, prior to the mentioned fix, resulting in the issue

We have a bunch that were created prior to May 21, which have not renewed and thus are still suscetible to the issue?

[opal schooner]

Correct, only new subscriptions will not be affected

[static wing]

another from May 22nd, req_gE9jmp95IGquVG, seems like we just missed the fix being deployed with a few of these

okay so its probably best that we recreate any subscriptions created prior to May 23rd (since we have some on may 22nd) that have a scheduled attached set to be canceled when phases are complete.

Theres no easier way to ensure we dont run into this bug?

[opal schooner]

For previously-created Subscriptions, the options are to recreate them or edit them though the edits will involve adding more phases to the Schedule before/after the desired billing cycle anchor date

Our team can help identify the affected subscriptions, if that would help.

[static wing]

yes please, if that is possible, it would be a great help

Editing the phases will involve waiting until the next "phase_start" to update the billing cycle anchor which could already be in the past. I think recreating them would be the best option and we'll have to do a similar approach of previewing the subscription, crediting them that balance, and then creating the subscription to ensure a net 0 charge to the end user.

This one interaction has been so much more helpful than 3 weeks of back and forth with support. I normally reach out here but was directed to the support team for this issue hence I thought it was a bit more complex but i really do appreciate the info and assistance on this one @opal schooner 🙏

[opal schooner]

Happy to help! Unfortunately, this was a pretty complex fix from what I can see. That meant it likely took more folks some time to grasp the impact, how to move forward

Thanks for working through this with us and with me in this thread

I'll flag in your support case that you'd like some help with a list of affected Subscriptions. I can't share those here, unfortunately

[static wing]

Understandable and for sure, we want to ensure a smooth experience for our customers as well and this was a bit frustrating to deal with.

Sorry one last question while I have you, the default settings when updating a phase to include the billing_cycle_anchor mentioned here https://docs.stripe.com/api/subscription_schedules/update#update_subscription_schedule-default_settings-billing_cycle_anchor, any idea what "automatically change it if needed" means, like what are the underlying conditions for that?

[opal schooner]

Ah, I think it's if you want the billing cycle anchor to be set automatically at the end of a trial (if you use a trial period)

[static wing]

Okay, we dont use trial periods in our phases so i think as long as we never set thedefault_settings.billing_cycle_anchor value, it should not changeor get altered going forward for any subscription created after May 21?

I can relay that back to my team as well if thats accurate

[opal schooner]

Not quite sure I follow

I understand you're recreating these Subscriptions. If you use the same migration scripts when creating the Subscriptions, you shouldn't run into the same issue with billing cycle anchor

[static wing]

I mean we never set the default_settings.billing_cycle_anchor setting as you saw in the various requests I shared. As long as we keep that same approach and recreate those subscriptions, extending it again in a year with the same request (end date would change to an additional year, hopefully altering items doesn't bring this bug up again), the billing anchor should theoretically stay the same for any subscription created after May 22, 2024

[opal schooner]

Correct

[static wing]

awesome! that helps me tremoundously and I can start working on a script to recreate those subscriptions. I'll follow up on the support thread that I need assistance identifying all the affected subscriptons as you mentioned. Thanks again @opal schooner 🏆

[opal schooner]

Happy to help!

[static wing]

Is there anywhere I can leave you a review for how helpful you've been today?

[opal schooner]

Here is good or in #1211832777608273960 🙂

[static wing]

Done!

Curious, now that the backend fix is in place so changes to subscriptions schedules that cancel at the end, no longer affect the billing cycle anchor, why are older subscriptions still susceptible to the issue?

[hollow notch]

Hi @static wing I'm taking over this thread, give me a sec to catch up the previous discussions

[static wing]

No worries!

[hollow notch]

Is your question about why after setting the end_date the billing_cycle_anchor is reset to the subscription creation date for subscriptions created before May 22? For example req_YBZQWi0bi5PhRp

[static wing]

we got to the resolution on any subscription created after May 21st should be susceptible to the bug where ```Okay, so the fix resolved an issue where we weren't preserving the original billing cycle anchor on the Subscription if a managing Schedule was updated to remove or extend the cancel date

shouldnt be susceptible* i am trying to ask why the fix, even though its deployed to production, only affects subscriptions created after a certain date, even though the requests to change the end date of the phase is the same across any subscription

[hollow notch]

I see. I'm afraid that I'm unable to answer this question. Can I suggest you to reach out support so that they can pass along your inquiry to the owning team? https://support.stripe.com/contact/email