[#7181] Incorrect pro rated amount

Yes this is correct. So to confirm the proration is not working on the actual payment/money spent, it's working on the price from the plan itself.
In order to achieve accuracy, shouldn't it be calculated from the users payment and not the plan amount since that can always be changed? You mentioned a bug ticket and I appreciate that, will it resolve it in such a way that this wouldn't happen again?

Thank you kindly!

Yes this is correct. So to confirm the proration is not working on the actual payment/money spent, it's working on the price from the plan itself.

Correct, it is my understanding it is designed this way.

In order to achieve accuracy, shouldn't it be calculated from the users payment and not the plan amount since that can always be changed?

It depends. The prorating is based off the remaining value. Giving them a discount or even giving them to subscription for free means you gave them that value. So if the price is $100 and you gave them $50 off you gave them a value of $50 with them buying the other $50 value. Meaning they still have $100 value. We've discussed this internally and are reviewing possibly implementing a feature to select how you want the prorating to function (based off value or amount paid).

You mentioned a bug ticket and I appreciate that, will it resolve it in such a way that this wouldn't happen again?

It's not actually a bug after discussing internally. We've changed the ticket to a feature ticket to explore implementing other, optional, means of handling prorating. Yes this will continue to happen as it is designed to function this way.

Let me give you a scenario in which this makes no sense:

Company offers a discount on a plan of $100 per month plan (company is not giving anything, they're simply "allowing" a lesser cost).
Discount = 50% OFF 1st Month
User pays $50 for first month
Later that day user decides to upgrade to better plan of $200 per month (no discount is offered on such plan)
User now receives approx $100 (maybe $99.change) towards a plan with no discount available

In this case as you can see the user would receive the plan which should be $200 for only $150. This is faulty logic because the user should only get a discount if it is offered.

I truly appreciate you all discussing this internally. I honestly can't think of any time where leaving the proration on the plan itself instead of the user's payment is a good thing. The only way to properly make sure the user always gets what they paid for && the Company is protected against such losses, would be to prorate their payment instead of the plan.
I understand why you'd want to give us the option to select which way we prefer, however also I believe it is redundant. Meaning if we're using the user's payment and the plan is $100, the proration will still be on the correct value which is in this case $100. In other words, the payment option would always be correct whereas the current method will only be correct sometimes.
Thank you all so much for implementing this at least as an option for us to decide. I do hope this helps to see that may not be necessary and may require more code from you all, but you guys have your reasons & a great product, so thank you for whatever you decide.

The prorating parameter directly states it uses the remaining value. It threw me off too as it's the proper accounting term, which I am not familiar with. You are giving them a value of $50 with the 50% off coupon and they are paying $50. Their prorated value is still $100. As explained above though we already have a feature ticket for this to review offering both prorating methods.