Re: [w3c/browser-payment-api] Currency Types and Rendering (#185)

@ianbjacobs said:
> How to display non-standard currencies (which I'm sure is a huge topic that I continue to think is out of scope)

This is in scope because the spec defines features that require implementors to display amounts (display items, shipping costs, etc). The ecosystem can't use non-standard currencies as a result of the mediator having a requirement to display amounts.

In an ideal world the only entities that need to understand what a non-standard currency identifier means would be the merchant and payment app but we've made the decision to put pricing UI in front of users as a feature of the flow so we need to define how that UI should handle non-standard currencies. At a minimum we should provide guidance so that we increase the chances of this being done consistently across implementations.

The only reason we don't have to do this for standard currencies is because it's already done so we trust the browsers to simply use the existing guidance.

If we leave this out then the exact same checkout experience on two browsers would be completely different. Imagine a payment request for 1 bitcoin that is rendered to the user in any one of the following ways depending on which browser they use:
* XBT 1
* 1 BTC
* <img src="https://en.bitcoin.it/w/images/en/archive/6/69/20150905134750!Btc-sans.png" width="12px" height="16px"/> 1

>From an interoperability perspective the spec has failed.

> I think we should allow for some experimentation here before we say "It MUST be a URL if it's not a three-letter ISO code."

I am not saying we need to say the identifier has to be a URL, that is a separate issue. I am saying that whatever we use for identifiers for non-standard currencies needs to be accompanied with a mechanism to help the user agent with display of amounts in that currency so that browser will can be consistent.

Or, as @rsolomakhin said

> As far as URLs go, it would be nice to present them uniformly across browser vendors

@tommythorsen  said

> I honestly believe that the problem of currency symbol conflict is not our job to solve. As long as the merchant has a way to pass a currency symbol to the payment app, the burden is upon them to agree what that symbol means

👍 - although I think you mean currency identifier not symbol?

The problem here is how we decide what is shown to the user before the request gets to the app?

> the burden is upon the mediator to present this in a user-friendly way.

👍 - although we should provide a way browsers to do this consistently (per @rsolomakhin above)

---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/browser-payment-api/issues/185#issuecomment-222164117