ACTION: Summarize arguments for/against shipping address capture about webpayments

[webpayments]

I think that, as a general statement, that the payments group should focus, ahem, on making a payment, and not expand to trying to handle the whole (if ‘whole' is defined) ‘transaction’.

For example, I am sometimes asked to use Paypal to pay conference fees or for other non-shipped deliverables. A delivery address makes no sense. Similarly for a regularly-scheduled blackmail payment :-(

So, in general, and from a privacy point of view, it’s best if each actor in a transaction knows enough to do their role, and enough to tie the whole transaction together. The seller knows they have been paid, and what they sold; the buyer that they paid, and for what; the shipper, that there is something to deliver; and so on.

On Jan 27, 2016, at 11:25 , Adrian Hope-Bailie [email protected] wrote:

Create a wiki page to summarize the arguments for and against capturing the shipping address in the web payments API.
Consider making this one of a collection of pages which begin to summarize the discussion around big issues that will likely be tackled at the F2F.

—
Reply to this email directly or view it on GitHub.

Dave Singer

[email protected]

[vkuntz]

For me, the shipping address is an integral part of the obligation (payments and delivery of goods/services) which is created when the customer confirms the purchase of the goods/services on the cart/basket. Without the shipping address the merchant cannot fullfill its obligations which resulted from the purchase. At least this is how it has been modelled by the experts in the ISO 20022 business model.

[dlongley]

Without the shipping address the merchant cannot fullfill its obligations which resulted from the purchase.

Just to be clear, even if we don't standardize a way to gather the shipping address in this first phase, merchants can still continue to obtain it in the same ways that they do today. I do expect that standardization of collecting shipping address information (and other payment-related information) will happen at some point during this work, it's just not yet clear exactly when.

[dlongley]

I've made a proposal that includes gathering shipping address:

https://github.com/w3c/webpayments/wiki/Checkout-API

[rsolomakhin]

My hope is to replace the whole checkout page with a single button. If the checkout page also includes a shipping address form, then we've solved only half of the problem, IMHO.

I agree that shipping address should be optional, so that virtual goods can be traded as well.

[ianbjacobs]

@rsolomakhin,

There is a lot of usability appeal to the single buy button vision. However, I have also heard the following sorts of statements.

• The people who provide payment systems are unlikely to want their brands to disappear.
• Users may have more confidence when they see a recognized brand.
• Merchants may want to display information about what payment methods they accept before a transaction begins, so users know what is coming.

Personally, I like the single buy button idea, just moving the brand visibility to another moment. But I think we'll likely see a variety of ways to adopt the API.

Ian

[rsolomakhin]

@ianbjacobs,

I agree that the merchant can display such information: branding, accepted payments, etc. I object only to typing in web forms. Typing is a pain, especially on mobile web.

[zkoch]

The people who provide payment systems are unlikely to want their brands to disappear.

Sorry, do you mean the merchants? Or the PSP that a merchant uses who might be controlling their checkout flow? Either way, if they don't want address collection, it's an optional parameter. I think it's on us to prove over time that it's beneficial to ask the user agent to facilitate this.

Users may have more confidence when they see a recognized brand.

Branding is still possible, even with a flow that is outside the merchants control. Though I suspect this is largely a UI issue and will be up to the user-agent implementing the API and how they decide to handle this.

Merchants may want to display information about what payment methods they accept before a transaction begins, so users know what is coming.

I can't think of anything that would preclude this from taking place.

[ianbjacobs]

@zkoch,

Sorry, do you mean the merchants? Or the PSP that a merchant uses who might be controlling their checkout flow? Either way, if they don't want address collection, it's an optional parameter. I think it's on us to prove over time that it's beneficial to ask the user agent to facilitate this.

I imagine that a credit card company, for example, would not want its logo to disappear from sites, subsumed by a "Buy" button.

You wrote that "branding is still possible" and I wonder if, for communications purposes, when we start showing people how the API works, we should prepare different views (one of which shows how branding can still be used).

Ian

[ianbjacobs]

Coincidentally, I came upon an infographic that conveys the point [1]:

"More than 80% of consumers feel safer seeing trustworthy card logos prominently
displayed within an online store."

I don't mean to weigh heavily on the infographic a proof, just as an indicator that we
should be conscious of as we communicate about the API.

Ian

[1] http://www.smartinsights.com/digital-marketing-strategy/barriers-to-online-purchase/

[adrianba]

I don't understand the relevance of the branding topic to the question in this issue.

At the heart of the PaymentRequest API, our goal is to make it easy for people to complete checkout flows with less effort and fewer errors. We will also support payment methods that allow transactions to be more secure. The hope and expectation for merchants is that this will increase conversion rates.

A lot of people buy and sell physical goods on the web. These goods need to be shipped to an address. Capturing the address as part of the flow allows greater innovation in finding a flow that is less effort and brings greater conversion rates.

One of the strongest arguments for not capturing shipping addresses is that it is hard to standardize and consequently we could do it later. There might be other standardization efforts that will solve this for us. I understand this argument (and I am using it in response to many other issues - i.e. they don't need to be in v1) however shipping physical goods is such a core use case that I think we should try to solve it in v1.

At some point we are going to have to solve for billing address for some of the payment methods we support so it is almost inevitable that we'll have to solve for addresses. Once that is done, the incremental different to shipping addresses will hopefully be small. It is common for sites to offer to ship to your billing address as a first choice, for example.

David Singer's point is an interesting one but I think we're too far away from that being a reality in the short term. It seems unlikely we'll get much merchant adoption if the API proposes an approach too different from current flows. We need to ensure that there is an easy path to integrate the API into existing sites.

So my proposal is that we continue trying to solve for shipping address - it is too early to give up because it is hard or because we think someone will do it for us. Perhaps we won't be successful but this issue is premature: there's equally no evidence that we won't.

[ianbjacobs]

@adrianba,

My apology. My comment was not about the issue directly. it had only to do with Rouslan's notion of "one big buy button." Let's take that topic elsewhere.

Ian

[nickjshearer]

I am in agreement with @adrianba's points.

[adrianhopebailie]

I created this issue to track an action I have to capture the key arguments for and against a shipping API.

I started doing this on a wiki page here by modifying @mattsaxon 's effort to capture the key differences between the proposals.

It was intended to become a good summary of key issues for discussion at the face to face, which co-incidentally @mountainhippo took as an action to create so hopefully this saves him some time 😄

As it is a wiki page it would be great if it was edited by everyone that has contributions to make.

@nickjshearer @adrianba @ianbjacobs @dlongley @vkuntz @rsolomakhin @zkoch feel free to edit: https://github.com/w3c/webpayments/wiki/Issue-Summary

[fredMeignien]

I agree with @adrianba's points too.
I would add the following: if we consider that the concept of check-out is the phase where the consumer must be obtained in a reliable way, secured for all parties, then the shippind address belongs to the key elements of consent; otherwise it would mean that a payment may be initiated with Billing address = Null, and then give room to an issue between Payer and Payee (for instance: "I never received the goods so I reject the payment"). In other words, the consumer might "withdraw his consent" using the billing address issue.
This consideration does not imply, of course, a specific technical solution, but the idea is that the billing address has to be encapsulated before payment request is generated.
In the VISA Direct API named "Create a Sales Transaction", this address is mandatory: https://developer.visa.com/products/cybersource/reference#cybersource__cybs__v1__create_sales_transaction

[ianbjacobs]

Regarding billing address: I had understood from previous discussions that data related to payments would be attached to the payment app, and therefore would be "encapsulated" during that process.
Is that the expectation others have?

Ian

[nickjshearer]

@ianbjacobs - yes, that's true, but we do have an optional deliverable (3.4 of the charter) to "attempt to define a specialization of the payment flow specifically for payment cards", which I would assume includes collection of billing address. So even if it's encapsulated we may still be defining the formats and messages used inside that encapsulation.

[ianbjacobs]

@nickjshearer,

Good reminder of the card specialization work.

Ian

[ianbjacobs]

Can we close this issue since we resolved at the Feb FTF meeting to include shipping address capture in v1?

Ian

[ianbjacobs]

Closed based on FTF discussion:
https://www.w3.org/2016/02/23-wpwg-minutes#item10