This is a great feature that has a lot of potential when building an online retail business. So here’s a flow:

1) Merchant makes a normal invoice for p&p and return p&p fee if product is not accepted or delivered, and sends that to the customer.

2) Customer pays that invoice and sends a return HODL invoice for the money paid for the p&p return once the delivery is accepted

3) Merchant pays that HODL invoice to return the fee for not returning the goods and then sends a HODL invoice for the purchase of the item.

4) Customer pays HODL invoice for the item and waits for delivery.

5) At this point we have:

a) Product in transit

b) HODL invoice to return p&p fee to customer once they accept

c) HODL invoice for payment of product

The only thing that was paid for was the p&p which is happening now as the product t is in transit

6) Upon delivery, the delivery guy gives a QR code that affirms that the item has been delivered, that will trigger the above HODL invoices, refunding the customer and paying the merchant, all in real time.

Based on the above, there is zero risk of loss for either the merchant or customer. The customer only pays for the goods when they receive it and the merchant guarantees that his goods will return to him, paid by the customer, if something goes wrong with the delivery. It’s almost like an ‘atomic purchase’. The only one who actually ‘technically loses out’ would be the customer who paid for p&p and return, but that’s only fair. Why should the merchant pay for the customer backing out of the deal.

This would also mitigate conflict about product not being delivered to the right person. Only the customer with the preimage can receive the goods and if someone were to intercept it, we would know it wasn’t delivered. So you get confirmation of correct delivery with delivery.

https://voltage.cloud/blog/lightning-network-faq/understanding-hold-invoices-on-the-lightning-network/

Reply to this note

Please Login to reply.

Discussion

No replies yet.