Adding support for Lightning Network - #2
Conversation
The current proposal has the processor independently determine when payment is made. This adds significant complexity to each processor and creates the possibility that the processor thinks a payment was made when the exchange does not (or vice versa). Having the exchange notify the processor of payments via a webhook solves this. This is easier for the exchange to implement since they are already crypto experts, lowers the barrier for processor adoption (since they don't now need to be crypto experts), and ensures that invoices are marked as paid only when they really are.
Exchange notifies processor of payments
| "receivedTimestamp" : timestamp, | ||
| "confirmedTimestamp" : timestamp, | ||
| # When exchange provided a guarenteed rate | ||
| "guarenteedRateReceived" : "false", |
There was a problem hiding this comment.
"guarenteedRateReceived" typo, guaranteed.
| "cryptoCurrencyCode" : "BTC", | ||
| "rate" : "15600", | ||
| "validUntil" : timestamp, # for LN only | ||
| “cryptoAmmount: 0.1, #for LN only |
|
|
||
| ===Case II: Merchant uses exchange’s LN=== | ||
|
|
||
| In this case, the Payment Processor requests a LN address from the exchange. The exchange keeps the Payment Processor up-to-date on payment status and sells the funds as configured. |
There was a problem hiding this comment.
Spell LN completely (Lightning network)
|
|
||
| In this case, the Payment Processor requests a LN address from the exchange. The exchange keeps the Payment Processor up-to-date on payment status and sells the funds as configured. | ||
|
|
||
| The steps are identical to Case I except LN addresses are sent instead of Bitcoin. |
There was a problem hiding this comment.
I think a different field should be used. The exchange could allow any of them, Carol is the one choosing whether to pay on LN or BTC depending on her wallet.
There was a problem hiding this comment.
Makes sense. I had assumed that LN & BTC would be different endpoints at the exchange but it probably makes more sense for there to be a single endpoint that just offers both options if available.
|
Awesome, I briefly read, I will do more tomorrow. A note: It can be useful to not only specify the LN address (BOLT11), but also the address of the LN node of the exchange. By doing so, the wallet can ask a user to open a channel with the merchant if he can't route his payment. |
|
Ping @lepipele I think it would make sense to use the BOLT you are creating for the LN address instead of using BOLT11. |
Merchant may want to be able to hedge funds received on live channel.
|
Sure, let me reference all this to Jack also and then @natefriedman can maybe join us when we have group discussion on implementation. With working integration we can definitely tweak proposals so that it's ensured they work well in practice. |
|
@natefriedman does it interest you to join http://slack.forkbitpay.ninja/ ? we have a channel about a spec for getting LN invoice address in a way that is more UX friendly. It is not clear yet if we should use this instead of what you just specified here for COX though, but might be interesting to talk about it. |
|
I would be interested in participating, didn't know this project existed! |
3 participants
I am proposing to expand this to cover two LN senarios:
I didn't fully spec out scenario #2 but wanted to share this as is to discuss. Let me know what you think.