#Subalee

1 messages · Page 1 of 1 (latest)

night valleyBOT
terse lagoon
#

That sounds like it could be expected behavior though I am not 100% sure. Checking in to this and will get back to you

elfin gull
#

Thanks for the quick response, to provide a little bit more context. Every schedule has 2 phases.

The first phase consists of the current state of the stripe subscription.

The second phase has the updated version of that subscription with the phase start_date is set to subscription.current_period_end

So basicall this should be the time when the subscription auto-renews.

When changing between different products/prices Let's say going from a PRO plan to a BASIC plan the invoice that is generated has the billing_reason set to subscription_cycle This is what I'd expect to happen.

Now imagine everything stays the same when it comes to the phases except for just switching to different price we also switch to a one with different interval. Meaning going from a yearly PRO price to a monthly PRO price.

When I advance the test clock in this case the invoice that gets generated on billing cycle has the billing_reason set to subscription_update even tough it's also the subscription_cycle

IMHO if there is a schedule it should behave more consistently.. Either all should have subscription_update or subscription_cycle

Let me know what you think, thanks a lot!

#

This is what the phase set up looks like

phases: [
          {
            start_date: stripeSubscription.current_period_start,
            end_date: stripeSubscription.current_period_end,
            items: stripeStartingPhaseItems,
            proration_behavior: 'always_invoice',
          },
          {
            proration_behavior: 'always_invoice',
            start_date: stripeSubscription.current_period_end,
            items: stripeEndingPhaseItems,
          },
        ],
#

test/customers/cus_NjLAT0kPdFLyJS the test customer where I pulled the screenshot from

terse lagoon
#

As far as I can tell this is expected behavior. I agree that it would be better if it was more consistent and I can put in feedback for that though unfortunately that wouldn't get changed until a future API version as changing this could break existing subscriptions that rely on the current values of those fields

elfin gull
#

All righty! thanks for the explanation. I fully understand it's not something that can be changed immediately.

I was more curious whether its not something on our end as in setting up the schedule wrong or something like that

terse lagoon
#

Hey actually with some more testing I found something that may help you here. I just tried creating a subscription that uses the iterations parameter to change phases and for that we actually do give a billing_reason of subscription_update for those invoices. So for you it would look like this:

          {
            start_date: stripeSubscription.current_period_start,
            iterations: 1,
            items: stripeStartingPhaseItems,
            proration_behavior: 'always_invoice',
          },
          {
            proration_behavior: 'always_invoice',
            items: stripeEndingPhaseItems,
          },
        ],````
#

So at least when using that, the reason will consistently be billing_cycle

elfin gull
#

Awesome, I'll give it a try!