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