Money rounding error in TPAC credit card payment interface

[Remington Steed]

While paying a fine by credit card in the TPAC, I encountered a money rounding error. The single fine was for $1.15, but the total immediately below it is displayed as $1.14 (see attached screenshot). If I attempt to pay the fine via credit card (via Stripe payment service), the confirmation page again says I am about to pay $1.14, but after the payment completes the receipt page says "Paid 1.15 via credit card". It displays correctly everywhere else in the interface (e.g. the "dashboard" at the top-right of the page, the initial fine-selection page).

This may require a larger discussion about using floating-point math vs. money-safe math, and there may be multiple places in the Evergreen code affected by this issue, as mentioned in this bug:

https://bugs.launchpad.net/evergreen/+bug/996029

[Bill Erickson (berick)]

Just encountered this bug. Patron had 100+ small billings ($0.10, $0.20, etc.). The final amount to pay was "9.999999999...", which PayPal naturally rejected. I traced this to the Money.pm code that's adding the amounts to create the $total_paid amount. Using the $amount*100; $total_paid/100 trick resolves it. Will post a patch after more testing.

[Bill Erickson (berick)]

After re-reading the description, I believe these are two separate issues. The issue I'm describing does not happen until the payment is actually sent to the provider. In other words, the payment API, not the TPAC display code.

By all accounts, the TPAC code building the payment page has been round-protected since EG ~2.2. See Account.pm:prepare_fines(). Not sure what's going on here. I'll open a separate ticket for my issue.

[Bill Erickson (berick)]

For reference #1474566

[Bill Erickson (berick)]

Returning to the original bug...

I have confirmed the original bug. It's easy to recreate. Create a single grocery bill for $8.29 then attempt a credit card payment. The total amount to pay in the UI will display as $8.28.

This can also be easily reproduced with:

perl -e 'print "no match\n" unless ((8.29 * 100) == int(8.29 * 100))';

The Perl int() docs warn against this kind of thing... I have also confirmed the AppUtils::fpsum() function, which was recently added to address these kinds of rounding issues (and does not use int()), produces the correct results.

Patch en route.

[Bill Erickson (berick)]

Fix pushed:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/berick/lp1282751-cc-payment-rounding-error

Note that I could have accomplished the same thing by simply removing the int() calls in the summing routine (with fewer code changes), but in this case I thought it was worth it to leverage the fpsum() utility function to help reign in the proliferation of floating point summing code. Plus, I think it's slightly more readable.

To test:

1. Create a single grocery fine on a patron account for 8.29.
2. As the patron, log in to the catalog, then change the URL to https://EVERGREEN_HOST/eg/opac/myopac/main_payment_form -- It's not necessary to have CC payments enabled to view this page.
3. Confirm the total amount to pay is $8.28 before the above patch and $8.29 after the above patch.
4. To further test, add more fines and payments and confirm amounts correctly add up in the same interface.

[Mike Rylander (mrylander)]

I've picked this into 2.10-master. Thanks, Bill!