Trouble sending payment to Hold Invoice via REST API

[ianpatton]

Background

I am developing an application that uses Hold Invoices, in order to allow an invoice to be canceled for up to 5 minutes before settling the payment.

The invoice is only payable for 60 seconds (expiry)

The client is sending payment via REST: POST /v1/channels/transactions

I am subscribing to invoice events on the receiving LND via SubscribeSingleInvoice, and can see the invoice transition to the state ACCEPTED

After expiry, the client LND log shows the following 2 lines:
2019-09-04 20:11:35.948 [ERR] CRTR: Attempt to send payment b93b72680382447d5f7408d4cc56b1a33819242bb4c96bc6d24f002f6f6bcd7b failed: IncorrectOrUnknownPaymentDetails(amt=95000 mSAT)
2019-09-04 20:11:35.959 [WRN] RPCS: Unable to send payment: IncorrectOrUnknownPaymentDetails(amt=95000 mSAT)

The REST client does not receive a response until expiry, and then receives this error as a result of the POST/v1/channels/transactions and considers the payment as failed, even though the receiving LND correctly ACCEPTED it.

I have read #2022 several times, but please let me know if I am misinterpretting something about how this feature is expected to work.

Your environment

• version of lnd - LND 0.7.1-beta for both
• which operating system (uname -a on *Nix) Ubuntu 18.04
• version of btcd, bitcoind, or other backend - bitcoind 0.17.1
• any other relevant environment details

Steps to reproduce

See background above

Expected behaviour

The REST client should get a successful payment message

Actual behaviour

The REST client gets no response until expiry, and receives an error

[wpaulino]

The client is sending payment via REST: POST /v1/transactions

I believe you mean /v1/channels/transactions?

Are you settling the invoice once it reaches the accepted state?

[ianpatton]

Sorry, corrected api route to /v1/channels/transactions.

No, I am not immediately settling it. As the description says, the reason for using hold invoices is to wait 5 minutes before settling.

[joostjager]

The 60 second invoice expiry is only checked by the sender before initiating the payment. In your case, the payment is initiated, so the invoice expiry shouldn't play any part in this.

You write you don't settle the hodl invoice after it's accepted, but did you cancel it after 5 minutes in the scenario above? That indeed replies IncorrectOrUnknownPaymentDetails to the sender of the payment.

It is correct that a sender does not get any feedback for an accepted hodl invoice. It is not in the protocol. A sender isn't able to find out whether their payment is still somewhere en route or being held by the receiver.

[ianpatton]

I see. I was actually setting a timer on the client and it was canceling the invoice itself after expiry. I removed that, as it seems unnecessary. Now I see the request hanging for the full 5 minutes until the invoice is settled.

The lack of any feedback from the API upon paying a holdinvoice leads to a bad UX in many cases.

In the scenarios described in the #2022 , example 4 and 5 leave the client with an unresponsive API request for an unreasonable amount of time. Special care will have to be taken to make sure to use a client that allows a request to be canceled/aborted.

It seems like LND API should handle this instead of pushing it off on every client implementation. I am not sure what the right behavior would be, since the LND node does not know the status of the in-flight payment, but not sending any response at all does not seem like the right approach.

Is there not a way to detect that the invoice being paid is a hold invoice, and give a reply that the payment is in transit?

[joostjager]

Is there not a way to detect that the invoice being paid is a hold invoice, and give a reply that the payment is in transit?

No, there is no way to know. It is not in the protocol.

The workaround is to use an additional communication channel with the receiver to get status updates to your application.

[wpaulino]

Closing as there doesn't seem to be an issue here other than a limitation in the protocol.