Understand the difference between UX of paying an invoice on mobile vs desktop

[pavlenex]

Ideally, an invoice should just be a QR code. However due to different UX on mobile vs desktop wallets, when merchant software displays an invoice, there's always a "Copy" section which provides a way to copy/paste data bypassing the QR code scanning.

• [ ] Explain the difference
• [ ] Research different solution
• [ ] Propose an optimal solution

[johnsBeharry]

Well it makes sense to copy and paste sometimes vs scanning a QR code.

For example:

Scenario: Multiple bitcoin wallets on mobile
    Given I am on a mobile device
     And the first bitcoin wallet I installed was "Mycelium"
     And the second bitcoin wallet I installed was "Blue Wallet"
     And I am browsing "www.acme.shop"
     And I find a product to purchase
     When I click the "Checkout" button
     Then I am taken to the payment processor page
     And I want to pay with "Blue Wallet"

In the scenario above the user is 1. not able to scan the QR code 2. if the user wants to pay with Blue Wallet clicking a link with the URI would usually open Mycelium (there are reports that results are unexpected).

Possible Solutions

1. OS allows the user to configure / choose the app that handles a certain URN also this can be problematic for brand named URNs.
2. Button to Copy the QR Image or entire Payment Request (URI) with the amounts and labels not just the address. Then the wallet reads the clipboard (this is common behaviour currently).

You may also find some related information here:

• https://github.com/peakshift/bitcoin-ux/blob/master/payments/qr-codes.md#uri
• https://github.com/peakshift/bitcoin-ux/blob/master/payments/payment-request.md

[pavlenex]

@johnsBeharry Just to be clear, I think there should be a way to manually copy, but in a form of a payment link like the BIP21 bitcoin:3MWkkkSNuF6GSCBNK...L?amount=0.00259915 where both are encoded copying address and amount separately can lead to invoice underpayment. For example you copy address and enter the USD amount manually.

[GBKS]

Might be helpful to start with a list of prioritized goals and use cases for this screen/experience.

[GBKS]

Here's what I would do to create a clean, organized experience (expanding on my conversion with @pavlenex yesterday). Video. On a sidenote, I'm using discussions like this one as opportunities to mock up various screens for the Bitcoin Wallet UI Kit.

[pavlenex]

@GBKS Interesting approach, but imo it kinds adds way too much information which can be distracting for people. When at checkout I just want to pay, if I need more info, I should perform an action (expand invoice view etc).

Is there a Figma link for this? I'd really like to re-use some of the elements and try to come up with a solution as well, will be useful while I research components as well.

It's just my experience on merchant's side and both btcpay thought me less is better when it comes to checkout experience.

[GBKS]

Here's the Figma.

For too much information, are you just referring to the stuff at the bottom? I mention in the video that the bottom info could be collapsed by default, so we would be on the same page there.

Definitely good to consider the screens that come before this one. If this one repeats things that were clearly laid out before, then they can be removed (or collapsed).

Just a general thought, I find that "less" and "simple" are weird terms in design. Fewer elements on screen can be more confusing if there's missing context or the layout is not carefully considered (like the visual hierarchy stuff I am pointing out in the video). From experience, properly labelling things is super important for usability. Totally get the push to simplify, it's just that simple does not always mean less.

[pavlenex]

For too much information, are you just referring to the stuff at the bottom?

Yes, I missed the collapsible comments, so we're on the same page there.

I also not a fan of the upper left section. The QR should be the focus of this page, since most times you just scan and pay and go over with your life. I still don't know how we can distinguish manual copying from scanning, but I like what you did at the bottom of the QR code.

BTW video was very helpful, will start doing the same for the issues, easier to understand.

[GBKS]

Feel free to change the design as you see fit. I'm curious to see how you would go about it. You can just duplicate the file if you want.

[pavlenex]

@GBKS Took me a while, but here's how to easier convey what I had in mind, though this doesn't resolve the issue.

I tried to reduce the amount of data in your proposal, mostly because this data is previously in most cases already visible in the cart of an e-commerce software. I've hidden those away in the invoice details.

One component that should be prominent and visible is timer. This is because rate is time-locked in usually 15min, and if you don't pay invoice during that time, it expires as unpaid. This is to prevent price-manipulation payments on merchants. So a timer should create a sense of urgency and let people know that they need to pay an invoice before it expires. I should also note that fiat price in amount field is not a good idea and I should remove it, as it may lead into buyer adding fiat value in a wallet, which may not be exactly the same value in BTC that merchant is requesting. So fiat value should be moved into invoice details.

My solution simply pulls out important elements, but does not resolve original problem, how do we communicate manual copy pasting address vs scan vs payment link? Any ideas on those?
What this should tell is :

1. Scan QR from your wallet to pay
2. Or, open a payment link directly into your wallet (for example if you're preforming a checkout on a mobile and have mobile wallet)
3. Or copy the exact amount and the address into your wallet (usually for desktop users, when you're making a purchase over desktop and have a desktop wallet)

[pavlenex]

Some more iterations.

[GBKS]

If the main issue is to let users choose why not frame the whole screen this way? This mockup offers three different options, with only one expanded with a clear call-to-action in the title to decide on a way to pay.

[pavlenex]

@GBKS Interesting idea. I like the collapsible approach. I'd just emphasize the timer there a bit more, we really want people to know they should pay invoice on time.

Would the desktop view be any different? I really like where this is going. Please please feel free to provide more mocks on current iteration or share any other ideas.

[pavlenex]

Here's slightly modified itteration of @GBKS's proposal where timer is more visible.

[GBKS]

I understand that it is important to see that the invoice will expire, but making it this in-your-face makes it appear like a pressure tactic, like the ones used by travel sites. A small "?" button could explain this (it should also explain what happens if your payment arrives after).

In terms of visual hierarchy, I would try to make in secondary to the title. When a user arrives on the page they first need to understand that this is the page for making the payment. Then it becomes relevant that this is a time-sensitive matter. Then they need to decide how they want to go about making that payment.

I also would make sure not to make it orange (or green in the case BTCPay), as that is the color used for buttons (or generally clickable/interactive) elements. You might already have an accent color for informational content (like blue).