#alalva_proration-calculation-upcominginvoice
neat edgeBOT
👋 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/1273700983838605395
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
tame rain
Hi 👋
Prorations are applied by the second. Providing a proration date coudl still be off from when the customer is actually charged.
The request you provided creates a Plan but I don't see how that relates to this question
Also, plans are deprecated in favor of Prices.
https://docs.stripe.com/api/prices
late heart
i wasn't sure which of the req it was, maybe it was this one. I'm having an issue wit the preview amount vs the charged amount when using the Update a Subscription. For example I am charging $5 and in my preview I am telling the user that they will be charged $4.99 but Stripe is charging $4.89. I am using Prorations and the subscription was created yesterday.
sorry - can you try this one req_3MwFH70dvp0wl4
tame rain
That's a GET request, we don't store responses
late heart
req_A3UMvOQ9UnVOOI maybe it was this one
tame rain
Sorry this is just whack-a-mole for API requests and I don't know what you are trying to communicate.
- This request updates a subscription item
- I won't be able to see the response from the Upcoming Invoice API call
late heart
I'm using the preview in other subscriptions but when it comes to a subscription that the user is already on and they need to add another user thats were the prorations seems to fail. i have the same logic but for some reason this amount is always is different.
tame rain
No worries, it's hard to tell beforehand what will be the most useful information
late heart
Thank you, i know - its my fault. hopefully this can help sub_1PlGsIATCXjCgCHXEEDsZ9zL
tame rain
Okay, taking a look
late heart
also so you are aware i'm creating a product within the product catalog with the id of C-P6PK4GXLA
tame rain
I see with the latest Invoice in_1Po7NlATCXjCgCHXVFUgeJkk, the proration is occuring between 2025-08-07 13:54:26 and 2024-08-15 10:22:41. We calculate the difference (in seconds) and this returns a credit of -503.9198083143074855
We have to round on to the nearest cent when we generate the Invoice so taking that with some discrepancy between the timestamp used in the Upcoming Invoice API call, that could account for the 0.02 difference
late heart
Thank you this is great information. Do you have a calculation that you go about to figure this out? wondering if i can look at it and apply on how i'm calculating.
tame rain
What triggers the change to the Subscription? Can you adjust your integration to make the change at a scheduled date/time?
Or does it need to happen immediately in response to the customer's action?
late heart
it would need to happen immediately in response to the customers action
tame rain
In that case wouldn't you want to make the request to the Upcoming API just prior to that? Rather than the day before? I still think the Upcoming Invoice API is the best approach here but I'm trying to determine how you could best use to ensure the amount you see is what will get charged.
late heart
ah i see what you are saying. Let give that a try. Thank you for your help!
by chance do you still have a formula that you use?
tame rain
We do but I don't think you should rely on it as we may change what we use internally. That's why I was suggesting the API.
But we do the following
time_fraction = =(proration_end - proration_start ) / ( period_end - period_start )
proration = time_fraction * amount_after_discounts
where all the date/time values are timestamps rounded to the second
late heart
you know i figured the issue out, for some reason when i updated the new subscription i wasn't defaulting to the original date but instead defaulting to today's date. I just changed the updated subscriptions to reflect the original subscription date and not go on the current date. I'm so sorry but i'm glad you made me realize to look at the dates a little closer in my database. THANK YOU!!!! So Sorry
tame rain
No problem! I'm glad we worked it out 🎉