New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 755151 link

Starred by 2 users

Issue metadata

Status: Started
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 3
Type: Bug


Participants' hotlists:
Payment-Interop


Sign in to add a comment

PaymentResponse.billingAddress should be PaymentAddress for "basic-card"

Project Member Reported by rouslan@chromium.org, Aug 14 2017

Issue description

BasicCardResponse.billingAddress is not an instance of
"PaymentAddress" (as required by the spec).

That might catch devs off guard is they are wanting to do:

```
response.details.billingAddress.toJSON();
```

 

Comment 1 by ma...@chromium.org, Sep 20 2017

Owner: ma...@chromium.org
Really! I did not know this. We are quite incorrect in that regard then.

Comment 2 by mar...@marcosc.com, Sep 20 2017

The spec was a little ambiguous, working to clear that up :) 
Owner: rouslan@chromium.org
Status: Started (was: Assigned)
Looking into this.
Marcos: I believe the specs say that the browser is supposed to pass the response from  the payment handler to the merchant website unaltered and only parse the JSON string into a JavaScript object. Converting a part of that response into a PaymentAddress seems to overstep the responsibilities of the browser. What do you think?

As a spec solution, perhaps we could change the type of 'billingAddress' to 'object', but note that it's in PaymentAddress format.

Comment 5 by mar...@marcosc.com, Nov 2 2017

> I believe the specs say that the browser is supposed to pass the response from the payment handler to the merchant website unaltered and only parse the JSON string into a JavaScript object. Converting a part of that response into a PaymentAddress seems to overstep the responsibilities of the browser. What do you think?

I'm not sure what you mean by overstepping here. Could you elaborate a bit? 

> As a spec solution, perhaps we could change the type of 'billingAddress' to 'object', but note that it's in PaymentAddress format.

See my OP about .toJSON(). It might also cause issues if `PaymentAddress` gains more methods/functionality in the future. 

 
> I'm not sure what you mean by overstepping here. Could you elaborate a bit?

Are browsers supposed to alter the payment app responses or validate them beyond JSON serializability? I do no think so. What's your opinion?

Comment 7 by mar...@marcosc.com, Nov 5 2017

> Are browsers supposed to alter the payment app responses or validate them beyond JSON serializability? I do no think so. What's your opinion?

For basic card, at least, it's exactly the same behavior/validation/formatting that happens in: 
https://w3c.github.io/payment-request/#shipping-address-changed-algorithm

I'm going to move the address construction steps into its own algorithm, and I'll get Basic Card to hook into that. 
 
Now... for Payment Handler... that's a bit more complicated, so let's chat about that this week. 

Comment 8 by mar...@marcosc.com, Nov 5 2017

Ok, so here is the split:
https://github.com/w3c/payment-request/pull/644

And here is the fix:
https://github.com/w3c/payment-method-basic-card/pull/45

`BasicCardResponse.billingAddress` was not specified at all! 😱 
Who is editing these things!? 🙃

Sign in to add a comment