Re: User Consent and Addresses

Well, POST isn't really the payload in the communication between the
Payment Mediator and the Payment App. POST is just the communication
channel. What I've seen suggested in the two specs I mentioned, is that the
payload that is POST'ed from the Mediator to the App, is a serialization of
the Payment Request. That means the full communication as specified today,
looks like this:

Web Page ---PaymentRequest---> Payment Mediator
---SerializedPaymentRequest---> Payment App
Web Page <---onshippingaddresschange--- Payment Mediator
Web Page <---PaymentResponse--- Payment Mediator
<---SerializedPaymentResponse--- Payment App

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.

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
>