#pascal_lin
1 messages · Page 1 of 1 (latest)
Hi there!
What do you mean by "control the time factor of the price calculation formula"?
Can you give a concrete example?
Yes, so you can set proration_date to a timestamp to when the proration will happen.
So you can set it to the present moment, or in one hour, or at the end of the day. It's up to you.
how can I use this field to control subscription billing🤔
Does my answer above help?
Do you mean if I setting this field to specific UTC 00:00am time of next day, it will calculate by daily precisely?
I'm not sure what you mean "by day". But it you set it to midnight, then the proration will be calculated as if the change happened at midnight.
emm... how does a subscription calculate the price?
I think I have got your opinion🤔 , this field is not control the price calculation of a subscription, it is only control the time gap to calculate the variable price...am I right?
Do you mean there is no time unit in price calculation, it is a linear formula?
Let me give you an example:
- You create a $10 monthly subscription on the 1st of the month
- Then, after on the 15th of the month, you change the subscription price to $100
What should happen? If you set the proration date to the date of the change, and withproration_behavior: 'always_invoice', there there will be a new invoice with: -$5, for the unused time on the original $10 plan- and
+$50, for the remaining time on the new plan
So the total is $45.
so what should I passing the proration_date value now, if I want the user paid $45, not $44.9 or any number with decimal point?🤔
👋 taking over for my colleague. Let me catch up.
actually, in my situation, it is not exactly a precise number🤔
hi
thanks for all your supporting🙏
no worries I read through, would you mind elaborating more on your question
I'm not sure I follow
I want to understand how a subscription calculation the price while I upgrade it😂
in my situation, I am following this docs to preview a proration, but I found that it is not a precise number if I passing proration_date parameter to current tiemstamp
that's normal because we're going to do a proration meaning that we're going to divide with the cycle duration and then multiply with the used time to get the used amount
which will most probably produce a decimal point number
in your colleague example, I will get a $44.5 or any other number instead of $45😂
it depends on the time, not just the date
so if I want to get $45 dollar for example, should I pass 00:00am of today to proration_date ?
okay, I think I should following stripe rules instead of making a other precise rules in my system.
thanks🙇♂️
I guess so 😊
it's easier