fletch0803

[whole socket]

Hello! Do you have a subscription ID that I can take a look at?

[barren herald]

Sure - 2 secs

sub_1ND5XUGn9miQ13OtYa4ttvaA

[whole socket]

Ah so the issue here is that there isn't really a nice way to anchor on the last day of the month - you created this subscription and anchored it to 1688166000 (which is
2023-06-30 23:00:00 UTC time, 2023-07-01 01:00:00 in your timezone). This means we'll always anchor on the 30th of each month (which is not the same as anchoring on the last day of the month).

A month later would be 2023-07-30 23:00:00 UTC, which is the same as 2023-07-31 01:00:00 in your timezone

[barren herald]

So the issue here is that I need to anchor the the correct UTC to the 1st on the month (as is out requirement). Ok, thank you - that makes sense. I recently bumped the hours forward away from middnight anyway so I don't think we will have the issue again.

Thank you. Is there a quick way to re-point / reassign future payment dates back to the 1st of the month as they are now stuck (for a few cases) to be the end of the month?

[whole socket]

There's a couple of different options you could take and you'll want to be really careful with prorations

• you could use a subscription schedule and create a phase that ends on the first on September and have it reset the bililng cycle anchor when it transitions to the next phase
• Wait until September 1st and then make an update request to set billing_cycle_anchor: now.
• Cancel this subscription immediately (with no prorations) and create a new one with backdated_start_date set to the original start date of the last subscription, proration_behavior: none and billing_cycle_anchor set to the 1st. This should create a new subscription that won't charge anything until the 1st (and from then on should be on the correct anchor)

[barren herald]

Awesome dude - I'll read and digest these. Many thanks for a speedy response! Have fun - if you can.

[whole socket]

👍 glad I could help!