#DeliveryTiem

1 messages · Page 1 of 1 (latest)

austere sandBOT
olive laurel
#

Taking a look

#

Could you try making the request again, but omit phase[0] (the one that has ended) from the payload?

proven bronze
#

Yep, I got another error: 'the subscription schedule update is missing at least one phase with a 'start_date' to anchor end dates to'. Request id is req_wGZ7DRduFYHDeq

olive laurel
#

Yeah, you'll need to pass start_date now that's the only active phase

proven bronze
#

I've ran into this before and that's why we pass in the old phase

olive laurel
#

Right, but I don't think that's permitted (hence the original error)

queen magnet
#

worth noting a test clock is being used here too(just saw that)

proven bronze
#

The API documentation says we can omit past phases, we don't omit them to pass in a comprehensive history of the phases to make sure the billing anchor doesn't change on updating

queen magnet
#

in your test clock it is May 16th 2023, so it could be that the issue is you're passing all these start_dates that are effectively 5 months in the past(you're passing e.g. 1673832225 for Jan 16th) , instead of relative timestamps to the time the API thinks it is.

proven bronze
#

Yeah we intentionally pass in the past phases that could be 5 months in the past, the assumption was that we can pass the first phase in to keep the start date of the second (current) phase the same after updating

#

The question I should ask is: should I not be able to pass in old phases with the start_date?

queen magnet
#

I don't think it makes sense to backdate a schedule like that(passing Jan 16 when the current date is May 16)

#

to me the way to do it is

  • create the clock with date X
  • create the schedule starting 'now' and a phase ending at like X+30 days
  • advance the clock to X+35 days
  • update the schedule to update the second phase(which should now be active), passing both phases 0 and 1(or possibly omitting 0 if that doesn't get accepted)

depends overall what you're attempting to test

#

sorry, I need to leave for lunch so have to run but my colleague can help

olive laurel
#

Let me know if I can provide any more context

#

Overall I'd agree that backdating doesn't seem logical, but equally its unclear to me whether its supported

proven bronze
#

It's not back dating, it's just telling the schedule what the old phases was so it can give the current phase the correct old start date (the end date of the old phase) when it updates the current phase.

olive laurel
#

So whilst that's not your intention, that is how the API is designed

#

My recommendation would be to omit the phase that has ended, and pass the desired start_date to the remaining phase you're updating

#

Otherwise I'd recommend writing in to our team and we can take a deeper look at this: https://support.stripe.com/contact

proven bronze
#

Ultimately, I have a subscription with a 1 month trial, then 9 months payment. Phase 0 is the 1 month trial, phase 1 is the 9 months payments. During phase 1 after the 4th payment the customer can change plans for the remaining 5 payments, we want to make sure the plan changes but still bills at the same date and time.

#

One minute reading that

#

and ty by the way

#

Got to do some thinking on this, can you keep this thread open?

#

Will be maximum 20 mins

olive laurel
#

Sure

proven bronze
#

Okay so I done some more testing and you can indeed update a schedule and pass in the past phase with the start_date. See request req_WYFkH7FXdKkMg5 (creation) and req_1hPvWyiaeOgkfD (update). BUT when I do the same creation & update requests and add metadata (creation: req_bwfy0g2vjDrnBJ, update req_OrPakpgF4BYFhE), I get the "You can not update a phase that has already ended. Trying to update phase 0." error. So it appears that there is a problem with the update request when trying to pass in the past phase with the same metadata.

#

Corrected the log ids for the create & update requests with metadata added.

olive laurel
#

My recommendation here is for you to write in. The server is very busy and this just requires a dedicated resource for us to look at this properly. Sorry

proven bronze
#

I'm gonna have to do a work around cause I can't see this being fixed or solved in the time i need it for, damn. I will write in.