Thanks @hanh. To be clear I’m not asking for wallets to support creation of QR code that supports other currencies in the URI. Only to accept QR codes (and URIs) that specify other currencies.
Then how do we support this use-case? Currently the only form or URI support would be for an email/pdf invoice to set both a USD and ZEC price on the invoice. The payer pays the invoice 10days later. ZEC rate is different of course. If the price of ZEC has goes down then the payee is incentivise to buy ZEC and pay the bill in ZEC. The payee is worse off. If ZEC becomes more expensive the user is incentivise to pay in USD and the payee receive adequate funds.
I’m suggesting the payee should set the price in the currency they are most comfortable with (e.g. USD). When the payer clicks the ZEC URI or scans the QR code the wallet sets up a transfer for $xxxUSD which is converted by the wallet at the most recent exchange rate. When the payee reviews their accounts their wallet they see the ZEC payment has been made. Maybe in the future a wallet provider might support displaying the transaction amount in USD at the historical exchange rate at time of the transaction so the payee can check they aren’t getting ripped off.
The thing I’m discovering from talking to people is the average person is more interested in how cryptocurrencies can make their lives easier not whether or not someone is going to try to scan a few cents off them by using a slightly incorrect exchange rate. When I show them they can scan a QR code and then pay for something in 1 click they are in awe at how easy it was compared to some other forms of payment such as bank transfers which require many many clicks. That’s why I’d like for wallets to support other currencies in the URI. When I can show them that a simple URI can be crafted that allows someone else to pay them $1USD for <1cent transaction fees they grasp the usefulness much more then simply some “imaginary” tokens (i.e. ZEC).
Actually that makes me think of another feature that’d be useful. Add another param that adds the exchange rate and currency amount payed added to memo . Problem solved! If they disagree on exchange rate they can discuss with payer. I suspect 99% of time it’ll be fine. But I guess some of that depends on the honesty of the community you live in .
Well… It is a hard no for me. Zec is not usd. I am against any mechanism that would imply there is a equivalence. If it was a stablecoin, that would be ok.
There is a mechanism on BitPay or something that gives prices in 15 minute windows. Paul from edge wallet told me about it but idk much more or if it is helpful here. Maybe others do.
What equivalence are you worried about implying? The mechanism would only be implying a certain amount of ZEC has an equivalent going market rate to the USD.
ZGo already has this feature for all orders generated through the app. Each order has the fiat amount, the ZEC price at the time and the ZEC amount requested via QR code. Providers can download their orders in a CSV if needed.
ZGo’s invoicing feature calculates the ZEC amount when the buyer opens the invoice. If they open the invoice and don’t pay, wait 60 days and come back and reopen the invoice, the latest ZEC price available is used to calculate the ZEC amount for the invoice.
The same thing happens in BTCPayServer. Payment URIs are dynamically generated and expire after a while.
But I don’t think having a static payment URI in Fiat works out financially speaking.
Thanks for driving the ZIP-321 QR-code usability issues @GGuy. With the upcoming feature set of ZSAs, it would be wise to re-visit every ZIP related to end-user interaction and work out the UX improvements to make any developer interface their existing applications with PoS systems that are constrained to certain jurisdictions/location.
The ZIP should consider reserving an assetId, assetType and unit for fiat currencies per the ISO 4217 codes to make it easy for exchanges, developers and users to rely on accuracy of transaction details when sharing QR codes or deep links. The same fields can be utilized for building a transaction for ZSAs transfers. I can help lead the ZIP update discussion.
It is to be noted that there are other urgent Zcash core priorities with the fee change mechanism going live and increasing the adoption of UAs and Orchard wallets. Till then, the end-user may want to rely on using a third party website/service to gather the ZEC amount to transfer in local currency before making a manual transaction, the QR code can be limited to scanning the merchant’s address for non-USD currencies.
@NighthawkApps development has been lagging since the past 6 months and the wallet has been practically unuseable for daily use. So we can’t really describe any features as “coming soon” before fixing the core wallet syncing issues and the denial of service affecting the Zcash network.
What I don’t understand is it’s already a feature to calculate exchange rate on the client side. I can enter $1USD as a transaction amount manually. Why is putting it in a URI different?
What if I wanted to put a QR code on my fridge as a shortcut so I could transfer my child ~$10USD to buy himself lunch at school every morning? Are you telling me I can only have a QR code with his address with no USD amount? My child might be able to pay in ZEC but the prices are set in USD. Why do I have to type in $10 every morning so that I’m sure they have enough base on the mornings exchange rate? UX is awful in this case because I’m surely going to mistype one morning and either give them $1 or $100 worth .
Sure I get it, sometime by the time they buy lunch they will only have $9USD worth of ZEC. But other days they might have $11USD worth. It’s all part of the fun .
I think the problem is you’re assuming the use-cases for URIs/QR codes are part of some adversarial use-case where the two parties are out to get each other. There are a ton of use-cases when both parties (payee and payer) have vested interests to do the right thing and it doesn’t matter which entity calculate the exchange rate/price.
I was thinking this. The URI/QR could contain the exchange URL it wants the wallet to use which could, as you suggested, point to some exchange rate feed that’s as average of many independent exchanges.
You could take this a step further and have a URI param for “amountURL” that makes a request for the amount in ZEC.
IMO: If it is a new standard, not an extension to existing payment URI, it’s ok to try new things. But Payment URI have a behavior that people (like me) expect. It expresses the price of an item/service, just like a price tag. I don’t expect a price tag in a store to show the price in anything but the local currency. I don’t think I would notice a price tag that doesn’t.
I don’t think a merchant would want to let the customer set the exchange rate. I’ve seen stores where you could pay in the local currency or in USD but invariably the owner sets the exchange rate (in his favor).
I think the use case you described are covered by remittance or recurrent payments. Many traditional banks already offer this service on their e-banking platform. Crypto wallets could support this in the future too.
Either way, I don’t see a need to add a currency exchange functionality to payment URI. Even if it’s optional, it could be exploited by scammers.
FWIW this will be printed and stuck to the fridge later today and introduce almost 100people to Zcash for the first time. Unfortunately people will have to manually type $1AUD each time. But either way still a cool way to introduce people to Zcash .
. Problem solved! If they disagree on exchange rate they can discuss with payer. I suspect 99% of time it’ll be fine. But I guess some of that depends on the honesty of the community you live in 
.
.
.
