-
Notifications
You must be signed in to change notification settings - Fork 308
whack another penny mole #2198
Comments
The target amount for the bad row is 676.00. |
#2029, per the commit description. |
I have the distinct feeling of not truly understanding the math behind what is going on here. |
It feels like to truly solve this and stop playing whack-a-mole, we should understand the math. |
Given a target amount, we want to find an amount that, when fed into PayPal's fee function, will result in the target amount or a penny less. What is the precise inverse of PayPal's fee function? |
That's the problem: it's not precise. PayPal's fee is 2%, so the inverse is X / 1.02. Since we can only upload pre-fee amounts to two decimal places, however, there are cases where we can't hit the target amount+fee. |
So we need to identify what those cases are and payout slightly less in those cases (with a note about the penny—or two?—we're leaving in their Gittip). |
That's 52¢ through 88¢, divided by 1.02. |
I don't have time to get to the bottom of this right now. |
I tried bringing back the 0.75 case, and MassPay was still off by a penny. Whack-a-mole indeed. |
@whit537 Should it be X - (X * 0.02)? Seems like division triggers a lot of issues with floating point math. |
We can eat a penny. |
...What. I just looked at bin/masspay.py#L81-L83. PayPal is rounding to the nearest cent? Isn't the correct banking procedure to always round up with fees? |
As we're seeing here, the math gets very unpredictable if they do that. |
After poking a bit, it looks like |
Closing this one. We would have dealt with the 676.00 just fine if I hadn't taken the 0.75 check out in #2029. |
We have another off-by-a-penny bug in MassPay. Reticketing from #2190.
The text was updated successfully, but these errors were encountered: