#Santos - subscription schedule

1 messages ยท Page 1 of 1 (latest)

real saddle
#

Hello. One moment

real saddle
#

Sorry for the delay. Can you send over the request ID for creating the schedule?

dire otter
#

No problem. Here's the ID req_pYbLz7tyu0d7OP

#

The problem I am trying to solve is upgrading/downgrading the plans on a subscription schedule AND the plan on the subscription.

I tried updating the plans on the existing subscription schedule and then tried updating the plans on the subscription but the API call failed here req_XA8bi1P21AdAgP

real saddle
#

Ah I think it's because you updated the price

#

Can you share any request id where you updated the schedule?

#

Also, you would only need to update the plans on the schedule

dire otter
#

I believe I updated the plans on the schedule here req_YY3hzUDEt1DGX9

#

So if there's an existing subscription schedule, I would only need to modify the subscription schedule and not the subscription?

#

Also, is it possible to set proration_behavior to always invoice for a subscription schedule phase like we do for subscriptions?

real saddle
#

Yeah when you tie a subscription to a schedule, you should just need to update it there. For proration_behavior I believe it's just create_prorations and none

dire otter
#

Is it not possible then to prorate the upgrade/downgrade on a subscription schedule? ๐Ÿค”

real saddle
#

That's what create_prorations does

dire otter
#

I see

#

When modifying a subscription, I set proration_behavior="always_invoice" and the customer is either charged the difference between the plans (upgrade) or they receive a credit to their account (downgrade) which we are then refunding.

Now I am passing proration_behavior="create_prorations" when modifying the subscription schedule but customer is not billed automatically: https://dashboard.stripe.com/test/customers/cus_LczY8plrcrcwUb/upcoming_invoice/sub_1KvjZ8ELRGuFUMs6jDTHSLqD

rough aurora
#

Hello ๐Ÿ‘‹
Catching up here
Can you give me a summary of your latest question? thanks ๐Ÿ™‚

dire otter
#

Sure thing.

I am trying to upgrade/downgrade the phases on a subscription schedule.

I can do this with no issues on a subscription and am able to invoice the customer for an upgrade or credit a customer for a downgrade by setting proration_behavior="always_invoice"

However, I can't seem to do the same when upgrading/downgrading the plans on phases on a subscription schedule. I am able to correctly update the plans but am seeing pending invoice items.

rough aurora
#

Thanks
And just to make sure I'm looking at the right sub
sub_1KvjZ8ELRGuFUMs6jDTHSLqD that's the one on which you're having trouble with prorations?

dire otter
#

Sorry about that. I am now working with sub_1Kvk98ELRGuFUMs68rY8CRkL

#

It looks like I am able to correctly modify the subscription plan first AND then modify the plans on the subscription schedule phases with no prorations.

However, there should only be 2 phases (current phase and next phasae) and I am seeing more than that on the subscription schedule.

#

When we modify phases attribute on subscription schedule, does Stripe append or override? ๐Ÿค”

rough aurora
#

can you share the subscription schedule update request ID as well?
As far as I know If the update changes the current phase only then the prorations are created.
It is possible that your current phase is intact and the updated phases are appended and scheduled as next phases

dire otter
#

Sure thing

#

req_Z1VzdGYcm7fhNv

fossil flume
#

๐Ÿ‘‹ stepping in here for @rough aurora as they need to step away. Catching up

#

Right off the bat though that update request sets proration_behavior: none

#

Also to be clear, updates override the previous schedule. They don't append.

#

You will see past phases returned when you update, maybe that is causing confusion?

dire otter
#

Ah

#

Yea I'm seeing the past phases being returned in the response.

#

Is there anyway to distinguish current from past phases?

fossil flume
#

Hmm I don't remember the best way to do this. You could look at the end_dates. I don't remember top of head if there is a better way.

#

I'd take a look through the properties returned

dire otter
#

Ah I see the timestamps in the current_phase property line up with the ones I'm updating - makes sense.

#

Cool, I think we're done here - thanks!