Ease of payment opinions - lightning vs card \ stacker news ~lightning

I was wandering whether lightning payments at a physical location (with modern technology) can be made with as good user experience as card payment. Assumptions:

lightning is mature enough so that paths don't fail often and so there isn't significant delays causing by trying different payment paths
the payment is made by scanning a lightning invoice QR code
we don't count opening an app as an inconvenience, since even now I can see a trend where cards are in the phone anyway.

So let's see how card payment works now from ux point of view:

merchant presents you with a device, where on its screen you can see the the amount you will be charged
you present your card to the device
the merchant receives some form of feedback that the payment has been authorized

And about a lightning payment:

merchant presents you with a device with a QR code, representing a lighting invoice
you scan the code and your device shows you the payment amount and a button that you should press to pay
you press pay
the merchant receives a feedback that the invoice has been paid

As you can see the only difference here is that you need to press one more button to pay here. (I particularly like this step and I dislike that currently paying by card you just trust (the bank, merchant, merchant's device's display) that you will be charged the correct amount, but it seems this is not a concern for most people.) When everybody is really trying to make spending money as frictionless as possible and paying attention to even the smallest things, do you think this is significant UX degradation that will make real adoption more difficult?

Some time ago I posted an objective degradation use case, where it is currently possible in many cities to use your debit or credit card as a public transit card (day card, not just one ride payment) and I didn't get any engagement there. Let's see what's your opinion here on this much simpler case.

415 sats \ 0 replies \ @DarthCoin 15 Dec

You never used LNURL NFC cards (so called bolt cards)? See here some examples: https://darth-coin.github.io/merchants/bitcoin-lightning-payments-irl-en.html

You can make your own ones with https://plebtag.com/ or buy yourself the NFC cards and configure it with a BTCpay server or LNbits or https://boltcard.org/ for example.

Those NFC cards can be programmed to have a certain amount of sats "spendable" and also how many payments you could do per day etc, various limits.

Is not a simple LNURL, it contain also a security string that will not allow to be spend after read (skimming).

The cards are very handy with kids for example. You load them up and they have a limited spend amount.

14 sats \ 0 replies \ @k00b 15 Dec

I particularly like this step and I dislike that currently paying by card you just trust (the bank, merchant, merchant's device's display) that you will be charged the correct amount.

Bitcoin txs are irreversible, so it's not likely we'll lose this step. Reversibility, for the payer, is actually a pretty nice from a UX pov. It allows us to mindlessly, ie frictionlessly, spend.

When everybody is really trying to make spending money as frictionless as possible and paying attention to even the smallest things, do you think this is significant UX degradation that will make real adoption more difficult?

It'll make adoption proportionally difficult so if this friction is actually small, then it's a minor hinderance. But, there are solutions to this.

BitKit allows you to configure an instant payment threshold where you don't make this check. I think we'll also eventually see some kind of implicit escrow emerge for medium to large payments.