Re: User Consent and Addresses

Agree with Adrian H-B.

This behaviour is crucial to the checkout flow for merchants (and
especially Shopify). I think the fundamental piece that we are forgetting
is the fact that the final amount is going to change based on a shipping
address or shipping option change. This was the reason for including the
shippingoptionchange and shippingaddresschange Events and their associated
event handlers it in the Payment Request API.
https://w3c.github.io/browser-payment-api/specs/paymentrequest.html#shipping-address-changed-algorithm
..

For example, a change of shipping address by the payer can invalidate the
shipping method selected (e.g. a change country from Canada to U.S. may
mean that CanadaPost is no longer available). This means that a different
shipping option will need to be selected, and as a result, the final
transaction amount will need to be updated (via
PaymentRequestUpdateEvent) _prior_
to proceeding with the actual payment.

Andre




On Tue, May 10, 2016 at 11:31 AM Adrian Hope-Bailie <adrian@hopebailie.com>
wrote:

> On 10 May 2016 at 15:42, Ian Jacobs <ij@w3.org> wrote:
>
>>
>> > On May 10, 2016, at 8:29 AM, Adam Roach <abr@mozilla.com> 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's web page, so
>> merchant.com has access to it" and "I entered data into Bobpay's payment
>> app, so merchant.com has access to it, even if I never submitted it.”
>>
>> Thank you for the clarification. I am hearing this:
>>
>>  1) I am interacting with merchant.com (browser-as-payment-app). This
>> amounts to the form-fill case.
>>
>
> This is not correct. The browser renders a special "checkout UI" to the
> user (during the process of selecting a payment app - not where the browser
> is acting as the payment app) that displays the list items provided by the
> website and also some data capture fields (if the website requested them)..
>
> When the user enters data into those fields events are fired that the
> website can listen for that give the website the data that was captured.
>
>
>>  2) I am interacting with bob’s payment app (third-party-payment-app).
>> This is a new origin.
>
>
>> Is that your observation? Do you think API behavior should differ in
>> those two cases?
>>
>> Ian
>>
>> --
>> Ian Jacobs <ij@w3.org>      http://www.w3.org/People/Jacobs
>> Tel:                       +1 718 260 9447
>>
>>
>>
>>