#Bertrand
calm flame
Billing cycle anchor is changing to the 20th right? So the first full month would be June 20-July 20.
There's no proration to give on the previous price since it was $0
whole island
No proration indeed - and expected.
However, the upgrade was made through the Customer Portal and I don’t understand why it is changing the anchor date in one scenario and not the other…
I would expect the anchor to stay the same, irrespective of the « previous » price before the upgrade. Here we can see that the anchor is moved when the previous price was « Free » while it stays the same in the other case when it was « Paid » 🤔
calm flame
Ah I see so the issue is the inconsistency with modifying the billing cycle anchor
Let me look into why this happens
whole island
👍
I scripted both scenarios trying to replicate what the Customer Portal is doing, and I could reproduce the same behaviour. However, everything is working fine after adding -d "billing_cycle_anchor=unchanged" to the subscription update request... What the Portal isn't apparently doing 😦
calm flame
Ok not sure what's happening actually
Let me ask a colleague to see if they think this is expected
whole island
Of course go ahead - you are our last chance… I’m puzzled now.
lilac novaBOT
calm flame
Ok so heard back from my colleague. This is due to: https://stripe.com/docs/billing/subscriptions/upgrade-downgrade#immediate-payment
Unfortunately we will always change the billing cycle anchor when upgrading from a free -> non-free price
The way to avoid this would be to avoid using the Customer Portal and start using Subscription Schedules: https://stripe.com/docs/billing/subscriptions/subscription-schedules
whole island
Oh gosh… Is there any reason behind this behaviour?
Why not respecting the billing anchor when set?
Is there any option to tell the Portal to leave it unchanged and set the appropriate parameter on its subscription update request?
Btw: schedules is not applicable in our case - we allow the customer to stay on the Free plan for as long as he wants and upgrade at any time… does not seem to be a right fit for the Schedules 🤔
frigid basin
Hello! I'm taking over and catching up...
To clarify, the behavior you want is that someone on the free plan can use the Portal to upgrade to a paid plan, but they won't actually pay for that paid plan until the 1st of the following month?
whole island
Not exactly. I want them to start paying from the time they upgrade up to 1st of next month, then every 1st of the month.
Actually I’d like the same behaviour in both cases (cfr above scenarios) 😉
Or stated differently, I don’t want the anchor to be modified when upgrading from free to paid
(Although it is free, we may be reporting pending invoice items that we want to be flushed out every month - always 1st of the month)
frigid basin
In order to get that behavior you would need to set up a webhook to listen for Subscription updates from free to paid made by the portal and update the billing cycle anchor when that happens.
The billing cycle anchor is set to the time they upgrade from free to paid because they need to be billed at that time.
whole island
When upgrading from a paid to a more expensive plan they also have to be billed… but the anchor does not move in that case.
(see what I mean?)
frigid basin
Yep, I see what you mean, but the system isn't designed to work that way unfortunately.
I can flag this as a feature request, but for now you'll need to work around the existing behavior for your use case.
whole island
Cool if you can file a feature request indeed.
Let’s talk about the webhook option as a workaround…
Most customer will start on a Free plan without any payment details recorded yet. We are just relying on the portal to collect them the first time then upgrade to a paid plan.
Let’s say the customer upgrade his plan - will I receive the update event in time ?
I’m afraid I’ll be too late and the subscription will already be modified and the invoice generated and payment collected.
Also the invoice details shown in the portal right before payment will probably not be accurate either…
frigid basin
There's nothing you can do to alter the first payment in that scenario, you can only change the anchor date after the fact.
The first payment will be for a full month.
From the date they pay to a month later.
You can then update future payments to land on the 1st.
whole island
Got it.
It is a bit of a shame since the API endpoints already offer everything that is needed - it is just that the Portal is not adding the necessary parameter to tell the system not to touch the anchor date 😦
Also, I should somehow conclude that it is useless to set an anchor date on a subscription with only free prices…
… unless you are adding pending invoice items that you want to flush every 1st of the month (this is working nicely). But then the schedule is screwed up after upgrading the product to a paid one 😦
frigid basin
As you pointed out this all works as expected if you use the API, this is specifically a limitation of the Portal.
whole island
Indeed. Any chance it could be adapted any time soon?
frigid basin
I doubt the behavior will change in the near future, unfortunately. Beyond the webhook workaround mentioned above the only other thing I can think of is to prevent free to paid upgrades in the portal and instead handle those with your own page and custom flow which uses the API to do what you want.
whole island
Yeah. We already now we will have to rollout our own « portal » solution at one point but yours was more than enough to start with…
And btw, you did an amazing job! I love your API, the doc is superb and all the tools you built around it are a real joy to develop with!
Congrats to the team!
whole island
Keep me informed 😉
Thanks for your help.
Can I delete the two sample subscriptions ?
frigid basin
Not sure I understand what you mean?
whole island
I created two sample subscriptions illustrating the scenarios for you to troubleshoot (see above). Do you still need them?
frigid basin
Oh, nope, you can get rid of those. 🙂