[Lightning-dev] Possibility to Include refund invoice in lightning payments

Paberlance paberlance at protonmail.com
Sun May 12 23:24:49 UTC 2019

Hello Lightning Devs,

i was wondering about the following idea: What if you attach a refund invoice to any LN payment. With this the recipient then has the possibility to refund, fully, partially or eventually tipping even a higher payment amount back to the sender.

From the user side, the userwallet pays just as normal Lightning Invoice, but attached along with the payment of 0 sat invoice back to the seller. From a UX perspective, this all happens is controlled by the wallet, which must agree on a protocol for embedding the return invoice with the LN payment.

On the recipee side, a normal LN invoice is recieved and optionally store that invoice to be able to perform a spontaneous refund later in time if he wants.As the invoice amount is not predefined, the seller is free to refund any payment, just bounded to the invoice timeout. Probably the payer will be motivated to issue invoices with a high expiry time-out.

Possible Usecases:

*Promotions, like: Every 100x Purchaser wins a prize, gets the order for free.

*Refunds: I order something, cancel the transaction, seller refunds the transaction partially, charging a service fee that he does not return.

*Safety deposits: You rent a car, the company keeps the payment as safety deposit, that gets reverted as soon as the car is returned.

*Spontanous payouts in games


*Hodl invoice, can achieve the same goal to refund the customer, but limited as it's an "all or nothing refund" option. Amount can't be more than the actual payment.

*"Spontaneous LN invoice creation " with server that acts as a lookup proxy that handles the lightning creation on request. Inspiration: @georgevaccaro


Payer has to generate a invoice and provide it encoded in the payment request as payload.
Reciver: must be able to settle the actual payment. And optionaly he may support the feature After storing the refund invoice, he then has the ability to decice if or how he will use it to refunde the client in the future.

Does this exist yet? What people can help me with this idea?

Any ressources or hints to digg deeper, built on top of that idea?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190512/716f0d0f/attachment.html>

More information about the Lightning-dev mailing list