Currency Types and Rendering

[adamroach]

I have some concerns with being able to sensibly render line items, especially with the “currency” field being effectively free-form (the current version says that it may be but does not have to be an ISO currency code).

Simply stated, no one using a US locale checking out from a US store expects to see “58.73 USD,” and this will certainly confuse some people. They’ll want to see “$58.73”. But if there’s no hard-and-fast convention about what “currency” means, then rendering this sensibly will be difficult. So, minimally, I think we need to say that anything that matches an ISO code is guaranteed to be that currency.

Without strictly requiring the currency code to be an ISO-registered value, though, this becomes problematic: any other three-letter code effectively becomes “squatting” in the space, and runs the (admittedly small but nonzero) chance of being later allocated by ISO. Which means that what we really want is some way to say “this is the ISO code for a currency”, and a mutually exclusive way to say “this is not represented with an ISO code, but with a different identifier, which is XXX.”

There's probably more thought to be given to these non-ISO identifiers in terms of renderability, but I'm mostly worried about the conventional currency cases to start with.

[ianbjacobs]

So, minimally, I think we need to say that anything that matches an ISO code is guaranteed to be that currency.

+1 to stating explicitly that the user agent must interpret any code matching an ISO (currency) code as the corresponding currency.

Ian

[adrianhopebailie]

I believe this issue highlights the need for implicit display semantics where they are not easily implied. For valid ISO currency codes it is easy to imply how a number must be displayed however not so for other currencies.

This suggests we need a mechanism for the website to provide these semantics to the browser.

Would an additional, optional, property like displayFormat solve this? It could use ES6 Template Strings

[ianbjacobs]

IMO this feels like it's too much for v1. We are talking about edge cases and I don't think we should focus on those right now.

Ian

[adamroach]

To be clear, when I say "some mutually exclusive way to say 'this is not represented with an ISO code, but with a different identifier, which is XXX'", it could be as simple as requiring any non-ISO codes to be prefixed with a "+"; e.g:

{
  "currency": "+DGC",
  "value" : "87000.00"
}

[dlongley]

I think non-ISO currency codes should be represented with a URL -- and that URL may, optionally, in the future, provide machine-readable information such as "displayFormat" to allow displayers to discover this information and properly display the currency. This approach allows us to largely ignore this issue for v1, but have a path forward for v2+.

[adamroach]

I think non-ISO currency codes should be represented with a URL

I find this approach very appealing. +1

[adrianhopebailie]

I think non-ISO currency codes should be represented with a URL

👍

To be clear, is the suggestion that currency should be either a 3 letter code or a valid URL with the handling of the URL form to be determined in future?

Can I suggest that we allow 3-letter codes that are not necessarily valid ISO codes as these have become very common (XBT, BTC, ETH, LTC, XRP) and are pretty easy to display as is?

For valid codes that the browser recognises (i.e. doesn't have to be valid ISO) the browser may implement appropriate display logic (i.e. for USD display as $ xxx.xx)

[dlongley]

@adrianhopebailie,

To be clear, is the suggestion that currency should be either a 3 letter code or a valid URL with the handling of the URL form to be determined in future?

Yes.

Can I suggest that we allow 3-letter codes that are not necessarily valid ISO codes as these have become very common (XBT, BTC, ETH, LTC, XRP) and are pretty easy to display as is?

I'm not opposed to this idea, I just don't know how you say whether or not a code fits into that grouping. Maybe we could specify them.

For valid codes that the browser recognises (i.e. doesn't have to be valid ISO) the browser may implement appropriate display logic (i.e. for USD display as $ xxx.xx)

In terms of spec text this essentially would be something like: "If the currency does not have an ISO code, it SHOULD be represented by a URL" (not a MUST)?

[ianbjacobs]

It seems to me unlikely that browsers would dynamically support display of arbitrary strings or other items.

Therefore, they would likely need to have built in the support, and they would have researched how to provide that support. Thus, I think a URL in this situation is not likely to be superior to any other type of string since I doubt strongly it will be dereferenced by either human or machine.

Thus, it seems to me that we don't need to say more than "Treat ISO codes per spec."

Ian
Ian

[dlongley]

@ianbjacobs,

It seems to me unlikely that browsers would dynamically support display of arbitrary strings or other items.

Payment Apps will also be displaying currency amounts. This isn't a browser-centric design. Browsers could just as easily treat URLs as opaque strings as 3-letter currency codes. If they recognize an opaque string (identifier) then they can do special display for it. This approach should place no burden on a browser but will also not limit the flexibility of Payment Apps.

To be clear, it would be nice if we modeled currency the same way for both Payment Apps and for the browser. That is why I say it's not a browser-centric design.

[adrianhopebailie]

@ianbjacobs if the URL dereferenced to a document that provided URL's for icons, regex for formatting etc I'd imagine they'd consider using these display hints.

We already have one browser that has expressed interest in the idea.

Ultimately this is just a display concern for the browser, it's the payment app that must actually make sense of the currency so as @dlongley says we should be careful about only thinking about the display considerations.

[adamroach]

Can I suggest that we allow 3-letter codes that are not necessarily valid ISO codes as these have become very common (XBT, BTC, ETH, LTC, XRP) and are pretty easy to display as is?

The issue there is that we're going to have some hard problems to solve if Bhutan ever changes their currency to a name starting with "C", or Ethiopia changes their currency to start with "H". I'll admit that it's pretty unlikely that Lithuania will get off the Euro any time soon, but there's still a matter of dealing with the distant future.

It's not elegant, but we can accommodate this set of cases like:

1. Any three-letter code MUST be an ISO 4217 code
2. The payments API document will define a short list of codes of the form "+XXX" corresponding to well-known non-ISO-registered value instruments (e.g., "+BTC")
3. Any other currencies can be represented by a URL, as proposed above.

[davidlehn]

Etsy recently published a nice article about currency display. It's more involved than a simple displayFormat field. They leverage CLDR dataset formatting patterns for language + region + currency combinations. It would be good if new currencies published similar CLDR data so existing formatting tools could be used.
https://codeascraft.com/2016/04/19/how-etsy-formats-currency/

[adrianhopebailie]

It would be good if new currencies published similar CLDR data so existing formatting tools could be used.

• 1 @davidlehn - I think we could get to that in future (where the website provides formatting hints to the browser) but for now I think we can keep it simple and follow the proposal from @adamroach above.

[adrianhopebailie]

@adamroach I like your proposal but would not limit the list of "+" prefixed currencies to a known list.

If the browser is going to simply use the 3 letter code for display then it should accept any 3 letter code.

[ianbjacobs]

@adrianhopebailie,

The issue with "any non-standard 3-letter code" is that it can lead to name collisions on the Web.

If we don't worry about that, then drop the URL part of the proposal because we no longer need it.

If we do worry about that, then keep the URL part of the proposal.

Ian

[adamroach]

+1 to @ianbjacobs' point, which I was about to make.

1. If we care about uniqueness and don't want a known list of non-ISO currencies, all we need is ISO codes and URLs.
2. If we don't care about uniqueness, all we need is ISO codes and something like the "+XXX" format.
3. If we care about uniqueness and want a published list of non-ISO currencies, we need all three.

I'm hearing @adrianhopebailie say he doesn't care about uniqueness, which would point to option 2.

I think we're going to run into practical issues if an identical code can mean two different things in two different contexts, so I think we need either option 1 or option 3.

[dlongley]

+1 to option 1 or option 3

[adrianhopebailie]

I think we are conflating two issues.

Issue 1 is the need for browsers to recognize the currency identifier so they can provide an appropriate display. That means they need to know what symbol to use, where to put it and how to format the numbers. A lot of this is actually tied to i18n stuff (not just the currency).

Issue 2 is the need to allow the ecosystem to introduce currencies without needing them to be explicitly supported by the browser. What if a merchant wants to sell something with loyalty points tomorrow? It's a regular payment request but where the currency is unknown to the browser. Are we saying we don't allow that.

Issue 2 forces us to support uniqueness because I don't want Bob's Tyreshop Credits to be confused with Bitcoins. But, if we solve Issue 2 by saying that a currency can be specified as URL then how do we solve issue 1?

I believe we should allow 3 letter ISO codes and URLs but then we need a way for requests where the currency is a URL to provide display hints to the browser.

[adamroach]

@adrianhopebailie writes:

I believe we should allow 3 letter ISO codes and URLs but then we need a way for requests where the currency is a URL to provide display hints to the browser.

Sure. And that's what @dlongley suggested up-thread: the URL can resolve to a document that describes these display hints. Because, honestly, I'm not sure "XBT" is going to mean much to most people.

This might mean defining at least a primitive (and extensible) format for that document sooner rather than later, but I think that's okay. Clearly we'll want something more advanced eventually, but I think this gets us at least to the property that you're suggesting:

{
  "symbol": "BTC"
}

In terms of backward-compatible extensibility, a future version might expand this to look more like:

{
  // Default Values
  "symbol": "Ƀ",
  "mantissaLength": "5",
  "position": "prefix",
  "spaceSeparator": false,

  // Locale Overrides
  "en": {
    "symbol": ["Bitcoin", "Bitcoins"], // corresponds 'en' to plural forms in Unicode CLDR
    "position": "suffix",
    "spaceSeparator": true
  },
  ...
}

(This is off of the top of my head, and not an polished suggestion; I just wanted to demonstrate how the format could potentially be expanded).

The one issue I see is that this gets us back to the question of who hosts format documents for currencies that may potentially be quite popular, such as Bitcoin. And that brings us back to the three-pronged approach, where we define non-URL codes for specific, well-known currencies that lack official ISO codes.

[ianbjacobs]

PROPOSED:

• ISO
• +NNN for well-known non-ISO codes
• Behavior for other strings is undefined

Rationale:

• I expect the "others" to be edge cases
• Leaving behavior undefined allows experimentation, including using URLs.
• If we were to specify URLs there would be a push to specify what user agents find when they dereference them. I feel like is likely a complex topic that, for edge cases, would not be a high priority for V1 of the specification.

Ian

[adamroach]

To be even more precise: it would be invalid to use a string of (length == 3) unless it is an assigned ISO code.

[rsolomakhin]

We seem to be drifting away from the premise that three-letter alphabetic codes must be ISO currency codes, which is something I thought we had good agreement around.

I propose that three-letter alphabetic codes that are official currency codes should be treated as such. We can also allow unofficial three-letter alphabetic codes. For example: BTX (bitcoin).

[ianbjacobs]

Previously I proposed a three-tiered approach:

1. Anything that is an ISO 3-letter code is treated as such
2. Non-standard 3-letter codes are prefixed with "+"
3. Anything else is undefined for now. You can put whatever data you want there and some parties may make use of it.

But 2 and 3 both amount to "you can do other non-standard things." So a simpler proposal would be:

1. Anything that is an ISO 3-letter code is treated as such.
   (Note that the standard set of codes may expand over time, so there may be times when some
   browsers recognize standard codes, but others have not yet been updated.)

2. Anything else is undefined. So you can put whatever data you want there and some parties may make use of it.

By the way, this seems to be where ECMAScript defines its use of currency codes:
https://tc39.github.io/ecma402/#sec-currency-codes

It talks about normalization of the 3-letter codes, which we should consider.

Ian

[adrianhopebailie]

@ianbjacobs This proposal gives developers no mechanism to provide display hints to the browser for a non-standard currency. So are you proposing that we punt on how to display non-standard currencies (which effectively means we don't support them because there is no standard for how to display them)?

[ianbjacobs]

• I think there is agreement this group should not be specifying how to display non-standard currencies.
• I think it's fine for people to provide hints to other people.
• The question is whether there needs to be a standard way to say "Here are some hints!". My proposal is that we do not need a standard way, but that we not prevent people from doing so. Thus, people MAY use URIs that could identify display hints (or anything else). But that in this version of the standard, we do not require conforming user agents to do anything with that data, and that formally we say that it is undefined. (This way, in the future, we can further refine the semantics of the data if we see that it is useful to do so based on experience.)
• My reasons for why I don't think that we need to are:
  • First, I hope that there won't be a lot of non-standard currencies, at least not for long. So in general I hope this is a small set of cases.
  • Second, unless there are actual display standards that people would point to, then there's not a lot of interoperability to be gained by pointing people at a bunch of different ways to do things.
  • Third, it is not clear to me that browsers would do anything with this information unless they have a lot more knowledge about what they will find.

Ian

[adrianhopebailie]

The question is whether there needs to be a standard way to say "Here are some hints!". My proposal is that we do not need a standard way, but that we not prevent people from doing so.

Yes that is the question but I think you are downplaying the effect of this approach. Realistically we are preventing the use of non-standard currencies entirely.

Whatever mechanism is used to provide display hints needs to be agreed upon by the browser vendors as they are the ones that will actually display pricing. We have them at the table today so why would we not try to find a solution?

First, I hope that there won't be a lot of non-standard currencies, at least not for long. So in general I hope this is a small set of cases.

That means no purchases using loyalty points, air miles, club points or similar? Sounds like a big blocker for merchants that allow this today.

Second, unless there are actual display standards that people would point to, then there's not a lot of interoperability to be gained by pointing people at a bunch of different ways to do things.

Shouldn't we explore this further before shutting down the conversation?

Third, it is not clear to me that browsers would do anything with this information unless they have a lot more knowledge about what they will find.

Mozilla were the original proposers of display hints so I don't agree

[msporny]

Whatever mechanism is used to provide display hints needs to be agreed upon by the browser vendors as they are the ones that will actually display pricing. We have them at the table today so why would we not try to find a solution?

+1, it sounds like there are a number of workable proposals on the table on how to do currency display for non-ISO currencies. This doesn't have to be high priority. We shouldn't close the issue unless there is push back on non-ISO currencies from the browser vendors and payment app developers.

[ianbjacobs]

@adrianhopebailie wrote:

"Whatever mechanism is used to provide display hints needs to be agreed upon by the browser vendors as they are the ones that will actually display pricing. We have them at the table today so why would we not try to find a solution?"

I take the point. I am happy to defer to the browser vendors if they say "We all plan to implement the following approach to hints on how to display non-standard currencies."

Ian

[adrianhopebailie]

I propose we resolve this issue based on @ianbjacobs proposal and create a new issue specifically calling out support for non-standard currencies that we can track and possibly put on the v2 backlog if the group decides to do so.

[msporny]

I propose we resolve this issue based on @ianbjacobs proposal

Which one, his revised one or the original one?

If we're talking about his original one:

+1 for ISO currency codes
+1 for URLs (and specifying display behavior in a separate issue)
-1 for "+BTC" microformat currency codes. That proposal seems to put the WG in the position of maintaining a non-ISO currency code registry. If you have an experimental currency, use a URL.

If we're talking about his revised one:

Anything else is undefined. So you can put whatever data you want there and some parties may make use of it.

-1 to this, sounds like we're not providing guidance to use URLs for non-ISO currencies.

[adamroach]

@rsolomakhin

I propose that three-letter alphabetic codes that are official currency codes should be treated as such. We can also allow unofficial three-letter alphabetic codes. For example: BTX (bitcoin).

If the ISO currency codes were frozen, that might be something we could consider. But the list is constantly updated and maintained, and what is unused today may be allocated tomorrow. It's simply not tenable to squat on unallocated codepoints.

[adamroach]

Poking around online to see how other people have solved this, I tripped across an interesting approach that is kind of a hybrid between the URL approach and short-code approach: currencies would be identified by a system, and a code point within that system. So, for example, for an ISO currency:

{
  "value": "25.00",
  "system": "urn:iso:std:iso:4217",
  "code": "USD"
}

And for non-ISO currencies:

{
  "value": "0.041",
  "system": "http://example.com/bitcoin-and-maybe-other-stuff",
  "code": "BTC"
}

This gives browsers the ability to at least display the code if they aren't familiar with the system. Payment apps would be expected to use the system to interpret the code, so there's no risk of the merchant providing intentionally confusing information there (as doing so would scuttle the payment).

[adrianhopebailie]

+1 to @adamroach and add:

1. system is a URI
2. system is assumed to be the value urn:iso:std:iso:4217 if not specified.
3. The value of code can be any string

[adamroach]

@adrianhopebailie --

1. Yes, system is a URI
2. I'm okay with a default of urn:iso:std:iso:4217
3. The value of code can be any string that is valid within the system

[ianbjacobs]

@adamroach and @adrianhopebailie

I like the direction of the evolving proposal:

• The easy (standard) case remains easy (thanks to default value)
• It gives extensibility for non-standard codes and increases the potential for interop
• It does not require this WG to specify anything related to display
• It does not require the browser to dereference any URLs. (The browser can just do string matching on an internal table.)

[adrianhopebailie]

Proposal from @adamroach accepted at F2F

[ianbjacobs]

I suggest that we not close this issue until the specification has been updated with the proposal.
Ian