Payment request

[omnat]

Brief: https://docs.google.com/document/d/1e1w93XkXFnpiSg4nuj-S36jGSimlHGiAaxu5YCcD_mA/edit#heading=h.z5etji6xe44v

@omnat to walkthrough this with CJ
Conditional user testing (depending if the design is a new pattern)

[bdresser]

in public beta, may want to link out to the Simplex page as an option for fiat onboarding

relates to MetaMask/metamask-extension#4867

[cjeria]

Gif of the initial lo-fi prototype of the payment request feature that @omnat's been testing.

[bdresser]

what about a "Show QR" option in addition to Send & Copy?

I see the QR option on the previous tray, but it'd be nice to also be able to encode an entire transaction (can I have .5 ETH) and just show that to a friend, who could scan & just tap "Confirm"

Also not super keen on the copy
Receiver will need the link below to send requested amount

• either party could be the "receiver"
• they don't actually need the link , they could always do this manually?
• maybe something like Send this link to a friend, and it will ask them to send [X ETH] to [Account Name]

[bdresser]

From design sync

• Add gas fee on top of the requested amount
• Add option to change asset being requested (maybe a simple drop down with autocomplete)
• Flow for when the other user taps a link
  • Drops other user in edit/send screen with amount, asset, address pre-populated
  • Ideally is possible to open the link in other apps as well

[omnat]

From design sync:

• visual design pass on the sender flow

Design receiver flow in different issue #83

[cjeria]

@bdresser @brunobar79 we're not considering NFT's for the request flow right?

[cjeria]

Updated payment request flow.

Up next:

• Adding ETH to fiat swapper
• If sending tokens, need to represent the token value + fiat conversion
• Consider adding token symbols to request amount screen
• Custom icons on the first receive option screen

[cjeria]

Here's an updated design. If the user selects a token to send, display the token symbol in the amount screen.

[omnat]

User test outcome below. Suggestion to highlight one of the 3 options on the last screen to inspire finishing of action. And the standard practice to add a confirmation after request is sent.

Question: will this sent request be stored in user's history? E.g., as a user, can I see all the requests I've made in the past and status on those (which ones succeeded, which ones rejected, and which ones pending..)? @cjeria

[estebanmino]

We can surely save the information of the requests that an user has sent.

which ones succeeded, which ones rejected, and which ones pending: we don't have the architecture to do this yet, as a payment request receiver you'll be able to send the transaction but not be able to directly (through MM) reply the status of it, yet.

[cjeria]

Updated request page per user research @omnat

[bdresser]

This looks great @cjeria!

Question for esteban and bruno: do you think the link will be as short as the one shown, or should we design for the case where the link ends up super long (and give a ... in the middle or something) ?

Question: will this sent request be stored in user's history? E.g., as a user, can I see all the requests I've made in the past and status on those (which ones succeeded, which ones rejected, and which ones pending..)?

We could theoretically show each of these links in the users tx history as a request ? But as esteban points out, we won't know much additional information about these requests, even basic stuff like who they sent it to, or whether or not the other user completes the tx. I think we should hold off on any dedicated management screens for these until we have more robust features like in-app messaging.

[estebanmino]

I think the second case would be the best here, for example to send 1 ETH in mainnet we have

ethereum:0x56CED0d816c668d7c0ccc3FBF0aB2c6896F589a2@1?value=1e18

that won't fit in all devices screens in the same way. Furthermore, we have ERC20 tokens, a edge case for that would be an user sending an amount with many decimal places or large amount of tokens.

Bruno made this generator that is online here https://brunobar79.github.io/eip681-link-generator/#, we're going to use the same logic behind it.

[bdresser]

Fimga link

[bdresser]

q's from @estebanmino

• on the partial modal, we have an X that isn't on other partial modals -- should we keep?
• how do we decide which tokens we want to show on the "pick asset" screen? maybe just show search box? @cjeria to think about a little bit more
• @cjeria to combine QR presentations to a single modal
• when you tap the receive + button in an asset view, we should take the user to the same four-tile screen

[estebanmino]

@cjeria RE how do we decide which tokens we want to show on the "pick asset" screen?:
While we wait for final designs I implemented both options in one as we talked today.

Dai and ETH are assets by default, combined with a new search asset component that we can modify to match designs.