#jester_schedule-update
limpid pulsarBOT
đ 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/1276645851636170933
đ Have more to share? Add more details, code, screenshots, videos, etc. below.
spring nimbusBOT
Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.
- thejester12_code, 3 hours ago, 17 messages
bronze atlas
This has been my best attempt so far:
$stripe->subscriptionSchedules->create([
'customer' => $user_stripe_id,
'start_date' => $start_date->timestamp,
'end_behavior' => 'release',
'phases' => [
[
'items' => [
[
'price' => $stripe_price_id,
'quantity' => 1,
]
],
'start_date' => $start_date->timestamp,
'end_date' => $next_full_billing_day->timestamp,
'proration_behavior' => 'always_invoice',
'billing_cycle_anchor' => 'automatic',
]
[
'items' => [
[
'price' => $stripe_price_id,
'quantity' => 1,
]
],
'billing_cycle_anchor' => 'phase_start',
],
],
]);
quaint acorn
jester_schedule-update
bronze atlas
The problem is that it still collects the full amount in that first phase
Rather than prorating it as desired
quaint acorn
that's how Schedules work really. Proration happens later at the next phase but not upfront
It does confuse a lot of people for sure
bronze atlas
Hmmmm
Its a bummer because I have working code already for starting a normal subscription immediately, and the first payment can be prorated like this example
quaint acorn
yeah but SubscriptionSchedules approach this differently
bronze atlas
But now my customers want to future schedule a subscription starting
quaint acorn
what you can do is start the Subscription and then turn it into a SubscriptionSchedule afterwards right?
bronze atlas
How might that help in this situation?
quaint acorn
You said the Subscription API supports proration upfront right?
So you can create a Subscription, get the correct first Invoice, and then turn that Subscription into a SubscriptionSchedule so you can control/add the future/new phases (without changing the current/first one already prorated/charged)
bronze atlas
Kinda. I see what you are saying but I'm not sure it solves the "3 steps" my customers are looking for where they subscription doesn't start right away, and their aren't changed for time before the subscription starts
quaint acorn
hmmm you might be able to combine trial_end and billing_cycle_anchor first on Subscription
but yeah otherwise it's just not a flow we support
bronze atlas
I was wondering about trials
For an existing subscription, you can only update its billing_cycle day to "now" correct?
quaint acorn
correct
but you can create a Subscription with a trial_end and billing_cycle_anchor in the same request so that might work
bronze atlas
Are you able to help me understand any more what "phase_start" and "automatic" actually mean in the billing_cycle_anchor for a schedule?
I've read that description a hundred times
Can be set to phase_start to set the anchor to the start of the phase or automatic to automatically change it if needed. Cannot be set to phase_start if this phase specifies a trial. For more information, see the billing cycle documentation.
And the billing cycle documentation doesn't really mention them any more
quaint acorn
it might make you feel better that I barely understand it myself and it's my job to explain it. It's just so complex. I mostly reverse engineer what happens to what it does.
But basically you are expecting us to go "oh the phase ends after 2 weeks instead of a month, let's prorate". But instead what we do is charge the full month and when the next phase starts we go "oh wait let's do proration for what was overpaid"
And while we do that you can also say "I change the Subscription mid-cycle, please reset the billing cycle anchor to the current time (phase_start) so that moving forward you charge at that time each month
bronze atlas
Ok, yeah, this is complex...
Fer sure
Ok, so no matter what its going to collect the full amount at the beginning of a subscription schedule
That might actually be fine
But by setting billing_cycle_anchor to phase_start on the 2nd phase and proration_behavior to 'always_invoice" it might not charge the the full amount the 2nd phase?
quaint acorn
it would charge full amount. You can test this end to end with TestClocks which makes understanding the real behaviour much easier: https://docs.stripe.com/billing/testing/test-clocks