search

alephium / alephium-frontend

A monorepo containing all things frontend on Alephium.
Other
11 stars 9 forks source link

Payment request flow #273

Open mvaivre opened 7 months ago

mvaivre commented 7 months ago

Adds the ability to emit a simple payement request, avoiding copy/paste & fat finger mistakes.

Receiver can generate a sharable deep link (from the "receive page") which embeds the receiving address hash along with the desired tokens and amounts.

The link can be easily copied or shared through any messenger app (on mobile). When clicked, the link is "understood" by both the MW & DW and should trigger the opening of the "verify tx" modal, with the address, amount and token fields auto completed.

nop33 commented 2 months ago

Payment QR codes. I had this experience in Greece where I paid withEUR for someone for his dinner and he wanted to pay me back in ALPH. He owed me 60 EUR and we didn’t know how much ALPH he should send me, so we went on CoinGecko to figure it out. So unnecessary. What we could do is that when the user goes to the “Receive” screen, instead of just selecting an address, which then displays the QR code of the address, we could embed more info in that QR code, such as how much ALPH/fiat we want to receive. Then, when another mobile wallet scans the QR code, everything is prefilled and the user only has to press “Send”.

We could even allow entering the value in fiat and doing the conversion to ALPH based on the current price so that the user doesn’t even need to leave the app to calculate how much they should send.

A step further would be creating payment links but that will require more infrastructure. What I just described can be done with what we have today, 2 smartphones that one displays the payment QR code and the other scans it.

I think the idea of extending our “Receive” flow by adding a “define amount” button which allows the user to enter an amount in ALPH (or any other token) and display an enhanced QR code instead of a QR code that represents only the receiving address is simple enough to implement easily.

We already had a request to display the fiat values of a tx before confirming the sending process, but I think the reason why users ask for this is that they initially want to enter a fiat amount and send the equivalent in ALPH. So specifying a fiat amount when creating a tx sounds like the right way to do this!