Rework Fixed Send Fee Calculation

[BlairCurrey]

Change the fixed send fee calculation to happen before creating the quote (paymentMethodHandlerService.getQuote) and base on the debit amount (instead of receive amount, as it is currently). This will result in a behavior change (ie different receiveAmount) and the quote/service.test.ts tests should be updated. Not entirely dependent, but probably best to address after this PR to add local payments is merged. This adds a debitAmountMinusFees which is determined during the amount calculations - ensure this field is still populated correctly.

Context

Currently with fixed send quotes, we get the quote then patch the debit/receive amount based on the fees. For fixed send, we apply the percentage and fixed fee to the receiveAmount (after it's been converted by the exchange rate, if any). Then it gets converted by the exchange rate. Given the percentage amount is derived from the already converted receiveAmount, applying the exchange rate again messes up the percentage based fee.

Worked example

debitAmountValue	basisPointFee	exchangeRate
200	200 (2%)	0.5

The current calculation is:

Note: initial receiveAmount comes from getQuote

$receiveAmount = 200 \times 0.5$
$receiveAmount = receiveAmount - ((receiveAmount \times 0.02) \times 0.5) = 99$

The new calculation should be:

$200 - (200 \times 0.02) = 196$
pass into getQuote where 0.5 exchange rate is applied
$receiveAmount =</code>98<code> $

More details on required changes

Basically, we could simply change this:

https://github.com/interledger/rafiki/blob/main/packages/backend/src/open_payments/quote/service.ts#L232

To use debitAmount like this: const fees = quote.fee?.calculate(quote.debitAmount.value) ?? BigInt(0)

At time of writing this causes the following tests to fail:

• 2% fee, 0.5 exchange rate, 99n receiveAmount. New, correct receiveAmount should be 98n.
• 2% fee, 20 fixed fee, 0.5 exchange rate, 89 receiveAmount. New, correct receiveAmount should be 88n.

This would give us the correct calculation. However, this change is insufficient by itself - we need to move this ahead of creating the quote. We don't need the returned quote to make these calculations so doing it upfront should make the logic a bit clearer.