remove currencySystem member #694

marcoscaceres · 2018-03-19T06:23:17Z

closes #617

The following tasks have been completed:

Confirmed there are no ReSpec errors/warnings.
Removed web platform tests

adrianhopebailie · 2018-03-22T14:23:09Z

@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 · 2018-03-22T20:25:13Z

@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 · 2018-03-22T23:43:15Z

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 · 2018-03-23T13:58:30Z

@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 · 2018-03-23T22:55:44Z

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 · 2018-03-24T18:24:05Z

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 · 2018-03-26T05:57:37Z

@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 · 2018-03-26T06:04:32Z

@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 · 2018-03-26T08:40:48Z

@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 · 2018-03-26T08:59:54Z

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 · 2018-03-26T14:16:35Z

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 · 2018-03-26T14:40:52Z

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 · 2018-03-26T15:09:44Z

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 · 2018-03-26T15:37:44Z

@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 · 2018-03-27T03:26:51Z

@adrianhopebailie, I updated #694 (comment) 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 mozilla/standards-positions#78 for Mozilla opinions (in the context of cryptocurrencies and in currencies in general). Some interesting feedback and questions there already.

ianbjacobs · 2018-03-27T21:32:02Z

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

marcoscaceres · 2018-04-03T10:33:23Z

Concluded on the Mozilla side that things as currently specified are ok. The comment at #694 (comment) 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 · 2018-04-03T13:37:48Z

@marcoscaceres,

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

marcoscaceres · 2018-04-04T07:47:39Z

@ianbjacobs appreciate the update! thank you!

ianbjacobs · 2018-04-04T21:56:50Z

@marcoscaceres, @adrianhopebailie,

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

There will be a registry for non-fiat digital currencies (which they may call "digital tokens" so as not to clash with the definition of "currency" in ISO 4217)
These codes most likely will not be 3-letter strings (due to name conflicts and scarcity).
It is possible (but not known for sure) that they will be 4-letter strings.
The time frame for the specification and registry is not known, but a guess is "1 year from now."

I don't currently have a proposal, but:

I am hearing people want to be able to use non-4217 codes with PR API.
I assume people want to avoid name conflicts (e.g., does BTC refer to Bitcoin or
to a future Bhutan currency according to the 4217 naming convention?)
This suggests some naming convention could help the browser recognize that someone has intentionally provided a non-standard code.
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"?
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?
How are other errors handled (e.g., a string of 47 characters)?

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

Ian

marcoscaceres · 2018-04-05T06:16:50Z

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 · 2018-04-05T07:05:45Z

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 · 2018-04-05T08:34:19Z

@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 · 2018-04-05T12:34:33Z

@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 · 2018-04-06T04:06:43Z

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

ianbjacobs · 2018-04-06T11:36:42Z

index.html

+              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 recommends browsers show


suggest s/can't/cannot

ianbjacobs · 2018-04-06T11:41:17Z

index.html

+              process to ensure digital currencies are well supported both in
+              future versions of [[ISO4217]] and in future revisions of this
+              specification.
+            </p>


Upon rereading this I would like to suggest simplifying the last sentence to: "The W3C Web Payments
Working Group is liaising with ISO so that, in the future, revisions to this specification remain compatible with
relevant ISO registries."

adrianhopebailie

LGTM

ianbjacobs · 2018-04-24T14:30:28Z

@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 · 2018-04-24T14:34:01Z

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

ianbjacobs · 2018-04-24T16:32:45Z

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

Ian

marcoscaceres · 2018-04-24T22:33:04Z

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

marcoscaceres · 2018-04-25T01:15:25Z

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

marcoscaceres · 2018-05-01T08:33:00Z

@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 · 2018-05-01T22:02:45Z

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

I will request publication tomorrow. Thanks, @marcoscaceres!

Ian

marcoscaceres · 2018-05-01T22:07:17Z

Thanks for the update!

Matches w3c/payment-request#694.

After a long discussion, Web Payment Working Group decided to remove the `currencySystem` member[1]. The currency code should be well-formed 3-letter alphabetic code and is allowed even if that is not part of the official ISO 4217 list. [1] w3c/payment-request#694 Intent to remove: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/-jtNNH_Bb6c Bug: 839402 Cq-Include-Trybots: luci.chromium.try:ios-simulator-full-configs;master.tryserver.chromium.mac:ios-simulator-cronet Change-Id: I17ac51c93e457c4bae00db365a4c7322274c8d4f Signed-off-by: Jinho Bang <[email protected]> Reviewed-on: https://chromium-review.googlesource.com/1042427 Reviewed-by: Kentaro Hara <[email protected]> Reviewed-by: Mathieu Perreault <[email protected]> Reviewed-by: Eugene But <[email protected]> Reviewed-by: Kinuko Yasuda <[email protected]> Reviewed-by: Steven Holte <[email protected]> Cr-Commit-Position: refs/heads/master@{#561348}

https://bugs.webkit.org/show_bug.cgi?id=185860 Patch by Jinho Bang <[email protected]> on 2018-05-24 Reviewed by Andy Estes. Source/WebCore: After a long discussion, Web Payment Working Group decided to remove the `currencySystem` member[1]. The currency code should be well-formed 3-letter alphabetic code and is allowed even if that is not part of the official ISO 4217 list. [1] w3c/payment-request#694 Test: http/tests/inspector/paymentrequest/payment-request-internal-properties.https.html * Modules/paymentrequest/PaymentCurrencyAmount.h: * Modules/paymentrequest/PaymentCurrencyAmount.idl: * Modules/paymentrequest/PaymentRequest.cpp: (WebCore::checkAndCanonicalizeAmount): (WebCore::checkAndCanonicalizeTotal): * inspector/WebInjectedScriptHost.cpp: (WebCore::objectForPaymentCurrencyAmount): LayoutTests: * http/tests/inspector/paymentrequest/payment-request-internal-properties.https-expected.txt: * http/tests/inspector/paymentrequest/payment-request-internal-properties.https.html: git-svn-id: http://svn.webkit.org/repository/webkit/trunk@232155 268f45cc-cd09-0410-ab3c-d52691b4dbfc

…ystem member, a=testonly Automatic update from web-platform-testsRemove PaymentCurrencyAmount's currencySystem member (#11099) Matches w3c/payment-request#694. -- wpt-commits: 741b59a02016570df79d117a808bf2cfadd4bbf2 wpt-pr: 11099

…ystem member, a=testonly Automatic update from web-platform-testsRemove PaymentCurrencyAmount's currencySystem member (#11099) Matches w3c/payment-request#694. -- wpt-commits: 741b59a02016570df79d117a808bf2cfadd4bbf2 wpt-pr: 11099 UltraBlame original commit: d47c0511ad3c9a14813437484258f1bfab3e82bb

https://bugs.webkit.org/show_bug.cgi?id=185860 Patch by Jinho Bang <[email protected]> on 2018-05-24 Reviewed by Andy Estes. Source/WebCore: After a long discussion, Web Payment Working Group decided to remove the `currencySystem` member[1]. The currency code should be well-formed 3-letter alphabetic code and is allowed even if that is not part of the official ISO 4217 list. [1] w3c/payment-request#694 Test: http/tests/inspector/paymentrequest/payment-request-internal-properties.https.html * Modules/paymentrequest/PaymentCurrencyAmount.h: * Modules/paymentrequest/PaymentCurrencyAmount.idl: * Modules/paymentrequest/PaymentRequest.cpp: (WebCore::checkAndCanonicalizeAmount): (WebCore::checkAndCanonicalizeTotal): * inspector/WebInjectedScriptHost.cpp: (WebCore::objectForPaymentCurrencyAmount): LayoutTests: * http/tests/inspector/paymentrequest/payment-request-internal-properties.https-expected.txt: * http/tests/inspector/paymentrequest/payment-request-internal-properties.https.html: Canonical link: https://commits.webkit.org/201388@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@232155 268f45cc-cd09-0410-ab3c-d52691b4dbfc

marcoscaceres force-pushed the del_currency_system branch from 53f333b to 434e82c Compare March 19, 2018 06:24

marcoscaceres mentioned this pull request Mar 22, 2018

Remove PaymentCurrencyAmount.currencySystem tests web-platform-tests/wpt#10135

Merged

marcoscaceres added the Blocked label Mar 22, 2018

marcoscaceres mentioned this pull request Mar 26, 2018

Cryptocurrency support with Payment Request API mozilla/standards-positions#78

Closed

marcoscaceres added 2 commits April 6, 2018 13:24

Remove currencySystem member

ab61e5e

Editorial: add note about digital currencies

2642114

marcoscaceres removed the Blocked label Apr 6, 2018

ianbjacobs reviewed Apr 6, 2018

View reviewed changes

adrianhopebailie approved these changes Apr 9, 2018

View reviewed changes

marcoscaceres added the Blocked label Apr 25, 2018

Review feedback from Ian

9183278

marcoscaceres removed the Blocked label May 1, 2018

marcoscaceres merged commit 6b2aebc into gh-pages May 1, 2018

marcoscaceres deleted the del_currency_system branch May 1, 2018 08:31

foolip added a commit to web-platform-tests/wpt that referenced this pull request May 22, 2018

Remove PaymentCurrencyAmount's currencySystem member

cbce208

Matches w3c/payment-request#694.

foolip mentioned this pull request May 22, 2018

Remove PaymentCurrencyAmount's currencySystem member web-platform-tests/wpt#11099

Merged

foolip added a commit to web-platform-tests/wpt that referenced this pull request May 23, 2018

Remove PaymentCurrencyAmount's currencySystem member (#11099)

741b59a

Matches w3c/payment-request#694.

saschanaz mentioned this pull request Oct 25, 2020

Add Payment Request types microsoft/TypeScript-DOM-lib-generator#937

Closed

himorin mentioned this pull request Jan 29, 2021

Prevent the use of currency synonyms w3c/i18n-activity#212

Closed

remove currencySystem member #694

remove currencySystem member #694

Conversation

marcoscaceres commented Mar 19, 2018 • edited by pr-preview bot Loading

adrianhopebailie commented Mar 22, 2018

ianbjacobs commented Mar 22, 2018

marcoscaceres commented Mar 22, 2018

ianbjacobs commented Mar 23, 2018

adrianhopebailie commented Mar 23, 2018

rsolomakhin commented Mar 24, 2018 • edited Loading

marcoscaceres commented Mar 26, 2018 • edited Loading

marcoscaceres commented Mar 26, 2018

adrianhopebailie commented Mar 26, 2018

domenic commented Mar 26, 2018

adrianhopebailie commented Mar 26, 2018

webpayments-specs commented Mar 26, 2018 via email • edited by marcoscaceres Loading

marcoscaceres commented Mar 26, 2018 • edited Loading

stpeter commented Mar 26, 2018

marcoscaceres commented Mar 27, 2018

ianbjacobs commented Mar 27, 2018

marcoscaceres commented Apr 3, 2018

ianbjacobs commented Apr 3, 2018

marcoscaceres commented Apr 4, 2018

ianbjacobs commented Apr 4, 2018 • edited Loading

marcoscaceres commented Apr 5, 2018

marcoscaceres commented Apr 5, 2018 • edited Loading

adrianhopebailie commented Apr 5, 2018

ianbjacobs commented Apr 5, 2018

marcoscaceres commented Apr 6, 2018

ianbjacobs Apr 6, 2018

Choose a reason for hiding this comment

ianbjacobs Apr 6, 2018

Choose a reason for hiding this comment

adrianhopebailie left a comment

Choose a reason for hiding this comment

ianbjacobs commented Apr 24, 2018

marcoscaceres commented Apr 24, 2018

ianbjacobs commented Apr 24, 2018

marcoscaceres commented Apr 24, 2018

marcoscaceres commented Apr 25, 2018

marcoscaceres commented May 1, 2018

ianbjacobs commented May 1, 2018

marcoscaceres commented May 1, 2018

marcoscaceres commented Mar 19, 2018 •

edited by pr-preview bot

Loading

rsolomakhin commented Mar 24, 2018 •

edited

Loading

marcoscaceres commented Mar 26, 2018 •

edited

Loading

webpayments-specs commented Mar 26, 2018 via email •

edited by marcoscaceres

Loading

marcoscaceres commented Mar 26, 2018 •

edited

Loading

ianbjacobs commented Apr 4, 2018 •

edited

Loading

marcoscaceres commented Apr 5, 2018 •

edited

Loading