I currently uses the uc_discount_alt module and when it calculate discounts to returns more then 2 digits, witch causes the quickpay form to fail.

I have solved this like this, but may by there is a better way, and other places it could be a problem.

Altered line 314 in uc_quickpay.module from

$form = quickpay_hosted_form($order->order_total,

to

$form = quickpay_hosted_form(round($order->order_total,2),

Comments

xen’s picture

xen commented
Status: Active » Closed (won't fix)

While this fixes the immediate problem, I really consider it a bug in the uc_discount_alt module. The form fails because you can't pay half a cent/øre/whatever (QuickPay wont do it, and I believe neither will any other gateway).

And if 9.95 is what you really pay, rather than 9.946, then the order total should reflect that, not an imaginary number thought up by a discount module. It would also wreck havoc with integrations to accounting software, with this fix you might end up with missing or too much money on one account, due to rounding.

Would you mind filing an issue on uc_discount_alt, regarding some way for it to round the order total?

lennart’s picture

lennart commented

The tax module (part of ubercart "core") seems to produce the same problem when used for calculating moms on some prices when the total price (the price sent to quickpay) will not end in two decimals.

xen’s picture

xen commented

File a bug on UC.

We can't charge $0.001 so UC shouldn't try to make us. While we can fix the immediate problem by rounding, it will just leave the problem elsewhere, as previously outlined.

tbrix’s picture

tbrix commented

I had a precision problem like this with quickpay. The quickpay module does not respect the uc_currency_prec variable.

So I instead of just using the raw $order->order_total - in uc_quickpay_module in function uc_quickpay_form - I round the amount like this:
round($order->order_total,variable_get('uc_currency_prec', 2))

/T

xen’s picture

xen commented
Status: Closed (won't fix) » Fixed

uc_currency_prec is a display formatting variable, NOT a proper way to fix UC being sloppy with calculations.

But apparently UC is so broken that I have to round the payment balance before comparing it to zero, as it might loose some fractions in the process, so I've added an option (true by default) to fudge the order totals.

I'll reiterate: UC modules that sets the order total to something with too many decimal places are *broken*. It shouldn't be the job of the payment gateway to 'fix' the amount.

Status: Fixed » Closed (fixed)

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