Does the same, but the `GetPayment` call explicitly wants a payment
hash, which is clearer this way (thought there might be a bug here when
I first read the code)
make sure link provider is per payment method of liquid assets. Also remove ETB as it has been unused. Also hide the send button as it is not supported thrrough BTCPay
* refactor: make `BitcoinCheckoutModelExtension` support other payment handlers
The bitcoin checkout extension doesn't have to be tied to the native
bitcoin handler since it only really needs the payment details to be in
a specific format, which can be provided by other handlers aswell,
allowing for better code reuse.
* refactor: initialize payment methods in constructor
* Fix divisibility in invoice details of lightning amounts
This PR will show 11 decimal in the invoice details for BTC amount
of lightning payment methods.
It also hacks around the fact that some
lightning clients don't create the requested amount of sats, which
resulted in over or under payments. (Blink not supporting msats, and
strike)
Now, In that case, a payment method fee (which can be negative) called tweak fee
will be added to the prompt.
We are also hiding this tweak fee from the user in the checkout page in
order to not disturb the UI with inconsequential fee of 0.000000001 sats.
* Only show 8 digits in checkout, even if amount is 11 digits
* Support pluginable rate providers
This PR allows plugins to provide custom rate providers, that can be contextual to a store. For example, if you use the upcoming fiat offramp plugin, or the Blink plugin, you'll probably want to configure the fetch the rates from them since they are determining the actual fiat rrate to you. However, they require API keys. This PR enables these scenarios, even much more advanced ones, but for example:
* Install fiat offramp plugin
* Configure it
* You can now use the fiat offramp rate provider (no additional config steps beyond selecting the rate source from the select, or maybe the plugin would automatically set it for you once configured)
* Apply suggestions from code review
* Simplify
* Do not use BackgroundFetcherRateProvider for contextual rate prov
---------
Co-authored-by: nicolas.dorier <nicolas.dorier@gmail.com>
* Show Lightning node availability in navigation
Instead of simply communicating the setup state of the store's LN node, this now also checks its availability.
Closes #5940.
* Cleanups
* Add Selenium test for public node page and status in nav
* Cache the available lightning node result
---------
Co-authored-by: nicolas.dorier <nicolas.dorier@gmail.com>
