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
Alternatives:
*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.
https://github.com/lightningnetwork/lnd/pull/2022
*"Spontaneous LN invoice creation " with server that acts as a lookup proxy
that handles the lightning creation on request. Inspiration: @georgevaccaro
Requirements:
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?
Paberlance
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
