search

w3c / payment-request

Payment Request API
https://www.w3.org/TR/payment-request/
Other
489 stars 135 forks source link

remove currencySystem member #694

Closed marcoscaceres closed 6 years ago

marcoscaceres commented 6 years ago

closes #617

The following tasks have been completed:

Preview | Diff

adrianhopebailie commented 6 years ago

@marcoscaceres this was discussed on the call today. Chairs will send out a CfC to remove currencySystem.

It would be helpful if that could include some description of what will be supported. Specifically, can someone use PR API to accept a Bitcoin, Ethereum or XRP payment for example?

I think I understand the current implementations as being able to handle any currency that is expressed as a 3 char code but would like to confirm that this is not limited to the official ISO 4217 set?

ianbjacobs commented 6 years ago

@marcoscaceres,

After discussion with @adrianhopebailie, we propose to start the CfC after hearing your reply to his question on current implementation behavior.

Also, will the spec say anything about recovery in the case of non-standard codes?

Ian

marcoscaceres commented 6 years ago

It would be helpful if that could include some description of what will be supported. Specifically, can someone use PR API to accept a Bitcoin, Ethereum or XRP payment for example?

Yes, absolutely.

I think I understand the current implementations as being able to handle any currency that is expressed as a 3 char code but would like to confirm that this is not limited to the official ISO 4217 set?

I think for v1, we should do ISO 4217 (get us past CR). But, in parallel (like starting today!), we should spin up our own currency registry (similar to the card brands registry) - and we should use that registry to coordinate with the ISO folks. Basically, currency codes we come up with should end up in future updates to ISO 4217. According to Wikipedia, ISO is already considering some preliminary cryptocurrency codes. @ianbjacobs, do we know anyone at SIX Interbank Clearing AG we can talk to?

ianbjacobs commented 6 years ago

@marcoscaceres, I will see if I can start a conversation with SIX Interbank Clearing AG.

In the meantime, I have added to the FTF agenda the topic of a local registry.

@adrianhopebailie, should we proceed with a CfC about the removal of the feature and discussion in Singapore? Or wait until after that discussion to remove it?

Ian

adrianhopebailie commented 6 years ago

I think for v1, we should do ISO 4217 (get us past CR). But, in parallel (like starting today!), we should spin up our own currency registry (similar to the card brands registry) - and we should use that registry to coordinate with the ISO folks.

I wouldn't support that. Glad I asked before we issued a CfC!

The whole point of currencySystem was to not force users to use only currencies from a registry.

Currencies are not as rigid a concept as many would think.

I can make up a currency today and have a community who are willing to trade in that currency online but I am prohibited from using PR until I get my currency on some registry and wait for browsers to add support for it?

There are currently over 1500 crypto-currencies listed at https://coinmarketcap.com/all/views/all/

There are innumerable private loyalty points schemes that will want to ultimately allow their users to pay with their points.

This is a scaling problem we can't solve using a registry and I certainly don't think W3C wants to maintain it nor do you want to have to keep your browsers up to date with it.

I propose that for CR we make no mention of ISO 4217 and stick with the reference to https://www.ecma-international.org/ecma-402/4.0/index.html#sec-iswellformedcurrencycode which appears to allow any uppercase alpha code that is exactly 3 chars long and doesn't appear to compare the value to a set of allowed values.

Anyone that wants to use non-ISO 4217 currencies just needs to find an appropriate 3 letter code. (ISO 4217 allocated the X** namespace for exactly that use case, unfortunately not everyone in the crypto-currency world adhered to that).

So, if I use the values XBT (Bitcoin), XRP, or ETH I should be able to use PR, but I would understand if the browser didn't have a nice currency symbol to show on the UI.

rsolomakhin commented 6 years ago

I would support removing currency system because not a single merchant or payment app has partnered with us to use a non-standard currency. When/if this happens, we can revisit the problem. At this time, I would prefer to solve the use cases of the people that are interested in working with us.

marcoscaceres commented 6 years ago

@adrianhopebailie, wrote:

I can make up a currency today and have a community who are willing to trade in that currency online but I am prohibited from using PR until I get my currency on some registry and wait for browsers to add support for it?

I think this is a very important discussion that we need to have. @ianbjacobs, @adrianhopebailie, something to add to the f2f agenda? The question is, how do we keep users safe from bad actors in the cryptocurrency ecosystem, while also empowering good actors?

Lately, due to high fraud, companies like Google and Facebook have moved to ban advertising of cryptocurrencies on their platforms (with Twitter possibly following suit). This is very concerning, obviously, so we are interested in ways of minimizing the risks of users being asked to pay with, or to buy, fraudulent cryptocurrencies.

I propose that for CR we make no mention of ISO 4217 and stick with the reference to https://www.ecma-international.org/ecma-402/4.0/index.html#sec-iswellformedcurrencycode which appears to allow any uppercase alpha code that is exactly 3 chars long and doesn't appear to compare the value to a set of allowed values.

That's pretty much where we end up after this PR - except descriptively references ISO4217 so a reader knows about the 3-letter format. There is no algorithmic check that the code must exist in "ISO 4217" (i.e., it's just the well-formedness check, as you point out).

marcoscaceres commented 6 years ago

@adrianhopebailie, wrote:

So, if I use the values XBT (Bitcoin), XRP, or ETH I should be able to use PR, but I would understand if the browser didn't have a nice currency symbol to show on the UI.

We have text for this too ☺️:

Where a localized currency symbol is not available, a user agent SHOULD use U+00A4 (¤) for formatting.

adrianhopebailie commented 6 years ago

@marcoscaceres, I think we're on the same page I just wanted to be clear on the nuances of what we're proposing to end up with after taking out currencySystem.

Can we include the following in the CfC to give WG members a summary of the expected new behaviour:

"Implementations will support a single currency system, ISO 4217. Specifically they will expect currency codes to be well-formed 3-letter codes as defined by ECMA 6 isWellFormedCurrencyCode. Implementations will therefor allow the use of well-formed codes that are not recognized currency codes from the ISO 4217 list such as XBT, XRP etc. If the provided code is a recognized currency then implementations MAY provide additional UI hints such as appropriate symbols in the user interface."

domenic commented 6 years ago

I think it's still an open question whether implementers want to allow the use of such non-recognized currencies. Given comments so far in this thread (e.g. @rsolomakhin's), I don't think that's clear at all.

adrianhopebailie commented 6 years ago

I think it's still an open question whether implementers want to allow the use of such non-recognized currencies.

Then that begs the question, why would they not allow these currencies? My understanding of the issue when it first came up was the desire to be able to do UI related stuff like show appropriate currency symbols. If that is not the only limitation then we should discuss these new constraints.

Let me say on the record Ripple would like to see support for XRP as a currency code and has demonstrated a number of examples over the last year of how this would be used in conjunction with the interledger payment method so there is at least one participant asking for non-ISO but well-formed.

I assume there are participants that would like to see other codes like XBT (or even BTC) supported.

webpayments-specs commented 6 years ago

Hi, all, Please may I add a practical comment from IFSF experience. IFSF use 4217 the 3 alpha-character code, the 3 numeric code and the currency symbol. However Fuel retailers have always issued loyalty stamps (at least over the last 30 years) and loyalty coupons/“points" and these form part of a “currency-like” payment method. e.g. 500 points is worth $10.

What IFSF did was extend the ISO currency codes with additional “Fuel" specific currency codes. E.g. we added LST and LSP (as loyalty stamp and Loyalty points) as a pseudo currency. With a pseudo "currency symbol" as well - optional.

These ”currencies" are most likely only know by the issuers since BP points and Texaco points might not have the same financial value and certainly are not interchangeable. A BP site will not accept Texaco points or vice a versa. These pseudo currencies have for 30 years rode on the back of “real" currencies. Using the same fields and messages as financial transactions (in ISO 8583 for example and been specified in the latest ISO20022 standard).

However you cannot expect a Retailer or Merchant to accept a currency he cannot clear and reasonably expect reimbursement. So a Shell retailer can be reasonably expected to accept Shell Loyalty points in exchange for fuel, goods and services but not accept BP loyalty points.

Implementors know which pseudo currencies they are accepting. And in all cases I am familiar with, there is always a need for it to be authorised (does the customer really have the points/stamps he claims) in exactly the same way as "are there sufficient dollars on his account” to pay for the products taken/to be taken.

So in my view the data transfer / interchange protocols must accept any currency code or symbol…. Yet those accepted by a particular retailer/merchant are “configured”. Local and pseudo currencies are configured in the local implementation.

I hope this clarifies the discussion ….

marcoscaceres commented 6 years ago

Might be more accurate to say (small nit fixes):

Implementations enforce ISO ISO 4217's 3-letter codes format via ECMAScript’s “isWellFormedCurrencyCode” algorithm. Implementations will therefore allow the use of well-formed currency codes that are not part of ISO 4217 list (e.g., XBT, XRP etc.). If the provided code is a currency that the browser knows how to display, then implementation usually provide additional UI hints such as appropriate symbols in the user interface (e.g., "USD" is shown as "$", "GBP" is "£", and so on). When a code is can't be matched, we recommend browsers show a scarab "¤".

We are continuing to evolve the standard as we gain experience as to how it’s going to be used.

But it would be really helpful to this discussion to see examples of retailer’s websites that use points/alternative currencies that they themselves don’t control. A few screenshots would really help!

stpeter commented 6 years ago

@adrianhopebailie said:

Currencies are not as rigid a concept as many would think.

Registries are not as rigid a concept as many would think, either.

marcoscaceres commented 6 years ago

@adrianhopebailie, I updated https://github.com/w3c/payment-request/pull/694#issuecomment-376200400 above.

@domenic, wrote:

I think it's still an open question whether implementers want to allow the use of such non-recognized currencies.

Agree. I've spun up https://github.com/mozilla/standards-positions/issues/78 for Mozilla opinions (in the context of cryptocurrencies and in currencies in general). Some interesting feedback and questions there already.

ianbjacobs commented 6 years ago

@marcoscaceres, @adrianhopebailie, I am making progress on my outreach to the people that maintain ISO 4217. Stay tuned!

marcoscaceres commented 6 years ago

Concluded on the Mozilla side that things as currently specified are ok. The comment at https://github.com/w3c/payment-request/pull/694#issuecomment-376200400 reflects how things work after this PR is merged - and reflects what user agents implement today.

Would like to encourage us to continue to liaise with ISO on all codes and symbols nevertheless.

ianbjacobs commented 6 years ago

@marcoscaceres,

Regarding liaison: This week I have a call with the relevant people around ISO 4217.

marcoscaceres commented 6 years ago

@ianbjacobs appreciate the update! thank you!

ianbjacobs commented 6 years ago

@marcoscaceres, @adrianhopebailie,

Here's what I learned from my conversation with our ISO 4217 colleagues:

I don't currently have a proposal, but:

I think we should add an informative note to the specification that we are liaising with ISO regarding updates to 4217.

Ian

marcoscaceres commented 6 years ago

I am hearing people want to be able to use non-4217 codes with PR API.

Limited supported today, so long as the code adheres to the ISO4217 format (with the known limitations/ambiguities you mentioned).

Once we know what the new format is going to be (length, allowed chars), we should incorporate that.

If ISO is likely (but not guaranteed) to use a letter-based code system, would it be appropriate for authors that wish to specify a non-4217 code (or other future ISO registry) to use a non-letter prefix (e.g., "-")? Would this enable the browser to help the user distinguish "potential error" from "seeming intentional use of a non-standard code"?

We definitely don't want to go down this path. That's HTTP's "x-frame-options" etc. and vendor prefixing all over again.

If we do "-Whatever", then that's the standards.

Would this enable the browser to help the user distinguish "potential error" from "seeming intentional use of a non-standard code"?

No. We don't do that today either. We just check the format (e.g. "YXA" is a perfectly valid currency code, which doesn't exist).

Should there be consistent display guidance to browser implementations for non-standard codes? (e.g., if the merchant-provided code is -BTC, display "BTC")? Or should the browser be free to show other symbols?

It should use standardized symbols, defecto symbols knows to the UA, or ¤ otherwise.

How are other errors handled (e.g., a string of 47 characters)?

RangeError.

marcoscaceres commented 6 years ago

Thanks everyone for the productive discussion here. I want to give a summary of where we are so far (and perhaps we should add the following to the spec as a note, as @ianbjacobs suggested).

User agents implementing Payment Request enforce ISO 4217's 3-letter codes format via ECMAScript’s “isWellFormedCurrencyCode” algorithm. When a code does not adhere to the ISO 4217 defined format, a RangeError is thrown.

Current implementations of the Payment Request API will therefore allow the use of well-formed currency codes that are not part of the official ISO 4217 list (e.g., XBT, XRP, etc.). If the provided code is a currency that the browser knows how to display, then an implementation will generally display the appropriate currency symbol in the user interface (e.g., "USD" is shown as "$", "GBP" is "£", and the non-standard "XBT" could be shown as "Ƀ"). When a code can't be matched, the specification recommend browsers show a scarab "¤".

Given the rise of digital currencies in recent years, ISO 4217's format has been found wanting. For example, does "BTC" refer to Bitcoin or to a future Bhutan currency according to the 4217 naming rules? To overcome the limitations with ISO 4217 with respect to digital currencies, ISO is in the early stages of evolving ISO 4217. At the time of publication, it remains unclear what form this evolution will take, or even the timeframe in which the work will be completed. The W3C Web Payments Working Group is liaising with ISO during this evolutionary process to ensure digital currencies are well supported both in future versions of ISO 4217 and in future revisions of the Payment Request API.

@adrianhopebailie wdty? I can send the above as PR and we can iterate.

adrianhopebailie commented 6 years ago

@marcoscaceres LGTM

Do we want to encourage the use of "X" prefixed codes for currencies that are not from a particular country? i.e. Use XBT instead of BTC to improve interoperability

ianbjacobs commented 6 years ago

@marcoscaceres, proposed:

Change:

"Given the rise of digital currencies in recent years, ISO 4217's format has been found wanting. For example, does "BTC" refer to Bitcoin or to a future Bhutan currency according to the 4217 naming rules? To overcome the limitations with ISO 4217 with respect to digital currencies, ISO is in the early stages of evolving ISO 4217. "

to:

"Efforts are underway at ISO to account for digital currencies in the ISO 4217 registry or a new one. We expect this will resolve ambiguities that have crept in through the use of non-standard 3-letter codes; for example, does "BTC" refer to Bitcoin or to a future Bhutan currency?"

The rest looks fine, thank you!

Ian

marcoscaceres commented 6 years ago

This should be good to go. Will remove the WPTests once this goes in.

ianbjacobs commented 6 years ago

@marcoscaceres,

As discussed in Singapore, I'm ready to issue a call for consensus to close this pull request. However, I'd like to see whether you would accept my editorial suggestions before I send the email.

Ian

marcoscaceres commented 6 years ago

Suggestions are good. Will try to integrate them tomorrow. please start the cfc 🙂

ianbjacobs commented 6 years ago

Call for consensus underway: https://lists.w3.org/Archives/Public/public-payments-wg/2018Apr/0020.html

Ian

marcoscaceres commented 6 years ago

Blocked until 1st of May, pending outcome of CFC.

marcoscaceres commented 6 years ago

@ianbjacobs, addressed your feedback. If looks good, please ✅.

marcoscaceres commented 6 years ago

@ianbjacobs, the CFC finishes at 10am ET today, so, now that this is merged, could you kindly send another request for publication after that?

ianbjacobs commented 6 years ago

Decision sent: https://lists.w3.org/Archives/Public/public-payments-wg/2018May/0001.html

I will request publication tomorrow. Thanks, @marcoscaceres!

Ian

marcoscaceres commented 6 years ago

Thanks for the update!