[feature request] msat precision in LN invoice payouts and invoice creation

[openoms]

Currently the calls lnInvoiceCreate and LnInvoiceCreateOnBehalfOfRecipient are only accepting the amount as a (Positive) Satoshi amount.

amount: SatAmount!
Amount in satoshis.
Metadata for SatAmount Type
(Positive) Satoshi amount

When BTCPayServer would create a payment request with msat precision the amount is rounded up to the nearest satoshi and an overpayment is created which causes accounting issues.

A solution for this would be allowing creation of invoices with msat precision on lnInvoiceCreate operation in the API.

cc @NicolasDorier @pavlenex

[openoms]

Update from @NicolasDorier:

Our work around for the invoice creation is the following: BTCPay asks for an invoice of say 5.123 sats, but Blink create a BOLT of 5 sats. In BTCPay we detect the mismatch and says "Ok so let's add a payment method fee of -0.123 sats" so when the customer pay 5 sats, with the negative fee, the invoice of 5.123 sats is considered paid without under/over payments.

The other more pressing issue is the overpayment of the msat precision invoices created in BTCPayServer and paid with the Blink wallet.
When a BTCPay ask a customer to pay for 1.234 sats Blink currently send 2 sats which appears as an overpayment.

The request is to have msat precision in payouts from Blink.

[NicolasDorier]

Here is how it looks link when a customer pays to a merchant on lightning now:

[NicolasDorier]

@openoms for the issue of lnInvoiceCreate only supporting sats. There is an "easy" way to fix that.

Just make SatAmount in your API a decimal rather than an integer. Wouldn't break anything either from consumer or in your backend. (except potentially DB columns which need type change)

[NicolasDorier]

Just to let you know: We decided to round down to the sats for 2.0 to avoid those issues in the short term.