LUD

dvide

Apologize for the long response, but I'll try to explain. The card can be used without any middlemen for both the customer and the merchant (other than the usual Lightning channel partners, if you want to count those). In this case, the business is probably using CoinCorner as a payment processor, but they don't necessarily have to. The card uses an [NXP NTAG 424 DNA](https://www.nxp.com/products/rfid-nfc/nfc-hf/ntag-for-tags-labels/ntag-424-dna-424-dna-tagtamper-advanced-security-and-privacy-for-trusted-iot-applications:NTAG424DNA) NFC chip. The chip is initialized with a secret and is set up to generate a unique LNURL-withdraw payment code every time that you tap the card. This URL could point to the customer's own server that they fully manage for themselves. The LNURL server would also know the secret that was flashed onto the card, and can use it to validate the payment request. This way, the LNURL server can be confident that the payment request could have only been generated by the card itself. If the payment request is valid, the server will authorize the merchant to pull BTC from the customer's own lightning node running at home. There is a nice article that describes [how this feature works](https://nfcdeveloper.com/blog/2021/12/01/how-does-dynamic-url-work.html) on the NFC chip. The URL it produces uses [LUD03](https://github.com/fiatjaf/lnurl-rfc/blob/luds/03.md) and [LUD17](https://github.com/fiatjaf/lnurl-rfc/blob/luds/17.md) from the LNURL spec. This [diagram](https://nfcdeveloper.com/assets/img/app-tutorial6.png) ([source](https://nfcdeveloper.com/tag-app/tutorial/)) also nicely explains how it works. In this case, the 'User with a smartphone' would be the merchant's point-of-sale device, and the web application would be the LNURL-withdraw server. There's a [draft pull request](https://github.com/lnbits/lnbits-legend/pull/674) in LNbits for this purpose, and an accompanying [article](https://www.whitewolftech.com/articles/payment-card/) that describes the process of initializing the card. So the tools are still in the process of being built for home use atm. These payment codes would be good for one-time use only. Every time that you tap the card, a new unique request is generated. There is no replay attack potential, as the LNURL-withdraw server would validate that each payment request could only have been generated by the card itself, and it will only process a withdrawal once for each unique payment code. This means that the merchant cannot just save the payment code and keep requesting a payment over and over again to drain your funds. The merchant cannot just increment a counter in the URL either, as the counter is encrypted by the card (using AES-128) using the secret, and only the LNURL server can decrypt that. I'm assuming that all of the cryptography is sound and that there is enough entropy and such that you cannot brute force URL request attempts until you find one that works. I personally have no idea about possible attacks along those lines. The LNURL-withdraw server can also enforce limits on how much can be withdrawn. You can set it up so that each payment code can only be used for a maximum of £60, or whatever you want. The merchant does not have to (and should not) take the maximum of £60 though. Say if you are only purchasing a £20 item, they should still only generate a £20 lightning invoice, not a £60 one. The idea is that the maximum they could do is steal £40 from you, if they were shady operators. You can also set a daily maximum limit. In the UK, we already have widespread use of contactless payments with NFC-enabled debit cards, and they have a very similar mechanism where they cannot be used for purchases of over £100. This is a global limit that is set for everybody. It was [raised to £100 from £45 during the pandemic](https://www.bbc.com/news/business-58898474), probably to further discourage the use of physical banknotes and coins from being exchanged. Fundamentally, limits like this are needed because it is a pull technology and not a push technology. Even though 99% of the time the merchant will not request more than the payment amount, they still could, so you don't want to enable them to be able to drain your entire account. As you can see, the POS also displayed a BOLT11 QR code, so the customer can just pay in the usual way with a lightning-enabled wallet as well, which would be using a push technology to send the exact amount.