lucas

[pearl mauve]

let subSchedule: Stripe.SubscriptionSchedule;
  if (sub.schedule) {
    subSchedule = await stripe.subscriptionSchedules.retrieve(sub.schedule as string);
  } else {
    subSchedule = await stripe.subscriptionSchedules.create({
      from_subscription: subId,
    });
  }

  const items = sub.items.data;
  const subModItems = items.map((i) => ({ quantity: i.quantity, price: i.price.id }));

  return stripe.subscriptionSchedules.update(subSchedule.id, {
    end_behavior: 'release',
    phases: [
      {
        items: subModItems,
        start_date: subSchedule.current_phase.start_date,
        end_date: Math.floor(millis / 1000),
        ...(sub.status === 'trialing' && { trial_end: Math.floor(millis / 1000) }),
        proration_behavior: 'none',
      },
      {
        items: subModItems,
        start_date: Math.floor(millis / 1000),
        proration_behavior: 'none',
        billing_cycle_anchor: 'phase_start',
      },
    ],
  });

thanks in advance 🙏

[stray tide]

Thanks for sharing! Looking into it now

[pearl mauve]

here's one that worked the way i expected, sub_1MqgWlEk6sr5GyDhCovpmnLU - it might come down to whether the schedule is pushing out the next invoice date or pulling it in. i wonder if the UIs next invoice date gets ultimately overriden with the schedule/phases attached.. i can try it out in test w a test clock

[stray tide]

I'm working with my coworker to find out why the upcoming invoice still remains as 2023-06-30 03:11:21 UTC

[pearl mauve]

thanks so much, im nervous that i gave this to my CX team and they're starting to use it quite a lot already so i'd hate to yank it back

and yeah - was able to repro the issue on test by pushing the next recurrence out past the "natural" recurrence and moving the test clock through the "natural" recurrence (what the original invoice date was) did create an auto collecting invoice, gah

so what im seeing is - pull forward, works as expected, push out, seems to invoice on that old natural recurrence then also invoices when the phase "seam" was

(brb 20 but ill keep an eye on this, thanks again)

[stray tide]

Subscription and subscription schedule are two independent objects. In sub_1MN6KzEk6sr5GyDhVWerb6F5, the subscription schedule https://admin.corp.stripe.com/request-log/req_38b7zwtEkhWHTP inform Stripe that subscription schedule will be changed on 2023-07-10 04:00:00 UTC.

The upcoming invoice doesn't consider future subscription changes and only consider existing subscription. Customer will still be billed from 2023-06-30 03:11:21 UTC to 2023-09-30 03:11:21 UTC. Only when 2023-07-10 04:00:00 UTC is reached, then the billing cycle will be changed.

On the other hand with sub_1MqgWlEk6sr5GyDhCovpmnLU, the subscription was set to end trial in https://dashboard.stripe.com/logs/req_3rvTyptlsogLiH that reset the subscription and billed for the period from 2023-06-09 16:50:47 UTC to 2023-09-09 16:50:47 UTC in in_1NH8WTEk6sr5GyDhKbFcLNRX. Since it has been billed, the subscription will follow the next subscription schedule update.

If the objective is to change the billing cycle, I'd recommend using billing_cycle_anchor on Subscription instead of using Subscription Schedule: https://stripe.com/docs/billing/subscriptions/billing-cycle#changing

[pearl mauve]

thanks for the reply,

yes - my objective is to change the next upcoming scheduled invoice date (and i've been in here a few times trying to accomplish this 😬 and the attempt above is the most recent advice),

i would definitely use billing_cycle_achor if it worked the way i need (arbitrarily move it forwards or backwards), but alas, you can only set billing cycle anchor to now. i see that i could use trial in order to move the next invoice date out, but i'd rather not - it screws up analytics (subs in trial aren't considered active customers) and we have a product need for trials so i'd rather actually use trial for its intended use case

is adding a trial really the only way to accomplish what i want to do here? that feels so wonky

[stray tide]

You can set billing_cycle_anchor to any future timestamp, not now only: https://stripe.com/docs/api/subscriptions/update#update_subscription-billing_cycle_anchor

From your given subscription examples, billing_cycle_anchor should work for your case by changing the next billing cycle

[pearl mauve]

ill give it a shot, but im almost certain that's not true... and what you link says it allows values "now" and "unchanged" - ill try passing a time value

yeah, here,

lucasgray@lucass-MacBook-Pro alloy-server % stripe subscriptions update sub_1NHA7dEk6sr5GyDh3OhGv6VK -d "billing_cycle_anchor"=1698814800   
{
  "error": {
    "message": "When updating an existing subscription, billing_cycle_anchor must be either unset, 'now', or 'unchanged'",
    "param": "billing_cycle_anchor",
    "request_log_url": "https://dashboard.stripe.com/test/logs/req_B8MDufK8iBBgkI?t=1686533787",
    "type": "invalid_request_error"
  }
}

(i'd love for this to work if i could submit a feature request :D)

[stray tide]

Can you share the request ID (req_xxx) of this request? Here’s how you can find it: https://support.stripe.com/questions/finding-the-id-for-an-api-request

Ah I see what the problem is! billing_cycle_anchor with timestamp is only applicable to new subscription.

With existing subscription, it can only be now or unchanged

With changing billing_cycle_anchor of existing subscription, it's only possible with trial

[pearl mauve]

shoot.... ok. it seemed like subscription schedules was the intended functionality to make this possible without trial

sad to see that's not the case

is there a way i can submit a feature request?

another annoying thing with trial separate from what i already mentioned - it generates 0 dollar invoices that i have to sidestep. not the end of the world, but sometimes we give people 100% off through our UI for certain use cases

[stray tide]

Thanks for the feedback. I'd suggest to write your feedback to https://support.stripe.com/contact

[pearl mauve]

ok thanks. i submitted there and the stripe subreddit