We were suffering from a problem where certain price combinations (when using uc_vat at least) would be added up and rounded in a way that caused the final price to be off by one cent (or even more, depending on the number of products that were rounded incorrectly and then added).
I incorporated a small fix in the uc_clickandbuy.module, line 383, changing
$price = intval($order->order_total * 100);
to
$price = round($order->order_total, 2) * 100;
Works perfect for us, would be great if you had a look at this issue, wrong prices in the payment process are unfortunately quite the showstopper.
As a limitation though, my fix won't work with prices below 0.01
Comments
Comment #1
longwaveThis change looks like it will affect the HTTP_X_PRICE check, which also uses intval() instead of round(). More testing is needed before I can commit this change. As discussed in IRC I don't think prices below 0.01 are an issue, this only affects the entire order total - and order totals below 0.01 should probably be handled by uc_free_order instead.
Downgrading this to normal, critical bugs are reserved for ones that stop the module working entirely - this problem only affects a small number of transactions when VAT is enabled.
Comment #2
honigferd commentedSo basically if I fix it as I proposed I will necessarily have to fix the HTTP_X_PRICE check using the same method aswell?
Comment #3
longwaveYes, without a similar change there I think you will find that carts that have the off-by-one error will fail when confirming with ClickandBuy, as the same calculation is done to confirm that the amount received by ClickandBuy matches the order total that was initially sent - and if these do not match then the transaction will not succeed and the order will not be completed.
Comment #4
honigferd commentedHm, I was wondering, since it seems to be the case that both the intval and the round methods have their own disadvantages/fail-screnarios, might it be an option to put a preference into the module configuration where the shopadmin can pick their preferred method?
Comment #5
honigferd commentedOn a sidenote, this also seems to be a more severe uc_vat/ubercart/global issue - having rounding problems with the paypal module aswell.
Comment #6
longwaveI don't think an option is needed for this, I've committed a change to -dev that rounds the prices including the HTTP_X_PRICE check - please test this and reopen the issue if there are still problems.
There is nothing uc_vat can do directly about this as it is not and should not be responsible for rounding. Before uc_vat and Ubercart release candidates, Ubercart modules never expected prices with more than two decimal places, so rounding or truncating was not handled at all - it is probably the responsibility of the payment modules to handle this correctly. If there are issues with PayPal I suggest raising a similar issue in the main Ubercart issue queue.
Comment #7
honigferd commentedSounds good. Will give it a shot next week and complain some more if there are still problems. ;)
Thanks!
Comment #9
MJH commentedI have the same problem:
I use Ubercart 6.x-2.2, Ubercart 2 VAT support 6.x-1.1 and Ubercart ClickandBuy Payment Method 6.x-2.0.
The prices show correctly in the ubercart cart and checkout area. (for example 4,20€ + 0,80€ 19% VAT = 5,00€)
On the ClickandBuy payment page, the price is always shown - 0,01€ (for example 4,99€ instead of 5,00€).
ClickandBuy seems to be the only payment gateway with this problem. Paypal and others show the correct price. Any ideas how to solve this problem?
Comment #10
tfranz commentedI have the same problem (6.x-2.0) – did you solve it?
I tried the small fix in line 383, but it didn't help.
I receive the following message in Ubercart (without the fix):
ClickandBuy transaction 0 failed:
Invalid transaction code.
Incorrect price: 8999000 vs 8999960.48.