Bitcoin Payment Method Cards
The Problem(s)
Let’s be honest, selecting and copying a lightning invoice string from a message is not great UX, but I guess we just put up with it because we are used to it.
To outsiders this is a bit janky - it’s certainly not quite the slick experience you would expect from magic internet money.
Additionally, it’s quite common to have a back and forth around the payment method, something like this …
So there are two problems which we should try and solve
-
Payment Method Selection - which method is most most acceptable to both the sender and the receiver.
-
Information transmission - how do we communicate the selected payment method, amount and description to the senders wallet.
Payment Method Negotiation
The solution to the back and forth problem above is the elegant BIP 321 (https://bips.dev/321/) created last year which allows the recipient to outline multiple payment methods which are acceptable to them, provide a description and include an amount all in a single text string (a URI).
The smart part is that the order in which the methods are listed defines the receivers preference, which can be parsed by the senders wallet.
This is what the above exchange would have looked like in the above example. We solve the back and forth, but now there is a huge wall of text
If you copy the great wall of text and paste it into a wallet like phoenix it will display a selection screen to the sender, which parses the payment amount and asks the sender which option they wish to use
Information transmission
Copy-pasting the great wall of text is not good UX, so we should see whether we can avoid that. One option is BIP353
BIP353 - DNS Payment Instructions
Spiral recently published a *blog post *outlining how *BIP 353 *could be a solution to avoid copy-pasting this huge URI. In short, the idea is that the recipient sends a simple, memorable name like ₿jack@cash.app which the sender can use to lookup the payment methods using the internet’s domain name system.
Unfortunately, very few users are going to configure DNS records themselves, so this task will inevitably be outsourced to third parties. The third party is then trusted not to delete these records, as doing so would result in the recipient being unable to receive funds. More concerningly, the third party could modifying these records without the recipients approval to instead point to their own payment methods, effectively intercepting the payments.
Furthermore, the BIP specifies that “payers are encouraged to perform DNS resolution over Tor or another VPN technology” but let’s be real, do we really expect that this will be done routinely?
To me this natural tendency for the solution to drive users towards a trusted third party makes it an unattractive solution (though it is a strict improvement over lightning addresses).
Secure Messengers + Payment Method Cards
I think it’s worth exploring how we could convert these complex URI’s into easy to understand bitcoin payment method card, which informs the sender of the available payment methods supported by the recipient (& the description & amount).
One place to start is to leverage secure messengers, which is often where people send this sensitive information.
Imagine a messenger renders a card instead of showing the URI. The card could summarise the transaction details, and have two buttons
-
Open Wallet: Open the URI using your default wallet
-
Copy: to the clipboard if you want to take it to a specific wallet or send by another channel.
Cards can show the methods which are available for the payment. In this case, onchain for rent and onchain & lightning bolt 11 invoice for a dev fund.
For the above example of onchain or onchain + single use LN invoice this is a massive improvement over a long string, but it gets even better! Going forwards we are going to see more payment methods becoming popular, gor example silent payments and bolt12 for recurring private onchain & LN invoices!
In the not too distant future we could be sending people payment requests which contain all 4 of these different payment methods plus an amount and a description, and yet using payment cards this remains approachable!
This also presents a great opportunity to educate the sender about the different methods which the recipient would support (some of which perhaps they are not aware of!). Clicking the icons would open up an explanation of what each method supported by the sender is!
I loved what the cashu team did with their https://bitcoinforsignal.org/ campaign, I think it would be really cool to do something similar to show how signal could massively improve the user experience of bitcoin users, all without having to integrate bitcoin into signal (yet…).