Re: User Consent and Addresses

Have we considered making a completely separate API for supplying the
shipping address? How about we make a ShippingAddressRequest that can be
invoked first, if the merchant wants? Then the flow could be something like:

Merchant ---ShippingAddressRequest---> Payment Mediator
Merchant <---ShippingAddressResponse--- Payment Mediator

[If the merchant is happy with the shipping address he can display the
adjusted total, including shipping costs, here. If the shipping address is
not valid (e.g. because the merchant does not do international shipping),
then he can show that status to the user, and leave the final payment
button disabled. If the user is not happy with the adjusted shipping costs,
he can reinvoke the shipping address request and select a new shipping
address.]

Merchant ---PaymentRequest---> Payment Mediator
---SerializedPaymentRequest---> Payment App
Merchant <---PaymentResponse--- Payment Mediator
<---SerializedPaymentResponse--- Payment App

(I have intentionally left the onshippingaddresschange mechanism out of
this. I didn't have to -- it could still be a part of the
ShippingAddressRequest -- but I feel we leave ourselves a bit more flexible
if we use simpler request-response messages, as they are easier to pass
through any communication protocol).

The advantages of this is that the PaymentRequest API becomes cleaner,
easier to understand and simpler to specify. I also think this gives the
merchant a bit more flexibility in how he wants to present the checkout to
the customer. The disadvantage might be that there will be slightly more
work involved for the merchants who are interested in shipping addresses,
since there will now be two requests instead of one, and the checkout page
will need to accommodate this.

-Tommy


On Tue, May 10, 2016 at 6:24 PM, Dave Longley <dlongley@digitalbazaar.com>
wrote:

> On 05/10/2016 12:06 PM, Adam Roach wrote:
>
>> On 5/10/16 11:02, Andre Lyver wrote:
>>
>>>
>>> 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.
>>>
>>
>> That all sounds correct. It also sounds like a pretty compelling set of
>> arguments for collecting the address and shipping method prior to
>> initiating the payment flow.
>>
>
> To add to that, there has been a lot of research indicating that showing
> shipping costs or collecting shipping address too late in the process
> leads to shopping cart abandonment.
>
> These points have been raised in the past as reasons for keeping
> shipping out of the process. Counter arguments have been that it's
> really difficult for users to enter their shipping address, especially
> on mobile, and browsers can help with that. Note that this doesn't mean
> it needs to be late in the process. My understanding is that another
> counter argument has been (paraphrasing) that "we haven't tried this new
> API yet, so maybe it will fix these problems."
>
>
>
> --
> Dave Longley
> CTO
> Digital Bazaar, Inc.
> http://digitalbazaar.com
>
>