#idfk_schedule-migration
twilit stagBOT
👋 Welcome to your new thread!
⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.
⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.
🔗 This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1301567217946591294
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
timid flax
In the above request
I see proration behavior set to none correctly and customer was not charged
They won't be billed until Nov 16
fathom mica
in the initial creation, with thes ame proration behaviour set, an invoiice was created in_0QFmgnD3BlWgNb1LCVCwSpJx 373B2FEF-0001 where a payment had failed
timid flax
That's for a different subscription schedule
Created in req_1RXZGZ9uwTaDvU
But in both I actually see an invoice created
What do you want to achieve in phase 0 exactly?
I don't understand
If you don't want to charge customer until Nov 16, why not set start date to that?
fathom mica
We offer customers an option to upgrade (change to a higher product), and it is tied into the stripe subscription. If the stripe subscription exists and is active, we are able to update their subscription and charge correctly. During the upgrade we plan on updating future phase to relfect the correct price_id as well
I was thinking of doing a migration 100 percent code that is set for single use per customer, but it raises issues with customers with multiple subscriptions.
timid flax
Still don't understand
You want them to have an active subscription immediately so they can upgrade and be billed immediately?
Because if the upgrade won't be charged until the next month, then it doesn't make sense to start as active
twilit stagBOT
fathom mica
The upgrade is charged immediately. Since an upgrade can occur if they add an additional seat, we would update their subscription to cover the difference to the higher price in a prorated adjustment.
So with that in mind, I intended to create phase[0] as their remaining paid runtime from the old system. Phase[1] would be when their service renews and we collect for the next subscription period.
fathom mica
So with the req_1RXZGZ9uwTaDvU, phase[0] was created with proration_behavior:none but still had an invoice attempt to charge after an hour instead of nov16
full patrol
Yeah but that part is I think completely expected.
Try that
- Create a Subscription with
billing_cycle_anchorset to the next invoice date +proration_behavior: 'none' - Turn that Subscription in a SubscriptionSchedule with
from_subscription - Update the SubscriptionSchedule to pass both the current phase and a second phase
Sorry those are always a bit painful to set up properly when something was paid out of band
fathom mica
In theory if phase[0] and phase[1] are on the same price id, would step 1 suffice by itself?
Yeah.. I initially had it all dialed in with subscription schedules set to start when their external subscription "lapsed", and they threw this wrench in lol
full patrol
I guess I'm back to not understanding your flow like my colleague 😅
Can you give a clear simple example of what a customer would pay when
fathom mica
Sure
cus_R82mUJQUzEkKLB exists on the old billing sytem and is set to expire on 2024-11-16
We want to reflect this existing subscription on stripe as we have functionality built around the Stripe Subscription being active.
The plan was to migrate the customer to stripe as an active subscription on the corresponding price price_0Q0VugD3BlWgNb1LCybQjp6C to run until 2024-11-16
In the event the customer decides to upgrade to a higher price price_0Q0VuhD3BlWgNb1LKQDzLchq, we do an automatic charge to cover the difference to it and continue to 2024-11-16
In the event the customer's subscription does not change, they are invoiced for price_0Q0VugD3BlWgNb1LCybQjp6C that would run until 2024-12-16
full patrol
Gotcha so yes with what you described you don't need Schedules at all I think you just need the billing_cycle_anchor + proration_behavior: 'none'.
You can try this with our TestClocks https://docs.stripe.com/billing/testing/test-clocks feature to simulate a future upgrade and see what happens and confirm it works
fathom mica
Okay will try -- if the chat becomes inactive can I revive it or restart the help cycle?
full patrol
We close threads quickly here as we help a lot of people in parallel. If the thread is closed by the time you have your next question you can ask a new one with the same buttons in #help
But it's not super busy right now so I can just help you get to the testing you want quickly if you have time now
fathom mica
I can use same buttons w/ help. if there's a reference number i can use later that could be useful
full patrol
no reference. Every thread is self-contained. We help countless people a day so we can't go back and read the original threads and all the context. We expect the developer/asker to provide a clear new summed up question and then we start fresh.
fathom mica
Sounds good - just have a different task i'm tackling at the moment.
Thank you
full patrol
No problem at all, was just offering in case it'd help 🙂