Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Accept invoice ID in request header as alternative to preimage #25

Open
philippgille opened this issue Sep 22, 2018 · 0 comments
Open
Labels
enhancement New feature or request

Comments

@philippgille
Copy link
Owner

So far the middleware required the preimage as payment proof in the second request.

But since PR #24 invoice metadata is stored in the DB, with the invoice ID being used as the key, so now we could also just accept an invoice ID and look up the status in the DB or check the settlement on the LN node.

This would make it much easier to implement clients that don't have access to the preimage. For example: Let's say the API is used on a website, but without automated payments via an LN node operated by the people running the website, and instead the website shows the user a QR code so he can pay for the API usage.
Up until now the website had to ask for the preimage. This is an extra step in itself, but even worse, if the user paid via mobile wallet, but browsed the website via desktop PC, he now had to get the preimage from his smartphone to the PC just to proof that he made the payment.
When the invoice ID is enough, the user doesn't have to input anything. The website can decode the LN invoice and take the invoice ID, show the user the QR code and a button "next"/"continue" or "paid", and then the website can just send the request with the invoice ID.

One example of such a website is https://lightning.ws, where the deployed APIs have a "Try out" section where the user has to do exactly the steps mentioned above.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant