Too many cases

[marcoscaceres]

It's great that you've taken a user driven approach, however, I think you have too many use cases. It would be great if you could scale them back and work through them with actual prototypes/mock-ups. User experience/flow is critical, and having the right (HTML or browser provided) components is critical for a successful purchasing experience. The current document is too broad in scope in this respect.

Having the prototypes (or seeing examples of successful payment experiences) would allow for a better understanding of the underlying primitives that are missing from the Web.

[marcoscaceres]

(I would recommend 3 cases, and just cover the immediate cases of paying with a credit card ... then, if that's even possible, move on to solving the other admirable problems...)

[msporny]

Hey @marcoscaceres, apologies for the long delay in responding. I wanted to get some consensus from the group before replying. We just had our 3rd face-to-face meeting in NYC. So, here's a "current status" response to your issue.

Yes, we have a lot of use cases, but not all of them will be attempted to be addressed in version 1.

Keep in mind that the use cases in this document are "micro use cases", in that they're meant to address a very small part of the overall payment flow rather than trying to describe the entire payment flow in a single use case.

Here's the current list of use cases based on where we had rough consensus at the face-to-face:

https://dvcs.w3.org/hg/webpayments/raw-file/default/latest/roadmap/index.html#use-cases

It's more than 3 use cases, but focuses on a very basic payment flow (basically what you mentioned above - pay with credit card). You can see the goals for version 1 here:

https://dvcs.w3.org/hg/webpayments/raw-file/default/latest/roadmap/index.html#goals

As you can see, this is basically the only thing we're focusing on in version 1:

1) invoking a payment request, 2) selecting a payment instrument, 3) initiating funds transfer, and 4) delivering a proof of payment.

Thoughts?

[marcoscaceres]

It's good to see the reduction in scope - keeping in mind the wider goals.

It's interesting that the "Deployment and Adoption" section excludes browsers. What's the rationale there? Is the group not expecting to produce UA conformance criteria? or is current technology (e.g., requestAutocomplete() and related HTML input element types) sufficient? I guess the better question is if the current solutions are insufficient/deficient?

As a browser vendor, I would really like to see the document address the above. It will help us know what kind of resources we should allocate to this (and how much attentions we need to pay to it). If it's going to be some kind of data interchange, then there might be nothing for us (browsers) to do.

[msporny]

re: Deployment and Adoption - section excludes browsers

My personal preference is to not put browser implementations in the critical path and instead do a WebIDL interface and polyfill for version 1 (to make sure we understand the API surface in live deployments instead of requiring browsers to implement something that may not be ideal). Some of the browser vendors that were at the meeting felt that they might want to implement a native API in version 1. I think consensus for either approach is to do something very minimal in version 1.

I do expect there to be UA conformance criteria in version 1. requestAutocomplete() is not sufficient (and there was a presentation at the face-to-face to that effect by the Chrome team). The current solutions are deficient (I think we're trying to remove all form filling, even if it is auto-filling, to perform a basic purchase).

There is a very draft-y charter here that mentions WebIDL (that I don't quite agree with, but it might give you a sense of what the UA may eventually be expected to do):

https://www.w3.org/Payments/IG/wiki/Roadmap/PaymentArchitectureWG#Recommendation-track_deliverables

All of this is in flux, so I wouldn't read too much into it. We did put together an API in the Web Payments CG some time ago (horribly out of date, don't take any of it as representative of the current direction) that was loosely based on MozPay:

https://web-payments.org/specs/source/web-commerce-api/

[marcoscaceres]

The browser vendors that were at the meeting felt that they might want to implement a native API in version 1. I think consensus for either approach is to do something very minimal in version 1.

Minimal is good, but I would caution about making assumptions about how this will integrate with either the browser's infrastructure (as payment provider) or with the OS (again, as payment provider).

there was a presentation at the face-to-face to that effect by the Chrome team

Ok, nice. Have you got a link to that? Super interested to see where it falls apart.

I think we're trying to remove all form filling, even if it is auto-filling, to perform a basic purchase.

A worthwhile goal. Again, super interested how things like the user's address would be provided as part of the purchase without form inputs.

All of this is in flux, so I wouldn't read too much into it. We did put together an API in the Web Payments CG some time ago (horribly out of date, don't take any of it as representative of the current direction) that was loosely based on MozPay

Np. I'm not interested in new APIs, tbh: more interested to know about deficiencies in current solutions - specially as they've been around for a few years now.

[msporny]

Minimal is good, but I would caution about making assumptions about how this will integrate with either the browser's infrastructure (as payment provider) or with the OS (again, as payment provider).

Agreed, we'd be involving the browser teams in all decisions. Representatives from the Firefox/MozPay, Chrome, and Safari teams were present at the meeting and seemed to be interested in being involved throughout the process.

there was a presentation at the face-to-face to that effect by the Chrome team Ok, nice. Have you got a link to that? Super interested to see where it falls apart.

http://www.w3.org/2015/06/16-wpay-minutes#item04

The "lessons learned" starts on slide 17:

http://www.w3.org/2015/06/browser_perspective.pdf

It may also be worthwhile to reach out to @zkoch for a deeper dive.

A worthwhile goal. Again, super interested how things like the user's address would be provided as part of the purchase without form inputs.

One proposal on the table is to re-use the Credentials CG work (although, this programmatic, non-form-based way of transmitting credentials/information is not for version 1). The api would look something like this:

navigator.credentials.get({
  '@context': 'http://schema.org/',
  name: '',
  shippingAddress: '',
  billingAddress: '',
  loyaltyCard: {
    '@context': 'https://bestbuy.com/vocabs/loyalty-v1',
    type: 'BestBuyLoyaltyCard',
  }
}, { 
  callbackUrl: 'https://bestbuy.com/credentials'
});

and that would end up POST'ing the following information to 'https://example.com/credentials':

{
  "@context": "http://schema.org/",
  "name": "Marcos Caceres",
  "shippingAddress": {
    "@type": "PostalAddress",
    "addressLocality": "Cityville",
    "addressRegion": "CA",
    "postalCode": "12345",
    "streetAddress": "123 Main Street"
  },
  "billingAddress": {
    "@type": "PostalAddress",
    "addressLocality": "Cityville",
    "addressRegion": "CA",
    "postalCode": "12345",
    "streetAddress": "123 Main Street"
  },
  "loyaltyCard": {
    "@context": "https://bestbuy.com/vocabs/loyalty-v1",
    "type": "BestBuyLoyaltyCard",
    "bbid": "932847293847"
  },
  // privacy-enhancing digitally signed credentials "proving" validity of 
  // information above issued by organizations like US Post Office, 
  // Best Buy, US Govt., etc.
  "credentials": [{...}, {...}, {...}] 

... again, just a mock-up of where the current discussion is, not predictive of where we'll end up.

Np. I'm not interested in new APIs, tbh: more interested to know about deficiencies in current solutions - specially as they've been around for a few years now.

@zkoch's presentation does a great job of the current solutions and their deficiencies from a browser perspective. @amuntner and @dbaron from Mozilla were also at the Web Payments face-to-face if you'd like to sync w/ them offline.

[adrianhopebailie]

Yes, we have a lot of use cases, but not all of them will be attempted to be addressed in version 1.

Further, some of the use cases that are considered in scope for v1 are "conditionally in-scope" per the notes in the roadmap. Example: The Receipt use case is in scope but there is no intention to standardise receipts.

Minimal is good, but I would caution about making assumptions about how this will integrate with either the browser's infrastructure (as payment provider) or with the OS (again, as payment provider).

As @msporny indicated we'd like to provide a standard that can be implemented via polyfill if possible but the apparent eagerness of the browser vendors to solve the pain-points that they have (and which are all dealt with in v1) means we may see this in the form of a browser API sooner rather than later.

One area which I think will be challenging, as you have highlighted, is how the browser to "wallet" communication will work. I'd like the browser API to simply be a pass-through to the "wallet" so that users are free to pick any wallet. This is easier if we are limited to cloud wallets in v1 but I think the consensus from the F2F was that native wallets must be in scope too.