Web Payments WG FTF

Payment Handler Spec Issues

[Ian slides on Payment App issues]

ian: going to go through main issues and look for WG feedback
... 4 main themes used to regroup these issues
... 1. Reuse web tech
... 2. Impact of Payment Req spec
... 3. Data exchange with PR API
... 4. Merchant preferences

[ian talking through latest proposals - see slide 5]

Display of Instruments / Wallets

ian: Regarding presentation of finer grain instruments in the browser sheet: if you can see detail and click directly, you can reduce the total number of clicks to make a payment.

zkoch: there's a few aspects to the options discussion. It's fundamentally a UX thing so we can't have normative reqs
... why I don't like it in practice:
... 1. space limited on mobile
... 2. consistency in display of same instruments (cards shown differntly by diff apps)
... 3. high likelihod of duplicates
... 4. not convinced by benefit if you still have to end up in the application
... chrome has strict design rules and others have other rules we should let everyone deal with this themselves (including apps)

rouslan: i often hear argument that the browser can decide if it displays options or not but I think that is poor as apps will need to define two handlers

zkoch: you'll usually find the ecosystem settling on lowest common denominator so if one browser doesn't support then none will

tommy: I disagree with zkoch on point 4 above. If the user has configured the app for optimized flow then the app may never even need to show UI.

zkoch: agree this is possible but don't see this being used in the real world.

tommy: for low sums (micropayments) then I see this happening

zkoch: this is an optimization. I see the challenge of simply getting the apps into the selections screen as hard enough. lets do that first

adamR: this is a checkout flow and clicks increase abandonment. we don't want this to be worse than the current web experience.

dick: +1 to adamR
... user experience where options are surfaced early is v important
... the options the user has are hidden which is also problematic

zkoch: this pushes the UX problems onto the browser. The app can have defaults set at registration so that the user doesn't need to choose an instrument.
... payment apps still need to solve UX problems at registration

mathp I foresee UX problems if each payment app can show, say 3-4 instruments inside the browser UI

dick: issue is that the user may not understand what options they have available if they pick the payment app (they don't remember what instruments they registered)

cyril: this seems like the discussion is about the merchant concerns (i.e. cart abandonment) whereas for financial service providers we care about the user's concerns like consent of the payment
... it is important that we don't forget that the user always consents to a payment

manash: stats on conversions show that card on file converts 40% whereas for example PayPal 1-touch has 80% conversion so there is evidence that conversion is impacted by clicks

zkoch: when a PayPal user pays with PayPal they just pick PayPal. They seldom care what the underlying instrument is.
... this optimized checkout flow is still possible.

ian: we have in the spec a definition of a data structure and no UX reqs. We have 3 options to go forward:
... 1. drop the part of the spec that enables payment apps to specify instruments in detail
... 2. keep that part of the spec, so payment apps can provide that data to browsers. But browser chooses what depth of display they implement
... 3. keep that part of the spec, so payment apps can provide that data to browsers. Browsers must make available to user all the instrument details (in some way)

[ian takes a strawpoll on the WG feeling about these options]

alan: could option 2 include guidance on display?
... there is a power shift from merchant to browser. We are giving browsers more control than they have today.

12 votes for option 1

12 votes for option 2

4 votes for option 3

manu: for those in favour of option 1, is the primary concern implementation complexity?

ian: I heard many concerns (beyond that)

nicktr: I'd like to point out an inconsistency in the existing implementations - essentially "basic card" handler is extra privileged because it displays all the instruments, whereas the other handlers (bobpay, androidpay as examples) only display origin/handler name

marcos: my experience is that we are trying to do too much too fast. We should be more incremental.
... we have good infra in place. We still have many things to solve so let's start with option 1

rouslan: +1 to marcos. primary concern is complexity. Let's do 1 first then expand to 2
... also UX concern on mobile
... in chrome we prefer to not use basic card so they get pushed to the bottom fi there are other options

<nicktr> notes (in response to Adrian's question) that this does seem to be another example of the basic card fudge getting in the way (see also short names, filters...)

dezell: most money spent on payment apps (traditional) is spent on preventing user deception

adamr: I don't think option 1 is backwards compatible with 2 or 3

<zkoch> finnneee

adamr: i think 3 is the way this should work but I have sympathy for implementers. I see option 1 as deviation from the correct order of constituencies

mike_mastercard: I can sympathize with both sides of this
... apps in market today have their own experiences that differentiate them
... so I am inclined to say 1 but I also sympathize with the desire to have an equal positioning with basic card
... there is always a learning process the first time you do something so we should not neglect the opportunity to optimize that

ian: propose the TF will take this input and come back with updates
... [discusses new issue - 116 which we'll not cover now]
... another new issue which needs to be logged relates to syncing of state between payment app window and payment app service worker

marcos: there are many other issues we need to still figure out like additional permissions and other overlay windows etc.

ian: yes, so let's pick this up in the TF
... big issue to discuss is impact of payment handler on PR before PR can go to CR

[back to slides - do we have what we need?]

<zkoch> ^^ yes

<marcosc> MC: should also mention memory issues on mobile with running 2 browser windows at the same time each running a service worker

<marcosc> (adding to minutes)

<dezell> May I suggest (I know everybody knows about this ) https://www.owasp.org/images/f/f8/OWASP_Top_10_-_2013.pdf especially focusing on A10, A8, and maybe A3.

Impact of Payment Apps on PR API

ian: have those that have done payment app testing got feedback on PR API?

rouslan: no problems for us. no changes needed to PR API required

ian: confidence in PR API has gone up since Lisbon

<Zakim> manu, you wanted to waaait and to ask whether we're actually going to discuss that last item.

nicktr: we will discuss later

Data passed to Payment App

ian: propose that PR API spec removes mention of using line items for details of products

zkoch: okay but had assumed that is just Google's position

marcos: people will use this for product items

<Zakim> manu, you wanted to mention that I thought we WERE going to use this for product details.

manu: this is why we objected to this before

nicktr: implementors are saying that if it exists people will use it but the WG wants to give strong guidance on how to use it

PROPOSAL: Drop the mention of "products" in the displayItems definition

[filed as issue 477]

Payment App Permission to Access User Credentials

ian: can the payment app get permission to get user data like email and shipping from the browser

marcos: this is already available through autofill

nicks: sometimes this data is not just auto-fill data. eg: current location

rouslan: I have heard more important than shipping is email. This allows payment app to optimize user experience

frank: I disagree that autofill is enough. If the user chose an address already then why make them choose it again in the payment app

zkoch: a) the privacy consent messaging sees very hard to figure out b) why is that critical information?

frank: b) we use it for real time credit?

marcos: there are ways to hack around this anyway

<Zakim> manu, you wanted to agree w/ Marcos, note that we may be working on that via Verifiable Claims or Credential Management API, multiple reasons for it to NOT be dealt with in this

manu: there are not core use cases that require this
... and it feels like we could push it off until later

adamr: for things that don't change often it's likely that the app will already have this info

<nicktr> notes that as push payment use cases increase, the requirement to do fraud screening against things like shipping address will increase on the payment app side. In other words, more use cases like Klarna...

adamr: second, this is not trusted info so we shouldn't treat it as such

<zkoch> AdrianHB: We’re taking first world, card-centric view of this whole thing. Real time credit is a reality of developing world. Becoming a big industry … every scrap of data increases chance of credit. Making this more difficult is just making it more difficult to give people credit. I think we're taking a very first world, client-centric view of this. Realtime credit is a big thing in the developing world, it's important that a provider can get any scrap of data they can get to. Making it difficult for them to collect that data is going to make it difficult for them to provide credit.

<nicktr> +1 to adrianHB's point - this is another example of the inherent skew to cards in the spec

frank: we still do verification. we don't assume the data is trusted

adamr: this sounds like an optimization

frank: yes, but so is a lot of what we are discussing

nicktr: are there implications for Payment Request API?

ian: no, this would all be spec'd in Payment Handler spec

Merchant Preferences and Recommended Apps

ian: ... point has been made that merchant ordering of payment methods may be sufficient
... also there is a complex layering of preferences between methods, apps and browser preferences (e.g. rouslan said that Chrome puts its own stored basic cards at the bottom of the list))

alan: Use case: Merchant wants the user to use the merchant issued instrument. Also express that a 3rd party app should use that instrument.
... also notion of instant credit may be available for specific merchants

1. express pref as an app

2. express pref for instrument within 3rd party app

3. express pref for payment method from specific app

ian: browser can try to match app and request based on origin and merchants can also define their own payment method and have their own app that is the only app supporting that method

nicktr: there is a way to order by method but not by app/handler or instrument

ian: observation, on the question of do we have what we need to take PR to CR, let's have that chat later

+1

manu: we want to deploy this using web apps and we don't see a clear path to doing so.
... so the question is are we interested in doing a polyfill. There is a tradition in W3C that we give a polyfill to people so they can experiment. I think it easier to go to CR if the group knows there is a polyfill for handlers being developed in parallel

ian: I think we may learn more from the polyfill but not in time to impact a decision about going to CR

manu: is anyone else interested in working on a polyfill?

marcos: I agree with manu but don't have the same conclusions. There are payment apps already working using PR API so I like the idea of a polyfill but not as a means to help learn more about PR API

manu: not enough web based payment apps and those being done are all on Tommy's build

ian: Getting implementation experience is critical, and so I support getting that. But I don't think we need to slow PR API getting to CR while we get payment handler experience.

nicks: I am wary of tying PR and payment handlers together because of dependencies on Service Worker in payment handlers and not in PR API

nicktr: any other strong feelings about readiness of payment handler impacting PR readiness for CR?
... my sense is thag the handler spec is much more mature and the general confidence in it is sufficient
... to take PR API to CR

ian: I advocated taking PR API to CR last September but there was pushback. And in hindsight it seems the WG made a good choice. Is PR API much improved?

marcos: yes but it could still change a lot. CR doesn't mean it won't change.

ian: testing is not on the agenda but we have made a small amount of progress on it. there are companies that can help with this if any members want to sponsor this.

marcos: remember we can't leave CR without a full test suite

adamr: if we go with option 1 (earlier) then we have a lot of revisions to make to the payment handler spec

<Zakim> manu, you wanted to clarify that his position has softened.

manu: I am not saying we can't take PR API to CR without a payment handler polyfill. We should set realistic expectations about how long we might be in CR
... this impacts merchant merchant adoption
... how easy we can show devs that this works

ian: do groups publish "official" polyfills?

marcos: some do. WhatWG has a great streams polyfill. so good.

ian: What is not a W3C Working Group, and that is outside the Rec track requirements.

ian: alan raised issue yesterday about apps exposing functions they have to browser

alan: happy to take that into TF dicussions

Credit Transfer Payment Method

[Vincent's slides]

<nicktr> About the Basic Credit Transfer Payment payment method specification.

vkuntz: Here's how we came up with the data fields => Common global implementation market practice group (CGI-MP) did this work. CGI-MP is driven by customer demand for multi bank coordination of implementations

[Vincent reviews a bit of the history of the CGI-MP; will defer to slides once available]

vkuntz: We validated the previous SEPA draft against CGI-MP and found only a small number of discrepancies that we addressed
... CGI-MP has produced templates for ACH payments, for cross-border payments, etc.
... For me a recurring payment is a direct debit

nicktr: I would say rather that a direct debit is a kind of recurring payment

adrianhb: Who are likely implementers of the credit transfer spec

cyril: Companies in europe are developing APIs to initiate credit transfer
... The timing is good to share with European companies this work since they are working on this sort of thing

adrianHB: We need to validate the payment method with Atos or Sofort or Ideal or a bank

Ian: We are starting to do that (cf. outreach to NACHA); more necessary.

CyrilV: BPCE will consider implementing this

vkuntz: 30% of payments in Belgium on the internet today are done through transfer

zkoch: Looking at the spec, does it make sense to have a generic credit transfer spec, or should there be a series of scheme-specific specs?
... I am not sure how IBAN is required in practtice

vkuntz: What is required is account number.

(Vincent shows the ACH documentation and mappings to CGI-MP)

MattS: We want to get to FPWD to get feedback from ACH and BACS and SEPA and other schemes.
... we have sense that there's commonality; need to verify this

zkoch: We support credit transfer and want to publish this....I am happy to advocate getting feedback

<manu> Ian: Zach had mentioned, "can you find a common data set"? We had the word of Cyril and Vincent, but that's what led to the NACHA outreach, that's what led to Todd getting this document to us. I think FPWD would help us to raise awareness. It would also help wrt. other Credit Transfer systems. We're in the early phases, filtering (here, on networks and countries) looks like it could be useful here.

Frank: We can help implement to validate the spec

MattS: Worldpay (and other aggregators) would be interested in implementing this. We will need a polyfill to experiment

vkuntz: Today people are routed to banking sites to log in

AdrianHB: That arose in 3DSecure...it required a redirect...do you know if the schemes have a way to get to the bank without a URL?

nicktr: Berlin group and other groups are trying to build read/write APIs....so you don't need to screen scrape web sites

adrianHB: I suggest that part of validation of this payment method involve a native payment app

CyrilV: In the spec, we may need to change the name from IBAN to "payeeBankAccount" and then include comments about what that will mean in different jurisdictions
... so yes, we may need to review the field names to make them more generic

<zkoch> Random question: Do we have a known set of possible “networks” that would be in here? SEPA, ACH… are there others?

<zkoch> Would we define those somewhere on w3.org like we do for card networks?

<Ian> Yes, as we have done for card networks. We don't have an approved list yet. We just have examples in the spec.

<zkoch> The bit in the appendix? ACH, SEPA, BACS, and CHAPS?

<zkoch> Yes

<zkoch> Cooool

<Zakim> AdrianHB, you wanted to say that example requests per scheme may be easier than actual implementations as a start

AdrianHB: Please put examples in the spec for different transfer networks

vkuntz: I would be reluctant to put examples in the spec since they are changing rapidly
... but +1 to examples, but maybe inked

mweksler: Why is this about credit transfer between two entities. The merchant is more fixed.

vkuntz: What you are describing is called direct debit.

CyrilV: It's hard to authorize a direct debit due to accounting challenge
... we have more credit transfers in france than card payments...lots of b2b credit transfers

vkuntz: Direct debits can be revoked up to 60 days; another reason people like credit transfers
... credit transfers are generally not revokable (except for some exceptions)

<MattS> Added issue 46: Push, Pull, Sync or Async?

Tokenized Card Payment Method Spec

Tokenized Card Payment method specification

roy: the spec has changed a lot; mostly things have been deleted.
... it's now an extension of basic card
... the filter is supportedTokenTypes (which takes two values)
... The other three fields are cardLast4, tokenType, tokenRequesterId

nickTR: TokenrequesterID is who the token service provider gave the token to

Roy: Spec shows some examples of inputs and outputs

MattS: The PMI is card-token....how does this spec relate to what others are doing?

Roy: This spec has no notion of merchant onboarding

MattS: So is FB PMI a specialization of this?

Roy: Yes
... It's easy to adopt this spec
... this doesn't require other steps like merchant onboarding that involve friction
... this supports easy one-time use tokens, auth for certain amounts, ....

nicktr: I am really glad that we've got this payment method but I think there's a lot of work still to do on this
... one of the concerns that I have is that it's a bit uneven. We talk about EMV tokens and issuer tokens
... but the Stripe token is a gateway token (not in scope)
... issuer tokens are effectively proxy cards...you can run those on basic card.
... merchant can't tell in that case
... There's also a mismatch between "emv" with our card network identifiers (some of which are not emv)
... we are extending a spec that isn't bound to emvco to a domain that is
... and also the extension of the spec to use CVV for a token makes my hair stand up
... that's not where token would sit in an emv transaction. I'm glad we have a framework to have a crack at this, but I think there's more work to do to align and make it complete. Regarding EMV and this spec; this would fall within the scope of a W3C/EMV conversation

alyver: Nick said my part....regarding terminology....for android pay....I've seen "network" and "gateway" tokens and we should perhaps use those terms

Roy: Gateway tokens not included here since inputs and outputs are so different
... each would likely be its own payment method

AlanSamsungPay: I don't see what the goals of this spec are.

NickTR: The use case we are trying to cover is that the payments industry is pushing towards tokens....
... you can't process a tokenized card payment with basic card data alone
... you need (at least) the cryptogram

Alan: Is this in the category of dynamic tokens and dynamic CVVs

AdrianHB: What entity would provide a token for this spec?
... Is the same question as for credit transfer....who would write a payment app for this and what feedback will they give us

Roy: It's feasible (can be done) that FB could create tokens

mweksler: When I think about how this would be implemented at airbnb, I think a slightly different version could be useful - gateway
... if we had ONLY the token and not the PAN
... I'm curious what is the use case of having a token alongside a full PAN?
... second question is how this would apply to the token-only case

[Discussion of likely lack of commonality among gateway token inputs]

pascal: Having at the same place a checksum and a token is considered a weakness and is forbidden by PCI/DSS. It depends on how the token is produced

zkoch: I think the use case you outlined is what we want...right now merchants have to establish N relationships and this is costly
... I'd like to figure out how to move this spec forward to something useful
... I think it would be useful but want industry experts to step up to help fix it

nickTR: That's the motivation for this spec. Matt and I would be happy to volunteer for this!
... I'd like to hear from the other XPay vendors

zkoch: It is helpful to have something to point to when we have internal discussions

PROPOSED: Take up Tokenized Card Payment as a work item

AdrianHB: I want to clarify that the scope includes gateway tokens

PROPOSED: Take up Tokenized Card Payment as a work item with gateway tokens in scope

MattS: I think a lot of discussion has jumped around....in the case of Credit Transfer we've established that there is commonality

PROPOSED: Take up Gateway tokens (and NOT issuer or network)
... Form a tokenized payment task force

oyiptong: Zach mentioned a desire to move forward. I agree. +1 to gateway token flavor and I volunteer.
... once we support tokenized cards we can make it easier for merchants to accept payments

nickS: I'd rather this be framed in terms of networks and gateways
... it's not particularly helpful to speak to XPay.
... Apple Pay supports other types of cards than EMV cards
... a lot of wallets like to add additional security features

<MattS> +1 to Nick's reframe

nickS: I could see people using the responses with custom data
... want to see more input from networks on this spec

<Zakim> Manash, you wanted to discuss cloud based tokens.

Manash: Once MC joins the group we'd love to contribute
... tokenization is important both for XPay and browsers

NickTR: I hear consensus that we should do this work. The proposal is to form a tokenized payment task force. They would take the draft as input but could explore areas like different flavors of tokens

Interested in participating: NickTr, Olivier, Roy, Michel, Andre, DavidM, Ken, NickSFence, MattS

<manu> Ian: Roy, are you going to take charge of that Task Force?

Roy is the chair of that task force

<manu> +1

PROPOSED: Do that task force!

<rouslan> +1

<oyiptong> +1

<AdrianHB> +1

<pascal_bazin> +1

<nicktr> +1

<zkoch> +1

<mweksler> +1

<dezell> _1

<dezell> f+1

<alyver> +1

<dezell> +1

<DavidM_GSMA> +1

<fdold> +1

<frank> +1

<Max> +1

RESOLUTION: To create a tokenization payment method task force

Payment Method Manifest

Payment Method Manifest File proposal; goal is to replace with a new proposal.

Max: We have a new proposal. Have not yet updated the draft spec

Ian: Use cases involve authorizing payment apps (especially those associated with proprietary payment methods). Alipay wants the browser to verify applications are in fact released by Alibaba.

Max: Second use case is for payment method owner to authorize other parties to distribute payment apps that support the payment method
... Third use case is for mediator to provide improved user experience by enabling run-time registration
... Here's how it works:

* Payment method identifier combined with HTTP Header enables browser to get the payment method manifest (JSON) file

* File includes two instructions: (1) pointer to apps from the origin that can be used (2) list of other origins that are authorized to distribute payment apps

zkoch: Web App Manifest gets a lot of the job done, plus a couple of fields we need.
... Use case - user likes bobpay...gets a new phone....would like to be able to install bobpay on the fly...this is do-able with payment method manifest file
... Use case for supported origins - most of the time in the world there is a 1:1 relation between method/payment app
... but there are cases like masterpass where there are multiple apps for a given payment method
... we need alipay or masterpass to be able to indicate trusted app distributors
... supported origins is just origins, not a URL
... we prefer a looser coupling so that origins can update their manifests independently
... we piggyback on the origin model.

[Zach reviews three use cases (1) limit apps (2) the "masterpass use case" (3) runtime installation]

zkoch: The way you get the payment manifest file is by doing a HEAD on the payment method identifier

manu: Is there a use case where you have multiple link headers?

zkoch: I think that we are asserting a 1:1 mapping between origin to manifest file

rouslan: There are already points where we can fork supported applications (1) we can mint multiple PMIs or (2) we can add links to multiple apps in the array
... Web app manifest has an extension point....tells you where to add extra data

<Zakim> AdrianHB, you wanted to clarify defaults vs restrictions

IJ: I want to say out loud please require an explicit way to say in a payment method manifest file "I allow any origin to distribute an app" rather assume that is true based on lack of information in the file. This is a security issue.

<AdrianHB> propose to call it "allowed_origins" or similar

nicktr: Do we need new explicit language in PR API to talk about the behavior of the mediator

IJ: There MAY be a dependency of PR API on this ... or at least we want to make clear that this can affect matching. That is: if a payment method restrictions the origins of eligible apps, those apps should not show up as matching apps. Thus the mediator needs to know about the payment method manifest instruction. It could be that there is no hard dependency on payment method manifest, but a reference to it might suffice. See issue 478.

mattS: Are there performance issues?

rouslan: Maybe for more than 10000
... maybe useful to have a server-side solution in some cases
... but there are also limitations there

zkoch: I think caching plays a role in implementation

NickTR: Should PMM be in PMI?

Ian: I prefer not since PMI mature; let's get that to CR

zkoch: Agree that PMM should be separate

zkoch: Do people feel this is a good idea?
... We need this to do third party payment apps; Alipay needs it too
... I would like to do this in a way that plays nicely with Payment Handler

PROPOSED: Take up payment method manifest as a work item with Zach and Max as Editors

<AdrianHB> +1

<nicktr> +1

<Ian> +1

<rouslan> +1

<alyver> +1

<Max> +1

<manu> +1

<DavidM_GSMA> +1

<pascal_bazin> +1

<fdold> +1

<dezell> +1

<jean-yves> +1

<zkoch> +1

<mweksler> +1

<Roy> +1

<Tommy> +1

nickTR: Anyone see this as a bad idea?

(NO hands)

RESOLUTION: To take up payment method manifest as a work item

W3C Process of Moving Specs Forward (and other actions post FTF)

Ian's presentation on getting to CR, which includes a checklist and a first pass assessment of how we are doing.

Ian: Getting to CR...
... Good to understand what the process requires for CR... CR means "Candidate Recommendation", which means - we're ready to implement.
... But first, getting to CR.... administrative things, we make a decision - it's a "call for consensus" - Chairs assess consensus, it's our guide for talking w/ the Director.
... We need documentation on substantive changes, we'll point to Github repo for that.
... We have 3 issues lists, we are going to postpone issues, closed all other issues... That's the role of the issues list.
... Are there any formal objections on the work? Not aware of any.
... Even though we don't have provably interoperable implementations yet, we should show them the demos for PaymentRequest API.
... For CR specifically, have you met WG requirements, have there been changes to dependencies?
... How long will CR last - during that time, you receive comments on the spec... those comments will typically be from outside of the group.

Marcos: We have to keep a list of that... disposition of comments.

Ian: Before you go to CR, we need wide review... pretty good footing, but least good footing.
... I sent out note to groups for review... have met with Privacy Interest Group... we're on the W3C Technical Architecture Group of groups list...
... We go on Github issues list, and get feedback... Baron and Leithead have actions in the TAG.
... a11y folks provided feedback, we want more formal eval from EMV, PCI, implementation from parties not in the room.
... I think we're okay there, but external review would be helpful.
... CR enables this ability to say features at risk, if we don't get two interop implementations, we'll drop them.
... Are there features at risk. Default expectation for leaving CR is two implementations. We may want to say more.
... progress on payment apps, add requestID, test suite progress...
... Do we need to invest more in testing to get our of CR, do we do that?

nicktr: CR provides IP exclusion opportunity.

Ian: There is a new window for exclusions that is 60 days long, covers differences between FPWD and CR.
... In the first window of opportunity Visa exercised their right to exclude which we addressed in the PAG. A new exclusion window opens up for 60 days at CR.

nicktr: Orgs need to figure out how to deal w/ IP issues and CR.
... How quickly do we want to go through CR?

Marcos: We would like to be a part of CR testing... we'd like to wait even longer if we could get more.

AdrianHB: You listed test suite as implementation experience, test suite isn't implementation expereince.

Ian: Test suite is not itself a requirement. The requirement is to show interoperable implementations, and a test suite is useful for doing that. Typically a group creates an implementation report that includes (perhaps among other things) indication of which implementations passed which tests of the test suite, or explanations of why some tests were not passed.

AdrianHB: What about coverage?

Ian: The default is that we cover (normative) features in spec.

AdrianHB: Can you do normative but optional.

Marcos: We don't have any of those.

AdrianHB: People have feature detection, payment handler is an example, this is how we want wallet to work, possibly.

Ian: You should have implementation experience for optional normative features.

AdamR: If necessary we could split the optional features out into another spec.

dezell: Are there no features at risk?
... Things like the wallet could be a feature at risk... if you have things that you think might be optional, it's a good idea to make them features at risk.

Ian: Expectation is basic card is a note
... So, we don't need to do anything w/ that...

AdrianHB: It's a note, do we write tests for it?

Marcos: We may want to make it a spec

nicktr: We may not want to do that conversation now.

PR API: Features at risk

zkoch: currencySystem

Ian: A reminder about this feature: it allows people to refer to currencies not yet in the ISO standard by pointing to other repositories and entries in those repositories. I don't know if we have any experience yet with people using that feature. It was for things like Bitcoin and Ethereum at least.

marcos: We need implementation experience to understand it better.

Roy: The billing address concept seems problematic...

Ian: That feature isn't in yet... so it wouldn't be a feature at risk.
... If we're in CR for a year, and we define that feature and get impelmentation experience, at that time we can find the best process for including it...
... Any objections to marking currentSystem as a feature at risk?

(No objections)

Ian: Are there any other features?

zkoch: That's the only one I can think of...

Marcos: It'll be marked in the spec as feature at risk...

AdrianHB: If it's marked as at risk - provides additional incentive to show that it's useful.

PR API: CR Exit Criteria related to Mobile/Desktop implementation

Ian: The minimal expectation in the W3C Process is "two interoperable implementations." Is that the only thing we expect to show when we request to advance to the next level?

nicktr: We had a conversation about payment app, and in terms of ordering, can we take Payment Handler API to FPWD first.
... We need to examine if we want to put exit criteria to CR to PR on maturity of Web App piece.

AdrianHB: We want implementations on mobile and desktop?
... I think we need two implementations on both.

zkoch: No

Ian: We have implementations on mobile, some on desktop...

mattP: We have implementations on both mobile/desktop - it'll be there, Windows works on both.

Marcos: Who wants to tie implementations together Payment Handlers and Payment Request?

AdamR: Yes, me.

marcos: Different DNA in implementations is good.

nicktr: Any other exit criteria

Rouslan: Two implementations, one from Samsung/Chrome - not same rendering engine... browser process is different.

Ian: Two things - do we have confidence in Web App manifest in some way, then what to say about mobile vs. desktop.
... Two of each, any strong objections?

A few objections noted ... unclear whether they're strong.

Alan: Is there criteria for the assertion of leaving... test suite?

Ian: Usually, showing "all green" (i.e., tests passed) in the implementation report.

AdrianHB: We're saying what we hope to achieve...

zkoch: Everyone has minimal time, priorities, etc... that doesn't reflect nature of the world... traditional is two implementations, that seems sufficient.

AdrianHB: Mobile vs. desktop... implementations differ between desktop and mobile.

Marcos: We turn off UI... that's what we're testing.

adamR: I've heard issues raised pertaining to user experience to justify design experience... that makes it valid to say we need to have multiple renderings of this, multiple form factors before we consider this done.
... We don't want to get into a position of where we don't have experience before exiting.

MattP: It's the same code base for us... if we pass test criteria, it's not going to matter...

<AdrianHB> manu: I thiught we already had 2 impl on both desktop and mobile

<AdrianHB> Are we saying 4 different companies with 2 diff form factors?

<Zakim> manu, you wanted to ask if we don't already have two different implementations.

Ken: From an Amex point of view - we'd be advocates that mobile and desktop are done... device doesn't always provide distinction between mobile/desktop... desktop transactions and purchasing behavior, have legs... product development perspective would be good.

David: I understand where AdrianHB is coming from, proven product that works... two different code bases, solution is the same... if you are implementing on desktop, implement it on mobile.

<Zakim> AdrianHB, you wanted to say that implementation experience can't just be technical compatibility with spec as it is today

<Zakim> manu, you wanted to ask AdrianHB which implementations he thinks we have on mobile AND desktop...

AdrianHB: If we limit ourselves to do implementations are one for mobile and one for desktop, we may not have it complete.

Marcos: It has to interoperate... it doesn't happen in vacuum.

AdrianHB: We need to have two implementations so there is discussion around things that are happening.

mweksler: Another perspective, tension I sense is between how much we want to constrain the exit criteria, trusting our future selves for exit critiera....
... The counter proposal seems to be a bit more strict.... I like the proposal with more wiggle room.

AdrianHB: As with everything, when we leave wiggle room, why bother... if committment is when we get there.

zkoch: Let's just do 2 and 2.

PROPOSAL: Two implementations from two different vendors on both mobile and desktop.

<adamR> With that proposal, I see no reason to push my point. If the proposal changes, I’ll want to requeue

That proposal carries based on number of hands raised.

PR API: CR Exit Criteria Related to Payment App implementation

Ian: What's the goal of Web-based Payment Apps exit criteria?

nicktr: We're trying to protect that charter requirement...

nicks: I would have to discuss w/ my WebKit colleagues ... we may object to that.

Ian: I'm not hearing objections to take Payment Handler to FPWD. This is a separate question about the relationship between Payment Request API CR exit and Payment Handler.

Roy: I disagree that there is no dependency between PR and PH APIs... there is a lot of useless stuff if we don't have web-based payment apps... so, I think we've failed if we never get web-based payment handlers implemented.

zkoch: We'd love to see a 3rd party ecosystem...
... Mozilla is in favor... we don't want to create dependencies on one or the other... let's get payment request out there, move it forward... happy to support PaymentHandler, let's think about them separately.
... I support 3rd party, separate and move foward...

adamR: I wanted to agree mostly with Roy... I think we failed to get a good 3rd party ecosystem out there... the right answer may bear on PR API.... how do we expres sfilter/matching criteria, it bears on PR... there are real dependencies here. We may need to change it. I agree with Nick, we need some kind of interlock so we don't need to change it.

Ian: We might set an expectation that they go to REC at the same time. We have all implementation we need before we do REC... they're both important.

AdrianHB: Part fo the motiviation for multiple implementations on both form factors, PR API may change when we implement 3rd party apps.
... If we have existence of decent number of Payment Apps, maybe we can tie CR to that.

<Zakim> manu, you wanted to support what AdrianHB is saying.... exit criteria more about implementation xperience.

<Roy> +1, I assumed spec process was a good proxy for third-party implementations existing, but the latter is the goal

AdrianHB: if we combine it with multiple implementations on mobile - web-based as well, would prefer... hard requirement for Web Handler spec.

nicks: I disagree, don't see PR to have exit criteria on apps... we don't need that.

Marcos: We don't need that dependency.

AdrianHB: That would be a bad spec.

Roy: I think the problem is not that AndroidPay is good or not. it's that they're tied to a specific form of payment request.

nicks: To be clear, that is not technically true... webkit is open source, you can see that.

Rouslan: Firefox could support android pay tonight.

zkoch: You shouldn't confuse business policy decisions with implementation decisions...

MattP: It's an interesting conversation, as a group, we said payment methods and support... support of 3rd party payment apps... multiple demonstration of 3rd party payment apps, that original intent is there. Sad irony is that we're not pushing to CR.

zkoch: What's limiting ability to do it in some cases is not technology, it's business.

Rouslan: Alipay has exposed android intents in a way that's interoperable with any application out there... need to have an agreement with whoever calls them... calls into Alipay... they are a 3rd party payment app. Anyone could call into Alipay, get Alipay in their browser... Alipay needs to knonw where money is going.

nicktr: I'm finding it difficult how this helps us meet demands of our charter.
... First deliverable (listed in the charter) is registering digital payment instrument... I can't see how we can object tieing these things together... maybe right time to tie them together is not CR or PR, want to deliver what we're chartered to do rather than limited subset.

nicks: Our charter doesn't specify the order of delivery
... What's in the charter that says spec A and spec B should be tie together
... We (Apple) don't have service worker, this makes this a much taller ask.

adamR: There are dependencies, technical dependencies.

nicks: What's in the charter that stops this from happening?

AdamR: We may shoot ourselves in the foot if we do that. where we keep changing things.

AdrianHB: There is not a dependency between the specs, ther eis a dependency on PR on supporting payment apps... that's the technical dependency. Some concept of apps. If Safari supported apps, that would probably be sufficient to say that PR API is fully implemented in Safari.
... while I appreciate the concern that Nick raised, that there are risks here, Zach and Rouslan make a good point, business relationships that we can't influence directly... design specs that don't prejudice people. Lot's that are left up to impelemntations.

Rouslan: I thought we made a decision to implement PR API then Payment Handler, for sequential delivery of both implementations. this decoupling ended up making specs orthogonal.
... We don't have payment apps? No, we do - it's hard to integrate... kinda... intents makes it easier.

roy: Why do we care about this process status?

marcos: IP committments

AdrianHB: To implement PR, you have to get Payment Handler forward, and Apple can't implement.

nicks: We want to lock this down, multiple reasons, you end up adding something that implementers can't achieve... we did separate these two specs out, we should have put them together.

MattS: When we separated them, we wanted to progress them at a different pace...

Ian: I think we should set an expectation but not a hard requirement about getting payment app implementation to inform the PR API implementation phase. If we get to a point where there is a desire to exit CR and advance to Proposed Recommendation, those who feel we do not yet have adequate payment app implementation (to inform PR API) can object in the corresponding call for consensus. In other words, let's send a signal now that people should implement PR API, and also set an expectation that people might object to the next PR API transaction (to Proposed Rec) if they don't feel we have enough payment app experience.

AdrianHB: In the status of the document, we expect to show implementations of payment apps to demonstrate implementability of this API.

<Ian> PROPOSED: Set expectation at CR of implementation experience of payment apps (native and/or web based) to demonstrate stability and usefulness of PR API.

<Ian> (Noting that people can object when the CfC happens to go to PR)

<zkoch> +1

<AdrianHB> +1

<rouslan> +1

<mathp> +1

<DavidM_GSMA> +1

<Manu> +1

<Roy> -1, want more aggressiveness

<mweksler> +1

<Ian> SO RESOLVED: Set expectation at CR of implementation experience of payment apps (native and/or web based) to demonstrate stability and usefulness of PR API.

PR API issues list (and other todos) before CR

Ian: I'd like to hear from editors first wrt. what needs to happen before CfC.

Marcos: We have a CR list on Github (see also full issues list)

nicktr: I see 7 open issues [goes through the issues]

MattS: Also some outstanding pull requests

Ian: Also some things that have been noted (e.g. editorial stuff, other questions)

Marcos: We should issue them ASAP and assign people to work on them

Ian: Happy to help

Marcos: Over next year we can fix editorial, but we have to identify critical. We have 7 there. Are there others?

<Ian> For CR consideration, please include issue 478. Given that we know we’re going to do method manifest, we should at least look at it.

Alan: Would like clarity on one issue: the requirements in the spec that dictate or guide the user agents on how they will display the payment apps
... what is the current spec on that
... im unsure of where that is

Ian: I thought you were going to point to 10 of 3.3

<Ian> "The user agent MAY show payment methods in the order given by supportedMethods, but SHOULD prioritize the preference of the user when presenting payment methods and applications. "

Alan: I’m in the right section now, thanks!

6 April date to freeze the list of issues to address before CR

nicktr: Any issues that anybody things need fixing before CfC should be marked as such. 2 week timeframe. Give editors 2 weeks to respond

Ian: Some minor concerns about 100 new issues.
... There is a balance between existing implementations and stuff. We should note spec has been in development for a year. So people should act in good faith. Do homework. See if issues have been raised and resolved.

AdrianHB: Amendment. IF you want to raise issues, tag with milestone, editors may say no. Chairs can make call if disagreement

MattS: Not everyone has ability to add milestone label

AdrianHB: Raise issues and ask for CR rec
... if disagreement, chairs can make a call

Ian: What is the statement about when?

Nicktr: 2 and 2, but open to challenges. In light of IETF, 1 week to raise issues too small

<Ian> NickTR: Please raise your issues by 6 April WPWG teleconf when we will review them to determine what issues make the list

Ian: Summarizing, 1 at risk feature, things in status section about exit criteria (one expectation, one # of implementations)
... didn’t say how much time. Why don’t we say on 6 Apr as other piece of discussion editors or implementors can have opinion on CR expectation
... todo list is essentially the issues list
... other reviews. may hear back from TAG. privacy review. can fix those comments into the 2 week window

nicktr: lampshade where we are, feels like there is expectation that we are moving towards CfC
... sounds like that will happen ~4 weeks from now

AdrianHB: Would be good to know if others will object

matts: Thank you for the summary. Are we taking about PR API only?

PMI Specification: Features at Risk

AdrianHB: What about short strings?

Marcos: Probably too late

IJ: Features at risk is about implementation, not features we don't like. We already have implementation of short strings

Features at risk? [None]

PMI Specification: Amount of time in CR

Ian: Align with PR API

PMI Specification: CR Exit Criteria

AdrianHB: Regarding payment method manifests, I think PMI depends on it

RESOLUTION: For PMI to exit CR, need at least FPWD of payment method manifest spec

AdrianHB: What is an implementation of PMI?

Marcos: There is an algorithm for URL matching
... should just be parsing and matching
... implementation expectation is 2 interoperable
... 6 April todo list
... I need to check the spec...and am comfortable by 6 April doing so

PMI Specification: Issues to resolve before CR

<AdrianHB> https://github.com/w3c/webpayments-method-identifiers/issues/

Basic Card: Note or Rec?

IJ: note that if we change the expectation about going to Rec, we trigger IPR things

(No move to make a Recommendation)

Payment Handler API: General Support for going to FPWD

<manu> Ian: Who would object for Payment Handler going to FPWD?

<manu> Marcos: We have to look carefully for what's going out there.

IJ: Any objections to going to FPWD?

Marcos: My concern is going out "too soon"

Marcos...we can help with big warnings

<manu> No objections for going to CfC for FPWD for Payment Handler API

<AdrianHB> no objections to taking Payment Handlers API to FPWD

MattPi: When we went to FPWD for PR API we had implementers. who are the implementers in this case?

Rouslan: Google is one implementer

MattPi: Do we have app developers?

Ian: (We heard "yes" from: Mozilla, Worldpay, Ripple, Gemalto, Digital Bazaar, Facebook, and Klarna.)

<manu> Ian: When CfC comes up, you can say +0 or +1....

Payment Handler API: Issues to mark in the spec at FPWD

* wallet granularity: none or some but not required to display

* payment app instrument ordering (and relation to payment method order)

* event.OpenWindow()

https://github.com/w3c/webpayments-payment-apps-api/issues

NOTED: Nobody asked that these be RESOLVED before going to FPWD.

Frank: Please add the issue about payment apps getting customer data; I'll add to the issues list

Ian: We will ensure that these four issues are called out in the spec and perhaps general shape as well

rouslan: None of the issues have an impact on PR API.

Marcos: Please also get rid of respec warnings

Ian: +1

Marcos: We also need a stricter review process
... Please also rename the repo to reflect new spec name

Payment Handler API: Time frame to FPWD?

NickTR: Time scale?

Manu: Can we do it after PR API?

MattS: Would rather see them all the same time

Ian: I will try to get Payment Handler API to FPWD sooner than the CR. That may be easier because we won't have to resolve issues, just ensure they are marked in the spec.

<nicktr> notes a strong preference to CFC Payment Handler API FPWD _before_ the CFC for PR API to go to CR

Tokenized Card Task Force

Ian: It seems we will not request FPWD of the tokenized card payment spec until the task force has had a chance to meet to discuss. But we resolved to take this up as a work item.

<scribe> ACTION: Ian to work with Roy to set up a repo for future tokenization spec(s) [recorded in http://www.w3.org/2017/03/24-wpwg-minutes.html#action01]

Credit Transfer Task Force

Adrian: I think the Credit Transfer task force is going to look for implementations

Payment Method Ordering

Ken: I wanted to share some thoughts in the last session but did not have a chance. I support this effort and think that the success of this effort can be enhanced by greater support from the card payment industry
... here's an issue that I have with the specs
... there's a potential commercial advantage given to merchants given their ability to specify payment method preferences
... my proposal is to remove the language
... in show() 3.3, step 8
... the ask to the group is to remove the merchant preference language

Ken: That would result, for example in the sentence being something like: "The user agent SHOULD prioritize the preference of the user when presenting payment methods and applications."

nickS: I am ok with this change; some others may object

Alan: Payment method ordering can also be used to guide merchant preferences

Ken: Language that encourages one use case may conflict with another. My proposal is to eliminate language and allow different market behavior.

<zkoch> FYI: filed issue 481

<manu> Ian: I am hearing the comment from Ken to be: if the merchant can express a payment method order preference, the user agent could use use the API that way despite a contractual obligation to do something else.

dezell: Merchant interests are important per our charter; just a reminder. just noting that our charters - intentionally or not - favor customers and merchants.

mweksler: Is not having any statement about merchant preference more problematic?

Ken: No, it is preferable to say nothing

Marcos: I think removing the language gives user agents more flexibility
... I want the flexibility

<jean-yves> About choice of PI, as far as the EU is concerned, have a look upon art 8.6 of Regulation (EU) 2015/751 on interchange fees for card-based payment transactions: http://eur-lex.europa.eu/eli/reg/2015/751/oj

Manash_MC: Payment app exclusion is a related topic

adrianHB: We have an order of constituents that we speak to, leading with users
... we don't have detailed naming of some parties in the ecosystem

IJ: I think language in our charter is about which use cases the WG should address (e.g., b2c rather than b2b). I don't think it's about the order of constituents.

nicks: One other point in favor of omitting the language....regulatory requirements can be very different in different parts of the world.
... omitting the language might help us avoid conflicts

AdrianHB: By omitting the language we put the onus on the browsers.

NickS: Omitting language doesn't prevent providing an order.

David: Be aware also of regulatory impact on mobile money

Alan: I don't think there's a lot of retail representation in the room. They are going to be interested in expressing preferences.

Merchant Adoption Strategy

Ian: We have no time for my presentation on the merchant adoption task force. I want to be sure people are aware of the FAQ which has about 60 questions in it. Please review and send comments (or edit). For API usage scenarios, we have a FAQ, let's keep building it up.

Next FTF meeting

Ian: Should we meet in the last half of July? We have a possible host in Paris.

Noting for the meeting record:

* Not much enthusiasm in tired room for July FTF

* Prefer to decide later based on need whether to hold a face-to-face meeting before TPAC 2017.

Next teleonference

No WG meeting 30 March

Next WG meeting is 6 April

AdrianHB: Another topic is what to do since mozilla may not be at Thursday calls
... Thanks to everyone! Seeing implementation is exciting. Seeing apps is exciting!

IJ: I am happy to have a call with Marcos, and others who cannot make the weekly call.

Marcos: Let's make more explicit that WG decisions are asynchronous.

Comms at CR

IJ: Should we do a press release and other communications at CR of PR API? (Ian observes support in the room.)

<scribe> ACTION: Ian will work with Marcomm on comms plan for CR for PR API [recorded in http://www.w3.org/2017/03/24-wpwg-minutes.html#action02]