#brayden-subscription
humble quartz
Hello! Can you clarify a bit more - what do you mean by updating it with a date in the past?
summer root
Hey, so here's the subscription in question
The current period should be from April 15th, 2022 until Oct. 15, 2022
Then I need another period from Oct 15th, 2022 ending on April 15th, 2023
This is what the subscription had previously, but when I tried to update the schedule it made the date today's date instead.
I'd like for the customer to not be charged anything until Oct. 15, 2022 on the update though because they have already paid for this phase of their subscription
humble quartz
Taking a look now!
summer root
Basically, every time that I create a new schedule it sets the current phase from today's date on, and I really need the current phase to start on April 15th, 2022
If doing that with a schedule is the best way, that's fine. It's also fine if there's just a way to update the subscription itself to have a current price which is $1348.50 billed every 6 months starting on April 15th, 2022 and no schedule.
humble quartz
Backing up for a second - are you trying to create an entirely new subscription that has this backdated start date? Or are you focused on modifying the existing one you sent over?
summer root
I'd love to just update the current one..
If that's possible.
It has historic data that's just nice to have. If the only way to do this is to create a new subscription, then so be it.
I just need to be able to do this without charging the customer in any way.
The first time that they should be charged is on Oct. 15th, 2022 when the current 6 month period runs out.
humble quartz
Yeah the issue here is that it's in a bit of a weird state - are you solely using the dashboard, or are you also using the API?
summer root
Mainly just the API
I had to cancel out a few draft invoices that got created when I was trying to update the schedule previously so that the customer would not be charged.
I did this via the UI
That's why the customer has 2 $0.00 invoices today
humble quartz
If you're using the API then I think what you want to do is change the current phase to be from today -> October 15th, and then add on an additional phase that starts after that sets phases.billing_cycle_anchor: phase_start (see https://stripe.com/docs/api/subscription_schedules/create#create_subscription_schedule-phases-billing_cycle_anchor)
summer root
I really need the current phase to start on April 15th, 2022 though
Like it did earlier today before I messed it up.. is that not possible?
humble quartz
I don't believe that's possible anymore because the current phases's start date has already been changed - you could try and make the API request to see if it'll let you set the start date to be one that doesn't match the start date of the current phase, but I'm fairly sure it won't work
summer root
Hmmm is this possible with a new subscription?
Without charging the customer for the current 6 month phase?
I don't think our prorations will be calculated correctly for this current phase if the phase is not 6 months long..
humble quartz
Yeah you can create a new subscription setting backdate_start_date to April 15 2022, set billing_cycle_anchor to be October 15 2022, and then set proration_behavior: none.
The key thing here is passing in proration_behavior: none so that we don't charge you for the time between april 15 - october 15
summer root
Okay, makes sense. This might be the route that we end up having to go, it seems.
humble quartz
Yeah, once you get a subscription in a specific state it can be difficult to revert those changes
summer root
Yeah, this got out of wack due to a bug that we had, so we're not like trying to do this sort of thing often. I was hoping I could just easily fix it but it seems that I destroyed it lol I'll give this a shot and see if I can get it working. Thanks!
So I just did this.. and it charged my customer when the new subscription was created
This is very bad. It charged my customer almost $1500
Also, this did not honor the backdated start date
humble quartz
You didn't set billing_cycle_anchor. in your request - so the request believe the subscription was anchored today (which is why it charged)
summer root
Interesting, I did notice that I missed that.. I guess because I passed proration_behavior: "none", I figured it wouldn't matter.
You're sure that if I try again and add that it's not going to charge my customer again?
humble quartz
I'd recommend just doing a quick request in test mode just to be extra sure nothing else is missing