W3C home > Mailing lists > Public > public-payments-wg@w3.org > May 2016

Re: User Consent and Addresses

From: Nick Shearer <nshearer@apple.com>
Date: Tue, 10 May 2016 10:20:37 -0700
Message-id: <3F6606D4-DCFD-4610-83BB-1A2312997684@apple.com>
Cc: Dave Longley <dlongley@digitalbazaar.com>, Adam Roach <abr@mozilla.com>, Ian Jacobs <ij@w3.org>, Adrian Bateman <adrianba@microsoft.com>, Web Payments Working Group <public-payments-wg@w3.org>
To: Tommy Thorsen <tommyt@opera.com>

> On May 10, 2016, at 6:54 AM, Tommy Thorsen <tommyt@opera.com> wrote:
> 
> I think many payment apps will want to supply shipping information along with the rest of the payment response, and I think we should allow that. However, since we are planning to pass the request to the payment app by means of HTTP POST, the onshippingaddresschange mechanism isn't going to work. The shipping address will have to be passed back in the payment response.
> 
> I'm personally not very fond of having two separate ways of passing back shipping information to the payee (onshippingaddresschange + PaymentResponse.shippingAddress), so I suggest that we get rid of one of the mechanisms. I haven't been following the discussions here for that long, so I'm a bit unclear on the rationale for the onshippingaddresschange mechanism, but I always thought it looked kind of odd. What would be the arguments against removing it?

Changing your shipping address frequently changes the amount you want to charge. Sales tax, for example, can vary by city.

> 
> -Tommy
> 
> On Tue, May 10, 2016 at 3:37 PM, Dave Longley <dlongley@digitalbazaar.com <mailto:dlongley@digitalbazaar.com>> wrote:
> On 05/10/2016 09:29 AM, Adam Roach wrote:
> On 5/10/16 08:16, Ian Jacobs wrote:
> Today if I type information (e.g., shipping address) in a form field, does that change the DOM and thus the merchant has access to the information immediately as well?
> 
> I am wondering whether the behavior you describe for paymentRequest differs significantly from today’s form-based approach. (I say “I am wondering” because I think
> you have a better grasp than I do.)
> 
> Yes, it certainly does have access. But there's a somewhat different
> mental model between "I entered data into merchant.com <http://merchant.com/>'s web page, so
> merchant.com <http://merchant.com/> has access to it" and "I entered data into Bobpay's payment
> app, so merchant.com <http://merchant.com/> has access to it, even if I never submitted it."
> 
> To be clear, I don't believe the latter represents the current API design. The shipping information (at least the information that is reported via `onshippingaddresschange`) isn't entered into a Payment App, but into a special checkout UI provided by the browser. However, it is correct that it is not entered via a page on merchant.com <http://merchant.com/>.
> 
> I think this may better capture what's going on: "I entered data into a 'special browser checkout UI', so merchant.com <http://merchant.com/> has access to it, even if I never submitted it."
> 
> 
> -- 
> Dave Longley
> CTO
> Digital Bazaar, Inc.
> http://digitalbazaar.com <http://digitalbazaar.com/>
> 
> 
Received on Tuesday, 10 May 2016 17:21:08 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 10 May 2016 17:21:09 UTC