LSP Integration

We're aiming to do this one in Q1/Q2. It heavily depends on when LDK team ships C# bindings for [lighting-liquidity](https://github.com/lightningdevkit/lightning-liquidity) which would allow us to support any LSP specs compliant [LSP.](https://github.com/BitcoinAndLightningLayerSpecs/)

I am starting this issue, so we could begin to discuss the desired UX around LSPs, as this is potentially going to be the hardest concept to agree on, as currently there doesn't seem to be once size fit all approach.

In order to receive a payment, a new node needs to be connected to the network. [LSP's ](https://bitcoin.design/guide/how-it-works/lightning-services/#:~:text=lsp) help facilitate that, but since the capital is being locked up in channels, obviously they want to charge a fee for this service. This fee currently, can be charged either upfront, or after the payment. Both approaches have different trade-offs which I attempted to illustrate here:

My opinion is that slapping LSP terminology together with channels and all of this aka this style, isn't suitable for our target audience.

On the other hand, abstracting things away could mean that fees for payments would end up being higher, which is arguably even the worse UX especially for our target audience, retail merchants who often deal with low margins and are very fee sensitive.

What I would like to propose is some sort of combination of both approaches, and this is where I'd really like to have some discussions on whether or not it's achievable. To get to the point, our whole idea with the app is that end-user, retail merchant is onboarded by an ambassador which hosts infrastructure required, but is **never** custodian to merchants funds.

Another consideration we have to add into equation is that we believe most ambassadors would ideally want to charge some sort of fee for the technical IT support they're providing for the merchant, hence we're introducing membership subscriptions.

What I would like to explore is the idea of having LSP01 (the cost-effective option) which is completely abstracted from the merchant, but not the ambassador. Ambassador could ask during the merchant onboarding (which we expect to be in person in most cases) approximate expected revenue, and inalculate that [into the membership plan](https://github.com/btcpayserver/btcpayserver/issues/6447) for the merchant, or basically offer subscription plan based on the expected, and later actual revenue.

For example, if you're onboarding someone to your BTCPay Server, and you're charging them certain fee for that, I wonder if you could simply in agreement A) Select default LSP B) pay for channel on behalf of the merchant you're onboarding.

This way technicalities are abstracted from the end user (hooray), the most cost-effective option is selected (hooray), but there are some costs for the ambassadors themselves, especially in scenario of a free trial, where ambassador gives X days to a merchant before they commit to a subscription, the upfront LSP cost is customer acquisition cost in a way for ambassadors.

I believe this is something both @Kukks and @NicolasDorier mentioned in different contexts, so I am logging it in.

For this to be achievable, we'd of course have to fully flash out https://github.com/btcpayserver/btcpayserver/issues/6447 and ensure all the cases are covered there, and hopefully bring LSP integration somehow into the BTCPay Server itself.

I cannot think of many downsides but, I guess this model would heavily be dependable on the **[Membership Plugin.](https://docs.google.com/document/d/1Gia61z-UpWVX-8LEw2B_8xaXeS9VvALH-pZ6hchlDIg/edit?tab=t.0#heading=h.ygp2279zer57)** We could however, design the app in which this can be a happy path, but then user could change LSP's from the dropdown and PAY for the channel upfront, or they click skip in which case they would be opting for JIT or manual channel opening.

Start by reading issue #6447 and the linked Membership Plugin document, then review the LSP01, JIT, and manual channel-opening flows described here. Clarify the desired merchant and ambassador UX, dependency on LDK C# bindings, fee ownership, and implementation scope; the work is done when the approach and cases are agreed well enough to define implementation tasks.

Written by the indexing model from the issue text.