Currently URI zip321 only support specifying amount in ZEC. Can we please add 2 extra params to allow supporting different currencies? Open to different naming…
Example
currencyparam=USD
currencyamountparam=10
If the wallet supports currency it would calculate the amount of ZEC using the current exchange rate. If the wallet doesn’t support currencies but “amountparam” is set it would use that as the backup default. Otherwise if it doesn’t support currencies and doesn’t contain the amountparam it wouldn’t default to anything.
I can’t imagine I’m the only one who wants this. Maybe it’s already a feature in some wallets @hanh@NighthawkApps?
Edit: this would useful for printed QR codes that need to adjust the ZEC amount via exchange rates.
Edit 2: Basically I’m just after a way to auto populate the currency amount which is already available in many wallets.
While we are at it we may as well also include param to default to (or at least ask the wallet to prompt the user) to “include my address in memo”. Open to other names…
Use-case
I want to put a printed QR code on the snack/drink fridge at work. Snacks/drinks cost $1 AUD. Currently there is a coin box near the fridge that people put their coins in. All honesty based. I want to add the option to pay for snacks in ZEC without having to put a screen next to the fridge which is not viable in this case.
If it’s honesty-based, it seems to be a niche use case and they could use an average ZEC value. I suppose they aren’t monitoring payments anyway.
In the regular case, having two prices is a bit confusing. The payee asks for 1 AUD and receives 0.2 ZEC. Is it enough? To determine that, it needs to have the fx rate. Then why not give the price in ZEC in the first place unless it doesn’t have a screen? But if it has the ability to recognize incoming blockchain payments, shouldn’t it include a screen too?
You’d need to include the price in ZEC for legacy wallets that do not support your feature yet.
Even if there was only one price in AUD, my point is that the receiver should be the one who decides the acceptable rate since he’s providing the service/goods.
Even if there was only one price in AUD, my point is that the receiver should be the one who decides the acceptable rate since he’s providing the service/goods.
While true for a honesty system that takes about $2 to $10 a day the cost of deciding the price in ZEC is more then it’s worth. They’d be happy to take any lost cents by providing a service to those they may not have otherwise purchased those goods.
The other example for this is an unmanned roadside pumpkin stall. A driver pulls over and doesn’t have cash but has a Zcash wallet. Pumpkins are $2 AUD. Most people only buy 1 pumpkin so default to $2. They stuck the QR code on the stall a year ago and haven’t had to replace it.
I’m not talking about the honesty system for which a QR code with a fixed price in ZEC works fine IMO.
For other use cases, I think the payee will want to set the price himself.
Isn’t that the same use case? The pumpkin stall does not have an internet connection, therefore it cannot check whether any payment was made. It’s a honesty system too.
In a group of people that trust each other to be ethical wouldn’t the payee actually prefer to charge the user at a close to accurate representation of the exchange rate even if it is decide on the payer’s wallet?
When the exchange rate is set by the payer’s wallet an ethical person will always pay and always use the correct exchange rate. When the price in ZEC is fixed an ethical person may sometimes decide on the method of payment based on which is cheaper. So when the ZEC price of the item is fixed in ZEC isn’t the payee worse off? Especially when the exchange rates can swing 20% in a week and there is a chance the QR code won’t be changed in that time frame.
Let me put it another way. I’m going to put a Zcash QR code on the snack/drinks fridge with no amount set and allow the user to type in 1AUD manually. I just thought this would be a really obvious and straight forward way to prevent the user from having to type it in manually.
So if I understand you correctly, you would like to have the QR code suggest a fiat currency & price while letting the payer choose the fx rate?
And the use case is “the payee trusts the payer to do the right thing and would like to make it easier for the payer to pick the right values”.
If yes, it makes sense but in my opinion, the use case is too rare to make it into a standard feature.
I’ve introduced Zcash to 2 individuals who have gone through the process of reading ZIP321 and generating QR codes. Both were surprised they weren’t able to specify the amount in another currency in the URI.
Another example use-case.
Ongoing service providers
Service provider (e.g. lawn mowing service) visiting house every 2 weeks. Accepts cash or wire/bank transfer. No online/credit/portal/website payment system. After ever visit the service provider emails a pdf invoice detailing the account number and outstanding balance. They manage their accounts with a spreadsheet or some other very basic accounting system. Common in my experience.
Periodically the service provider reviews their bank account and adds any credit to the appropriate account in the spreadsheet.
If the service provider accepted ZEC they would review their Zcash wallet and add any ZEC as credit to their account. The wallet has a feature that displays the amount in another currency based in the exchange rate at time of transaction which is what they’d used as the amount to credit the account.
@NighthawkApps are you interested in introducing support for other currencies in the uri in the future? I’ll be introducing Zcash to under 100 people for the first time in about 3 days. Would be nice if I could describe this feature as “coming soon”.
The exchange rate can vary drastically in a short period of time. It won’t be captured in a static URI.
AFAIK, there is no crypto currency that supports Fiat in their payment URI. Not Bitcoin, not eth, not even Ripple.
Edit: ywallet supports Fiat currency but converts to Zec when the URI is created.
.