* 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>
* Support the new LN lib
* fix test
* do not cache factories
* try without useless userinfo in lnd
* Remove monero wallet files
* support simpler DI too
---------
Co-authored-by: Dennis Reimann <mail@dennisreimann.de>
* Refactor logic for calculating due amount of invoices
* Remove Money type from the accounting
* Fix tests
* Fix a corner case
* fix bug
* Rename PaymentCurrency to Currency
* Fix bug
* Rename PaymentCurrency -> Currency
* Payment objects should have access to the InvoiceEntity
* Set Currency USD in tests
* Simplify some code
* Remove useless code
* Simplify code, kukks comment
* Lightning: Relax GetInfo constraint for LNDhub connections
The LNDhub-compatible implementation by LNbits does not support the `GetInfo` call for all their funding sources — see lnbits/lnbits#1182. By catching that exception in combination with the `LndHubLightningClient`, we give people the ability to still use their LNbits-based LNDhub as a Lightning node.
Fixes#4482.
* Update approach to handling unsupported GetInfo calls
* Do not generate new address when a new payment is detected
* Update BTCPayServer.Tests/UnitTest1.cs
Co-authored-by: Andrew Camilleri <evilkukka@gmail.com>
---------
Co-authored-by: Andrew Camilleri <evilkukka@gmail.com>
* Prevent an NRE in LNURL
In addition to f05a7f9f14. Fixes#4904.
* Revert "Prevent an NRE in LNURL"
This reverts commit 0b241d61ab.
* Fix NRE
---------
Co-authored-by: nicolas.dorier <nicolas.dorier@gmail.com>
* Refactor: Dot not make LNURLPaymentMethodDetails depends on BTCPayInvoiceId
* Abstract PaymentProof
* fix bug
* Make the selenium container resolves the btcpay host name
* Update price display
As proposed by @dstrukt in #4364.
* Update format
* Unify price display across the app
* Add DisplayFormatter
* Replace DisplayFormatCurrency method
* Use symbol currency format for invoice
* Unify currency formats on backend pages
* Revert recent changes
* Do not show exchange rate and fiat order amount for crypto denominations
* Fix test and add test cases
In case of the unified invoice, the LNURL wasn't correct — with this change we are simply reusing th one that was issued on invoice creation instead of generating it anew on the fly.
Also fixes missing uppercasing for the QR code in case of non-unified QR.
And removes the `lightning:` scheme from the LNURL that's displayed to the user (unifies it with what we do for Onchain and Lightning)
* Make NFC built int
* support checkout v2
* uninstall old plugin
* fix lnurl in unified checkout
* fix tests
* fix tests
* fix old checkout unified qr
* clean up and make nfc submission more sturdy
* support topup invoices for lnurlw
* fix test
* Payment URI fixes
* Fix LNURL exclusion cases
* UI updates
* Adapt test
---------
Co-authored-by: Dennis Reimann <mail@dennisreimann.de>
* BIP21: Uppercase addresses only in QR, not in payment URL
The uppercased address/BOLT11 should only be used for the QR code, the payment URI for the link should stay as it is.
References:
- #2110
- https://bitcoinqr.dev/
* Improve comments
* Add comments step by step
* Ensure correct delimiter
Co-authored-by: nicolas.dorier <nicolas.dorier@gmail.com>
