#lion-schedules

1 messages ยท Page 1 of 1 (latest)

urban parrot
#

it's fairly obscure and I can't really think of a simple use case that would require passing this

leaden solstice
#

My use case is the following:

My company bills from 1st until the end of each month.

  1. One of my customer is finishing his subscription on 15th. Subscription has an upcoming invoice on 15th.
  2. My customer changes his mind and doesn't want to end the subscription anymore. I cancel his end_date but there is still an upcoming invoice to be generated on 15th.

Ideally I would like to reset his billing anchor to be at the 1st of each month and have no upcoming invoice to be created on 15th since I don't need it anymore.

#

I was wondering if this parameter could help but since it is rather obscure I will not use it ๐Ÿ‘

urban parrot
#

thinking...

#

Subscription has an upcoming invoice on 15th
do you mean the 1st of the next month? Not sure how there would be an invoice on the 15th there โ€” I assume you are describing using cancel_at_period_end in general for this 'cancelling the subscription' use case?

#

oh okay you're using a Schedule overall to manage the subscription so maybe you don't use cancel_at_period_end

leaden solstice
#

Sorry for not being clear. I could not respond earlier because of meetings.

do you mean the 1st of the next month?

Yes absolutely that is what I meant

Not sure how there would be an invoice on the 15th there โ€” I assume you are describing using cancel_at_period_end in general for this 'cancelling the subscription' use case?

If you cancel a Subscription at a certain date. Stripe will set the Subscription billing_cycle_anchor to this date. I believe the main purpose is to have a final billing before a subscription ends.

However when you want to cancel the "cancellation" Stripe does not change the billing cycle anchor. The billing cycle anchor is still the previous end date of the Subscription which is not suitable in my use case. I want the subscription to be invoice each 1st of the month (real estate company).

I don't use cancel_at_period_end. Either I'm updating the Subscription or updating the current phase of the Schedule which manages the Subscription.

Stripe::Subscription.update(subscription.id, {cancel_at: cancel_at_date })
schedule = Stripe::SubscriptionSchedule.create({from_subscription: subscription.id})

first_schedule_phase = schedule.phases.first.as_json
first_schedule_phase["end_date"] = #any date within current billing cycle

Stripe::SubscriptionSchedule.update(
  schedule.id,
  {
    end_behavior: "cancel",
    phases: 
    [
      first_schedule_phase
    ]
)
urban parrot
#

oh, ok. I rarely use cancel_at , it's odd that it updates the anchor but I suppose you're right, it's so that a final invoice is generated. If we don't change it back when you set cancel_at to "" to cancel the cancellation then I'd imagine you'd want to set billing_cycle_anchor at the same time, like Stripe::Subscription.update(subscription.id, {cancel_at: "", billing_cycle_anchor:first_of_month, proration_behavior:"none" })

For a schedule though it should be just updating the phases (like in your example there) and changing end_behavior back to "release" I think. Sorry for the uncertainty, this is a bit of a complex scenario and not something I've directly tried

leaden solstice
#

I'd imagine you'd want to set billing_cycle_anchor at the same time, like Stripe::Subscription.update(subscription.id, {cancel_at: "", billing_cycle_anchor:first_of_month, proration_behavior:"none" })

Yes exactly. However looking at your doc the only 2 values authorized for the billing_cycle_anchor parameters when updating a subscription are either "now" or unchanged".

https://stripe.com/docs/api/subscriptions/update#update_subscription-billing_cycle_anchor

For a schedule though it should be just updating the phases (like in your example there) and changing end_behavior back to "release" I think.

That's what I also assumed but it actually changes the subscription billing_cycle_anchor. You can see an example using the following subscription id sub_1K3gTCEqnnYTeijJZ65rHWhA

Sorry for the uncertainty, this is a bit of a complex scenario and not something I've directly tried

No worries. It was worth trying it !