m2049r / xmrwallet

monerujo: An Android Monero Wallet
https://www.monerujo.io/
Apache License 2.0
607 stars 275 forks source link

[FEATURE] Merchant Mode #816

Open ghost opened 2 years ago

ghost commented 2 years ago

Adoption is a big part of what the success of Monero means. At the moment if a in real life merchant wants to accept Monero, can open the Monerujo wallet in street mode, and start generating QR codes. But this experience could be better. My proposal:

  1. The seller puts the amount in XMR or any local currency.
  2. A QR code is generated with a sub-address only for this invoice.
  3. The seller is noticed if something goes wrong (buyer sent wrong amount or is trying to do some kind of attack)
  4. If all is going as expected, Monerujo goes again to screen 1.

This increases a lot the UX of merchants that nowadays have to:

  1. Generate QR for the amount. Adding description and local currency.
  2. Show QR to buyer.
  3. Go to main screen to see if payment is received.
  4. Go again to the QR code generator and input all again (currency and description) And here there is no a specific sub-address for each invoice which could lead to some confusion when accepting payments of multiple people in a short time-frame.
nahuhh commented 2 years ago
  1. A QR code is generated with a sub-address only for this invoice.

I'd say no to rotating addresses for a merchant mode. Id much prefer a static address for merchants or better, merchants should be using openalias or unstoppable domains with a static address.

I'd swap out #2 for

  1. a qr code is shown
  2. Each tx haan auto generated private note containing the time and historical exchange rate
  3. If the entered amount for 1 and the historical exchange rate differ by >1%, notify the merchant
m2049r commented 2 years ago

@anhdres @Baltsar

Baltsar commented 2 years ago

Alright

anhdres commented 2 years ago

Id much prefer a static address for merchants or better, merchants should be using openalias or unstoppable domains with a static address. This could be a setting, but why are you against generating a new subaddress per tx? I see that it will create lots of subaddresses, but the only issue would be if the vendor generates more than 100 subaddresses that receive no funds. Am I right?

But this experience could be better. We'll explore it. What you're describing sounds like a mode that is enabled once the wallet is unlocked, much like the street mode. Locking the QR window would be a must in this case.

nahuhh commented 2 years ago

Id much prefer a static address for merchants or better, merchants should be using openalias or unstoppable domains with a static address.

This could be a setting, but why are you against generating a new subaddress per tx?

I'm not against it as a feature that can be turned on and off, but i do not see the benefit of it in regards to a merchant. A reputable merchant should have no reason to hide their payment addresses.

If im working at a market, all of my customers should be able to prove that they paid my booth.

All of this is strictly assuming merchant mode is meant for in person TX with a business.

I see that it will create lots of subaddresses, but the only issue would be if the vendor generates more than 100 subaddresses that receive no funds. Am I right?

I just dont see what use a mechant would have where he required more than 1 address per department.

Again, I dont think merchant mode has any relevance towards online sales, so this is strictly assuming in person purchases from a business.

What you're describing sounds like a mode that is enabled once the wallet is unlocked, much like the street mode.

Correct

Locking the QR window would be a must in this case.

The more I think about this, I think this is better done using 2 devices.

Merchant mode could be

After the Monerujo device sees the tx on the blockchain, monerujo device should reset the screensaver on the POS, getting ready for the next customer