Add content around receivers requesting payments (pull payments)

[Bosch-0]

With BOLT12 on the horizon, a requester will be able to send an invoice to a payer through the lightning network effectively creating a pull payment. LNURL-withdraw can already do this, and is an example of a pull payment but LNURL invoices are shared out of band (over HTTP) whilst offers are shared within the network (good for privacy) so it's a little different.

[GBKS]

Could you find any documentation on this? I was not able to.

From a pure UX perspective, I think this falls into the general "presenting payment requests" user flow. Whether the invoice got into the app via link click, QR code scan or otherwise is not so relevant to the presentation. Only addition might be a notification, and possibly a small indicator on the home screen showing that there's a pending invoice.

[Bosch-0]

Not really no, I was discussing this in the bolt12 offer Telegram . Some details can be found in this file

There would be some slight UX differences during the sharing payment requests on the requesting page also for this.

[GBKS]

What would be the UX difference? Another button to share directly via the Lightning network?

[Bosch-0]

Another button to share directly via the Lightning network?

Most likely something like this yes. If you go and try out how Zebedee users request payments from other Zebedee users this is the UX I'm talking about.

[sbddesign]

If you go and try out how Zebedee users request payments from other Zebedee users this is the UX I'm talking about.

So I agree that Zebedee is an example of a user sending another user a payment request. I would lop Zebedee, Strike, and CashApp together as examples of apps where you can send payment requests to other users. That's definitely a distinct user flow.

However, I am not entirely certain that BOLT 12 send_invoice facilitates this use case. My understanding is that send_invoice is really in response to an offer. In other words, my lightning node would not just send an invoice to another node out of the blue -- it would send an invoice to that node only when prompted via a BOLT 12 offer.

I think we have to think of it in reverse. Imagine you have your friend's BOLT 12 offer stored in their contact metadata, then you can treat that as serving the same purpose as a CashTag, Strike userrname, or Zebedee gamer tag.

[Bosch-0]

it would send an invoice to that node only when prompted via a BOLT 12 offer

I thought the same when I first was reading into this. I asked in the BOLT 12 offer telegram and was told that the above UX is possible. You are correct though, send_invoice is just how the invoice is shared over the network which is part of how this works but not the whole picture, I misunderstood that. I changed the OP and title of this issue to reflect that.

I'm not 100% on the details of how this works, but with offers (very similar to LNURL-withdraw) pull payments are possible. Here is a scenario:

1. I'm a user who needs a refund from a merchant and they have sent me an offer
2. I can scan the offer, and rather then them serve me an invoice (how standard invoices are served) I can send them an invoice from my node that they pay.
3. I get my refund.

What I wanted to address in this issue two things:

1. When the user scans the offer, if I can request (send them an invoice) or pay (receive an invoice) this needs to be reflected in the UI.
2. How on the merchants end they would receive this request. Would they just get a notification saying 'User X sent you an invoice' of which they would click and pay. This would most likely need to appear in the users activity.

To complicate this further subscriptions are also possible with offers so that would need to be part of this flow (could just be a toggle to say making this a recurring request or payment).

This issue would touch on quite a few pages.

When I get to revising the requesting page I will probably change the Withdrawal request heading to Pull requests and include LNURL-withdraw (already there) and Offers as a start.