* Allow overrides on all methods
* Add non-returning SendHttpRequest methods
* Use SendHttpRequest consistently
* Use file-scoped namespace
* Rates: Set default null value for currencyPair
* Ensure it works with instances which have BTCPAY_ROOTPATH set
* Add Greenfield API endpoint for pull payment LNURL items
close#4365
* Rename GetLNURLs to GetPullPaymentLNURL
* update "ln-url-not-supported" to "lnurl-not-supported"
* remove hardcoding of "BTC"
* update "PullPayments_LNURL" to "PullPayments_GetPullPaymentLNURL"
* update description of 400 status code response
Co-authored-by: Nicolas Dorier <nicolas.dorier@gmail.com>
* Editorconfig: Add space_before_self_closing setting
This was a difference between the way dotnet-format and Rider format code. See https://www.jetbrains.com/help/rider/EditorConfig_Index.html
* Editorconfig: Keep 4 spaces indentation for Swagger JSON files
They are all formatted that way, let's keep it like that.
* Apply dotnet-format, mostly white-space related changes
This allows external services to integrate with the payouts system to process payouts. This is also a step to allow plugins to provide payout processors.
* It provides the payment proof through the greenfield payoust api.
* It allows you to set the state of a payout outside of the usual flow:
* When state is awaiting payment, allow setting to In progess or completed
* When state is in progress, allow setting back to awaiting payment
* Automated Transfer processors
This PR introduces a few things:
* Payouts can now be directly nested under a store instead of through a pull payment.
* The Wallet Send screen now has an option to "schedule" instead of simply creating a transaction. When you click on schedule, all transaction destinations are converted into approved payouts. Any options relating to fees or coin selection are discarded.
* There is a new concept introduced, called "Transfer Processors". Transfer Processors are services for stores that process payouts that are awaiting payment. Each processor specifies which payment methods it can handle. BTCPay Server will have some forms of transfer processors baked in but it has been designed to allow the Plugin System to provide additional processors.
* The initial transfer processors provided are "automated processors", for on chain and lightning payment methods. They can be configured to process payouts every X amount of minutes. For on-chain, this means payments are batched into one transaction, resulting in more efficient and cheaper fees for processing.
*
* fix build
* extract
* remove magic string stuff
* fix error message when scheduling
* Paginate migration
* add payout count to payment method tab
* remove unused var
* add protip
* optimzie payout migration dramatically
* Remove useless double condition
* Fix bunch of warnings
* Remove warning
* Remove warnigns
* Rename to Payout processors
* fix typo
Co-authored-by: Nicolas Dorier <nicolas.dorier@gmail.com>
* wip
* Local GreenField Client for Plugins
* support notification handlers being missing
* Initial support for scoped btcpay client
* test out scoped local client
* wip
* small fix
* Throw exception if using local greenfield client and it has not been implemented yet
* adapt based on new changes in BTCPay
* update
* fix tests
* Allow Local client to bypass authorization handler
* Add Misc endpoints to Local API Client
* Add new endpoints
* Apply code review changes
* Mark Payouts as Paid
This PR allows users to mark payouts as paid manually through the UI and through the API. It also sets up the payout proof system to be able store a manual proof that will in a later PR allow you to specify a proof of payment (link or text)
* add docs, test and greenfield client
* remove extra docs stuff
* Update BTCPayServer.Tests/GreenfieldAPITests.cs
Co-authored-by: britttttk <39231115+britttttk@users.noreply.github.com>
* clean up pull payment/payouts fetch code
* Ensure payoutis are retrieved with pull payment
Co-authored-by: britttttk <39231115+britttttk@users.noreply.github.com>
