RE: Undiscussed (?) issues in Payments API

Thanks for the details.

On Issue A, I very much disagree. This group should not be defining user consent.

On Issue B, that makes sense. I’ll write a PR.

On Issue D, I believe the spec already defines this in the steps for updateWith. What is missing?

On Issue F, I’m not convinced we should add this complexity. Perhaps there is a better alternative that imposes less complexity on implementations since pages are in control of not rejecting this promise.

From: Adam Roach [mailto:abr@mozilla.com]
Sent: Wednesday, May 4, 2016 3:47 PM
To: Web Payments Working Group <public-payments-wg@w3.org>
Subject: Undiscussed (?) issues in Payments API


After reading through the Payments API document, I have found some issues that I don't think have been discussed yet. I wanted to bring them up here before opening dedicated issues in the tracker in case I missed prior discussions on the topic.



Issue A: Interaction between address updates and user consent

Section 16.1 specifies that user data, such as shipping addresses, are to be provided to the merchant page only with user consent. It's unclear how this interacts with the behavior of "onshippingaddresschange," which fires every time the user changes their address in a payment app. As a user, I would not inherently expect such actions to be automatically exfiltrated to the merchant web page. We definitely need to think through and document what kind of behavior represents informed user consent in these cases.


Issue B: acceptPromise interaction with abort()

I think this is just a mechanical oversight, but I believe that section 4.3 needs a final step that causes acceptPromise to be rejected.


Issue C: Currency Types and Rendering

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.


Issue D: Time validity of updateWith()

I think this is probably what everyone has in mind, but we should be clear: updateWith() needs to be valid only during the event processing loop its corresponding event fires in. We want to make sure that the web page cannot update the value except when the UI is frozen as described in updateWith() processing. (Race conditions between update and submit could end up being dangerous, especially when cryptocurrencies are involved).


Issue E: shippingAddress and "c/o" field

Pretty simple question: do we need a "c/o" field? In some locations, mail will be delivered only if the known resident's name appears on the address label. Sure, people can hack this by providing it as part of the street address or business name, but since we're defining this greenfield, I think we should accommodate this in a semantically sensible way.


Issue F: Update promise rejection

The procedure in section 13.2 does not mention any processing steps in the case the update promise d is rejected. In this case, I think that the only sensible thing to do is to revert the change that the user made which triggered the event. This implies that payment apps must retain the state prior to the change that triggered the event so that it can be rolled back to.

--
Adam Roach
Principal Platform Engineer
Office of the CTO