Re: User Consent and Addresses

<snip>

>
> Web Page ---PaymentRequest---> Payment Mediator
> ---SerializedPaymentRequest---> Payment App
> Web Page <---onshippingaddresschange--- Payment Mediator
> Web Page <---PaymentResponse--- Payment Mediator
> <---SerializedPaymentResponse--- Payment App
>
>
Actually this is not the flow.

The data collection steps (shippingaddresschange events and handling of
these) must be done before the request is passed to the payment app.

The assumption is that once the request is passed to the payment app the
final amount is known.

This is why the data collection is done through the same (or prior) user
interface as the payment app selection.

I believe that Adam's point is that when the user is capturing data into
that UI it is not clear to the user that that data is being passed back to
the website before the user even selects a payment app.

Put differently, if the user selects their shipping address and then
cancels the payment before even selecting a payment app they have already
given the website their shipping address.


> I see why the onshippingaddresschange is needed (for updating the Payment
> Request when the shipping address changes), but it feels a bit messy with
> the two different ways of passing the shipping address back. We could solve
> that by only letting the Payment Mediator supply shipping address, and then
> only through the onshippingaddresschange mechanism. That means we remove
> the shippingAddress field from the PaymentResponse and as a result also
> remove the Payment App's ability to supply the shipping address. This would
> be a lot cleaner, and a lot easier to both specify and implement.
>

Matt Saxon raised a similar point in last week's call. There is a risk that
if both the website and the payment app need to collect the same data (eg:
email address, if the website wants to email a receipt and if the payment
app uses this to authenticate the user) then we make the user experience
worse, not better.


>
> On Tue, May 10, 2016 at 4:36 PM, Adam Roach <abr@mozilla.com> wrote:
>
>> On 5/10/16 09:15, Tommy Thorsen wrote:
>>
>> I'm referring to the "Payment Apps" and the "HTTP API" spec proposals
>> here:
>>
>>
>> http://w3c.github.io/webpayments-http-api/#generating-a-payment-response
>>
>>
>> https://w3c.github.io/webpayments/proposals/paymentapps/payment-apps.html#submitting-the-paymentrequest-to-the-payment-app
>>
>> Both of these propose to pass the payment request to the payment app by
>> using an HTTP POST.
>>
>>
>>
>> Sure, but those POST requests come from the payment mediator, not the
>> merchant site. I understand the proposal to look like:
>>
>> Web Page <---PaymentRequest---> Payment Mediator <---POST---> Payment App
>>
>> The event is used by PaymentRequest, and the shippingAddress field is
>> used in the POST response. Right?
>> --
>> Adam Roach
>> Principal Platform Engineer
>> Office of the CTO
>>
>
>