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

longwave’s picture

Priority: Critical » Normal

This 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.

honigferd’s picture

So basically if I fix it as I proposed I will necessarily have to fix the HTTP_X_PRICE check using the same method aswell?

longwave’s picture

Yes, 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.

honigferd’s picture

Hm, 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?

honigferd’s picture

On a sidenote, this also seems to be a more severe uc_vat/ubercart/global issue - having rounding problems with the paypal module aswell.

longwave’s picture

Status: Active » Fixed

I 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.

honigferd’s picture

Sounds good. Will give it a shot next week and complain some more if there are still problems. ;)

Thanks!

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

MJH’s picture

Version: 6.x-1.1 » 6.x-2.0
Status: Closed (fixed) » Active

I 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?

tfranz’s picture

I 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.