#ironbeard-prorating-situation
scarlet quarry
Heyo!
upbeat ridge
Happy to chat, however the best thing to do is to test out proration scenarios really since they can be somewhat convoluted to hypothetically talk about.
scarlet quarry
Hmm, yeah. You're probably right. This particular one involves multiple Subscriptions, so wasn't sure if there was something obvious:
So we're selling SaaS (or online data access), it's all annual subscriptions. The data is broken up into different regions (e.g., 50 US states) that you can subscribe to ($250 a piece), each for the same price, or they can subscribe to "everything" (e.g., all states) for a reduced rate (say, $1000).
If someone signs up for a subscription to Texas on Jan1st and then later on Sept1 signs up for Arizona and California. Is there a way to "upgrade" their subscription to just the "everything" package in a way that takes into account prorations from their two different subscriptions?
To clarify: the upgrade would hypothetically happen after they have two separate subscriptions, like say on Nov1
tranquil pecan
No, if you have separate Subscription objects they are completely independent
Instead, you should be upgrading the Texas subscription to the new Product/Price not create a new one. Why are you creating separate ones?
scarlet quarry
Well, we wanted to ensure that the person is paying the full price each time they make a purchase. If e.g., someone paid for a single region on Jan1 and then on Dec31st they upgraded it to All Regions (which would prorate to a small amount, since the renewal day is hours away), they could presumably download the data and cancel the plan, and basically get the data for much cheaper than we're charging for it.
This is based on my understanding of prorating and the fact that "upgrading" would keep the old billing date.
Our way of making sure they pay the full price was to use separate Subscription objects.. but I suppose that's not the only way to do it?
tranquil pecan
What if you did the credit but charged the full amount then? Basically on Oct 28 they switch to the new Product and pay for an entire year Oct 28 2022 - Oct 28 2023, but they get credit for the Texas Product/Price for Oct 28 2022 - Dec 31 2022
tranquil pecan
kind of. You pass billing_cycle_anchor: 'now' so that it immediately rests the billing cycle to a full period and charges for it. By default we will calculate the credit prorated amount but I don't like "magic" and I recommend being explicit and passing proration_behavior: 'always_invoice' but it's already the default and what will happen
scarlet quarry
Yeah, I'm familiar with always_invoice but didn't know about billing_cycle_anchor. Interesting, so that would change their billing date from the date of their previous purchase to the date of their current purchase?
tranquil pecan
yes!
scarlet quarry
Hmm, I think this might actually be a great solution. Thanks so much 🙂
I'll need to test it out but it sounds promising
That's done on the Subscription object, right? The docs look like this is a timestamp, but I can pass 'now' on creation and update?
Oh wait, it's only on update. Gotcha
Okay, I should be good to go! Thanks 🙌
tranquil pecan
yeah that parameter is what we call "polymorphic" like trial_end it supports a timestamp (on creation) or 'now' as a string (on create/update)
scarlet quarry
Ah, gotcha. So 'now' is an acceptable creation value?
tranquil pecan
yes though it's implicit in a way since it's the default
scarlet quarry
sure, it was more a matter of where I'm placing the value in my code. Gonna mess around with this, thanks again 🙂