[Feature] 1 invoice for 2 (or more)

[patrickReiis]

Feature description

An invoice is attached to a single person, so if I want to pay A and B, first A creates an invoice and sends to me and B does the same thing (then I pay).

This has this problem:

• I can't guarantee that either both will receive or none will receive, paying A could be successful but paying B could fail, forcing me to do a pay retry with B

This could be understood as a database transaction feature, where everything works thus is saved in the database or nothing works thus is not saved into the database.

Describe the solution

A solution to this would be to make an invoice based in 2 or even more lightning addresses, that when paid, calculates the percentage for each one and attempts to pay both.

So when you decode the invoice, A gets 20% of the total amount and B 80% of the total amount.

Describe alternatives

Currently I need to do it manually but it's not elegant.

Additional context

No response

Are you working on this?

None

[reneaaron]

There is no way you can span a transaction across multiple LN payments to different receivers.

Do you mind to explain the exact use case you are trying to solve here?

[patrickReiis]

Zap split

[reneaaron]

Yeah, I don't think that's possible since you can't know beforehand which payment succeeds and which does not. (and obviously you can't "call back" your transactions for good)

Even with with HOLD invoices you'll have the same problem at the "settle" step of the process.

[bumi]

@rolznz had something there. but it is discontinued: https://github.com/getAlby/ZapSplitter

[rolznz]

This app could be more simply implemented now with NWC. Another idea for an Alby Hub plugin :rocket:

[alexgleason]

I think what we're looking for is not one invoice for multiple people, but one QR code / bech32 entity that encodes multiple invoices, so that the Lightning wallet handles the UX of zap splits. Basically so that the Alby window does not have to pop up for confirmation multiple times, and it handles errors for failed payments within its own UI.

Also, I don't understand what ZapSplitter does. :thinking:

[rolznz]

@alexgleason this is probably not possible, at least not in a standard QR code (There's too much information)

ZapSplitter is a lightning prism. When the user receives a payment, it will be forwarded to N other lightning addresses (each recipient getting a configured % of the payment, which is configured by the user).