#mario_api
1 messages Ā· Page 1 of 1 (latest)
š 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/1362192211848073329
š Have more to share? Add more details, code, screenshots, videos, etc. below.
I used this code to update the subscription:
\Stripe\Subscription::update($subscription->stripe_id, [
'items' => [
[
'id' => $item->stripe_id,
'price' => $this->newPriceId,
],
],
'proration_behavior' => 'none',
'billing_cycle_anchor' => 'unchanged',
]);
Cool cool. It would make that change immediately, not at the end of the period (but we can come back to whether or not that actually matters in a minute).
Where are you seeing the prorations being calculated?
I can see it in the Stripe Dashboard,
and also when I run:
$invoice = Invoice::upcoming([
'customer' => $subscription->customer,
'subscription' => $subscription->id,
]);
Why has that subscription been updated like 8 times?
because we test price changing
but wasn't successful
We couldn't make it work without proration.
We couldn't make it work without proration.
What does that mean?
I mean that even though we set proration_behavior to "none" and billing_cycle_anchor to "unchanged" when updating the subscription, the upcoming invoice preview still shows proration charges.
We tried to update the price without any prorated adjustments, but it didn't work as expected.
Are these the same period type? Like both monthly, or both annual?
yes same
both monthly
yes because first time when we updating the prices we use laravel cashier
and method swipe()
without noProration()
and that made this request.
But then we rewrote the code to the one I sent above, and we ran everything using that.
Cool, thanks. Do you still have any outstanding questions about this now that you know what caused it?
ok now i know what caused it
but what can we do with it?
is any solution or not?
If we change the prices on these subscriptions again in the future, proration will apply then too, right?
So the only solution is to cancel the subscription and create a new one for each product, I assume?
Delete the items?
delete the item in subscription and create new right?
Didn't the update(s) get them to the new price correctly? Or did I misunderstand the issue?
The prices were updated, but we can't rdisable prorations nothing more.
I don't understand what "disable prorations nothing more" means?
we want to turns off all future prorations for a subscription
It's not a flag on the Subscription, it's an instruction as to how to handle the Update API call you made - it doesn't "stick". Does that make sense?
Then why is it that even though Iām sending proration_behavior: "none" in the latest updates, the proration still shows up on those subscriptions?
If it cost 3,39⬠it must be 3,39⬠ii dont want any proration
The proration items are sitting there waiting for the next Invoice so they can be paid. They were created by that reequest I mentioned earlier; no subsequent request to update the Subscription is going to remove them.
Oh thank now i understand
So if we want to prevent subscripers to pay it we must delege subscription items and create new one?
No, just give me a sec.
Okay š
I'm so sorry. I think you can go into the Dashboard, and delete those proration items. If that's not doable, it can be done via the API. Let me find the link.
Please try to find api link
it should probably be https://docs.stripe.com/api/invoiceitems/delete
Complete reference documentation for the Stripe API. Includes code snippets and examples for our Python, Java, PHP, Node.js, Go, Ruby, and .NET libraries.