Support » Plugin: Accept Stripe Payments » Possible Rounding Error When Applying Tax

  • tomtotalsurf

    (@tomtotalsurf)


    Hi

    I have a product set to the value of 10.825 with a 20% tax rate which should bring it to 12.99 but when I attempt to make a payment it shows it as 13 and if I do make a payment, it says:
    “System was not able to complete the payment. Invalid payment amount received. Expected £12.99, got £13.00.”

    Trying it with 11.99 was fine, and that’s a much longer decimal so not sure what’s going on.

    Thanks

Viewing 12 replies - 1 through 12 (of 12 total)
  • Plugin Support mbrsolution

    (@mbrsolution)

    Hi, I am closing this thread because it is a duplicate.

    Thank you

    Plugin Support mbrsolution

    (@mbrsolution)

    There is a duplicate thread conflicting with this one. So I marked it as not resolved again.

    Plugin Support mbrsolution

    (@mbrsolution)

    Hi, out of curiosity what if you set your value to 10.82 instead of 10.825? Does that help in any way?

    Regards

    Thread Starter tomtotalsurf

    (@tomtotalsurf)

    Hi

    Sorry for the delay in replying.

    Bringing it down to 10.82 makes the total 12.98 after tax. I’ve tried playing around by increasing/decreasing the value to see if something like 10.8249 would resolve it but it doesn’t, it’s either 12.98 or 13.

    Thanks

    Thread Starter tomtotalsurf

    (@tomtotalsurf)

    Hi

    Just as another test, I set the product to 10.825 and then included shipping of 2.49 and I still get a similar issue:
    Invalid payment amount received. Expected £15.48, got £15.49.

    The same happens if the shipping becomes 2.50:
    Expected £15.49, got £15.50.

    Thanks

    Plugin Contributor Alexander C.

    (@alexanderfoxc)

    Hi.

    Thank you for your report, I’ve reproduced the issue on my test server.

    However, the issue is not in rounding, but rather in the fact that it’s not a good idea to set the price to something with more than 2 numbers after decimal point. So the only “fix” I see here is to force the code to floor all money-related values to 2 numbers after decimal point. In your example the price would become 10.82 no matter what you put after the .82 part.

    Now the question is: what you want to achieve by setting your price to 10.825? As I understand, you want the final price with 20% tax to be 12.99?

    Plugin Author mra13

    (@mra13)

    We only support price amount upto 2 decimal places (which is standard for a price value). You need to edit your product price amount value and use a normal amount that is upto 2 decimal places (not 3).

    Thread Starter tomtotalsurf

    (@tomtotalsurf)

    Hi

    Yes we’re trying to get 12.99 with 20% tax.

    I understand rounding the price to 2 decimal places, but it seems strange that this is done before the final value is calculated. Doing it this way means there are values which people just can’t sell an item for. If I look at Germany’s 16% VAT as another example, they can’t sell an item for 15.99 as the base price would (accurately) need to be 13.7844827586.

    I’ll probably just see if I can tweak it easily enough for my purposes or just push for a slight change in price, but hopefully you understand where I am coming from.

    Thanks

    Plugin Author mra13

    (@mra13)

    Lets see if we can re-work something in the plugin.

    Thread Starter tomtotalsurf

    (@tomtotalsurf)

    Hi

    So I’ve been looking at it further and I’ve found a solution, at least for my use case and a couple of test cases I looked at. Unfortunately I haven’t really been able to fully test it and not sure if I will get the chance. Part of that means I have made some changes but not 100% certain if it actually mattered to the end result as I haven’t had a chance to revert those changes.

    Basically all I did was looked at any instance where you’re rounding a number and increased the precision on it, or removed rounding altogether (removing intval function calls). Whether those actions were needed, I’m not sure. The final action which actually showed a result was in /public/assets/js/pp-handler.min.js and making vars.data.amount=Math.floor(PHP_round(tAmount,2)) in the calcTotal function.

    To be honest there’s still probably some inaccuracy in the calculation as the value is 1299.6 when it should just be 1299, but it seems to work in this instance and could potentially be a more robust solution? Again, more testing would be needed to see if it’s worth it.

    Thanks

    Plugin Contributor Alexander C.

    (@alexanderfoxc)

    Altering plugin files directly isn’t a good idea. Your changes will be overwritten when plugin is updated.

    In the upcoming plugin version we have fixed rounding inconsistency for prices with more than 2 numbers after decimal point. So there was rounding issue with that indeed, thank you for helping to nail it.

    Regarding your requirements, I think there is a solution. We had discussion with our team on this and here is what we come to. Currently (after the fix in the upcoming update), all the amounts are rounded to 2 numbers after decimal point on each step of the calculations. So your price 10.825 becomes 10.83 + 20% = 12.996, which is rounded again to 13.00.

    We will probably introduce new settings option. When enabled, it would only round final amount. So calculations would look like this: 10,825 + 20% = 12.99. Same applies to your other example: 13.7844827586 + 16% = 15.99. Without this upcoming option enabled, 13.7844827586 would be rounded to 13.78 + 16% = 15.9848, then rounded to 15.98.

    I cannot currently give you any ETA on this, as this would require some global changes in calculations. But this will be worked on after version 2.0.36 release.

    Thread Starter tomtotalsurf

    (@tomtotalsurf)

    Was a fix ever implemented for this or is it still in the pipeline?

Viewing 12 replies - 1 through 12 (of 12 total)
  • You must be logged in to reply to this topic.