#nukesforbreakfast_api

1 messages ¡ Page 1 of 1 (latest)

deep oxideBOT
#

👋 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/1415196698094866464

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

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.

jade comet
#

oops, looks like I didn't finish my thought:

What have you already attempted?
I attempted the update as described above. I am not able to find an attribute of proration_date in the subscription schedule API docs.

waxen plume
#

Hello! do give me some time to take a look at this

waxen plume
#

Could i check what are you trying to achieve with the Subscription Schedule Update API request?

jade comet
#

Yes, I'm simulating a scenario where a subscription was set up under the wrong price and it was noticed later on. I was trying to figure out the right API calls to prorate the prices back to the original date of the subscription schedule start.

waxen plume
#

by prorate the prices back to the original date, do you mean change the price back to the original price and then generate prorations for that change?

#

Apologies, just ensuring i understand this correctly before providing any solutions

jade comet
#

basically. The original prices were $50 first year, $25 second and every year after. I was trying to change it to $25 first year, $15 every year after in this test.

#

but it can also go the other direction, increasing in price if someone accidentally set it to the wrong price initially.

#

I created the schedule with "now", so it started on 2025-09-09. I advanced the test clock to 2025-10-15 and then made the subscription schedule update call.

#

or something close to that anyways...

waxen plume
#

Ah i see, thanks for that explanation!

Using your first example, when you change the price from $50 dollars first year to $25 dollars first year, you want prorations to be created based on the time from 2025-09-09 to 2025-10-15?

jade comet
#

I wanted it to be prorated as if the price was $25 from the start, so 2025-09-09 to 2026-09-09 should be $25, and they should get $25 of credit for the overpayment.

#

instead of what happens now is it seems to treat 2025-09-09 to 2025-10-15 as $50, and then 2025-10-15 to 2026-09-09 as $25.

waxen plume
#

Subscription Schedules does not have a way to backdate the start date, you should be using our Subscription API instead, which has the proration_date parameter

jade comet
wispy flax
#

Hi @jade comet I'm also an engineer from Stripe and I'll follow up on this thread

#

Am I correct to say that basically you want to "give back" some money to your customer because they were charged with the wrong price in the begining ?

jade comet
#

yeah basically. And I wanted to use the default subscription proration behavior to handle giving them the credit towards the future subscription cost. Also it would work in the other way where if the price went up it would create the pending invoice item to charge what was missing.

wispy flax
#

Got it. An easier way will be issuing a credit note to your customer to give them a credit for the overcharge

#

For example, they were supposed to be charged for $25, but they actually paid $50. You can just create a credit note of $25 to make up the difference.

jade comet
#

I guess that works too since I'm not doing any weird partial prorations in the middle of a cycle.

#

so it's not hard math to subtract once price from the other.

#

but what about if I need to update the subscription schedule to lower the price for the next year? I basically just keep the existing phase and then modify ne second phase?

wispy flax
#

Yes you are right, you can still edit future phases.

jade comet
#

so in the other direction, where the price should have been higher

#

I would create a new pending invoice item for the difference?

#

Either way though, it also seems like the subscription schedule's update API should support the proration_date parameter. Is that a feature request you can log?

wispy flax
#

Yes you can just create an one-off invoice to charge the difference

#

No there's no plan to add proration_date to subscription schedule API, and you use credit notes to give credits or an one-off invoice to charge your customer for the difference.