CurrencySystem is at risk
The W3C Web Payments working group has hit a major milestone, the Payment Request API has progressed to Candidate Recommendation. That means we have a few months to use the API and test interoperability between different browsers before it becomes a Proposed Recommendation and is feature-frozen. (The deadline for comments for Candidate Recommendation is 31 October 2017.)
Another aspect of the CR stage in the W3C process, is that experimental features included in the specification are marked “At Risk”. This indicates that when the specification exits CR the WG must decide if there has been sufficient demand for the feature to justify keeping it.
What is CurrencySystem?
All amounts in the Payment Request API are expressed as a PaymentCurrencyAmount dictionary which has a member, currencySystem, that specifies the currency system that is in use. By default this is the ISO 4217 set of currencies, the ones we are all familiar with like USD (US Dollar) or my native ZAR (South African Rand).
Specifying the currency of a payment request is not only essential for processing (obviously) but is used extensively by browsers to render appropriate UI.
As a result, if a website creates a PaymentRequest with amounts from an unknown currency system the browser is unable to pretty up the UI for that currency.
Why is CurrencySystem at risk?
Browsers like to validate input, especially if that input affects the UI they render to their users. If you read the thread on Issue 490 you’ll get some context on this from the spec editors.
Allowing a website to request payments in an obscure currency, like airline miles or crypto-currency, is a UI and security challenge with a lot of questions (how long is a valid non-ISO4217 currency code?) and not many answers without detailed use cases from the affected developer communities.
5 years ago this feature may have been dropped by the standards process unquestioned (and it still might), but as Michael del Castillo has pointed out recently, the new browser APIs open the door for an exciting new world of payment methods like the Interledger protocol and new currencies like Bitcoin, Ether and XRP.
Without the ability to express amounts in alternative currencies the use cases for the new browser APIs are seriously curtailed.
What about “3-character-alpha non-ISO4217 codes”?
Strictly speaking an implementation of the current specification will accept any 3-letter currency code. The specification says:
When using [ISO4217], all well-formed 3-letter alphabetic codes are allowed (i.e., the numeric codes are not supported). Their canonical form is upper case. However, the set of combinations of currency code for which localized currency symbols are available is implementation dependent. Where a localized currency symbol is not available, a user agent should use U+00A4 (¤) for formatting.
This beg’s the question though, what’s the correct code for Bitcoin? Is it BTC (the de-facto standard) or XBT (the more correct but less used alternative code)?
The ISO 4217 system uses a 2-letter alpha country code as the first two letters of all currency codes and on that basis, BTC is a non-existent currency from Bhutan. It would be quite confusing if the Bhutan flag appeared next to a Bitcoin payment because BTC was mistakenly interpreted as an ISO 4217 code.
Some crypto-currencies like XRP have stuck to the ISO 4217 convention for “supranational” currencies, while others like Z Cash (ZEC) have considered it but chose to ignore it.
At the time of writing, only 3 of the top 10 crypto-currencies by market capitalization follow the ISO 4217 rules. Even worse, 2 of the listed currencies don’t even use 3-letter codes (DASH and MIOTA).
The risk of squatting on legitimate codes was raised early on by Adam Roach from Mozilla, who proposed the current currency system solution. (There’s a lot of history behind the current design.)
The issue then is, what is stopping the current flurry of ICOs from quickly squatting on all remaining 3-letter alpha codes that start with legitimate country codes? It’s like the gold-rush for 3-letter domain names all over again.
As I think this illustrates, simply using ISO 4217-style codes and hoping for the best is probably not a good solution and this doesn’t even address the non-crypto use cases like airline miles, loyalty points or the many other non-money currencies we use everyday.
Without CurrencySystem, or something like it, the developer community is in for a big headache. Admittedly, support for CurrencySystem simply shifts that burden to the browsers but that’s long been the preference for any W3C standard that has wide support.
What can you do next?
If you have a use case for non-traditional currencies then the Working Group wants to hear from you (before 31 October).