用Java计算交易费用

Question

Lets say you have website that keeps balance for each user. You give each user option to deposit money into their balance from PayPal, Amazon FPS, Authorize.NET eCheck and Credit Card and maybe couple of there once.

Each of the above companies charges fee. And since you are the receiver you are responsible for fees (except for Adaptive PayPal API there you can say who will pay the fees).

So lets say website user (sender) will deposit you $1000.00 And lets picker fee of 2.9% plus $0.30 fix fee = -$29.30 So the receiver (the website owner) ends up with $970.70

If you try to charge $1029.30 you end up with $999.1503 If you try to charge $1031.11 you end up with $1000.90781 which is acceptable (this is when the fee is increased by 0.181% to 3.081% + 0.30)

So this question is, what is the best way to calculate the 0.181% in Java method

I know this is more of math problem than Java problem but what would be the best algorithm to use for guessing the best fee percentage so the final value would get as close as possible to the final value of what the website user is try to deposit.

So the method should take the actual fee 2.9% (0.029 for multiplication), the fix fee 0.30 the amount the user is trying to deposit and figure out the final sum to be charged that would be as close as possible to the deposit amount.

The way I have been doing it is trying to increase the 2.9% until I hit slightly higher after the fees are subtracted.

UPDATE

As per bellow answers I coded up this method. Any further suggestions are more than welcome:

public static float includeFees(float percentageFee, float fixedFee, float amount) {
    BigDecimal amountBD = new BigDecimal(amount);
    BigDecimal percentageFeeBD = new BigDecimal(1-percentageFee);
    BigDecimal fixedFeeBD = new BigDecimal(fixedFee);

    return amountBD.add(fixedFeeBD).divide(percentageFeeBD, 10, BigDecimal.ROUND_UP)
            .setScale(2, BigDecimal.ROUND_UP).floatValue();
}

Answer 1

Any time you're dealing with money you'll want to use a precision data type rather than floating point math. In general there are rules about how you round on matters when dealing with things like sales tax.

BigDecimal has parameters you can set to control the rounding behavior that will probably get you to where you need to go. In any case like this the math will never be exact on fractions of a cent but you should be able to guarantee that you'd never charge more than an extra fraction of a penny.

Answer 2

amt_you_receive = amt_customer_pays - .029 * amt_customer_pays - .30
amt_you_receive + .30 = amt_customer_pays * (1 - .029)
(amt_you_receive + .30) / .971 = amt_customer_pays

So take the amount you want to get, add 30 cents, and divide by .971 (aka multiply by approximately 1.029866) to get the amount you should charge.