Web Payments WG TPAC Face-to-Face
20 Sep 2016

See also: Agenda, 19 September minutes, IRC log


(no, one), AdamR, zkoch, MattS, BenSmith, Manu, nicktr, MaheshK, Dongwoo, dezell, Roy, Shane, Rouslan, ShaneM, Max, JiaJia, Mountie, evgeny, Ian, AdrianHB, NickTR, LarsErik, William, Laurent, MattP, NickS, Jean-Yves, AlexandreB, lbolstad, jyrossi
AdrianBateman, Pat Adler


<nicktr> Day 2 proposed agenda -> https://github.com/w3c/webpayments/wiki/FTF-Sep2016

Review of weekly WG teleconf

<manu> AdrianHB: Are folks okay with the call times?

AdrianHB: Any challenges to current call? Weekly too often?
... Would like to make it easier for people to provide input to the agenda

(No change.)

Web Payments HTTP API Next Steps

<manu> Web Payments HTTP API Next Steps (Slides)

Manu: We recently published the two specs. They are designed to mirror payment request API
... the HTTP API is about how you execute the current browser flow using purely HTTP
... Digital Bazaar and Worldpay have done basic implementations
... the orgs didn't chat about their implementations but we are off to a good start
... three categories of questions arose around the specs:

1) Do they reflect existing practice?

2) What are the use cases?

3) Who do we get relevant parties involved?

scribe: the HTTP API works like this:

* You try to get something and are told you have to pay

* You are told where to send a payment request, which is shipped via HTTP

* You get a payment response and you get access to a resource

scribe: on the question of whether the API reflects current practice - the flow we are trying to enable is the SAME flow that we are talking about in the browser API, just out of a browser.
... the question arose - isn't this about communication between the payee and the payment service provider? That's not what the API is about, but we could do that if the group thinks that's a priority

adrianhb: Let's talk about use cases first

<Zakim> AdrianHB, you wanted to suggest we discuss use cases first

adrianhb: if the use cases are things that don't exist, then the other questions would be moot
... so let's start with the use cases

Manu: I think there was a misconception that the HTTP API is for internet of things use cases
... while in theory that could work, that's not our focus.
... the primary focus is automatic payments.
... e.g., your bank software makes monthly payments
... or you want to use an app (not in the browser) to make a payment
... software running in kiosks...so it's non-interactive but it's not IOT
... think of paying a utility bill...today you give your payment instrument information to the utility company....if your card changes you have to set it up again
... the other thing with utility payments is that they occur regularly, but you don't know what you have to pay until the end of the month
... what you could do is having wallet or banking software where you set up a payment endpoint with your electricity provider, and your banking software will ping the provider to get a total. That results in a payment request. The utility company says "you owe this much this month". Your wallet software responds to the payment request (using some payment method) and the utility processes the payment.
... there are various benefits (e.g., your wallet can pay with your updated card)

zkoch: Is the idea that once it's set up it's automated?

Manu: Yes.

zkoch: It's hard for me to imagine automatically switching underlying form of payment without user consent. I'm having a hard time understanding the line between HTTP/Browser because of the user consent that's likely

Manu: The scenario goes like this: there is prior consent to use different payment methods.

zkoch: So is a key use case that you are delegating to the wallet authority to make decisions on how to pay.

Manu: That is a use case, not the primary use case.
... the primary use case is "some piece of software other than the browser" that you have configured to make payments on your behalf.
... Another use case is a large corporation that wants to pay vendors automatically
... e.g., a gov agency could ping different suppliers each month where automatically they ping the vendor for the amount owed,
... and the system determines whether the value is within an acceptable range, and if so payment happens automatically

<Zakim> AdrianHB, you wanted to note some similarities with PSD2

Manu: so the primary focus is "smart payment agents making payments on your behalf"

AdrianHB: Understanding the actors has made it clearer to me parallels to the PSD2 architecture
... you are describing an actor that is authorized to initiate payments...PISP in PSD2

manu: Yes, the PISP could be using HTTP API

pascal_bazin: Could the HTTP API be used to introduce third party payment methods not managed by the browser?

Manu: The goal is to use any payment method that the browser supports....

pascal_bazin: Could you use the HTTP API implement a new payment method?

Manu: Maybe; but that's a general answer

dezell: NACS is interested in not forcing merchants to use apps.
... I like the HTTP API and the separation of concerns it represents.
... it enables us to decompose problems
... in my day job at Verifone we push some L2 processing into an outside web server
... that's the sort of thing that the HTTP API would enable us to do
... I also think that conexxus could make use of this

manu: Some addition use cases (but not an area of focus): in-vehicle, electronic receipts
... On the question of "do we have the right people in the group to work on this?"
... we have a healthy list of payment app providers (10), merchants or merchant reps (6)
... if we wanted to do the new connection between payment app / PSP we only have about 3 PSPs in the group and we'd need to do more outreach
... So the question if we have limited resources, should we focus on "enabling the same browser flow in other software" or "PSP communication"?

<AdrianHB> ian: thinking about who is in the group

<AdrianHB> ... if I understand the use cases it's focusing on automated payments

<AdrianHB> ... the value of interop for the browser api is small number of implementations and wide user base

<AdrianHB> ... what is the interop gain for http api and therefor who do we need involved in the work?

Manu: Interop is that app providers have common format.

<AdrianHB> ian: who are the companies that would be payment app providers?

IJ: I have not figured out the economic / interop incentives yet.

manu: Anyone who is doing a wallet app wants to do automatic payments...
... so the incentive for wallet providers is that users stay in their wallet for all payments
... There is no way today for a wallet provider to hit a service and get a payment request in a universal format

Shane: Manu mentioned not being able to hit an endpoint. One thing you can't do today as an automated service provider...
... there are proprietary ways to do things...but there's no standard way to do thing
... I can pay mortgage monthly today
... if my wallet had a way to talk to the electric company, get the amount, and pay them, it would improve user experience and improve interop for all wallet providers

IJ: Who are the service providers who want to come together to do this?
... I apologize I am not understanding the incentives yet

Manu: We want to work on a primer and clarify the benefits, then reach out to parties to determine whether this is a compelling use case for them

IJ: +1 to talking to key parties to determine what the interop needs are

Manu: Are org is very interest in this level of interop...we don't hear enough orgs in the WG today so we want to go out there and talk with them. If we go out and find out that this is not something that is broadly desired, we'll need to change direction.
... so we need more data to find out whether this is a compelling thing for merchants and payment service providers

AdrianHB: My feeling is that it's too early to say what direction to pursue. I think people are still thinking about the use cases.
... I can understand the question Ian is asking...it's not about technical benefits of interop...what are the incentives for the players in the ecosystem to implement the standard?

Ben: I think you need to show what this displaces in the current processing chain. More work on that would be useful

AdrianHB: I think we need to figure out the commercial incentives...

<adamR> …And we seem to be back.

<AdrianHB> ian: I like the idea of doing outreach; I support that as a next step

<ShaneM> Intuit (Quicken), LastPass, Fitpay

<ShaneM> micropayments / paywall access

IJ: +1 to getting feedback from potential implementers on value of the spec and interop.

Ben: I think that users would like the additional automation, what I don't understand is the relationship to current processing and stakeholder roles.

AdrianHB: So Manu, you are driving the work and can continue. I would plan to get more involved once we've addressed other priorities in the WG. Also the Interledger CG is setting up a micropayments breakout tomorrow.

Evgeny: From a PSP perspective. I had not understood previously that HTTP API is for automated payments; I agree that is useful. It would be useful to simplify the API as a starting point. E.g., 2 calls to make a payment.

DavidE: On your point of people who would like this: zipline and P97 are two companies that come to mind. They are the kinds of NACS members who want to innovate in the wallet space.

Push payments

Roy: See my write-up of the problem statement. Failures in card payment scenario are not that harmful. But for Alipay, SEPA pay, etc. where funds are changing hands before you get the response, there are many failure points in the flow where failure is more harmful. One previous idea to address this would be (1) mediator generated identifier (e.g., UUID) in combination with (2) discovery service

Zach: How are things done currently? How does UUID solve problem? I look at paypal as an example...they provide a callable endpoint ...what is that we are standardizing?

Roy: I think it's the fragmentation problem. A lot of services today use a back-end communication mechanism.

Matt: We do this in the SEPA spec.

Zach: So I can poll a service using a unique identifier?

Rouslan: The other benefit for UUID...the merchant can generate it and bind it to the user IP address. If the user clicks the buy button again, the payment app can detect an attempt to pay twice, and prevent that.

AdrianHB: The value of standardizing this is that you can introduce this identifier earlier in the flow. So you know the merchant has an identifier, and as a payment method provider you can architect around this. If we only standardize it in the payment, you can't rely on it in the same way.

Roy: For me it builds on the theme from yesterday - I hope we can minimize the dev time for merchants to use a new payment app. Payment app standard behavior makes it easier on merchants.

IJ: I think the value starts with open payment methods since the merchant doesn't know what app the user will select.

Rouslan: Where should this go? I see the value of it.

AdrianHB: There would be a need to augment payment request

zkoch: I don't think payment request needs to fulfill the role. We can say that there's a good practice to standardize an identifier.

AdrianHB: But if you want the browser to notify you, you need the event.

zkoch: The "event" about point of control handoff seems generally useful. But I don't think payment request needs to generate the ID.

Rouslan: Does this apply to pull payments as well?

Roy: No, since funds are transferred after funds are complete and so you don't care the same way.

IJ: Might be useful for things like chargebacks. Tracking payment receipt with the transaction.

AdrianHB: Idea is "event" triggered at moment of hand off to an app. (We've not discussed what data can be transferred at that moment; part of upcoming discussion?) So there are two things that are useful - identifier + where control was handed (payment app).

AdamR: But that's useless unless you can get back to that app at some point.

AdrianHB: Or the service provider they speak with. Maybe there's another event on the service worker to process queries.

AdamR: I think that (1) identifying payment app locally and (2) payment app globally those are two separate problems. Service worker lets you address the first one. But for something cross-browser you would need something like a URL.

AdamR: We need both "who control was handed to" and "how I get back to them."

IJ: In Alipay does server ping Merchant or vice versa?

Max: Both exist - alipay server can send notification to a merchant server (called the notification URL). Merchant can also query the status of the alipay server.

@missed@: The business model of the push payment solution is about risk... may not be just a mechanical spec. A merchant might allow a purchase even if the merchant has not received a notification.

IJ: Do you have other use cases, Zach, for a handoff event?

zkoch: Merchants would like more exposure into life cycle of payment request. One thing they can't know yet is what the user chose. They would like visibility into that earlier. Seems like having another reason to do the event I could see doing that.

IJ: So with an event, Roy, do you want to flesh it out further?

Roy: Do we want to go a step further and build it into payment request or at level of payment method. Otherwise we might still find fragmentation.

IJ: I feel like we should start at the payment method level.

MattS: We've seen it twice already.

Roy: I would be happy to look at both specs to see how it works at a lower level.

ACTION: Roy to work with AdamR on revised proposal around push payments.

zkoch: the other open question I have - is there interest from payment method providers in implementing this. My hesitation in putting in payment request is not knowing who wants it. E.g., does Facebook want this to do a push payment method?

AdamR: We have heard it from Worldpay and Alipay

Roy: Everyone is doing this. You have to have something like this to not double charge people.

zkoch: I understand the value, but I have not heard people say "I want this." It seems premature to put this in payment request.

MattS: On the SEPA spec I have a specific issue about this.

zkoch: The industry is handling this today. I don't want to add something to payment request without explicit demand.

Roy: I see this as a potential adoption issue. If I am an emerging business and deciding whether to use payment request v. my own flow, if I have to do a lot of work to integrate payment apps, the less likely I will use the API. The more rolled into the API the better.

zkoch: There's still a lot of individual integration that needs to be done. I think that you would still need individual relationship with providers, they would probably have proprietary endpoints. I don't think we can avoid 1-1 relationships with processors or integrators.

AdamR: But the app can handle the endpoints for you.

zkoch: I don't think so.

Roy: I think it could answer some questions for you.

IJ: I suggest incrementally building it up...start with event and identification of ID...then add UUID later if we detect the benefit.

AdrianHB: Yes, generation of UUID is nice to have. So we need:

Payment Method Identifiers

AdrianHB: I think we have agreement that PMIs are URLs that refer to web payment manifests
... data about how an origin plays in the ecosystem

zkoch: I want to be able to finish the PMI spec.
... There are a few high level use cases we want to support:

1) For a given payment method, we want to make security assertions about apps

2) Browser wants reliable information about where to get an app

zkoch: I want to get agreement that there will be a manifest file, and secondarily (later) we can discuss what goes in it.

PROPOSED: An identifier is an absolute URL composed of the schema, origin, path. No query string params and no fragments.
... these URLs could be used by users to get web pages

PROPOSED #2: At that URL you can append payment-manifest.json which has data describing that payment method.

zkoch: There is precedence for this in Android

<Zakim> ShaneM, you wanted to propose something alternate to that

ShaneM: I don't object to the hard-coded path, but there are other ways to do this like HTTP headers
... that gives us the ability to more easily extend in the future.
... that does imply two round trips.

AdamR: That's not the case for HTTP 2

AdrianHB: So if I visit the site of the PMI I get back an HTTP header?

Shane: Probably multiple headers (e.g., here's information about the payment app, etc.)

AdamR: I get a little heartburn from a hard-coded path

zkoch: There are a couple of reasons I like the hard-coded URL but I am open to other approaches.
... one advantage is it's very easy for merchants to implement....it's harder for merchants to manage headers
... this proposal also lets me do things in a single request
... it's costly to download a page and parse it to get more information. This is particularly costly on low-end devices

AdamR: If it were a common operation that would be compelling, but IMO this will happen rarely for a given payment method

<Zakim> AdrianHB, you wanted to emphasize when this happens

AdrianHB: This will happen every time a browser encounters a payment method they haven't seen before

zkoch: Or if they want to refresh.

AdrianHB: This may be happening int he background and therefore needs to happen quickly.

nicktr; I have two practical points. I am really worried about this....what do we think the likelihood that orgs will put a manifest at a URL?

zkoch: We are going to use short strings for the open payment methods; this proposal about URLs is for proprietary systems

nicktr: My second practical question is - are you introducing a single point of failure for those payment methods?
... suppose a bad actor takes over the site.

AdamR: You already have that problem with bobpay.com....

<betehess> note that it could at least be /.well-known/payment-manifest.json (that's https://tools.ietf.org/html/rfc5785 )

<adamR> betehess: That only works if you require that each origin has at most one payment method. I don’t think that’s a reasonable restriction.

zkoch: I am open to discussing headers; need to understand more how they work

<betehess> adamR: I see

IJ: Have you talked with Anne/Tab about URL matching?

zkoch: I think there's some discomfort but this proposal is preferable - string match on well-defined components
... we'll loop back with Tab and Anne on this

AdamR: I believe that the constraints that zkoch is talking about addresses the points that have been raised

ben: I would like to check with our security team how they would feel about this.
... from a regulatory perspective, I am pretty sure that the payment method needs to be identified

zkoch: The URL has to be HTTPS
... origins will control the shape of the URL

rouslan: I'm happy we seemed to be agreeing on constrained URLs
... on the second proposal Shane mentioned headers
... I'd like to hear some examples of technologies that are using header links.

<adamR> Link headers: https://www.w3.org/wiki/LinkHeader

Shane: Web annotation protocol spec specifies that link headers with certain values allow you to discover resources of various types within that ecosystem

<betehess> lots of uses of Link in https://www.w3.org/TR/ldp/

<adamR> HTTP/2.0 server push: https://tools.ietf.org/html/rfc7540#section-8.2

<betehess> Twitter API uses it too https://developer.github.com/v3/#link-header

AdamR: HTTP 2.0 server push...if set up correctly, will let you get a single response rather than two trips

AdrianHB: So I am hearing "one less request" is not a key benefit using HTTP 2

<Zakim> ShaneM, you wanted to point out that this means the URI is BOTH an identifier and a resource

RESOLVED: PMIs are constrained URLs as describe here.

zkoch: For open systems we decided short strings. I suggest that we limit those to [a-z0-9-]+

SO RESOLVED: short strings constrained to [a-z0-9-]+

AdamR: I suggest you talk to TAG about use of headers v. pre-defined URLs

zkoch: I am ok to talk to TAG...but there is a question about ease of implementation by merchants

[We will take Proposed #2 to lunch and possibly the TAG]

AdrianHB: Are we agreeing that the PMI -- through some mechanism to be defined -- will enable someone to find a manifest

<rouslan> +1


<AdrianHB> +!

<AdrianHB> +1

<adamR> +1

AdrianHB: Primary use of the manifest doc is security (which apps are authorized to fulfill the payment method)

zkoch: I think we should aggressively limit the number of short strings that circulate

<Zakim> wseltzer, you wanted to discuss findable vs must be found (and when)

wseltzer: One piece of commentary from a staff conversation is that just because you have a URL doesn't mean you have to look it up all the time...they can be useful because their references are findable by automated processes.
... but they don't have to do the lookup most of the time

AdrianHB: Our expectation is browsers will cache info they get

<nicktr> nicktr: Notwithstanding the desire to bootstrap the ecosystem, I am worried about W3C claiming a mandate to control and define payment methods that we do not have - the minting of short-strings troubles me

(Interesting question - relationship between PMI and caching if done through headers...)

MaheshK: Suppose I only trust certain apps as a merchant

<Zakim> MaheshK, you wanted to comment on open method without manifest

[Discussion about URLs and short strings some more]

Laurent_: Is it bad to use a URL?

IJ: We heard objection to server risk.
... It's not clear to me that we need a manifest for open payment methods

Laurent: An empty manifest file might be useful to tell browser something about the payment method (that it's open)

AdrianHB: We still need to define what goes in the manifest

<Zakim> rouslan, you wanted to comment that URLs are not only for security, but also to define your own payment methods.

rouslan: I heard a comment that the best use of the URL is to ensure the security of the payment method and interaction via payment apps. I think an even better use case is to define your own payment method.
... I would like to respond to Lauren's comments
... I think it's cool from an engineering perspective to have a URL like w3.org/visa .. the problem is of course the server risk.
... we could hard code information into browsers so that there is no dereferencing.

IJ: Hard-coding in the browser is equivalent to them implementing a short string but it's harder on developers
... We've had problems with software downloading DTDs too often

Nick: Worldpay, too


- PMIs are constrained absolute URLs

- They can be used to get manifests (through mechanism TBD)

IJ: Do you have preliminary ideas on what goes in the manifest?

zkoch: I have a PMI strawman proposal.

What goes in payment manifest


- Restricting origins

- Where to get apps

zkoch: I think the two broad categories are:

- platform dependent things (e.g., what you need on Android)

scribe: including something like "where to get in the app store)

- web assertion model (I delegate to other origins)

AdrianHB: Are we happy to restrict by origin? Or specific apps?

<nicktr> See Zach's manifest strawman.

AdamR: Are we relying on origins for native apps?

AdrianHB: I am suggesting we say things in two parts (1) identify origins (2) identify where to get apps associated with those origins

IJ: The other piece I've thought about for payment method manifest is "Here is the payment method spec."

[Discussion about payment app data]

AdrianHB: Some data about apps can be part of the service worker code (rather than external file)
... but there's a use case where the browser can go get data about an app before executing a service worker

IJ: E.g., recommended payment apps

<Zakim> rouslan, you wanted to talk abut restricting by origin

rouslan: I agree that those three pieces of information in a manifest (trust, apps, payment method spec) would be useful
... regarding trust representation..I am ok to drop path part

<adamR> basically, something like this: https://pastebin.mozilla.org/8911575

rouslan: in terms of service worker and manifest file relationship...I think you are right that we will need some info about the App BEFORE the service worker is invoked.
... I think that service workers can update the manifest files.
... this allows payment apps to push updates to the browser

AdrianHB: As a payment app publisher I want to avoid saying the same thing twice

<Zakim> questions, you wanted to comment on manifest

AdrianHB: We have more work to do on what data is specific to browser-based payment apps.

MaheshK: What about native apps?

AdrianHB: That's platform specific...and we have more work to do on the payment app spec to put hooks in place

MaheshK: Samsung had different apps (for different regions)

IJ: Interesting....it's one thing to say the apps are allowed and another to say "You can't use this app in this region" I don't know where that's implemented
... Actually, use server-side filtering

AdamR: What I want is to know all the apps that are allowed. And a second concern is "For your region, here's where to get an app"

AdrianHB: Is origin-based constraint sufficient?

<adamR> https://pastebin.mozilla.org/8911575

<adamR> zkoch: https://www.w3.org/wiki/LinkHeader

<zkoch> here was my original straw man.

zkoch: Web app manifest has a way to go from web app to a native app
... my straw man speaks to this
... we can probably define a platform that is "web"
... I agree we can strip the path (as Rouslan pointed out) when delegating authority to other origins

Max: In yesterday's demo we used this mechanism!
... so it works

<zkoch> +1

AdrianHB: I am hearing manifest has these sections:

- allowed origins (for app distribution)

- getting apps

- payment method documentation

IJ: So do we partner about the payment app data bits (that might be in a manifest or in a payment app manifest)?

zkoch: Partner

Q1: Should payment app data be both available inline or by ref?

Q2: Should the manifest spec define both types of data

zkoch: What I will probably propose first is to put everything in the PMI spec...we can then see if payment apps also want it and we can pull it out as needed

<adamR> zkoch: Re icons — https://www.w3.org/TR/html5/links.html#link-type-icon

zkoch: Propose everything be in PMI spec to start


IJ: +1 to including the payment method and payment app data in the PR API + Basic card + PMI spec to start...and pulling out as needed as payment apps proceeds

zkoch: +1

adamr: If we take what adam proposed, it's mostly about icons

<scribe> ACTION: Zach to work with Max to revise the payment manifest proposal [recorded in http://www.w3.org/2016/09/20-wpwg-minutes.html#action01]

<trackbot> Created ACTION-37 - Work with max to revise the payment manifest proposal [on Zach Koch - due 2016-09-27].

Overview doc

Manu: Not much has changed at a high level to Web Payments Overview 1.0 since June. I did update some links to TR specs

PROPOSED: Publish this as a NOTE in TR space, and update it as other specs are updated

MattS: I have some minor edits to suggest.

Manu: You can suggest those changes during the CFC

<AdrianHB> +1

<MattS> +1

<ShaneM> +1

<Roy> +1

<Max> +1

<lbolstad> +1

<rouslan> +1

<nicktr> +1

IJ: +0 (no objection; but think it does not need to be a TR doc)

<bensmith> +1

RESOLVED: Issue a CFC for overview specification

WPWG timing on payment request API

IJ: Proposed CFC in 5 weeks. Also PR API would not leave CR until payment apps enters CR

AdamR: Would rather have all specs leave CR at the same tine

<Zakim> Mike, you wanted to comment

Mike5: The way I think PLH would articulate it is that you should not start CR until you know when you are going to leave CR.
... I think that you should have a test suite before leaving CR
... we don't have two implementations yet that we know about that we can test; we only have one that we know of.

<adrianba> I think you need to know _how_ you are going to leave CR - i.e. what are the exit criteria but not when

Mike5: in short - I think the focus should be on getting the test suite to advance in order to have a concrete discussion about when to leave CR

<adrianba> you also need a minimum CR time period

nickS: I would have some concerns about gating payment request (which is implemented) against something that is not implemented (payment apps)

<adrianba> exit criteria should outline how you're going to determine that you meet the PR entry criteria, which is likely to include a test suite

NickS: ...I would be concerned about introducing that dependency

Manu: I don't understand what going to CR buys us. It's usually used to demonstrate that the group is done with the work and we are fairly sure what we have. Why do we want to move to CR? What does it buy us?

zkoch: I think what CR buys us is some stability.
... people are confident that we won't introduce breaking changes unless really necessary...and those are based on implementation issues.
... Today we have one implementation. I think others would like more confidence in the stability of the API

MaheshK: We are concerned about going public with our implementation unless it is a CR

AdrianHB: Who do you think is looking for the stability? Merchants or browsers?

zkoch: Both

<adrianba> we definitely are looking for stability - want to avoid rework

<adrianba> when we talk to partners they want to avoid rework too

zkoch: I believe from Editor perspective we are ready from a spec perspective

IJ: Note that having a test suite is not prerequisite for entering CR

ShaneM: I think it's fine to set goals (e.g., go to CFC in 5 weeks)
... wrt testing, I think having a test suite will be easier with two implementations available
... I am happy to having a test suite available in 5 weeks if we have two implementations available
... finally, I'm ambivalent about whether to push to CR because of payment apps

IJ: Charter milestone is CR in Nov 2016
... I believe stars are aligned to go to CR (1) charter (2) implementations (3) stable spec trajectory

Manu: I hear people saying that some other things may destabilize payment request API...payment apps could destabilize payment request API
... that's what I'm hearing.

MattPi: +1 to IJ and ZK points about CR and stability...I think it will send an important signal to our partners

IJ: I think that payment apps and payment request API do relate closely hence proposal that PR API not leave CR before other in CR

MattPi: I'm not sure of the dependency.

[Summary of CR]

nicktr: I am hearing two different accounts: some want to go to CR (implementers in particular who are talking to customers) and those who do not (notably around payment apps)
... so one question is "when will payment apps be ready"?
... I think personally that there may be some things in payment apps that affect payment request API

zkoch: We've tried to design payment request API with all this in mind - how things work in the real world.
... it's based on that confident and we are confident about moving forward
... this is an opportunity to say "we are not going to add new features"
... my other point is that these are independent specifications.
... we believe in the open ecosystem, but the specs are independent.
... we can make a best effort to go to CFC in 5 weeks to motivate ourselves
... and see where we are in 5 weeks
... it doesn't seem negative to me to aim for a target date.

AdrianHB: Something Zach said - what is the expectation at the end of the 5 weeks?
... I want to be clear what the expectation will be in 5 weeks.
... I don't think we are in a position to say "We will issue a CFC in 5 weeks." I think we are in a position to get things done and then check then
... whether we are ready to go to CFC.

AdamR: I am concerned that when we get further into payment app spec, we may find we will make breaking changes to payment request API

zkoch: I'm aware of that.

<adrianba> I think the proposal for the timeline encourages people to file their issues rather than holding on to them

zkoch: I think we've tried to design with this in mind.
... Payment request API is built to solve a real problem independent of payment apps
... there are goals that it independently accomplishes.
... I think there is value pushing PR API forward and getting implementation

AdamR: I think there are dependencies that are not as stable as some are asserting

AdrianHB: So we have an impasse regarding the dependency on payment apps
... Perhaps we should accelerate both

AdamR: That seems realistic

zkoch: I support 5 weeks as a motivator to move the specs, test suite forward

AdamR: What is the expectation of what happens at the end of the timeline?

AdrianHB: I feel like the two groups (PR API and payment apps) need to help each other advance

AdamR: I feel that payment request API is not stable due to payment apps state

NickS: Payment request API exists independently of the payment app spec. I am not convinced that PR API should be held until the payment app spec is ready

Adam: Yes, I propose both enter CR together

NickS: I think it's odd that have that API that has implementers in the wild and we are going to gate moving into CR with a spec that depends on it

AdamR: I think there are mutual dependencies..we want an ecosystem that includes payment apps with PR API
... if we discover the shape of the API is not suitable, we may need to be changes

AdrianHB: I hear AdamR's point about going to CR sending a signal of stability that is not accurate given state of payment apps

NickS: You're implying that there is a technical dependency

AdrianHB: An example is push payments.
... does it require a new feature in payment request API (e.g., an event)

NickS: There does not seem to be a clear timeline for payment apps, but we have a much clearer timeline for PR API
... both chrome and edge are implementing. It seems like we are doing a disservice not going to CR as quickly as possible

AdrianHB: We want implementers to look at the payment app spec and say "this is on the right track"

<Zakim> Mike, you wanted to comment

Mike: [Speaking personally] Please find a precedent in W3C where a spec is held until another one is ready

Manu: WebRTC (IETF and W3C discussions)

Mike: Show me precedent; I think the burden is in part showing this has been done in the past.

<ShaneM> I disagree with Mike - this isn't about process precedent

Mike: I think that it's reasonable who feel that we should start CR (for PR API) to ask that we get some Director input on this.

Rouslan: There was a question about implementers giving a signal to the payment apps task force
... several weeks ago I reviewed that spec and I made several comments ... I think they were taken into account and incorporated
... I think the task force is on the right track.
... the technology that's being described in the payment app task force is the basis of the demo for Alipay
... so I don't know that there are a lot of changes in payment apps that would break payment request API

Manu: I think there are two points of trepidation (1) we don't have implementations of payment app spec
... the easiest way is to get at least an implementation of the payment app spec done at which point we'll be far more sure about the decision

NickTR: I am not hearing consensus

AdrianHB: I think we do want to set goals

<ShaneM> I disagree with Ian. The spec in CR is meant to be stable except for things that are marked as at risk.

IJ: You can make changes in CR. I am proposing we set the expectation both that changes may occur due to implementation of PR API and also payment apps
... Given that people agreed to read the spec yesterday by 3 October, we can have a payment app FPWD easily by second week of Oct

MattS: Should we set the criteria?
... Maybe there are 2-3 key issues to address.

<AdrianHB> Goals following F2F:

<AdrianHB> 1. Review of Payment Apps spec (Zach, Max, Shane)

<AdrianHB> 2. Proposal to address push payments (Roy)

<AdrianHB> 3. Payment Method Identifiers (Zach)

<AdrianHB> 4. FPWD Payment Apps

<AdrianHB> PROPOSAL: Accomplish goals 1 - 4 in 5 weeks and if they are concluded assess readiness of Payment Request for CR

AdamR: I am more comfortable saying "let's review the landscape in 5 weeks and see if we have got those things done"


<adrianba> the most critical part of a roadmap to CR is getting people to file issues with time to resolve them

IJ: Proposal ok with additional expectation that reviews AFTER that period will not arbitrarily suggest large breaking changes

MattS: Other things we wanted during this time

- confirm that we have a second implementation

- test suite progress

<rouslan> +1

AdrianHB: People ok with this proposal?

<AdrianHB> +1

<adamR> +1

<nicktr> +1

<ShaneM> +1

+1 since I think it's as far as we will get today


Testing presentation (Slides)

Shane: Service workers makes testing easier

[Light minuting]

<Mike5> for the record, zkoch and rouslan noted that clicking Buy button to initiate a payment request is not a trusted click event

<Mike5> can be initiated programatically (which makes it possible to automate that part of tests when we need to)

Roy: I am still available as a test reviewer

Shane: I would like a way to refer to a "known" payment method (for testing) and to be able to turn on/off support for that

Rouslan: Why not just "basic-card"?

zkoch: there should be a blocking user consent thing

<Mike5> [discussion about Chrome adding an optional flag to enable test to automate the step that requires user action otherwise]

Shane: Sounds like we've agreed to use basic card, with some user interaction


more test numbers:


<pascal_bazin> EMV specification is that the PAN can be 12 to 19 digits

implementation expectations of w3c process


[Mike shows what we have so far]


Summary of Action Items

[NEW] ACTION: Zach to work with Max to revise the payment manifest proposal [recorded in http://www.w3.org/2016/09/20-wpwg-minutes.html#action01]

Summary of Resolutions

  1. PMIs are constrained URLs as describe here.
  2. Issue a CFC for overview specification
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.144 (CVS log)
$Date: 2016/09/29 20:55:48 $