Web Payments Working Group

06 Nov 2017

Agenda · 7 November minutes


dezell, AdrianHB, CyrilV, Dongwoo, Manu_Sporny, Wonsuk_Lee, alyver, Mohammed, Dadas, marcosc, Gildas, SteveSommers, btian, Ian, nicktr, andrewsudbury, mbu, cwebber2, mountie, jmacwhyte, sam, Takashi_minamii, tminamii, tminamii_, Ken, vincentK, Magda, vincentK_, Rouslan, Keyur, ChrisMarconi, MattdeGanon
Ian, manu

Group photo of WPWG



NickTR: Nice to see growing WG

<AdrianHB> nick: [talking through goals]

<AdrianHB> - Communicate progress (on a variety of specifications)

<AdrianHB> - Ensure shared understanding of roadmap for current deliverables

<AdrianHB> - Identify and prioritize new topics in scope for the next Working Group charter

<AdrianHB> - Share early adoption experience, feedback from merchants

<AdrianHB> - Determine next face-to-face meeting regions and approximate dates

NickTR: Introduce yourself to others

<AdrianHB> scribe assist: AdrianHB

<AdrianHB> ian: [getting numbers for restaurant]

<AdrianHB> ... The agenda has 4 parts

<AdrianHB> ... Part 1: Payment Request API (current and future)

<AdrianHB> ... Part 2: Payment Apps

<AdrianHB> ... Dinner then back tomorrow

<AdrianHB> ... Part 3: Payment Methods

<AdrianHB> ... Part 4: a few streams. Merchant adoption, planning for next meeting, time for any topics we must revisit etc

Payment Request Implementation status

Marcos: We have about 99% of tests done

[Marcos walks through various implementations and how they are doing with the test suite]

Marcos: Chrome is perhaps 95% conforming to the spec
... Firefox has implemented the API but we haven't finished the UI yet
... We should see conforming implementations within the next 6 months, in particular at the pace the Chrome is going
... rouslan will be here later; google working hard to get to 100%
... mozilla wrote most of the tests and were testing against our own implementation, so we are confident that once we have a UI we will pass the tests; we are about 95% done wrt tests
... manu has also been running the tests in the context of the polyfill

Manu: We were able to pass a lot of tests quickly; that was reassuring
... the only issue we had with the test suite was having to manually run tests.
... what is the plan to automate those?

Marcos: We are trying to do that because all the browsers have different buttons, but ideally we would automate the button pushing

Mike: We have had a grand plan re testing....now we have resources invested. The plan is so you can do trusted click events

Ian: When will we exit CR?

Marcos: Could be about 6 months

AdrianHB: We have an at-risk feature (Issue 617 about currencySystem)
... The question is whether has anybody implemented the currency system feature?
... is anyone here interested in that use case and ensure that this feature does not get removed?
... as a first pass, the best thing you can do is write the test

[ISO 4217 may be updated to include some cryptocurrency codes]


<jmacwhyte> Bread here (cryptocurrency wallet): This is something we could see a lot of need for, but we don't know anything about organizing testing. There are many sub-categories of cryptocurrencies that could be used for payments. Regarding additional currency systems...there are a lot of subcategories ....within ethereum, for example, there are tokens
... so we could see a lot of use for ... but we are not testing experts

Nick: Is Samsung inheriting from Chrome or doing tests separately?

Dongwoo: We are trying to do our own testing with our own UI; have not done so yet

Zkoch: Nothing to add

Molly: Nothing to add

Mike: There is a web-based runner you can run tests from; so the better way to run the tests is that we have a command-line enviornment; ping me if you want to run tests

Ian: If you have questions about testing, it's a good opportunity to talk to people this week.

<Zakim> manu, you wanted to ask if it's that difficult to implement (UI issues), and ask if polyfill will be one of the implementations in the implementation report...

Manu: Why doesn't the polyfill count as an implemention.

<AdrianHB> ian: it's not intended to be a standalone application. It's intended to be a stand-in system. As we discussed in March explicitly, our goal is native implementation in (different) browsers.

<AdrianHB> manu: we don't want a polyfill that fails the tests to go out

<AdrianHB> ian: it's helpful in the testing but I am not aware of precedent within W3C to user a polyfill as a way to exit CR.

Manu: Still not sure why polyfill doesn't count

Editor's note: Ian subsequently checked with W3C staff and was corrected: being a polyfill would not automatically disqualify an implementation from consideration as an implementation for CR exit.

Marcos: You won't be able to do implement all features of the specification as a polyfill
... we had to add something to the browser to get this to work.
... the iframe tests, for example, you should not be able to polyfill the @@
... I think the expectation is that the feature has a chance to succeed in the market
... the polyfill will inform the standard
... but I don't think it will replace the standard, nor will it be able to achieve all the tests.
...This is an open invitation for people to help us with testing.

Firefox with Payment Request API

Marcos: Don't judge us! :)
... we are still working on the UI
... our implementation integrates well with autofill

[Marcos shows how information is recovered from previous data entry and previously stored information]

Max: Does the test suite also include the payment method manifest?

Marcos: Not yet.

Max: How about native app support?

Marcos: We currently don't have any plans to do mobile on firefox
... just desktop
... We have a lot of interest in doing it but it's a resource question

Max: How many volunteers have been working on test cases?

Marcos: mostly me and some help from Microsoft and Rouslan

Max: I will discuss with the payment method manifest authors whether we can add test cases for those.

AdrianHB: We are also looking at doing more test-driven editing

<scribe> ACTION: Max to look into getting resources for testing around payment method manifest

Safari with Payment Request API

Andy: I work on Webkit at Apple
... some background...Safari shipped ApplePay on the Web in Sierra and iOS X...we saw some adoption and were excited to bring it to PR API
... I wanted to show a demo of how this works.

[ApplePay button on the screen, using PR API]

[...an ApplePay sheet pops up]

[...changing address fires relevant event]

[....we show in the demo an example of an error if the merchant cannot ship to an address ...I'll say more about error handling in a bit]

[...demo shows authorization via the fingerprint]

scribe: demo shows payment response data ]
... we use the details field to give the merchant the ApplePay token

Andy: Merchants are interested in two events that are not yet in the standard:

a) Merchant validation. We fire an event that has a URL...merchant sends to server...who sends to our server...who responds to merchant who updates the payment quest

b) In Apple pay you can have multiple cards set up

scribe: so we added an event for this

scribe: and when you switch between the cards, that fires an Apple Pay event
... that gives the merchant the opportunity to update the line items...that event has information like credit v debit card

[IJ thinks there may be privacy issues to address around that one]

[Andy shows code]

scribe: The Apple Pay PMI is https://apple.com/apple-pay
... there's some data for our payment method: version, merchantIdentifiers, merchantCapabilities, supportedNetworks, countryCode
... there are also some optional (ApplePay-specific) fields

Andy: We have one problem ... we redact customer information prior to authorization by the user
... we only provide some information once user has authorized payment in the applePay.js there is a way to validate information to give the user a way to correct errors and authorize
... but in PR API there is just one Promise
... merchants would have to fail the transaction and find a new one.

NickTR: Do you currently support any payment methods other than Apple Pay?

Andy: Right now just Apple Pay

Manash: If Apple Pay extends to other payment methods....

Andy: Safari is the only webkit client authorized to use apple pay

Manash: If Apple supports payment handler API and other web-based wallets, the user experience would be different

Keyur: Will this work on mobile or desktop or both?

Andy: Works on both Mac and iOS

<mbu> The issue in question that Ian mentioned is https://github.com/w3c/payment-request/issues/645

Andy: On testing: We support web platform tests. We run them all in webkit...we pass all but the allowpaymentrequest feature
... there are two interesting things to note
... since we only support apple pay right now, some of the tests we modified that use the basic card payment method (to use apple pay)
... the second thing that we did was to automate manual tests using some webkit internals
... to script a mock apple pay sheet
... we were able to turn manual tests into automated tests; but not sure how generalizable those are
... would be good to understand if there are plans for generalizable test tools

AdrianHB: In V2 one topic is deterministic response if you specify some specific input params
... we might want to work through that approach

NickTR: Sounds like you've discovered some features ... is your intention to propose spec text?

Andy: Yes, we'd specify on github

NickTR: Is there a payment method manifest at the end of your PMI>?

Andy: There's a web page but not a manifest file.

Chrome with Payment Request API

zkoch: PaymentMethodSelected has a privacy issue.
... payment method detail modifiers may be another approach
... I will be interested in hearing more about the other topics and how to generalize them
...re: Chrome status - rolled out on Android in Sep 2016
... we went live on other platforms as of milestones 62, so about 1 month ago
... sorry 61 for desktop
... we also have a pseudo implementation on Chrome IOS
... it's wkwebview...we inject a glorified polyfill
... but it doesn't play nicely with iframes...but we do have some support for basic card.
... Merchant adoption has been steady and good for us
... regarding v2 features, we will need to evolve PR API to stay competitive
... e.g., gift codes...we should be prepared to embrace for the next version of the API
... for Android, we also have native payment app support...e.g., samsung pay, alipay, others
... we also have implementation of payment handler API
... there are some issues that need to be worked through...there is a serious limiting factor in the world of registration
... rouslan will discuss this
... as you talk about payment handlers, if we can drop that requirement completely, that will be useful
... that's my brief update

<zkoch> I’ve got to head out, but I’m around starting tomorrow evening if people want to mee up and chat

CR Exit Criteria todo list

Marcos: In order to advance on the Recommendation Track (exiting Candidate Recommendation) we need to do some additional things and reach consensus on some topics
... the main thing is to have multiple implementers pass the test suite
... the other big topic is the feature at risk.
... there are some editorial matters as well

Issue 480


Marcos: Nick asked us if we could have payerGivenName and payerFamilyName
... to make it compatible with NSPersonNameComponents

Tess: Yes, we would still like this change
... we'd rather not have to take a name and decompose
... if the merchant already has it in separate components, could just use that
... ther is also phonetic prepresentation in some markets
... both family/given and phonetic version is valuable

Marcos: Should this be a CR change or a 1.1 feature?

Andy: Not important for CR

PROPOSED: Make 480 a next version feature

Issue 588


Marcos Everyone is using UUIDs. Should we make this a MUST?

Andy: We are using UUIDs

PROPOSED: Change to MUST for CR

IJ: One implication is that merchants would be required to provide UUIDs

Marcos: The proposal is that the auto-generated ones are UUIDs, not all of them (from merchants)
... Merchants can provide whatever they want
... we can't enforce syntax / uniqueness as the browser

Mike: How are we going to test the UUID generation?

Marcos: It's testable for length but not uniqueness.

Mike: It seems like it should be testable
... the requirement may be the length but not the uniqueness

Issue 608


Marcos: This is a hard one....given an address...e.g., in Japan
... it may be using a non-English script
... how does the browser make the language code determination?
... we will probably use Unicode CLDR

<shift4sms> Clarification on Unique id , it should only be unique for the merchant, so maybe it needs to be combined with the merchant identifier.

Andy: We are currently doing empty string

Marcos: What should we do?

Andy: We would happily do something specified, but don't have any current plans

Marcos: We have not yet dealt with this on the gecko side

NickTR: How do we get to an answer?

Marcos: We are kind of stuck on this; this is probably the biggest gap in the spec?

IJ: Who do you need to discuss with to get an answer?

Marcos: Implementers. Will everyone use Unicode CLDR?
... will need to talk with our internationalization teams

NickTR: Has this been solved elsewhere in W3C?


Marcos: Given an address written in one language, you need to derive what the language is without asking the user

AdrianHB: Why?
... Why does it need to be changed?

Marcos: It's not changing it, it's just saying that's what language it's in

<jmacwhyte> I agree, specifying the language doesn't seem very important

Mike: The spec has a "language code' property
... if we are going to require a property for PR....there are circumstances when you won't be able to determine it....we either decide we are not going to have it (if not necessary)

Marcos: I need an answer from Rouslan or Zach or the folks from Apple
... Google is using a Unicode library (that others can use as well)

AdrianHB: I think it's ok to say "if you can't determine the language code, return nil and bytes untouched"

Andy: Also I'm curious if the user agent can determine it from the string then the merchant can do so as well

AdrianHB: We may have to return to the question of why we needed this code


NickTR: Our charter expires end of Dec. Charter scope is important wrt the patent policy
... explicit charter language helps organizations make the business decision to join. This is your opportunity to call out things you want to see sharpened up in the draft charter.
... much of today's agenda will be about features, and we want to ensure that the charter enables us to work on them. Our draft charter has us continuing work on payment request, payment handler, payment method manifest, payment method identifiers, and basic card
... then we would take up formally additional payment method specs
... such as tokenization, credit transfer, direct debit, interledger, etc. We will also look at some operations (e.g., how we publish payment methods, filter short names)
... proposed to stop work on HTTP payment specs
... and some liaisons language.

Rechartering process

NickTR: Reminder of the rechartering process: First, we get a WG decision
... then we get W3C Management support, who then propose to the W3C Membership
... aim to finish rechartering by March 2018 (with extension provided by management until that time). Charter scope balance is an art - don't want to bite off too much but want to keep the work interesting

AdrianHB: Regarding the new features discussion - we expect to come up with a list of things to consider, then the chairs and staff contact will review the scope of the charter to ensure it covers the topics
... I don't expect it will be a list of GitHub issues in the charter

NickTR: Our current charter excludes loyalty....question is how to open that box in the new charter, for example

Out-of-browser payments

AdrianHB: We have published HTTP API and HTTP Messages as FPWD and propose to discontinue in the next charter
... it wasn't clear who the implementers would be of an HTTP API
... we can continue to discuss whether to drop
... but what has happened recently is that I have proposed to the IETF WG to explore the use of our data model (payment request data)
... with HTTP HEADERS, and I would like to mention this liaison explicitly in the charter. My request is to have an explicit liaison with the HTTP WG. I am presenting the draft RFC I wrote to them next week
... what has been proposed to the HTTP WG is to take some ILP experimentation and formalize it

<Zakim> manu, you wanted to explain why there was so little work on it. and to explain why there was so little work on the HTTP API

Manu: I'd like to give background on why there has not been a lot work on HTTP API/Messages....we were waiting for the PR API model to stabilize
... for HTTP Messages we wanted to create a data model that is the same either in the browser or out of the browser...
... I fully support continuing to work on these two specifications
... from a liaison status point of view, I don't know that it makes sense
... I think the headers make sense at IETF
... but for the message data, it comes from W3C
... so I would like the WG to continue to work on the deliverables....if headers cannot capture all the data, we should do that in our WG
... we also did not focus on those specs because people were focused on browser-based payments

NickTR: Who in this WG is also in the Web of Things WG?

[No hands]

NickTR: My sense is that the use cases for HTTP are interesting in the case of IOT payments
... interesting point from Manu on data model in the WG and HTTP headers perhaps elsewhere

Ken: Why move it out of the charter? How difficult would it be to bring it back within the scope of the charter?
... one challenge we've seen from a Web Commerce IG perspective is limited resources
... there may be interest but not enough resources allocated yet
... it would be good to understand what doors we are closing if we move forward with the proposal as-is

Ian Several reasons to remove from charter. One is patent policy. We currently have exclusions over those specs. Second, the charter is intended to reflect the groups intentions. There has been no work on these so this should reflect that.

<marcosc> mc: you would need to incubate it regardless

<AdrianHB> ... can any group take up the work and continue to work on it?

<AdrianHB> ... yes, I think there is a need for the group to charter such that it is in.

MattSaxon: We would like to continue to work on HTTP-based payments. Can we have it as "possibly in scope" in the charter?

dezell: I would like us to keep the HTTP payments in scope for this WG

<Zakim> manu, you wanted to say patent policy for data model is already covered with Payment Request API and to say we might want to be hesitant to take it out without someone else

manu: What Ian said re: HTTP API makes sense. The data model is already in PR API
... it's really the documentation of the data model we have in the browser....so we could do that in the wG, and push HTTP Headers off to the IETF
... I think that's a reasonable way to keep things in scope

Ken: If we retire it and bring it back...what is the level of effort of patent analysis later?

Marcos: For those who are interested you can incubate it in CG
... to get something that people can work on

NickTR: I've heard several participants say they are interested in leaving in the charter
... Does anybody want to speak strongly in favor of taking it out?

AdrianHB: I don't want to strongly say take it out, but I do want to say "if you want to work on it, make a commitment to work on it."

MattSaxon: I'm searching for a pragmatic solution. The difficulty I would have is working on other items today.
... I can't make a commitment of when I will work on it.

Manu: Concrete proposal is to leave the data model spec in the group and discontinue the HTTP API spec
... people have not been working on the HTTP API
... I am happy to take the PR API Proposed Recommendation and put data in a data model spec.

AdrianHB: But who is going to implement the specs? And how will it improve interop?
... I think we need to show that there's an interoperability need that this would meet and there are people lined up to implement it.
... The IETF use case require neither this data model nor the HTTP API

PROPOSED: Leave data model spec in the group and publish the HTTP API as a Note in the WG

Marcos: You can transfer the spec to a CG
... e.g., to the WICG

<AdrianHB> +1

IJ: Beyond the charter, there is a social expectation that we need stakeholders to sign up to work on this before we start working on it

[Show of hands for people interested in general in a non-interactive payment request specification]

(Half the room-ish)

PROPOSED: Leave data model spec in the group with an expectation that we will need people to step up as interested stakeholders to move this to active work. Publish HTTP API as a Group Note.

NickTR: Indicate your support of proposal in IRC

<manu> +1

<Magda> +1

<AdrianHB> +1

<bertrand> +1

<Ken> +1


<marcosc> +1

<CyrilV> 0

<mattdeganon> +1

<cwebber2> +1

<alyver> +1

<frank> 0

<marconi> +1

<MattSaxon> +1

<vincentK> 0

<dezell> +1

<Sachin_ahuja> +1

<dlongley_> +1

<oyiptong> +1

<joerg> +1

<Keyur> +1

<mdadas> +1

<mountie> 0


Payment Request API next steps

[Adrian walks through his slides, which summarize issues involving feature requests]

AdrianHB: We've postponed some features over the past couple of years
... today we are going to review those and other suggestions for what to do next in the API
... today we are going to get a feel for what we need to work on. I have created some themes

[Slide 2: Themes]

Adrian: I organized topics from least to most controversial

[Slide 3: Best Practice]

AdrianHB: Not sure if deterministic testing should be part of charter.

Issue 613: Facilities for merchants to test the API

IJ: Issue 613 is about merchants testing their use of the API (not browsers testing their own implementations). I could have a higher-level topic like "Merchant Adoption" that could include topics like testing by merchants
... as well as things like developer portal etc

Marcos: I'd support exploring merchant testing further

Molly: +1 to supporting something like this

Steve: As a developer I think it's a great idea.
... this might affect multiple specs
... I think you will need to propagate information test results through various specs

Adrian: Issue 600: We also want to align with feature policy as that advances

[API and Data models, slide 4]

Issues 3 and 29: Multi-currency

Adrian: Multi-currency...merchant wants to be able to say $100 or 90 Euros
... slightly more complex way to do this is per-payment-method amounts
... for example, for each accepted payment method, I could specify different currencies and amounts

AdrianHB: In my experience with push payments, this is usful
... merchant wants to advertise different produces per payment method

Manu: I think that these issues are a signal for a deeper concern that Digital Bazaar has about payment request API; see my blog post about monolithic design of PaymentRequest API. Recall that we had asked that Payment Request API be more composable. I think some of these issues that you are referring to hint that there will be a growing set of features that the browsers will have to implement.
... the concern that we have is that payment request API will take on more and more features, which will give merchants fewer and fewer options.
... the general comment is to address this in a healthier way, and to deal with a more general problem
... I think that we should continue to keep that in mind as we work on the problem.
... I think we have painted ourselves into a corner and that the design doesn't lend itself to extensions. My hope is that if we implement some of these new features, we find a generalizable way to do this, so that other WGs can reuse components
... e.g., related to billing addresses
... so do we slap everything into Payment Request or do we create a smaller API that we work on in the rechartering,.

manash: I agree with Manu's point that we don't want things to get too complicated. But I come at this problem from the merchant adoption angle.
... we need to see whether we are addressing valid merchant use cases. If we see that these features are important to merchants for their adoption, then we should elevate the priority of these features

cwebber2: I work on decentralized social networks. That work ties into payment request API. The type of technology that is being developed here could be generalized even beyond payments.
... We recently came up with an identical work flow in our other group for a non-payment use case
... maybe there is an opportunity to be less specific to payments

mountie: multi-currency is an important requirement
... this is especially important for non USD economies

adrianhb: I am hearing 2 discussions (multi-currency, composablity)...I would like to return to composability at the end
... I am hearing multi-currency as an important issue

Issues 27 and 550: Billing / Invoice Address

AdrianHB: I also think that billing address is a big demand
... that we need to capture not just shipping address but also billing address

IJ: Billing address is currently in Basic Card. Are there other payment methods that need it?

Andy: Apple Pay does need billing address

<manu> Ian: One way to think about this is if these things are specific or generalizable.

NickTR: I expect we will need for tokenized card

AdrianHB: So I am hearing strong support for billing address as a top-level feature

Issue 639: Update PaymentRequest fields before show()

Issue 639 - update paymentrequest fields before calling show()

scribe: two things happening in parallel...as a merchant I am looking at information in the background and the user clicks show before I am done
... the question is what to do (e.g., NOT show out-of-date data)
... so it sounds like there are refinements to the API (e.g., passing a promise to show) to fulfill this use case

<jenan> adrian is summarizing https://github.com/w3c/payment-request/issues/645 but 639 is related

Miscellaneous issues

Marcos: 592 is about "get" on current details of Payment Request

AdrianHB: also think we need to look at validation and errors passed to the payment sheet (issues 225 and 537)

[API Flow and Extensibility, slide 5]

Adrian: Some issues related to payment handler - handling abort() in the payment handler (issue 473)
... capability matching (issue 470) and where do we need more extensibility?

AdrianHB: Another requirement that has come up is the ability to pre-filter shipping addresses
... e.g., "only allow shipping addresses within a particular region"
... Apple Pay does this by giving merchant some info about the shipping address (but not all) and allowing merchant to send back information to the user side
... Issue 548 is about capturing additional data (which is related to the composability topic)

[Business Requirements slide 6]


Adrian: We don't currently support pre-auth today
... that could be part of canMakePayment() where an app could do a pre-auth for that payment method
... two topics were about origin and authenticity of data; I think we should make an explicit decision whether to explore
... do we want a generalized feature to allow parties to identify one another
... Do we need to deal with regulatory requirements related to proof of consent to pay (issue 113)

<npdoty> Does TLS not provide the level of assurance you expect about integrity?

<voisine> for push payments, the payee may need to supply refund information

Adrian: these are becoming more specific in Europe.
... we need to be sure that what we spec out can be used in different regulatory environments
... are we doing things to enable / make things difficult.
... Do we want to enable the merchant that explicitly tells the user what they are paying for? Is there a regulatory requirement?
... my feeling is that as soon as we cross the line where the browser is in the regulatory space, it becomes more complex
... e.g., what liability might the user agenda bear?

<Zakim> manu, you wanted to note that many of these are potentially Verifiable Credential use cases.

Manu: You could argue that pre-auth and digital signatures are closely related to verifiable claims work
... so if we work on that, we should have a liaison

Adrian: I think it depends on what you mean...but I hear you
... agree we should add VCWG to our list of liaisons

jheuer: We are putting a lot of semantics into what we do. This means that we need to understand the semantics implications in different contexts
... mechanisms should remain neutral as possible regarding regulatory semantics

mountie: Regarding proof of user consent to pay.
... if we are trying to handle this, we will need to discuss lots of things like non-repudiation

Adrian: Store pickup.

Issue 237: Manipulation of available instruments by browser based on heuristics

Adrian: Suggest as out of scope "manipulation of available instruments by browser, based on heuristics" (issue 237)
... I don't think we need to spec that one out
... eg., should a browser stop presenting a card if the card continues to fail

IJ: +1 to not calling that out explicitly

AdrianHB: I suggest we close it and leave it as a a browser implementation detail
... Do we want too spec this? Do we want force browsers to show all payment methods? My preference would be that the scope of the charter not touch on this

<manu> +1 to put manipulation of available instruments by browser based on heuristics out of scope (because of the can of worms that opens up)

nicktr: Strong +1 to leaving it out

<MattSaxon> +1

<mountie> +1

<Magda> +1 to leaving it out

<mattdeganon> +1

<rouslan> +1

<dezell> +1 to leaving out

<scribe> ACTION: AcrianHB to close issue 237 with "will not do; leave to browsers"

Discount codes

alyver: I wanted to start by voicing our support for some of the topics before lunch: billing address collection, multi-currency, and in-store pickup
... for discount codes, we opened an issue (Issue 145) that was parked; that was fine for v1.
... 80% of our merchants use discount codes. 20-25% of transactions involve discount codes
... so we'd like a form in the sheet, e.g., alphanumeric up to a certain number of characters without browser validation

Marcos: What do users do?

alyver: Having the user input data to a sheet creates friction. We have worked around this today by having a pre-sheet that pops up

marcos: We'd like to work on that, but want to see more of what they look like in practice.
... this way we can help users enter them

alyver: codes are typically words (or like "fall2017")

adrianhb: I think that giving users a free input field is not a big issue in itself, but giving the developer the ability to label the field may be more important.
... but there are security issues like if the label says "Card PIN"

JamesM: Another issue has to do with merchant-side validation of codes...including price updates

AdrianHB: That's a good question

JamesM: My first impression is that it would be handled BEFORE PR API is called

Sachin: It belongs in the merchant realm, I agree

alyver: This has probably been the biggest issue we've faced to implementing PR API
... this issue and adoption by more payment handlers would be a significant boost
... we have everything we need except discount codes

rouslan: I think it would be a great idea to add discount codes; I'm not sure yet how it would be handled in the UX or payment apps, etc.
... definitely I think we should do this in v2

Magda: Point of clarification - are we talking only about promotional codes? Or also coupons and other offers?

alyver: For us so far it's only been promotional codes

keyur: Discount codes belong to the merchant; there could be multiple codes. The user needs to know that the price changes with the discount code.
... before even invoking PR API the merchant could validate the code and update the amount then update the amount; I think that will be a better user experience

alyver: That's what we do today; I'd rather have it all happen in one sheet
... with an event/update cycle

marcos: Let's capture the use cases in github
... I am supportive of the model proposed - put in code; merchant validates; then it can be added as a display item
... I think there are good solutions there
... that gets us closer to display item times (e.g., tax v. discount code v. generic item)

Jenan: Stripe checkout is in some senses a PR API precursor. The #1 feature people ask for is discount codes
... I think next logical step is adding discount codes; merchants don't want to split the user experience
... +1 to alyver's point of having PR API take this on; we've had this request for years
... the earlier in the flow you put PR API, the better the user experience
... if you jump straight to the project page, the more value there is to PR API

Manu: Checkout is a complex process; we can't put everything in the sheet.
... another approach is chattier merchant interaction with user
... would multiple APIs enable achievement of goals, or is really all needed to be in the browser.

Ian: Regarding what to say in the charter: I am hearing a lot of support for discount codes being in scope. There may be other topics (e.g., coupons) but I don't want to prematurely generalize. I am hearing specifically support for discount codes (which I believe have less information than coupons). I don't think the charter needs to go into detail about how we solve the use case. Regarding API composability, please suggest concrete proposals (e.g., for multiple APIs). This is what we did when we first started, and we picked an API approach. It is trust that we have more experience at this point, and it's fine to entertain a new proposal. But let's be concrete.

Manu: There's no purpose in putting forward a proposal if there's no appetite

Ian: I think we can only make a decision given a concrete proposal.

Adrian: Shipping address involves the REUSE of stored data; discount code does not.
... that makes me wonder whether the purpose of decomposing the API is for the merchant who doesn't want to use shipping address via PR API, or is the purpose to have more flexibility in the call?
... I think the latter will be a difficult solution to propose. I think that it will be hard to sell a generic sheet-building API

<mountie> discount code => two different amounts => multiple currencies and amount? connected

alyver: I think Manu raises an important point...other features that are missing from our viewpoint:

scribe: or accepting terms and conditions on checkout, or shipping dates (e.g., for florists)
... these are things that are collected on checkout

dezell: The need for an API has become apparent in the Commerce IG....there's a lot of computation that becomes predictable...but outside PCI concerns for payments
... in the 80%/20% rule...I am hearing most people want promotional code
... it's not as complicated as "offers generally"; I don't see harm in adding that.

rouslan: Thanks Manu for pushing us on this; I do think we should do discount codes. Regarding reusability of discount codes; perhaps payment apps should handle discount codes
... you collect them (and store them) and reuse them at a later time
... how this would work in terms of UX is not yet clear to me.
... if there is no good way to do discount codes, we may end up not doing them

marcos: I echo Rouslan's point.
... making things generic has to also be driven by the particular use cases
... Manu's raised some interesting ones.
... there is a risk of overgeneralizing. I am not for a generic checkout API.
... we should be looking into limiting the API rather than growing it. If we are adding more UI, we may want to have it be handled by the Web itself
... let's look at what people need to do and find solutions to those.

jheuer: Discount codes can be reused in some cases.
... I think we are over-simplifying and ultimately making the API overly complex
... I want a tool that allows me to bring in a token, and not rely on the browser to understand meaning

<jyrossi> +1 on Jörg's demand "I want a tool that allows me to bring in a token"

NickTR: I am hearing there is an appetite for discussion about discount codes; so we should ensure that the charter enables that.
... I think we need to keep an eye on composability.

Feature Requests from the Webkit Team

andy: I have four topics that came up during our implementation of PR API in Webkit
... The first topic is the need to dispatch custom events for apple pay
... one for merchant validation, and one for when instrument changes (e.g., from debit to credit)
... I have heard we may be able to use paymentDetailsModifiers, and the more I think about that the more it seems reasonable. I mention custom events not because we need necessarily these specific events, but rather how does a payment method deal with custom events.
... we created applePay- namespace prefix for our events
... we tried to dispatch these events on data...but the spec has wording on JSON serialization that makes it difficult
... is this an issue that has been raised previously?
... any suggestions for new payment methods that dispatch to the merchant?

AdrianHB: I think there are two things there since Apple Pay is a payment method
... first is whether there should be a payment method change event ....and what scope?
... I think the payment method modifiers works but can get complex
... so interesting to understand whether an event is fired when there's been a change in user selection of payment method...but the question is also whether payment apps should be able to send back signals

Marcos: I would encourage you not to prefix with applePay-.
... eventually all browsers will need to implement those prefixes.
... you could fire events and not have the corresponding IDL events

Andy: this one is pretty specific to Apple Pay

Marcos: I suggest addEventListener as a fallback.
... just avoid the prefix
... the lager question is about custom events
... I agree it will come up and is reasonable to try to sort it out

rouslan: Thanks Apple for getting more involved! I'd like to echo Marcos' point about avoiding prefixes
... I see two possible solutions here.
... one solution is maybe for generic reasons for these events and every browser would implement them....web devs would not have to write custom code
... a second way I see this working is similar to service workers...where new APIs that need to be in the SW write extensions to the SW interface
... you write an extension (e.g., with two extra events)
... web developers would feature check for those event endpoints
... they would not be prefixed (ApplePay-...)
... but I think I am currently more in favor defining generic events
... I think it would be even ok to include this in V1

andy: The only one we need in v1 is validate

michelle: It's interesting that you mention that. We have fired a request with PR API because there is no way to update things after show()
... merchants may be making computations on server and need to do updates after show()

andy: I have heard that use case as well.
... Maybe one problem with that is that it's still "race-y"
... it extends the time you have to get data back but does not give you an async way to do it

michelle: If it worked like shipping that would suffice for us

Observation about event model

AdrianHB: We've ended up with 2 models updating the sheet depending on what changes
... in some cases modifiers, in others events
... should we move to a standard model ?
... if you change anything on the sheet we fire an event
... and we always redact some fields
... if I were developing against that it would seem a lot easier
... I would know that whatever field changes I can get an event that I respond to

NickTR: I am hearing there is work to do around the event model

Webkit Request: Merchant validation

Jenan: I am curious about plans v. canMakePayments() v canMakePayments with active card

Andy: We are still discussing this; today it's implemented one way but that's not a final decision

Marcos: Something here seems specific to a system that has a validated merchant

AdrianHB: You raise an interesting point..if we do merchant validation, we can unlock features that we've resisted before due to privacy concerns
... e.g.,having validated a merchant, I can fire events that I would not fire otherwise
... Is there interest in merchant validation a la Apple Pay?

<alyver> +1

<shift4sms> +1

<MaheshK> +1 on exploring merchant validation

[Only a small number of hands raised for merchant validation]

NickTR: There's a difference I think between supporting something in the ecosystem v. adding something to the ecosystem

AdrianHB: Any OPPOSITION to merchant validation solutions?

NickTR: I might strongly oppose; I have to think about it

Webkit request: Error reporting

[We see a demo by Andy of how error reporting could work]

Andy: Error reporting is the next feature request

Andy: So merchant can guide user to edit and fix errors

Andy: in our implementation you can send multiple things through the API

Adrian: I am hearing some interest regarding error messages

Rouslan: Seems like a v2 feature

Andy: ApplePay allows specification of a default shipping and billing address

Andy: Goal is to allow merchant to specify the address in the constructor

Marcos: +1

Webkit request: Address Validation

andy: Another feature is address validation
... Contact info is redacted until user authorizes payment
... some validation cannot be performed during changes
... full contact info is available after accept promise resolution only provide, but no change for error correction
... apple pay js solves this with the validate merchant event
... could potentially solve with an extra, non-redacted shippingAddressCHange event before accept promise resolution
... that would allow error correction of shipping address (though not billing address)
... so we can't easily retry

AdrianHB: Part of the problem with PR API show() you don't know whether money has left account.
... we may need a slightly different flow
... this seems like a big change

shift4sms: +1
... the payment address...I can see some cases where the merchant won't ship to a PO box...how does that work if street address is masked

Andy: In that case we have a status of "address unserviceable"

AdrianHB: Ability to do "last opportunity validate" might be interesting, but also raises privacy issues.
... this is where merchant validation is interesting....allows for more trust

oyiptong: I am in favor of continuing to explore this.
... knowing the billing address is important to us...the origin of the payer determines fees and other info we might add to line items
... there are some regulatory issues for us as well (e.g., if payer is based in US, they have to pay in USD and not another currency)
... for these we need to know billing address country before authorizing payment

<Zakim> rouslan, you wanted to say this may be done by adding a new method on the PaymentResponse object.

rouslan: Regarding "best way to structure the API to do last-minute validation...."
... I think a good way to do this could be a new method on the response object....e.g., response.tryAgain()
... with information about what field caused charge to fail.
... that would keep the sheet up (since not payment.complete()) and improve user experience.

AdrianHB: But push payments will make this tricky (since payments are already done)
... so another thought is an event back from payment handler to merchant

Andy: I will raise issues for all these four points

Stripe issues

Jenan: We filed two issues - user wants to update line items before show().
... because canMakePayment() won't be affected, we can just make a new payment request...which is what we are doing, so that's done
... but the related issue is that merchant sends request to server and user clicks Pay before I have response bakc
... so the idea is to show() but e.g., don't allow the user to finish because I'm still waiting for data back.
... so need async way to finalize total, line items
... e.g., show() takes a promise
... or some other way to tell the browser "user wants to start payment but we don't have have full information"

<Zakim> rouslan, you wanted to say that payment handler can set the "retryable" flag. and to

rouslan: Interesting use case; that's for raising it
... I can see how modifiers don't work here
... so could show the sheet and have button grayed out
... do you want anything else to appear in the sheet, or is it just a generic loading screen
... and maybe times out after a minute
... but if you want to show other things on the sheet and not the total price, then it's more complicated

Jenan: For this purpose, the loading screen would suffice
... ApplePay's onPaymentSElected behaves similarly
... we don't expect the delay to be long
... so sheet comes up...promise resolves, and move on

Rouslan: I'd like to discuss with other browser vendors as well

Jenan: The last issue is billing address

AdrianHB: I am hearing strong support for billing address


AdrianHB: Do you see a path forward?

Manu: Depends on the browser makers.

Marcos: We don't see this as an issue.
... I think that we might see this as an emergent frustration
... or people might want back form data rather than JSON string
... these issues may bubble up naturally; I don't think we need to change the API a priori, I think we could decompose what we already have into what we need
... I think it's premature to do it now
... the market needs to tell us what we need based on use cases

AdrianHB: At the moment, there is no other API to gather that stuff. If verifiable claims were implemented as an API.....

rouslan: I can see both your points....
... I see the value of having pieces that work by themselves, but I agree with Marcos that we need more players on the platform to tell us what problems they encounter and their pain points....
... I agree we don't want to make the API a kitchen sink; suggest we follow Marcos' suggestion

Split tender

AdrianHB: Should we support split tender now (e.g., when using gift cards)?

[8 or so people expressed support for split tender payments as an in-scope topic.]

nicktr: We talked about compatability ... is there a way to get architecturally and ensure backwards compability

Manu: I don't want us to get into a position where we say "this doesn't exist so we can't do it"
... I like Adrian's criterion of whether a piece of data is reusable.

AdrianHB: I think that the charter could say something about web extensibility in the charter

MattSaxon: We've just sat through various feature ideas....big bucket of stuff to work on...how the WG prioritize them in a continuous way?

Marcos: We can tie in the issue of versioning

NickTR: let's revisit that tomorrow
... good question especially as the group has grown

Evgeny: We now have PR API and Payment Handler with "basic-card" and "other payment methods" (url-based payment-method definition), but I suppose it is not enough to have payment method single-dimensional. Say, for Yandex.Money payments (which in proposed scheme should now be a payment method itself) there can be a wallet payments (which can be done only in Yandex.Money interface) and card payments, which should preferable be done in a native browser interface. And now there is no real way to made Yandex.Money card payments in a process with more than one payment method enabled in native browser interface since there is only payment-method field in API. I'm not sure where should it come to Charter or just to Issues.

MattSaxon: The general idea is that payment apps should be able to ask for information from the environment
... I have a use case related to this as well

Payment Handler API Demo

Rouslan's slides

Rouslan: Payment Handler is in Chrome Canary (behind a flag)
... it currently works on chrome desktop and android (slightly better on Android)
... the way you flip a flag is chrome://flags/#service-worker-payment-apps
... Check out our demo at bobpay.xyz. There are ways to register or unregister the payment app (service worker)
... we get name, icons from Web App Manifest
... on Android we are currently just displaying the top-level name of the app
... we might experiment more on desktop with showing more details of the instruments registered within a payment handler
... payment app registration happens with installPaymentApp()
... the registration process returns a payment manager which tells the browser what the available instruments are
... each instrument has the name of the payment method (e.g., basic card or custom PMIs)
... you can also specify name/icon per instrument but it may not be shown by the browser
... we register a service worker (paymentapp.js)
... the main thing that goes there is an event listener for paymentrequest
... note that the handler "payment request" is not an exact copy of the merchant's payment request; it's a subset of that data
... the event is fired when the user selects a payment app
... payment apps can do a variety of things in the event handler
... for example, simply return a token
... but you can also do asynchronous actions, such as a round trip to the server
... this is accomplished via promises
... and perhaps one of the most powerful features is to open a new window for user interaction
... e.g., to have user confirm a transaction or use some other api (e.g., web auth) to get strong auth
... all this happens inside the promise
... remember that the url that you open (for the window) has to come from the same origin as the payment app itself

[Masterpass part of demo]

Manash: Masterpass is a network of wallets
... merchants implement the masterpass API....we have our own wallet but also are implementation of capital one wallet, Bank of America, CityiPay
... if the merchant indicates that they accept masterpass as a custom-payment method, then we would expect any of our wallets to appear if registered.
... Web-based wallets are important to us. Most of our users use Masterpass in Web wallet form
... we are REALLY interested in Payment Handler API as a result
... to register a payment app, the user has to visit the domain of the payment app
... in the demo I register masterpass as a service worker and then the bank app as a service worker.
... now when I click Pay the sheet pops up with a payment handler.
... it will be interesting to see how the open window experience happens
... and interoperably
... now that we are in the masterpass wallet, you could authenticate the user, allow user to add/edit instruments, and so forth
... then when the user clicks pay, the data goes back through PR API
... in our demo today we return an "id" (specific to masterpass)
... but in the future we want that to be tokens
... [Manash shows selection of either wallet through the chrome sheet]
... installation could be silent or with user consent
... but the user has to be in the domain to get the service worker registered
... Here is what we would like from the browsers:

rouslan: For Chrome, we plan to make data available across Chrome browser instances.
... on Android this is possible with native payment apps
... where any browser can communicate with any payment app (but just on Android)
... I would like to solicit feedback from other browsers.
... whether they would be interested in implementing Android's API allowing them to use payment applications on Android
... currently I am aware of two payment apps that have launched with this...one is Google's payment app in India, and the other is Samsung Pay
... and so if browser vendors implemented the Android API, those browsers would work out of the box

AdrianHB: One worry in terms of rolling this out beyond Chrome and possibly Mozilla is the dependency on service workers

<nicktr> google's payment app in India is called Tez

Ian: One implementation update regarding service workers: it is my understanding that service worker implementations are underway in Edge and Webkit.

jenan: What are browsers planning for UI in desktop
... will it be as nice as the sheet itself?

rouslan: We definitely want the UI to look premium and safe and recognizable
... we will be improving on the demo you saw today. We also need to work with the security team so that either the origin or other info is available for trust
... as a first step we have been thinking of using the same window and making it the same size of the payment sheet
... we will have to do a bunch of A/B testing to ensure that the conversion rates stay up

<nicktr> Ian: do you want UI review volunteers from this group?

<nicktr> Rouslan: Would be great to get quick review of UIs

rouslan: ..but user data will be final judge

Payment App Issue Review

<manu> scribe: manu

Ian's slides

Ian: Recap - payment apps task force in WG - brought Payment Handler to its current state... we moved payment apps into main WG.
... We haven't done much recently, focused on getting to TPAC and getting ready. This is the first time we're really getting feedback on spec so we can move forward on these issues.
... We're adjusting API based on real world implementation experience... features in spec have been implemented... there have been improvements and refinements... it's being implemented.
... We created the resources "payment app good practice" as a part of the development portal.
... We've added a number of Payment Handler API editors (Rouslan and Jinho), Marcos will join us once he's done w/ test suite.

Issue 157: Capability Matching

Ian: First issue... capability matching... at a high level, payment request API matches on payment methods. What does the merchant accept?
... Filters give you extra granularity.
... Merchants can provide finer detail to improve user experience... only W3C payment methods have capability matching right now...
... An issue that has come up - who does the actual matching? If the browser does it, you get the benefit of the browser shielding data from merchant and making life easier for payment apps... but browsers have said they don't want to do capability matching... why not have payment apps do it?
... Payment apps could do it, via boolean matching... challenge - can make payment is the key place where this happens... if something happens before user has selected app, there is a privacy issue. We have a concrete proposal from Rouslan... standardized payment method would provide static capability information.
... Browser would do the matching and there would not be any data leaked to the merchant.
... For URL-based methods, canMakePaymentEvent provides data... if merchant already has information - merchant can accept the risk if they know relationship... risk is mitigated.
... There is an edge case where payment handler supports both types, standard and URL-based one. Favor privacy over completeness... match may happen on static data in that case.
... Is this edge case going to arise? Is that a common scenario/practice?

Sachin: Can we make it such that the response on canMake... finer grained... merchant can prioritize based on their economics.

AdrianHB: Unfortunately, I think that'll have issues w/ privacy. Merchants shouldn't be able to probe the API.

Sachin: Yes, fingerprinting problem... but is there any way to ensure privacy...

Ian: You can query with just the payment method 'Masterpass'... nothing else.

Sachin: Yes, but that's a hack that gets around it.

AdrianHB: There are hacks around it, but only if user has previously consented to Masterpass

Sachin: Personal information shouldn't be shared... just list of accepted payment methods w/ yes/no.

rouslan: Thanks for describing the filtering, here's the latest thinking.
... If the merchant requests basic card and URL-based method, and payment app supports both basic cards and android.com/pay - what we were considering doing... browser looks at basic card instruments, filters those out, and shows payment app if it's possible to pay, doesn't show it otherwise...
... however, it may be more logical to perform steps as before... we see that both merchant and app supports androind.com/pay (for example), and just for that one URL-based payment method, and fire that one event and that event would carry that information. In that case, we're still respecting relationship w/ payment app and merchant, but not violate privacy. Our thinking is evolving.

<Zakim> rouslan, you wanted to talk about the edge case

Manash: A couple of quick questions related to filtering, is there a way for the merchant to indicate that they have a preference. Can the merchant ask for custom payment methods, but say they have a preference for certain things?

Ian: The API is silent on that right now

Manash: There is a ranking - for basic card, for network tokens, for custom payment method - what are the browser vendor's vision for this?

<MaheshK> rouslan: can you provide link where the proposal is for this event you talked about for canMakePayment?

NickTR: The spec didn't use to be silent on ordering, but we took that feature out.

marcosc: It talk about user preference

adrianHB: But not about merchant preference.

Issue 117: Delegating abort() to payment handlers

Ian: Delegating abort() to Payment Handlers... how do we forward merchant desire to cancel on to payment request?

<rouslan> MaheshK: Pull request: https://github.com/w3c/payment-handler/pull/170/files. Preview: https://rsolomakhin.github.io/payment-handler/#filtering-of-payment-instruments

Ian: Just because merchant recceives it, doesn't mean it can be canceled.
... We have no expectation for payments already sent to be rolled back
... abort() delegation via an AbortPaymentEvent...
... PH can respond w/ boolean indicating whthere it was able to abort payment.

Issue 116: Display order of payment handlers

Ian: Display order of payment handlers - there are a few options on the table:

  1. Specification remains silent on the topic
  2. “The user agent MUST favor user-side order preferences over any other order preferences.”
  3. “The user agent MUST allow the user to configure the display order of payment handlers.”

Ian:... You could say nothing, or use user-side order prefs... allow user to config display order... or some combination

<keyur> +1 for option 2

Ian: I don't have a sense from browsers today on their preference.

Manash: Now that we're looking at security... what security mechanisms are browsers going to use to show default payment... just putting it out there.

Yvgeny: It's impossible to clearly decide order from browser side... might also need info from merchant... "must favor" is the most strict sentence that can appear.

Yvgeny: It can't purely be a browser decision.

mattdeganon: This is an area where this seems strange where we allow the user to set preference but instead create an arbitrary order based on the browser... from a personal and an issuer standpoint... we may run into issues if we try to arbitrarte that.

Ian: Is this regulatory trouble?

mattdeganon: I heard an issue earlier today - if we remove or drop priority of a payment method, a decline issue can come up for any number of reasons but we don't know if user has declined using the payment method.
... if the browser removed the choice, that may have been the wrong choice.

dezell: We've been around the block on this - let's stay silent on this... merchants frequently have contractual obligations w/ card brands - merchant has skin in the game to have some say so. This is fraught. This will probably cause us more discussion than what we choose to have.
... In brick and mortar stores, when people buy terminals, payment choices need to be shown in a precertified way. I don't think we need to go there, but we don't need to forget about it.

Keyur: There is a fourth options - last used payment method... rest can be up to browsers implementation method... last used should be first option, then users choices.

????: Strongly endorse option 3 - we do it all over the place - our electronic life is fraught w/ acting on behalf of the user

Marcos: we should say nothing

Etienne: merchants have a hard time following selection criteria... regulatory issues, in france, if ordering isn't defined, it's a bit of a dead issue... don't know if it'll stay like that in the long run. They are specfic on how co branded cards are displayed,... food for thought.

Ian: What do browser vendors think about making this configurable

marcosc: Nope, don't do it.

rouslan: I second that

molly: Nothing to add.

Manash: +1 to Marcos

Tess: It's probably best if specs are free from requring specific UI stuff.

Ian: Clearly, tension in the room on various mechanisms forward..

nicktr: as we get more implementations, different jurisdictions will have different requirements - spec will need to support all of that.

Joerg: I'm a bit surprised to see this discussion going this way, if this is the user's agent, they should have a say in these things.
... Maybe it's a wallet that does that? There is a place for innovation here...
... I could have context information that helps the user pick the right thing... take the viewpoint of the user - this should be open in a way.

Ian: Thanks for the input.

Browser/Handler Data Exchange (in both directions)

Ian: Issue 123 is about payment handler being able to access user-stored data to speed up payment handler onboarding. Issue 218 is about browser having access to payment handler data to speed up user onboarding.

Ian: Browser/Handler Data Exchange... if browser stores some data, some folks want access to shipping address... could you have payment app request it if you have user consent.
... This would be new... payment app and browser to get stored data...

Frank: We thought about how we would implement this...
... We thought about how we should implement this...

Keyur: Regarding shipping address handling ...

Ian: This is payment app getting shipping address...
... This could be useful for initial capture of data if user doesn't have data yet.

Frank: This is only if user has info in the browser.

NickTR: This is like AVS for push payments, which you can only do if payment handler gets info from browser.

Sachin: This is another case of checkout and not payments...

NickTR: risk information on the transaction, so payments.
... Is this on payment registration or per payment?

Frank: Per payment.

Michelle: We find issue 218 useful - payer email, payer name, payer address...
... In chrome, address comes after payer info...

<mbu> slight correction: in chrome, payer info comes after payment handler selection

Merchant Interactions with Payment Apps

Ian: Merchant Interactions with Payment Apps - basic card - given merchant might not want payments from particular payment handler - two use cases cited, payment app is known to be fraudulent or it's a competitor.
... Other concerns - would like to have partnerships w/ payment apps - favor them... might want to learn about user's payment app for given transaction... contributing chargebacks to given payment handler...
... I don't think that current expectation would return information - payment handler chosen... just get data back... few ideas w/ helpingn w/ merchant side filtering... merchant can creat etheir own payment method... Target publishes Target method via payment app manifest -f eels heavyweight, but can be done today.
... Or we could augment w/ accepted handlers that parallels manifest from merchant perspective... payment handler information can be identified... maybe merchant should have mechanism to say "these are the things we accept"... browser algorithm could look to see if user has matching apps... then shrink that set by removing stuff that merchant doesn't accept.

Steve: So, you're treating that like a whitelist instead of a blacklist.

Ian: We haven't gone that far yet into deciding whether whitelist or blacklist or both, etc.
... Any other observations on whitelist?

<sachinahuja> +1 on whitelist

NickTR: That's in the payment request?

Ian: The "manifest on the merchant site" didn't come up...

NickTR: There are a set of origins that merchants accept credentials on...

AdrianHB: I'm not sure this requirement is justified - if merchant doesn't like a particular payment method, they shouldn't support that payment method.

NickTR: This is a requirement for me...

AdrianHB: A card number is a card number - doesn't matter where it comes from.

Ian: You can't ignore the desire to prevent competitors from gathering data on your mechanism.

<oyiptong> +1 on whitelist

Jenan: Strongest use case for this is basic card - saying to merchants, if you want that power, you don't want everyone to get that info... seems like semantics, but sounds like something we want to discuss.

<mbu> +1 on allow whitelist as well

Jenan: For merchants that want to do this, on behalf of... like Stripe...
... Why do you have to say it's all or nothing, why can't it be an extension to Basic Card

AdrianHB: That would be a new payment method.

Jenan: I'm ambivalent about it becoming a payment method...

adrianHB: You want to forward this payment request to different payment requests...

Jenan: Like known bad sites.
... If any site can install payment handlers... we have responsibility to protect both merchants and users from known bad sites.

AdrianHB: What's the risk here? Getting bad card data?

Jenan: Risk to merchant and their reputation if a bad payment handler scoops up bad stuff and sends it back.

[Jenan explains the risk to AdrianHB, who agrees with the risk... don't know what 3rd party is entering information.]

NickTR: This is the risk of bad payment handlers.

Jenan: What if they sell card numbers?

AdrianHB: The merchant has no say on what payment handlers to use...

Jenan: There is no permissions dialog that pops up...

Marcosc: No, there is.

rouslan: Payment Handlers in chrome support basic card.

Manash: Yes.

[Manash outlines how this is supported now.]

Jenan: One solution to this problem is merchants or payment processors have many other solutions - my fear is not having that, not having visibility with ease of installing... the combination is dangerous.
... It'll probably be easier to have user permission - stripe is in position to manage block lists - another thing to manage... don't have a strong opinion.

Ken: A couple of things...
... Big fan of sharing perspectives... it's helpful to achieve a balanced and optimal solution... with that said.
... I hear the concerns that Jenan has raised, at AmEx we hear that from merchants as well. We're trying to navigate this. I sit on AmEx network side of business, proprietary issuer, acquirer, 3rd parties, we try to take a balanced approach.
... We think it's important to recognize that there are regulatory issues here.
... There are a variety of different use cases - first time usage, repeat users, to card on file, multiple iterations to frecencies... what user is given in terms of ability to prioritize. Other perspective is from acquiring perspective... merchant has opportuity to influence payment preference on what they choose to accept or not
... The goals of what I think the WPWG have been trying to achieve - making reference to original charter - level the playing field.
... If you give merchants ability to do preference... makes it difficult to keep that playing field level, generates a bias.
... When you start adding ability for merchants to pick and choose - that starts to interfere w/ consistent user experience... we wrestle with merchant request... I understand the challenge, but hopefully it helps to understand the perspective we take.

evgeny: Some use cases where merchant needs b/w/listings - if merchant has agreement w/ a few PSP's, one of which accepts only wallet payments, while other accepts, say, card payments as well, we need an option to say using a standard that one payment app can be used with one set of methods and other payment app with other set.

Steve: The merchant risk that's involved is also important... good wallet vs. bad wallet... Apple Pay has a good system for validating card. Merchant might come across wallet w/ cards through the system... define in the specs to create infrastructure to verify... merchant not invoved in whitelist/blacklist... for example, chrome downgrading a CA.

oyiptong: Wrt. merchant fraud, if payment response says its due to basic card, the only way to block that is to block basic card... if there is no info around origin of card number...
... If there is additional information, that might help.

Ian: We don't respond w/ origin back to merchant, unless merchant can say "don't use that origin anymore". In interest of time, let's keep moving forward.
... Thanks for getting this started.
... We did decide that we didn't need anything special for partnership proposals.
... For this particular merchant need, no need in the spec.
... wrt. quality assurance... payment handler origin - raises privacy issues... native payment apps don't have origins... browser basic card store, you don't learn that... payment handlers can communicate w/ merchants... if you don't share the information, we are not preventing payment apps anyway.
... That may be doable in any case, it's not that harmful to send payment app origin back... that's a perspective... no conclusion on that.
... open window algorithm is still open... default handler icon.


<Ian> scribe: Ian

Manu's slides

Manu: Why do we need a polyfill? Existing browser market
... if you want consistent experience around payments, polyfill and be useful. Note that details do matter but I am moving quickly for this presentation
... we have implemented both PR API and Payment Handler
... a polyfill is a pure JS implementation. Our goal with the polyfill is to get older browsers to do payments using the next user experience

[list of browsers supported]

Manu: With polyfill we add another 50% of the browser market (not that people are using it, but how many people could have the feature available to them). There are some security concerns we are worried about
... Similar coverage with the payment handler polyfill
... we have worked on passing the test suite
... we think we can get to about 95% but you need native implementation for some of the tests
... the big question we have for the group is this - are implementers (e.g., merchants) waiting for the stuff to be widely deployed in browsers, or could the polyfill be part of your strategy
... that will help us determine whether we continue to work on it.

Jenan: How are you handling canMakePayment? Where are you vaulting PANs?

Manu: The sheet has to be served from a single domain
... that's the scary thing about the polyfill.
... there are ways to mitigate phishing

[Manu demo]

Manu: I install a payment handler. The polyfill site requests consent from the user
... then the payment app stores some data
... then on the merchant site you push the buy button
... the polyfill mediator site shows the sheet
... the merchant doesn't see the data; the mediator site does

IJ: I think that this is very similar to a third party service provider providing a sheet-like experience in a web form
... Is this basically like current practice styled like the sheet?

Jenan: What is the proposal? That merchants include the javascript on their page?

Marcos: Would you take this experience as being as good as a Stripe experience?
... that's what's being asked.

alyver: I am still confused .... you mentioned in the blog that there's a discoverability problem...does the polyfill have to be installed beforehand?

<marcosc> MC: the polyfill is just a progressive enhancement

Manu: Here's how stripe and shopify would have to deploy this today.
... for a fallback experience, you'd either have to build the experience yourself, or install this polyfill...to give them a near native user experience.
... so the result would be a more unified experience across browsers, without having to wait for deployment to get large enough for you to switch over

shift4sms: A big factor for merchant acceptance is how reliable is canMakePayment()

MattSaxon: What's the behavior for browsers that support payment request but don't support payment handler?

Manu: Good question; we don't want the polyfill to stomp on browser implementations.
... and what happens if browser never implements payment handler API?
... and what if polyfill supports a feature but browser does not?
... another issue is that the polyfill cannot detect native apps
... Whatever we do needs to be ok with the browser vendors.

Ken: We see this as going back to the request that MC made; we see polyfill as good for transition and good user experience

mweksler: I want to echo something that Jenan commented on - where does the data get stored?

Manu: Unless we get buy-in from a lot of organizations to share the load......

mweksler: Because you are not storing card info, you won't support prefill, is that right?

Manu: Card information is stored by the payment app.

IJ: What about shipping address?

AdrianHB: What persistence is there cross domain? It only works if every merchant uses the same polyfill library
... this implementation of the payment request doesn't store payment details...you need a payment app for that.

mweksler: I can use the same card on airbnb but not on other merchants (due to cross-origin)

Manu: It is possible for us to add that functionality to the mediator but we don't feel comfortable doing that right now

Jenan: I am still not sure to understand the value proposition to merchants
... is the proposition that with the polyfill you can throw away your traditional payment flow
... if that's the case, I think that is missing the value of payment request
... we would tell merchants today you need to have both PR API and your fallback existing form.
... I don't see any merchant being able to throw away their traditional payment forms
... stripe tries to make it possible to create a traditional form and also have PR API
... where PR API support is nice and has value over traditional flow, otherwise allow user to follow traditional flow
... e.g., I might want to pay with a new card that I don't want to enter in the browser...firefox allows you to not save card in the browser
... I don't think it's a 100% replacement, so I'm not sure what the value of the polyfill is
... over a traditional form.

Summary of Action Items

[NEW] ACTION: AcrianHB to close issue 237 with "will not do; leave to browsers"
[NEW] ACTION: Max to look into getting resources for testing around payment method manifest

Minutes formatted by David Booth's scribe.perl version 1.152 (CVS log)
$Date: 2017/11/21 13:38:54 $