Bug in Custom Payments - order total is zero

[Chandra]

Noticed this in two tb installations. Order total always shows zero on dashboards, customer page etc. for orders using custom payment methods. Notice the cart total shows correctly on the screen but all order totals are zero.

[Traumflug]

Black irony is, some of the old PS code would simply set prices to zero in case there are too many digits behind the decimal. And this happens easily, think of periodic numbers like 3.12121212... Code introduced in 2014.

While this gets corrected with the current price calculation audit (an exception is certainly better in such a case, proper rounding to avoid it first place even more), the quick fix is to look up method isPrice() in classes/Validate.php and make it return always true.

[Chandra]

@Traumflug

Hi, I am guessing the rounding issue is not at play here since the order gets calculated correctly. I think it is a bug in Custom Payments module.

I looked up the values in the tb_orders table for the custom payment method (where the issue shows up) compared to a payment method that works correctly.

The deduction from my analysis is that custom payment method does not update the field 'total_paid_real' in tb_orders table, while other payment methods do. It appears this field value is used in listing/displaying order values.

I am not sure why the order amount is duplicated in this field and where it is used.

Is there an easy way to have this module update the field in question?

[Traumflug]

Well, if you're capable of stepping through the database, totals are in table tb_order; lines (one product * quantity) are in table tb_order_details. Yes, there's some redundant information. Price with tax, price without tax and price ... which is the one which was shown to the customer and matches one of the other two. Also a couple of values which are recorded for (I assume) statistics. One can look up these tables to see whether there are zero'd prices.

If you're also capable of reading PHP code, look at this: https://github.com/thirtybees/thirtybees/blob/1.0.x/classes/order/OrderDetail.php#L701-L708 it literally sets prices not validating to '', which means 0.000000.

Payment modules should not be involved. While orders are indeed created from a cart at the end of the payment process (class PaymentModule), they'd have to override that whole method.

[Chandra]

I can confirm prices are not zeroed in tb_order_details

This leads me back to the 'total_paid_real' field in tb_orders that is not getting updated in custom payments. I shall research a little more.