Web Payments Working Group

16-17 Sep 2019


Adrian Hope-Bailie (Coil), Andy Estes (Apple, attending remotely), John Bradley (Yubico), Bryan Luo (Amazon), Ciciley Nelson (TSYS), Fawad Nisar (Discover), Gerhard Oosthuizen (Entersekt), Giulio Andreoli (Apple), Ian Jacobs (W3C), Jalpesh Chitalia (Visa, attending remotely), Jeremy Wagemans (Stripe), Jonathan Vokes (Worldpay), Laszlo Gombos (Samsung), Lawrence Cheng (Barclays), Roy McElmurry (Facebook), Sophie Rainford (American Express), Tony Nadalin (Microsoft), Vishal Mehta (Expedia), Wonsuk Lee (ETRI), Eiji Kitamura (Google), Alex Liu (Airbnb), David Benoit (Reach), Clément Warnier (Canton Consulting), Florent Lambert (Lyra Networks), Frank Hoffman (Klarna), Gildas Le Louarn (Linxo), Heejin Chung (Samsung), Dongwoo Im (Samsung), Krystian Czesak (Shopify), John Fontana (Yubico), Jonathan Grossar (Mastercard), Justin Toupin (Google), Marcos Caceres (Mozilla), Michel Weksler (Airbnb), Rouslan Solomakhin (Google), Nick Telford-Reed, Sahel Sharify (Google), Wanli Yang (Airbnb), Tomasz Blachowitz (Mastercard), Jungkee Song (Microsoft), Vincent Kuntz (SWIFT), Takashi Minamii (JCB), Masateru Mashita (JCB), Sakiko Suzuki (SWIFT), Cheryl Mish (Discover), David Ezell (Conexxus), Yuriy Dybskiy (Puma Browser), Tobie Langel (UnlockOpen), Norie Ozawa (JCB), Jeff Hodges (Google), David Marsh (Australian Payments Network)
Russell Kendall, Danyao Wang

WPWG group photo


Published agenda

Monday, 16 September

  1. Introductions
  2. Meeting Objectives
  3. Payment Request API 1.0 Status Update
  4. Payment Handlers
  5. Card Payment Security Task Force
  6. Payments in Asia
  7. Airbnb PR API Experience
  8. Payment Handlers
  9. Connecting guest checkout with signup

Tuesday, 17 September

  1. Consumer and Merchant pain points
  2. Review of pain point breakout findings
  3. Rechartering
  4. Web Monetization
  5. Web Authentication Update
  6. Handling Payments
  7. Housekeeping
  8. Next meeting



NickTR: Welcome to the meeting! It is your meeting; let Adrian and Ian and me know if you have priorities we are not addressing.
... Meeting proceedings are public (not the case for all organizations).

[Nick show us some IRC command magic]

[Nick reviews the agenda]

Meeting Objectives

NickTR: Here is my opening list of objectives for this meeting:


Remove any blockers to moving Payment Request forward in publication process

Explore enablers for wider engagement of community with Payment Handler

Hear about developments in new payment methods

Agree priorities for future work and re-chartering

Continue to develop our web payment community


NickTR: A big value of these meetings is the conversations that happen outside the room
... these relationships sustain us when we are not all in the same room
... happy memories of reindeer and snowfall and the morning light over the fen.
... if we can walk away Tuesday knowing how we will complete PR API and Payment Method Identifiers, that will be very valuable
... payment handlers is another important topic - but not as broadly implemented as we'd like
... so we need to understand more of what we need to be doing.
... and then for payment methods I'm interested in hearing about SRC, payments in Asia, Web monetization

Payment Request API 1.0 Status Update

[We start with updates from the Chrome Team]

Rouslan: The remaining Chrome issue wrt advancing Payment Request API 1.0 to Proposed Recommendation is actually related to Feature Policy implementation, so we are working with them on it
... we estimate a fix in Chrome 80 (the current version of Chrome is 77)
... thanks to Jinho!

[We see a demo of the new retry functionality]

Rouslan: the demo shows the merchant calling retry with an error message customized by the merchant

[Ian Jacobs then presents slides on PR API 1.0 status]

<AdrianHB> ian: [talk through slides]

<AdrianHB> ... features: identified in 2018, stable since CR (April 2019)

<AdrianHB> ... [ talk through tests]

<AdrianHB> ... some small fixes required to get us to CR for frozen feature set

<AdrianHB> ... proposal to address objection from Sam Weiler (W3C Staff) is to replace boolean request for data with requests for specific details of user data (see the proposal)

<AdrianHB> ... Sam has indicated satisfaction with proposal but it has not been fully implemented in browsers

<AdrianHB> ... and WG has no implementation experience

<Rouslan> We suggest this feature go into 1.1 as we are already implementing 1.0 (i.e., spec version doesn't affect our work as a browser) but it shouldn't hold up having a solid spec (1.0) that has gone to Proposed Rec

<Andy Estes (by email on this topic> My position is that I don't see pull request 873 as blocking Payment Request API 1.0. I believe Apple's comfortable with the privacy characteristics of the existing address APIs, we've been shipping those APIs (or the proprietary variants of them) for years, and we have a merchant install base that is using these APIs in production right now. We must maintain web compatibility with these merchants, so removing the old APIs in a 1.0, or mandating the new ones, would mean that Safari could not properly implement the spec. I’d less severely object to merely adding these APIs to 1.0 as an optional feature because of the lengthy implementation delay it would introduce. Since the existing address redaction rules elide the most sensitive parts of an address, very often revealing no more information than could already be derived from an IP address, I’m comfortable shipping 1.0 as-is. That said, I believe pull request 873 represents a genuine improvement, and would support seeing it introduced in a later spec version, as I tried to articulate in my GitHub comment.

<AdrianHB> ian: people can deploy PR API today. We would like to hear from the group whether you are aware of merchants or other members of the community who are unlikely to adopt PR API unless the spec is a Recommendation.

<AdrianHB> nicktr: my sense is that getting to Recommendation is a confidence signal

<AdrianHB> ian: I think we have heard three proposals for proceeding...

<AdrianHB> (1) Request that PR API 1.0 advance to Rec with no mention of this feature

<AdrianHB> (2) Request that PR API 1.0 advance to Rec with this feature as optional for browsers to implement.

<AdrianHB> (3) Request that PR API 1.0 advance to Rec with this feature as normative for browsers to implement. This option will require extra time.

<mweksler> +1 on finishing 1.0 without the feature and marking it as optional

<AdrianHB> ian: there has been a request to apply this to billing address too

<rouslan> Option 1, please

<AdrianHB> +1 for option 1

<mweksler> +1 on options number 2

<wanli_> +1 for option 2

<estes> I agree marcosc

<estes> I think the WebKit impl of this would not change the Apple Pay payment handler

<AdrianHB> marcos: browser could apply redaction to data even if payment handler provides full address

<AdrianHB> ian: the data is in the payment method data

<AdrianHB> rouslan: it is payment method specific (billing address)

<estes> +1 for option 1

<krystosterone> +1 for option 1

<jv> How long is adding the feature going to delay the spec, months or years?

<AdrianHB> ian: we will still support both features for merchants. Chrome team suggest adding the feature will take 8 months

<Ciciley> Option 2

benoit: I would opt for the option that does not delay the Rec stamp
... I would also like to see this feature for billing address as well
... billing is only needed to facilitate payment

Marcos: Let's break out on this topic!

<tomasz> +1

<Roy_> +1 for option 2

show of hands for option 1: 9

show of hands for option 2: 14

show of hands for option 3 (in v1): 0

Payment Handlers

[Justin Toupin slides on Payment Handler]

Justin: We believe there are multiple benefits to the payment handler approach:

Justin: We continue to invest in the improvement of payment handlers:

[Demo: Payment handler can get updated total from merchant based, on, e.g., changes in billing address]

gerhard: I'm following in the specs. In the payment handler spec is this defined?

Rouslan: The event is part of payment request (paymentmethodchange interface)

AdrianHB: You can see that the paymentMethodChangeEvent only tells you method name and "method details" blob
... the question is whether we want the billing address to be a standard model...that might let us simplify the topic of removing pieces of billing address

[Slide on Just in time install]

Rouslan: We now make just-in-time payment handler installation in more cases.
... so if the merchant accepts payment methods A and B and the user has a payment handler for A, chrome will now show B for just-in-time installation

[Slide on Payment handler event logging]

Rouslan: We have heard payment handler developers say that developing the handler can be confusing, so we have built a tool to help them
... some improvements include more verbose messaging
... we now put messages in the console while testing
... When deployed, those messages can be collected on the server side and analyzed
... what we are seeing on the screen is the ability to see the events fired in the payment handler and see what happens

[Slide on Delegation of requests for contact, shipping to payment handlers]

[Sahel shows a proof of concept; see also the Explainer from Sahel]

Sahel: we think that this will reduce checkout times due to skipping the sheet
... we propose that at registration time, the handler tells the browser what the handler can handle
... if the payment handler can handle a request, we don't show the request in the sheet (and that is true for each type of data: address, contact)

Justin: If the payment handler claims to be able to supply data, the expectation is that the payment handler will do so.

Sahel: Today we are doing partial delegation; another option is "all or nothing". That is: today we allow the payment handler to declare that it can support a subset of data, and we show the remaining members in the sheet for the browser to supply.

AdrianHB: You want to be sure the browser does not give data to the payment handler

Justin: That's correct

Sahel: Today the merchant has said what they want. They don't make any change to their call. It's just who handles it that changes.

Tomasz: These are the payment options. (Our demo does not show billing address)

IJ: Payment handler API does not yet show passing these booleans to the payment handler; that is on our payment handler API edit todo list

Sahel: What Chrome proposes is new API features for changing the shipping address/options
... and notifying the merchant of changes so the merchant can update the total

[More UX improvements in the payment handler implementation in Chrome]

Rouslan: We have heard that people want a more native like user experience
... in our first implementation, the payment handler screen was 70% of the window height
... that static height approach created some problems for payment handlers requiring more space
... so we are experimenting with enabling payment handler UI to expand to the top of the screen

Justin: The use case is payment sheets with long scroll bar...that would trigger automatic expansion in height

AdrianHB: Does this change the spec?

Justin: No. I'd like to hear from payment handler developers

(We count 7-ish payment handler developers in the room)

NickTR: Why are more people not developing payment handlers?? :)

Rouslan: Some payment handler developers want the browser to handle some of the UI (e.g., list credit cards, authenticate the user)
... one thing that we are thinking about is "minimal UI flow"
... in some circumstances, some payment handlers could say "I would like to handle only name, total, account balance"
... in this demo, user just initially sees a prompt to authenticate
... user can pull payment handler window up to see more
... we are thinking about various constraints.
... e.g., during registration there may be some sort of negotiation of when to show the minimal UI
... one other thing is that if this UI is enabled, the payment handler would not be able to show other UX

Justin: We have been exploring the range of complexity of payment handler UX

Gerhard: These are great. One of the ones that we'd been looking for is to flip into a bank app, interact with the bank app, and then flip back

Roiuslan: We have heard that use case. I think we can use that today
... the bank app would alter their payment method manifest a bit
... and if the merchant calls PR API with the information that matches the banking app, then chrome will validate the app, flip into it, and then flip back to the merchant
... this is how Google pay works today in India
... Anders Rundgren has built a demo of this

Ian: For the breakout: how payment handlers specify what they want.

Justin some questions for discussion in the breakouts:

- What do we need to do to make payment handlers successful?

- What needs to be part of the payment handler API?

- What parts of UX are exciting to people?

Ian: Another big topic for breakout session - how to get more payment handler support

Card Payment Security Task Force

[Tomasz Blachowitz slides on SRC]

Ian: We had hoped to have an introduction on SRC from a delegate from EMVco but we couldn't get that sorted out

<benoit> +1 for SRC summary

Ian: but we do have a document that the Web Payment Security Interest Group been working on
... this draft is not currently public so it's still work in progress
... (Pause while everyone reads the introduction to SRC on the screen)
... Any questions on SRC?

[No questions]

Jonathan: I'll show progress since the April discussion and demo.
... in April we illustrated how the EMVCo SRC specifications could be implemented within PR API flows
... to show that the specs are not in competition but that they can be used together.
... in the 5 months since then we have been looking into the details of that integration
... what are the challenges we need to resolve?
... what data model is involved?
... how will identity and authentication work?
... how to identify the user to enable them to access enrolled SRC cards
... how can we leverage Web Authentication?
... or identities from other identity providers
... the goal today is to walk through some user experience flows
... have been working with Jalpesh (Visa) and Tomasz (Mastercard) on the details. The flows are:

  1. New user who is adding a card to SRC
  2. Returning user on the same device; select a previously enrolled card
  3. Returning user but using Web Authentication

<tomasz> More details on SRC, including set of specifications, can be found on the EMVCo website.

Jonathan: As part of displaying enrolled cards for selection, there are use cases for both protected and frictionless access to the list of candidate cards. Once the cards are displayed, the user may may have to authenticate to pay with the card. In the case where the user had to authenticate to get the candidate list of cards, and to authenticate again to pay with the card, that would be two authentications. We want to avoid the user having to do too many authentications

Tony: When you say "Authenticate the transaction" what are you authenticating to?

Jonathan: Authenticating to the issuing bank.
... that could be done in a few ways
... the goal is ultimately for the bank to recognize the cardholder.
... this could be required by PSD2, or simply based on a risk assessment

Tony: You take into account the information provider in the PSD2 situation?
... are you authenticating both the "info provider (AISP)" and the "payment provider (PISP)"?
... I may need some information before I do the payment.

Jonathan: We'll dive in after the demo

[Demo shows mobile checkout]

Jonathan: I am going to buy shoes. I click the "Checkout" button which is the SRC trigger.
... ah, but first some notes:

(1) payment method can be implemented by browser or third party payment handler

(2) This demo leverages Chrome's "skip the sheet" capability

Jonathan: some questions about payment handler ecosystem to discuss
... so in this demo I am a new user (to the SRC system(s))
... so I will enter a new card (in the SRC system)

Jonathan: I am glad Chrome is working on expanding the payment handler window when there's a lot of content!
... in this example, there's a user identity that is an email address
... that data could come from a variety of sources, including typing by the user but also some email known to the browser for this user
... after I enter data in the payment handler I enroll it in the SRC system. This demo is frictionless, but the demo could do 3DS for example

Vishal: This is not exactly frictionless. I have to wait for the customer to add a card to SRC
... the flow seems similar to google pay
... why as a merchant would I opt for SRC when I need the user to add a credit card.
... which might lead to a drop in auth rates

Jonathan: I mean by frictionless that there was no customer authentication.
... in this demo, the user has never enrolled a card. It could be that issuers already enroll a user's cards in SRC systems. That would reduce user typing by having SRC enrollment managed by the issuing banks.
... part of the guest checkout experience in general requires the user to enter some card; but we are hoping for more and more experiences where the user doesn't have to enter info...for completeness I wanted to also show the enrollment path, but the transaction flows are smoother.
... This email is stored by the SRC system to identify a user and cards. So when I change devices, I just have to enter email on a new device.
... but for a new device, I will need to be verified, and those approaches may vary
... e.g., OTP or trusting an identity provider, etc.

jalpesh: I agree with Jonathan's comments. The key point I want to emphasize is that this flow does not come into play unless the merchant says the user has to type in data.

justin_toupin: How do you see this working with other payment handlers? How would this work with an existing wallet?

Rouslan: Another way to ask the question: can you see PayPal, Google Pay, etc. accessing SRC for cards?

Jonathan: Yes

[Demo of returning user; first is with frictionless auth and second is with user interaction]

Jonathan: In this demo, the payment handler queries SRC system(s) using the user identity. If the SRC systems have enrolled cards, they are displayed in the payment handler
... when I select a card, I get information about the card (and the token payload)
... so in this demo the user chooses a card and the token payload is returned through PR API to the merchant
... there was no need to authenticate the user to give access to the cards enrolled in SRC
... and no need in this demo to authenticate the user for this transaction
... as a side note: in a flow like this, 3DS could be invoked behind the scene

Vishal-Expedia: Can the merchant say what information they want.

Ian: In PR API, merchants ask for what they want, and the user experience changes accordingly.

Tomasz: SRC functions similarly

Lawrence: Payment doesn't happen yet when the user pushes "continue"

Jonathan: Correct; auth etc can happen at that stage
... e.g., 3DS or other
... 3DS invocation could happen from within the payment handler if the merchant asks for the payment handler to do it on the merchant's behalf.

Lawrence: How do you see this experience compared to Apple Pay and Google Pay?

Jonathan: That's the next demo
... we do some device auth as part of the payload you submit

Sophie: Thanks, these demos are really helpful !
... the question I have is - how does the handoff happen between PR API and SRC system
... you could also do this without PR API

Jonathan: I am starting with the font end, then Tomasz will show backend work

Giulio: My understanding is that if the user had only one card enrolled (or 2 enrolled but 1 as a default) that you could skip a screen and go straight to the next screen.

Ian: Skip the sheet is a browser implementation optimization; once a payment handler has been launched, it's up to the payment handler to optimize its own experience for the user

Gerhard: In your flows you already say "welcome back Allison"...you could show a default card but allow the user to choose a different card.
... that's just an example of a streamlined flow optimization

(Consensus that payment handlers can optimize the UX)

Giulio: You could also have the option of adding a card in the same way

Joanthan: Agreed
... the real idea here is that when I click the "checkout" button I see my cards (however optimized)

[Demo: Returning user on same device]

Jonathan: Suppose I don't trust the device (e.g., a shared device)
... in previous example, for example, a cookie might have been set after the user has been recognized.
... we can use web authentication to access the card list
... so I pick the payment handler, authenticate with my thumbprint, then I see the list of cards.
... one question is the user experience on a device with multiple web authn identifiers
... we did some demos and it worked with Chrome on Desktop but not on Chrome

@@: When you showed the UI, was the content bound to the signature that FIDO gave?

Jonathan: The WebAuthn here is to get access to card metadata.
... for that I need an identity that I can use with different SRC systems
... there is an assumption that the user had already enrolled previously (with FIDO keys)
... so that key is bound to the card list

[Discussion of how this works]

JeffHodges: This is not yet specified but could occur as follows: the SRC system would say "the user is not authenticated; you're asking me to return info about a card but I don't yet know the user"
... there was no ambient authentication passed in.
... so if the SRC system wants to authenticate the user, it would make a request to the device, and that's where WebAuthentication would occur
... how WebAuthn is woven into SRC needs to be part of the SRC spec (If I am correct)

Jalpesh: I didn't quite follow that. But I agree with Jonathan's perspective. We are saying the relying party is the payment handler. The payment handler in turn talks to the SRC system.

Tony: The registration would have to happen to the SRC system at some point. The SRC system would then have the public key of the client. It would be up to the SRC system to look up the key to find out what key ids are related and then those are displayed accordingly.

[We touch on the delegation of Web Authentication to TLD+1...a topic for tomorrow]

Rouslan: It's possible that SRC will invoke the authentication. But it's also possible that the payment handler does the WebAuthn and the backend trusts the payment handler.

Jonathan: SRC system may decide to trust some payment handlers who do Web Authn for access to cards
... I agree there are two approaches: SRC does the authentication (for access to cards) or SRC trusts payment handler who does the authentication.
... again here we are discussing access to card list, not cardholder authentication

jezza: I want to clarify something around authentication. In the demo, the user authenticated with the SRC system. If my user is in Europe and the transaction is not exempted for SCA, then the user will need to re-authenticate with the issuer.
... so now we are in the scenario where the user has to authenticate twice

Jonathan: Before trying to answer this question, let me show you another flow
... if we assume that I am a recognized user on a device and I can access the cards, and we merge the two together. ...
... when I select a card, because of PSD2 regulation or a risk decision, I may have to authenticate the consumer.
... it could be the merchant invoking 3DS or the merchant could delegate to the payment handler
... the payment handler could invoke 3DS or the payment handler could authenticate with WebAuthn.....
... that means previously you had an enrollment for that card, where the user then authenticates the user with normal SCA
... it is possible for the first Web Authentication (to access the card list) could be reused as input to a 3DS process (once the user has chosen to pay with a given card).
... the strong signal would then reduce the odds of a subsequent step-up.

IJ: So the payment handler reuses the blob from the first Web Authentication as input to the subsequent 3DS flow initiated by the payment handler

Lawrence: What's in the payment method payload?

Jonathan: Can include token and cryptogram.
... that is then used by the merchant or PSP for authorization

Lawrence: If the payload contains the token which is uniquely identified to the consumer, would the issuing bank have to do the SCA?

Jonathan: That's separate from the token. We are talking about authentication for the transaction. There are multiple options including merchant calling 3DS once they have the payload.
... or if it's the payment handler who has been doing this on the merchant's behalf.
... The issuer is always responsible for the SCA, but the issuer may delegate this function. The issuer may also (based on WebAuthn data) make a choice not to do SCA. That would still be compliant with SCA either through delegation or step-up if needed.

Nick: Agreed: the issuer is definitely responsible for the SCA. But that doesn't mean that they actually have to perform the task.

Tomasz: The SRC-I role is the actor that invokes payment request on behalf of the merchant. (The merchant could also be the SRC-I). The SRC-I receives the credentials.
... the SRC-I can only receive displayable data (which merchant can display to the user)
... the merchant's PSP could receive the part of the data that is just for payments

[Tomasz shows data model from the DRAFT SRC Payment method]

<jeffh> thx

Tomasz: Note that we have some redundancy between booleans in PR API to request some data and the draft SRC payment method; we need to look into simplifying that

<AdrianHB> [tomasz talking through slides]

<Ian> Our goal is to define a datamodel for SRC and PR API that is common between networks

<Ian> ... next question will be whether or not we take this up as WG deliverable

<Ian> ... so next question is, can you make a tx using the data model?

<Tomasz> Not yet

tomasz: More work needed to complete the data model

Jonathan: If we want the data model to be totally complete, the question is who works on that, and how do we ensure it works with EMVCo.

Jonathan: So we probably need to invite EMVCo so send more people to the task force

nicktr: The proposal as it stands assumes that the person building the PR API call is the SRC-I
... or that they are downstream from the SRC-I....but I'm not sure that's the correct assumption.
... that prevents the payment handler from being the SRC-I.
... there are some things that look like payment handlers today that are aware of the identity of the merchant
... the note I would give at this stage: I'm not sure we want to assume the SRC-I is on the side of the payment requestor.

Jalpesh: There is no reason a company like Stripe couldn't be both the payment handler and the SRC-I
... payment handler / DCF plays role on behalf of consumer; SRC-I represents merchant (whether merchant or PSP)
... we don't have to call it the SRC-I in the w3c spec. Any developer can call PR API. In EMVCo terms that's called the SRC-I.

Tomasz: I think it's probably important to discuss.
... if SRC-I does invoke PR API, the SRC-I can provide this information.

marcosc: Please avoid "Object" in WebIDL due to security issues

Tomasz: Here's why we defined them as Object today - it's due to the EMVCo spec. We don't have specific typed objects in the SRC spec.

<Ian> In terms of user experience considerations, we want to ensure there is no gap in flow for users that have cards. A user with a card should have some payment handler available that either lets them select from among previously enrolled cards or add cards. We have talked about "browser default payment handlers" for payment methods (SRC or other).

<Ian> ... another UX topic: can we show individual cards in payment sheet?

<Ian> ... another topic we need to explore is user identity management (for logging into the SRC system)

<AdrianHB> ... where does it come from, who vouches for it

AdrianHB: We have something of an entity modeling challenge.
... when we first designed this architecture, we had the concept of a payment handler which is executable code distributed by a publisher. And inside of that there are instruments.
... but it doesn't map well to SRC...there is more required in SRC on identity
... I think we can generalize some of the things that SRC is showing us

Rouslan: Chrome Team would like to see some SRC experience in the market that is working end-to-end
... that will enable us to think more about how the browser can optimize the user experience.
... Yes, we should continue SRC work.

Gerhard: We are wondering (as reps of banks) how to add ourselves to the ecosystem. I have an option of being a payment handler.
... the card issuer wants to do authenticate the cardholder
... is there a way in which the payment handler can hand off to the issuer for the authentication.
... I think something's possible
... so the question is whether there can be delegation
... we need to be clear about what the issuers need to do, otherwise the issuers are going to try to do too much, and confusion will prevent adoption

NickTR: Have any schemes published SRC implementations or a timetable for such?

Jalpesh: Visa publicly announced that we will migrate our acceptance and our experiences into SRC. We haven't quite published a timetable.
... when available the systems will be available for testing by various parties in the ecosystem (including folks here)

Jonathan: We made similar announcements.
... launch is imminent

Tomasz: I agree we should continue; but also have more work on "how"

PROPOSED: The card payment task force should continue to work on an SRC payment method and its integration into the PR API ecosystem.

<AdrianHB> +1

<michelweksler> +1

<Sophie> +1

<rouslan> +1

<Fawad_> +1

<benoit> +1

<krystosterone> +1

<bryanluo> +1

<Dongwoo> +1

<jezza> +1

<Gerhard> +1

<jv> +1

<nicktr> +1

<dave2037> +1

<Ciciley> +1

<wanli_> +1

<heejin> +1

<jonathan> +1

<Roy> +0

<justin_toupin> +0

<frank> +0

<agektmr> +0

Payments in Asia

<AdrianHB> [Takashi Minamii slides on QR code payments in Japan]

<NickTR> Is the new QR standard in Japan aligned with EMV work on QR codes?

<Takashi> No

<AdrianHB> Can QR code be used for online payments?

<Masateru> No, it is focused on in-person

<Lawrence> [question about UX, missed detail]

<Masateru> UX is not as good as card but better than cash

<Lawrence> What is the motivation to switch?

<Masateru> The merchant is motivated and so offers cash-back to incentivise consumers

<AdrianHB> motivation from government is "anything but cash" so cash-back incentives are high

<David Benoit> Compared to AliPay, this seems like astatic data generated by the customer. What prevents me from stealing the code and using it somewhere?

<Masateru> Security is dealt with by providers, I'm not familiar with the details. It's not possible to reuse the barcode

<Gerhard> This looks like tokenization. Why not use the EMVCo standard?

<Masateru> I'm not familiar with the design discussions.

<Gerhard> I see the benefit of the form-preserving token but does it require merchants to add cameras to the terminal?

<Masateru> The majority of terminals already had the camera

<Gerhard> Which is more common, merchant presented vs consumer presented?

<Masateru> Providers all support both. The choice is driven by cost.

[Presentation by Sakiko Suzuki on payments in Asia]

Sakiko: Market affected by (1) various instant payment initiatives in Europe and (2) new payment methods from China

[Background on SWIFT]

Sakiko: SWIFT covers over 200 countries and multiple currencies.
... drivers of change: volumes, e-commerce, real-time, regulation, open banking
... volume is doubling each year
... in Europe we provide instant payments across multiple countries for cross-border payments
... in Australia we do so for all sorts of payments including P2P and B2B
... SWIFT is focusing on cross-border payments; regulation is really important
... there are issues like AML
... APIs help foster development
... we have three focus areas: modeling, publishing, consumption
... GPI is a new system to provide instant payments

Sakiko: We are trying to connect additional networks as well since we cannot provide all solutions ourselves
... "NPP" (New Payment Platform) in Australia
... started in January 2018
... distributed architecture.
... allows Australian banks to do real-time clearing and settlement
... distributed model ensures continuity of payment services
... before NPP, Australian could not do real-time, 24/7
... based on ISO20022
... 1400 data fields available
... 24/7 real-time
... PayID or BSB and account number;
... we provide an API sandbox to facilitate development
... after 1 year, NPP has 75 Members connected to the network; $75 Billion worth of transactions
... any type of payment can be supported by the network
... GPI has been around for 3 years
... next year, all SWIFT Members will be on this network.
... 98% of transactions settled in 1 day; 40% in less than 5 minutes
... most of the advanced banks can settle in 10-20 seconds
... GPI instant: 20 seconds end to end on average; maximum 60 seconds

[Trial participants include NAB, ANZ, ICBC, Bank of China, Bangkok Bank, DBS, UOB, Standard Chartered[

AdrianHB: If we push for real-time push payments, is the end goal retail?

Sakiko: I think it's possible. SWIFT can provide account-to-account transfer

[Demo of GPI with PR API]

Vkuntz: With PR API, merchant can ask the bank to track a payment and let the merchant know if it has not been received within 60 seconds.

[Demo shows a gpi-tracked payment method]

Vkuntz: the user selects an account from which to make the payment
... selecting "confirm" causes payment information to be sent to the bank.
... the merchant gets back a tracking ID
... then we can simulate the bank initiating the transfer
... then the payment method enables the merchant to know that the payment has been initiated.
... so the payment handler has closed, and the merchant can monitor the status of the payment.
... the payment response includes an identifier for the transaction in the GPI system

IJ: What about authentication?

vkuntz: Authentication is in g-link
... so we have it but have not applied it.

AdrianHB: What data is sent to the payment handler? How does the merchant identify itself?

vkuntz: There's merchant account identifier.
... it's globally unique

Airbnb PR API Experience

Alex Liu presents slides from Airbnb

mweksler: Some points to think about as we go through the presentation:

Alex: Lots of slides but I will go quickly
... Airbnb has a number of top-level businesses all of which leverage an underlying "Airbnb platform."
... one functionality within that platform is payments
... Airbnb has about 200 people working on payments
... we operate in lots of countries and accept a lot of currencies.
... we go through multiple PSPs for redundancy
... we have our own coupons, credit plans


Alex: We wanted to redesign the Web experience; lots of people start from Web (not native)
... wanted a streamlined first time booking experience
... and thought we could use PR API to collect information.
... we have a signup wall and thought we could use PR API to streamline that process.
... we also wanted to use PR API to be able to support more payment methods
... e.g., access to Apple Pay and Google Pay
... so PR API gave us access to more payment methods.
... in Brazil we have to collect a lot more information ...
... the longer HTML forms for data collection can lead to drop-off
... with PR API we don't have to manage all the form fields, and resizing and display
... we also thought we could speed up checkout for use cases where users already had *Pay setups


Alex: We integrated it with desktop web via moweb.

[We see a demo using basic card, and a demo using google pay]

Alex: We saw a lot of benefits - no complex forms, use existing wallets, access to more payment methods, no custom billing form, buit-in infrastructure
... For us, we liked the standard API because it was easy to swap in, and have it work across browsers


Jonathan: Are you using PR API all the time, or just first time user?

mweksler: PR API remains an option, but previously used cards are available in subsequent checkouts (card on file)

Alex: If you start adding card-on-file, once you have a mix of instruments (card-on-file, card-in-browser, google pay) that can be confusing to the user
... Biggest pain point around the use of PR API is the lack of official payment handlers.
... e.g., no PayPal
... even for the ones that are there (e.g., Google Pay), they are only available through some (but not all) browsers
... You should be able to see all the payment methods on all the browsers
... Second point is consistency across browsers. Suppose we use Chrome basic card implementation...experience on mobile not same as experience on desktop

IJ: Would label customizations in the sheet help?

Alex: Yes, that could help
... so we'd like to see (1) more official payment handlers (2) support across browsers (2) configuration of form fields / labels
... that is, customization
... even if the browser does not allow customization, make it possible for us to know the strings that would have been rendered and we can match them
... Second challenge was stored instruments
... if the user has some cards on file with Airbnb but also cards in browser and so they get a difference experience
... not obvious to users how to find most up-to-date card information
... so might be nice to integrate on-platform instruments into the sheet.
... Another topic is "tokenization". If we were to implement PR API, on the back end (e.g., Stripe, Braintree) the backend integrations are different

IJ: Do you want a standardized API on the backend or a standardized payload?

mweksler: For a merchant would be great to have a standardized token shape, but PSPs may not want that level of interoperability

nicktr: I think this is a live debate within payment providers whether to have tokens that can be moved among payment platforms.
... there is nothing in the ecosystem today that prevents transportable tokens from being built.
... you can use EMVCo tokens today
... but the tokenized card payment method could support that
... I think that if there were 20 large merchants who wanted EMVCo tokens, there might be product managers willing to make a business case in their org.

benoit: Regarding universal tokens - I would personally love that
... whenever anything changes in the payment chain, you need to gain new authorization from the cardholder (this is a compliance issue
... so seamless backend swapping is technically not allowed)

IJ: But at least you could get rid of some technical friction

mweksler: There are multiple ways that we could comply (including user agreement up front)

NickTR: The question is "who is the token requestor"...if the token requestor were the merchant (bound to the merchant) then do-able

mweksler: What we are after is slightly more nuanced - we don't want merchants to have to bear the burden associated with being token requestor. We want the PSPs to do the heavy lifting, and then we want to be able to use the tokens wherever we want.

Tony: Delegation is tricky (e.g., key exchange)
... so more tricky than just user consent

AdrianHB: That's probably why our efforts at a tokenized card payment method didn't progress.

rouslan: You expressed a sentiment that if more payment handlers on more platforms that would be great; I completely agree
... so the question is: what does Chrome need to do for people to start using payment handler API

mweksler: Lack of payment handler implementations I think is a big challenge; merchants need to treat it as "yet another payment method" instead of the "single payment method API"
... another topic is the user experience when there is both card-on-file and card-in-browser
... some sort of merging of the two worlds would be helpful
... I refer to this as "on boarding existing users to PR API"

AdrianHB: The second topic is interesting

mweksler: Every large merchant would have to write the same payment handler, which suggests it is a possibility for standardization
... we don't store the cards (people do that for us)
... we'd like to merge them into PR API


- integration with airbnb systems

- customization

- ease

Regarding integration: it works really well today when replacing a single payment method.

Alex: e.g., PR API with just Apple Pay or just GooglePay

Regarding ux consistency:

- imagine large merchants adopting this - you'd have consistency across sites and that would build trust

- great for device-specific payment methods


- not consistent with other Airbnb pages

Alex: different branding for example
... also the ux is different across browsers (since different platforms)

Regarding customization:

- would be great to be able to customized display sections, and get label consistency

Payment Handlers

Justin: What should we be investing in to get more payment handler adoption?

Roy_: One thing that would be helpful is to know the ecosystem of adoption of PR API

Justin: The volume in terms of transactions is growing

mweksler: I think you should encourage people internally that the more info can be shared the more adoption is likely to increase

Jeff Jaffe: I'd like to understand more why the information about adoption is proprietary, or whether we can have some conversations about stripping the proprietary information
... even reducing to a single figure of merit (e.g., growing x% per year)

jv: EMV manages to publish annual maps about card adoption
... they anonymize data

AdrianHB: So each vendor could provide data to W3C and W3C could anonymize the consolidated data

<scribe> ACTION: Justin to check internally at Google about what can be shared

<trackbot> Created ACTION-128 - Check internally at google about what can be shared [on Justin Toupin - due 2019-09-23].

vishal: I think from a decision perspective good to know (1) has there been an increase in number of merchants adopting it?
... so doesn't need to be user numbers, can be merchant numbers.
... regarding intro - we have examples in the payments industry about branding Payment Request

<Ian> ian: We studied PR API branding and found there was little support because the observation was that PR API is not a payment method. Users recognize payment method brands and want to interact with those; there does not seem to be appetite for a new visual identity for the user experience that is built into the browser.

Vishal: I'd like to see a credit card logo without specific brands, to indicate triggering PR API
... PR API is a payment method from an end-user perspective

AdrianHB: I think the goal is that users don't think of it as a payment method...ideally we should figure out a way to make the experience fit into the current branding requirements of some of the big payment methods
... e.g., Apple requires an Apple Logo
... we have an unsolved problem about exposing the supported payment methods of the user and exposing them as actionnable buttons on the page

Rouslan: What is the biggest obstacle to people writing a payment handler today?
... this will help us focus our energy

<benoit> Issue 870 about location rules is one for me, but likely not for many others

bryanluo: Two things come to mind for us. The first question I will be asked is "What's the business value for doing a payment handler?"
... it's not exactly clear at this point. The second topic is more technical, but a couple of things come to mind:
... flexibility and extensibility within the API. As a payment handler there will always be edge cases
... PSP integration is a big part of the payment handler business model...where does it fit in?
... industry is moving away from iframe....does this PH approach create another isolated thing

Rouslan: Thanks for this information!
... Payment handler is a top-level window, so it does not suffer from cookie restrictions on iframes

bryanluo: So it's like a popup that has a special UI?

Rouslan: Yes

AdrianHB: Regarding data model -the payment method owner owns the data model

Bryanluo: Ah, so there is already an open channel between merchant and payment handler

AdrianHB: Yes
... also note that OAuth experience in the PH modal happens without losing the merchant context

Gerhard: If I get to the checkout page and PR API is the third option, I am likely to pick the first 2, so instrument-level display would be helpful
... It could also be useful for merchants to load payment tokens in

<AdrianHB> ian: we do have a long standing request for "instrument level display" on the page

<Zakim> Ian, you wanted to ask Google for blog post on handler benefits

<scribe> ACTION: Ian to work with Justin and Google on writing up payment handler benefits

Justin: Our thesis is that PH API can improve conversion rates; that's a key data point; we'd like to partner with people to get that data.

Jeff Jaffe: The question at the beginning was how to get more payment handler adoption. Lots of good pieces "bottom-up"
... but a different approach is to ask which payment handlers we most need.

<AdrianHB> ian: My observation is that chrome took that approach and picked the industry leader and continue to work with them. The one blocker is that the potential payment handler will only move forward with more browser support (specifically Safari)

mweksler: For Airbnb, definitely PayPal would be great
... I think two that are not as big but also strategic are Alipay and WeChat

Rouslan: Are you talking about China market or international market?

mweksler: Primary market would be China. When you look at their online payment methods, the most popular ones are the mobile ones that redirect to their app
... it's not an easy payment handler, but it's interesting

AdrianHB: That integration already exists on some platforms (e.g., Android)

Rouslan: Side-loading apps would not be good for security reasons
... Alipay did demos about integration with Chrome on Android
... signature verification does not happen with legacy redirect

mweksler: If you have a payment handler provided by Alipay you may not need to redirect

Vishal-Expedia: We have been talking about 3DS 2.0. Entering the OTP is in the payments page, which is great.
... seeing that flow compared to PR API overlay, its kind of clunky to have an overlay compared to in-page display
... choosing of the payment method in the page would be nice
... I don't see many merchants in this meeting; need more exposure to merchants

IJ: Who besides MAG?

Vishsal: MRC

<AdrianHB> ian: we work with MAG (who are meeting this week so can't be here). Any suggestions for others are appreciated?

Vishsal: we have a meeting in January in Singapore

Jeff Jaffe: If I were running this as a business, I would figure out how the WG should go after each opportunity. PayPal conversations are underway.
... for Alipay, the head of standards of Alibaba is here this week
... it would be good to build a story for Alipay
... WeChat is Tencent, also a W3C member
... as far as Merchant outreach, having a meetup between MAG executive council and the WPWG might be a more effective way to drive adoption

Rouslan: Question for browser vendors - should some implementation features of Chrome be "standardized" (even if not in spec):

- Just-in-time installation

- Skip the sheet

See details on JIT installation and skip-the-sheet

Rouslan: These are user experiences and we've tried to not standardize them as a result
... my feeling for skip-the-sheet is that should not be normative in the spec, but could be mentioned as an informative note

marcos: Agree that generally we would not put something like this in the spec

jv: But having same experience across browsers would help adoption

Marcos: Putting this into the spec may not help; browsers will do the right thing in order to provide the right UX

Rouslan: We have documented the conditions where Chrome skips the sheet

AdrianHB: Any changes we need to make to the spec to make it easier to implement as a browser?

Marcos: Architecturally we need to do a bunch of things to support the spec.
... so don't want the spec to go too far ahead, but also like the adoption experience so looking for a balance

mweksler: I wanted to add a comment to the skip-the-sheet discussion
... I think there are other cases beyond "just one payment handler"
... for example, configuration to allow me to use same payment handler always on same site
... that info could be stored either by the browser or the site
... e.g., Airbnb could store the preference and tell the browser to skip the sheet and which payment handler to use

AdrianHB: I think that full delegation is an important piece of this - that the handler can handle shipping address

Sahel: In the demo we did today, if payment handler supports delegation, we do skip UI

Justin: We showed the minimal UI flow

<AdrianHB> ian: this is getting close to previous Mozilla comments on UI risks

<AdrianHB> marcos: there is a lot of UX work around permissions and constraints

nicktr: The "minimal UI" is a special case of the special case
... if I were a Payment Method owner that was struggling to get traction across a huge installed base,
... you could offer slick 1-click experiences because you'd know, even with guest checkout, that the consumer has a primed payment handler
... this seems like a great thing
... have you done work with minimal UI on desktop?

Justin: No not yet

michelweksler: I like the minimal UI. I am wondering if we can go even further.
... is there a way for the user to say I authorize micropayments up to a certain amount?
... could be less intrusive

Gerhard: I have these use cases:

1) The "no user auth" use case. We've already established credibility within a bank context. You flip into it and you flip out

2) FIDO. I the FIDO credential is in another domain, you could flip into it, do biometric, and flip back

3) Bank has an issuer wallet (there is a token + cryptogram in the native app)...needs to retrieve the cryptogram from the app

4) External device authentication (eg., browsing on desktop, authenticate via phone)

5) In south africa we've hooked up with mobile operators to use USSD. Text-based interface; phone wakes up; you type in a number to grant consent
... we do some sim-card protection
... it works on feature phones

AdrianHB: I want the minimal UI to be more minimal
... for Web monetization, the use case is that I enroll up front
... I have a concept of a balance..and an agent in my browser making decisions about when to pay and how much
... our idea is that payment handlers are invoked, but the payment handler is not interactive

<Ian> The payment sheet + basic-card is a variant of a minimal UI in some sense

<Ian> ... i.e. the sheet provides UI to the payment handler

<Rouslan> That's not how we have done it now

<Rouslan> ... we want to support push payments which will have a financial impact each time they are invoked

<Ian> It feels like you're doing the same thing so you could move the browser local basic-card payment handler into a "minimal UX payment handler"

<Tomasz> I like the idea of making the "basic-card" handler behave more like other handlers

Alex: I want to add onto that. Maybe comes back to the question as well for the merchant who has cards on file
... if we could shove instruments into the sheet, that's a powerful use case for us.

AdrianHB: If we just enhanced basic card so that if you passed in a list of things on file, and if the user picks one, the response data is an index back to the card that the merchant provided

Alex: Passing in reference is interesting

AdrianHB: I think we want to move away from using basic card. I wonder if there's a way to move an instrument into a more secure version.

Tomasz: Airbnb could have its own headless payment handler that registers instruments with the browser.

Connecting guest checkout with signup

<Mweksler> Can we unify the guest checkout + website sign-up?

UNKNOWN_SPEAKER: can we tie it together with authentication?
... info about user, information about credentials, what's needed to use them in the future

NickTR: There is a trusted site concept in PSD2 flows

mweksler: I am thinking more about unifying the flow of identifying yourself with the payment step and future login step
... maybe merchant says "I also want to create an account for the user"

AdrianHB: I hear two use cases:

- Sign up and consent to my profile being used for payment later

- When making a payment agree to terms of service as well

agektmr: I think it's interesting to add a password option so user can create account with new password easily
... important to make clear to user the info is being used for signup

AdrianHB: Right now PR API allows merchant to request email. The merchant should be able to tell the browser to tell the user that data will be used to create an account as well
... that is, make it easier to create an account as part of checkout

Tony: In a PSD2 situation, I may want to go to the information provider to get that information

AdrianHB: Question is whether we can enhance API to support authentication and later log-in

Rouslan: Can you tell me what you would do instead of a password? FIDO? Or OAuth into google or facebook? Or password generation?

mweksler: We have building blocks to not do passwords. We could use OAuth or WebAuthn or other
... what I'm seeing is an opportunity to tie things together

Alex: You could delay password creation to later

Mweksler: There's an opportunity to get rid of passwords and use WebAuthn

Rouslan: So I'm imagining that in the sheet has an action button that says "Pay and Create Account"

mweksler: Need also to be able to provide access to terms of service agreed to for sign-up
... in short: let's do all things at once rather than serially

Rouslan: If we build this, will you start using this?

mweksler: This is one of the things that the team that evaluated PR API were looking at as a key benefit
... if they had had this feature they would have used it

Alex: One of the biggest priorities is the guest checkout experience
... The high priority is getting the payment and signup done
... once the user has paid and has an active reservation, it's easier to ask the user to provide data
... but if you have to get all the data in advance, it's less likely the user will complete the reservation

Giulio: With Apple Pay we are big fans of guest checkout
... we have several implementations that can accomplish this goal.
... get the payment and then use the info to create an account
... the big question is what's the data: password? birthday?
... there are several examples of this sort of thing being done
... we have some examples where at end of payment a "silent account" was created without a password
... but we've moved away from that.
... for a while the approach was to add a password after the payment. ... but now we are moving toward "sign in with apple"

Marcos: For Airbnb you may need to send passport photo.
... at some point we are going to end up at just another browser tab
... I am concerned that payment handlers become too heavy....we have APIs to achieve some of these things already
... do we just need an overlay browser context for payment handlers?
... we want to be able to do logins on the Web....I think we all want to solve that problem

NickTR: Dinner at 7pm. Thanks everyone for concentration today!

We adjourned until Tuesday.

Consumer and Merchant pain points

[Slides from Ian and Lawrence on pain points]

Ian: Our first session this morning comes after a suggestion from Lawrence Cheng who wanted us to ground our work in real-world pain points.
... We have collated information about both consumer and merchant painpoints
... Later we will run some mini-breakouts to evaluate the importance and difficulty of addressing some of these pain points.

[Slide - painpoints at checkout]

Ian: I put this slide on painpoints a checkout first since it is most closely related to Payment Request API. As you can see, I think we are doing a good job at addressing many of these points

Lawrence: I am sure we can add to these. We should look at these with a "pinch of salt"
... and what is the wider context
... and does payment request address these?

Ian: Would be great to collate more point points from the group (invites colleagues to contribute via IRC)

Vincent: shipping options/addresses for smaller countries are often not well provided for

[Slide - trust, security and privacy]

Ian: We may not be able to do so much on these topics in this group, although some work in other groups could help (e.g., related to trust, privacy).

vkuntz: the bigger online sellers are not present in Belgium (for example) and do not ship there
... but often the consumer doesn't know about this until the end of checkout. Another pain point to consider: shipping location not indicated upfront - shipping actually not possible to a specific country

rouslan: vkuntz's use case is very interesting
... I would probably start by geo-locating the IP address of the consumer and display a warning

ciciley: what does best practice look like with payment request?

Ian: we have some developer documentation but happy to add that to the list

<AdrianHB> [group takes moment to pat itself on the back]

ian: next we look at merchant painpoints

[back to slides - payments and checkout]

ian: redirection to hosted payment page is called out as poor user experience

vishal-expedia: how does Payment Request deal with the hosted payment page challenge?

ian: payment handlers solve for this. User doesn't lose the merchant context

Vishal-Expedia: what about 3DS 2.x?

ian: the security task force is looking at this - in short it's tackled by the improved experience of handler

rouslan: payment handler is treated like a full page redirect but appears as an overlay

Ciciley: the other pain point is that stronger authentication negatively affects approval rates
... most merchants are frustrated about why transactions are being declined (cards)

jonathan: the point of 3DS2 is to provide better scores to the issuer but this information may not be known to the merchant
... so the expectation is that approval rates should improve

benoit: Login while traveling a pain point. I think Ian's attempt at a demo (but that rendered in Japanese) showed a good pain point - localisation which might not be appropriate
... but also if the issuer doesn't step up the authentication and then declines the subsequent transaction then that really sucks

ian: on trust/security, payment handler attempts to reduce the complexity/cost of providing more secure experiences

lawrence: on security, I think the key is "that work for customers"
... also would be good to talk about firendly fraud

Ciciley: Lawrence, I was queued up to talk about friendly fraud.
... I think it's appropriate for this group to figure out during auth to figure out it's the "parent not the child"
... where issuer thinks parent authorized a transaction, then the bank is liable and they'd like to reduce that
... too many Fortnite purchases.
... that's another step in the right direction....ensuring the right person is authorizing the transaction.

<html5cat> What is "friendly fraud"?

NickTR: People would be shocked at the size of the friendly fraud problem, e.g., on the order or 40%
... or "buyer regret"
... Many children can unlock their parents' phones
... I think it's something that would be hard for us to tackle.
... I note also that some payment mechanisms (non-card) do not include chargeback mechanisms

Jonathan: I think the use of WebAuthn and biometrics helps a lot
... the problem we have with device biometrics is that there is no way to link to a specific individual
... if there were a way for a given transaction to have more specific authentication, that could be interesting

<benoit> unlocking a device and authenticating payment should be different things

lawrence: if we could crack some of these points, then we could give ourselves a real leg-up in getting merchant adoption
... so the question is do we see any unique selling points ("USPs") in payment request

ian: for our webauthn colleagues in the room, are you looking at this issue of more personalised ID?

John Bradley: it's something we've looked at - many platforms are missing the ability

<Ian> (IJ hears: "segmenting biometric templates" raises usability issues)

John Bradley: we may end up with a system that is too complex for consumers to use

xxxx: it's the individualistic biometrics that are difficult

John Bradley: you could have separate hardware tokens for different users. Once you have multiple templates on a single device, it gets very difficult to understand and it's difficult to design biometric systems which are not defeatable

vishal: it's not just kids - also criminals forcing users to biometrically authenticate

<Ian> Vishal: Netflix does this well - ok to have friction to set up new profile

<Ian> ...they ensure there's a kids profile

<Ian> Jonathan: You can have different profiles, but the same biometrics can access the profiles

<Ian> John Bradley: On newest Android, and where not blocked by carriers, templates are available

<Ian> benoit: Multiple profiles on the phone is a good concept but agree with usability challenge

<Ian> ...I think the real solution to this (but not necessarily for this WG)....I could set up a flag on a biometric "this fingerprint cannot be used to authorized payments"

<Ian> dezell: Some pain points for us at Conexxus (for physical world payments): EMV at the pump; second generation EMV. +1 for better granularity of control of permissions granted to specific biometrics (but consumers are unlikely to set up). SRC seems ok but Conexxus members still waiting to see how works with PR API

<jonathan> +1 for better granularity as well

<Ian> dezell: Anticipate more remote payments (e.g., barcode based payments). Merchants need more consumer data; but GPDR and and California rules make it challenging

ian: back to the slides
... integration is complex - we heard yesterday from AirBnB that it would be great to do more (like sign up) with PR

[rules and regulations]

ian: we have a lot of items on our backlog for shipping
... but we have not looked (to date) at a lot of new features because the consensus was to finish v1 first
... let's organise into 4 groups and prioritise this list of 16 pain points

html5cat: at Puma browser, we would like to see if our browser could be helpful for some of these painpoints - we are not bound by the incumbent user bases of the big browsers. We can innovate quickly.

<rouslan> +1

[Breakouts on pain points]

Review of pain point breakout findings

We listed the following pain points for discussion:

<Ian> Images of importance/difficulty discussions

Adrian's group

AdrianHB: We thought everything was important
... a common theme was that a lot of pain points could be addressed through more widespread use of payment handlers

Ian's group

Lawrence's group

Lawrence: For global players, simplifying cross-border important and difficult
... for local merchants that do export today, there are not a lot of options for them to do cross-border payments and it can be expensive
... at the same time, we have situation with wallet players for cross-border payments....the volumes are quite low (e.g., Chinese tourists using Apple Pay today)
... the other one I want to point out is "optimal speed for checkout"...not too fast/too slow
... for new-to-merchant consumers we thought it was important but somewhat difficult
... but for returning customers, as important but not as difficult

Ian: We also talked about not too fast/not too slow

Lawrence: We observed our goal ultimately is imperative conversion and reduce chargebacks.
... to be able to tick the box that we have succeeded we need to be able to show scale

Nick's group

Rouslan: We had some challenge figuring out who this was related to (difficult for whom? important to whom?)
... maybe privacy would be super important to users if more was communicated to them.
... on the other hand, in terms of difficulty, some things may be difficult for PSPs today, but some things might be shifted to UAs through web payments
... our process was first to figure out what was important, then we assigned difficulty

Ian: We did that as well.

Rouslan: We had some confusion around "account-free checkout"
... who is the account with?
... I think the most difficult things to figure out are things that are product challenges (moreso than engineering challenges)
... so reduce auth friction and speed up checkout...those are great...it requires a lot of experimentation and user studies to do this well
... so it's actually quite challenging to do in practice

Ian: Next steps - four of us synthesize and report back


[Ian's slides on Rechartering]

<Zakim> vkuntz_, you wanted to note that Credit Transfers will probably become more relevant with PSD2 in Europe

<nicktr> Lawrence: can we have a table showing the possible and actual combinations of browsers and payment methods?

<nicktr> Rouslan: Chrome's position is to support as many options as possible

<nicktr> ...so we'd like to see no tie-in between handler and browser

<nicktr> ...though that isn't the current reality

rouslan: Payment handlers can help localize the user experience; there's now way that a browser is going to adapt to all the local requirements
... so payment handlers are the future. Basic card isn't really implemented anywhere but Chrome. We can probably stop actively working on Basic Card.

marcosc: We think that basic card is "worth it" but it's challenging to do well; we had about 10 people working on it
... if anyone out there wants to be the Basic Card provider for Firefox, contact me!
... I agree that having multiple payment handlers would be ideal
... Firefox would need resources to do and maintain Basic Card.

Gerhard: I think Basic Card is useful.
... regarding SRC subsuming 3DS and tokenization
... all three of them are "optional" and "interoperable" but need not be used all together
... it's important for me and I think the industry that with PR API that the flexibility be maintained
... I agree that the 3 together would be a beautiful symphony, but don't assume merchants will demand to use all three of them.

Jungkee: I agree with how Ian captured the spec status in Edge.
... we support the idea of supporting multiple payment handlers. We don't have any plans to disable any payment handlers.
... regarding Basic Card, Edge already supports it.
... I see no reason to stop working on Basic Card
... It's an ongoing discussion with MS about relationship to MS Wallet; but I don't have any updates about MS Pay
... So we'd like to figure out how to further promote PR API
... including more communication with customers, merchants, partners
... are there good ways to approach merchants let's discuss

dongwoo: Here's a status update from Samsung - we also support Basic Card in Samsung Internet browser.
... so I think Basic Card remains useful and we should at least maintain this as a solution
... Samsung Pay also works on Android.
... and we're happy to work with other browsers and other collaborations with payment handlers

benoit: Will SRC be required for all issuing banks? If the answer is no, then we need another payment method for other cards the are issued

Jonathan: SRC does not require tokens

[Question about whether SRC would ultimately subsume Basic Card]

benoit: We can't eliminate Basic Card unless we have a replacement that meets the requirements.

JonathanG: Could you list the requirements you have in mind?

jv: The basic premise is we need a minimal level of interop; card payments (basic) are the de facto. Seems Basic Card is basically done (but for Safari).
... we need something that works "most of the time" otherwise PR API won't be adopted.
... 3DS is no longer really optional (cf Europe)
... tokens are not that hard to do, so I think they will be increasingly used as a trinity

<rouslan> +1

<Zakim> AdrianHB, you wanted to distinguish between basic-card and the need for basic-card handler built into browsers

AdrianHB: I think it's important to make the following distinction -merchants should be able to get card details back, but that doesn't necessarily mean that the card details need to be returned by the browser. Today Basic Card is basically replacing autofill....in my opinion, that's the sticking point for the moment
... I think it's useful to distinguish the simple ability to return card details, but can we change how that's implemented today?

<estes> I agree with AdrianHB. We didn't see basic card built into safari as a meaningful improvement over autofill and thought it could introduce user confusion to show a payment sheet that might look like Apple Pay but not offer its security benefits

justin: Chrome ships with an implementation of basic card. There could be third parties that are willing to support basic card (think "Firefox")
... if the browsers are not building support, are there third-party payment handlers willing to step up to support the payment method?
... we had a lot of conversation yesterday about 3DS....I also challenge the assumption that it's covered by SRC.
... I think there's some more thinking to do on that

nicktr: As much as I'd like to see Basic Card go away (due to security challenges), the reality is that we need to have basic card

<jv> +1 Keep 3DS/Authentication separate from SRC

nicktr: so I think it's difficult for merchants to see the benefit of implementing PR API
... because there is not a single payment method supported across all browsers, that's a key disincentive to adoption
... if I could pick one key thing in rechartering, it would be to have one payment method that works across browsers.

Ciciley: There are some payment brands that have landed support for some aspects of SRC

Vishal-Expedia: We've been having SRC conversations for 1 year. There are some use cases within Expedia where Basic Card is absolutely required
... so not having Basic Card would mean we would not adopt PR API
... I think you need to ask 100 merchants for their views on the importance of Basic Card

Gerhard: Maybe the answer is to extend Basic Card to support an e-commerce token (that merchants are being required to accept)
... perhaps useful for merchants to reduce PCI burden via e-commerce token

Tomasz: What else would we add to Basic Card? We could stop work on Basic Card and it could still be used by the industry.

<nicktr> I'd like to suggest that the security task force looks at Gerhard's suggestion - we were looking at "tokenized" payments before SRC came along. Can we support both?

Rouslan: We are not really talking about killing Basic Card, just no longer working on the spec.

AdrianHB: If we are going to fully embrace payment handlers, shouldn't basic card support be more like other payment handlers?
... I have some slides for after lunch

<AdrianHB> ian: one question to consider, are there other payment methods we need to consider

<AdrianHB> ... prioritization of future work

<AdrianHB> ... we have developed good liasons with FIDO and EMVCo, are there others?

<AdrianHB> ... we also need to think about how long the new charter should last

<AdrianHB> [STRAWPOLL] Any objections to recharting?

<AdrianHB> - None

<AdrianHB> ian: next steps is for chairs to draft proposed new charter

Gerhard: Yesterday we say a presentation on QR codes. EMVCo has a standard. We are seeing more demand for it. Should we explore QR codes in our charter?

<AdrianHB> +1

<michelweksler> +1 for QR

<nicktr> +1 for QR

Ian: Could auto-fill plug into PR API requests for Basic Card

Justin: Some issues around user-consent in that model

Rouslan: For auto-fill-to-basic-card...something even more interesting than that is flowing in the other direction...
... data flows from basic card payment handler to auto-fill fields
... so the merchant doesn't need to use PR API, but Payment Handlers are still useful to users.

AdrianHB: We've had at least one example of a 3rd party payment handler that did Basic Card (this was Klarna)
... are there others who might explore that if Basic Card were the ubiquitous option?

<Gerhard> +1

Ian: (I recall the value proposition was riding basic card rails without requiring any changes to merchant site.)

Ian: So next steps is for the Chairs to come up with a draft charter based on your comments and other data from this meeting

Apple sent email prioritizing feature requests for Payment Request 1.1 based on previous discussions. These notes were included in the minutes after the meeting:

Web Monetization

[Adrian Hope-Bailie slides]

AdrianHB: This is just a quick-ee intro; we can go listen to Stefan across the hall for more in 30 mins
... a site that wants to accept streaming micropayments puts a <meta> tag in their site
... the content of the tag is a URL that is a payment pointer
... the way that the protocol works is that the browser fetches the document at that URL
... the browser generates a session header (unique)
... when payments are sent to the address, the address is slightly different for each session
... to avoid correlation
... the Web Monetization spec under discussion in the WICG defines a monetization object. An event fires every time a payment is sent by the browser
... in terms of sending the payments, Coil has implemented this as a browser plug-in; Puma browser has implemented this natively
... what we are looking for is a new payment method called "monetization"
... and implicitly there is no user interaction; there is assumed some pre-authorization of an amount
... and as the user browsers small amounts of value are transmitted
... a "web monetization agent" is a component in the browser that makes decisions on the user's behalf about how much to spend on each site
... users need to be able to control their ability to pay on certain sites.
... a core requirement is privacy - how do we build a client-side component that evaluates how much to pay and how much, but without becoming a tool for parties to track users?
... the monetization agent is authorized to make payments out of the user's wallet (which may be the same or different party from the party that distributes the monetization agent)
... that is: we've decoupled monetization agent from wallet (source of funds).
... e.g., use Coil's web monetization agent but pay via google pay

<Zakim> rouslan, you wanted to ask whether the web has any other progress type events

Rouslan: This is an interesting idea. A "progress" type event might be tricky to implement
... Marcos, do you know of any progress-type events?

marcosc: There is a Progress indicator element that has one

AdrianHB: We have been thinking about this as a streaming protocol

<marcosc> rouslan, e.g., progress event from XHR https://xhr.spec.whatwg.org/#interface-progressevent

AdrianHB: On 16 September we (Coil) announced a "Grant for the Web." We've set aside funds for grants to people who are developing content to push this ecosystem forward.
... joint announcement with Mozilla and Creative Commons
... the overlap with the WPWG is:

* Definition of a monetization payment method

* Role of payment handlers

AdrianHB: one idea is web site calls PR API (instead of "meta") and payment handlers respond
... there are breakouts tomorrow on this topic

IJ: Describe user flow?

AdrianHB: I have money in a wallet. I get an authorization from that wallet in the form of an access token. I give that to the monetization agent.
... I leave it up to that agent to make decisions about how to pay for content

IJ: What is payment request role?

AdrianHB: Potentially the merchant could use it to invoke web monetization, but without user interaction

IJ: That would require a change to PR API that requires a user gesture

Marcosc: I encourage people to check it out

[The crowd chants for demo!]

AdrianHB: It's up to each site to figure out how they reward the monetization offer
... e.g., in the game demo we just looked at, the game provider offers free coins. Somebody else might, say, not show ads.

Rouslan: Web Monetization based on ILP?

AdrianHB: Yes.
... The way we've done the payments rails is using ILP
... ILP let's us set up an addressing space.
... it's easy for us as Coil to route payments that way
... it's not a payment network per se...just an addressing overlay on existing payment systems

Rouslan: Is that a hard dependency on ILP?

AdrianHB: In theory no, but yes practically. There is no other way that is cost-effective for sending such small payments

Rouslan: Is Interledger being done at W3C?

AdrianHB: Work started at the W3C Interledger CG. There is now an Interledger Foundation. The intent is for all the IP to be held by that organization, and to stay open and RF
... the IETF draft on Interledger is not standards track
... we've not taken anything on a formal standards track
... these are community-developed documents.

agektmr: What is relation to Metamask?

AdrianHB: There are quite a few efforts to do this with cryptocurrencies.
... if the hard dependency on crypto rather than ILP, that will be the end of the game for them
... until things are built into browsers, it's not going to take off
... if they were to do payments with payment systems we already use, they would be more successful

Web Authentication Update

Tony: The Web Authentication Working Group is working on WebAuthn2. Also, we'd like to understand better payment handlers.
... Web Authentication WG is rechartering through 2021
... some level 2 features include:

Tony: We have deployment of WebAuthn1 in Chrome, Edge, Firefox. In development in Safari (desktop)
... we'd like for payment handlers to be able to use WebAuthn
... we don't have delegation yet
... it takes place between the relying party (the handler) and the client (the browser)
...We'd like to understand your requirements for authentication beyond the payment handler itself

marcosc: We have a payment sheet that operates as a top-level browsing context.

AdrianHB: We still need to cover delegation

Tomasz: In the context of 3DS 2.0, there is a challenge flow that is sometimes implemented as an iframe.
... it's not possible for the issuer to perform 3DS step-up without an iframe

Tony: I had pointed to pull request 911. The group had wanted to go down the feature policy path; there were objections and we are trying to work through them
... I think it's just feature policy itself.

Jonathan: There are a few things we discussed yesterday..."delegation" is one

Tony: We want to understand your use case and determine the best approach.
... I have the feeling there are use cases where you'd like to carry authentication downstream.

Jonathan: Someone who is not the relying party wants access to FIDO credentials and return the signature back to relying party
... a second use case is something to facilitate 3DS where the issuer has created credentials and the merchants would like to use them

Tony: There is some information we've agreed to with EMVCo about what information will be passed along [to 3DS]

Jonathan: In that case, the relying party is still the merchant. But there are use cases where the relying party is not the merchant.
... this morning we also discussed that it would be nice to distinguish from among users (that sort of support for multiple profiles is more of a FIDO or platform thing).

Tony: Agree that's a platform question.

JohnBradley: As mentioned earlier, profiles raise usability issues

Tony: if the wallet is doing the WebAuthn directly on the device, there is no concept currently of segmentation of the use of the credential.
... it's easy to say "the wallet could do it" but then we'd have to have different enrollments all the way back up
... the complexity goes up when building up all the things around it

Jonathan: I had in mind that the relying party at enrollment time could create some new things (e.g., templates)

JohnBradley: That's theoretically possible but the infrastructure parts may not be able to handle the segmentation

Jonathan: Yesterday we also spoke about the use case where the relying party wants to know what key ids belong to it.
... is that something that is standardized?

JohnBradley: It's standardized so that the relying party can never know that.

Jonathan: Even if the relying party created the keys?

JohnBradley: We can't create a super cookie that can be returned without user consent
... if you want to create a cookie to memorize credentials, you can just do that.

Jonathan: Is there a privacy issue to know what authenticators are on the platform?

JohnBradley: Yes
... There is at least one person on this side of the table who has concerns about adding to browser fingerprinting.

Jonathan: You would like to know whether there is an authenticator on the platform.

JohnBradley: You can learn "there is an authenticator" and for some platforms you know what that is, but you cannot find out what biometrics are supported by that authenticator

Tony: You can ask for user verification, but you can't ask for implementation of that

Gerhard: I want to touch on 2 edges of the spectrum
... one things mentioned in SCA is secure display
... right now there are 2 levels: user presence, 2 factor
... but there's missing a third level - secure display
... it would be great to combine "secure display" with getting biometric

JohnBradley: That's defined by the spec but supported in no browsers or authenticators...there's no support by browsers
... the counter-proposal would be to have something that is more generally deployable
... nothing in SCA says the secure display has to be part of the authenticator itself
... but I would argue if your browser is compromised you have bigger problems.
... so in WebAuthn we could have info from the payment handler signed as part of the client data
... I think we could meet SCA requirements across all browsers with existing authenticators...signing the payment handler output in client data

Gerhard: That is the open banking scenario; you may have registered 5 authenticators and the calling party (the "AISP") might have to reach out to all five, and all five might decide to do their token step-up and that would be a bad UX
... so any way to passively sign to give a lower risk indicator and defer step-up; that would be useful.

JohnBradley: Silent signatures from relying parties raise the same fingerprinting concerns

Gerhard: I'd like to say "If I can prove who I am ..."

JohnBradley: Should be able to use cookie
... token binding comes to mind here

Tony: You could do something through cached credentials (somewhat how UAF does this today)

JohnBradley: It would be an interesting privacy discussion

Gerhard: Many rules are based on risk assessments. If I can get more proof of who the person is, I can have less friction, and less abandonment.

JohnBradley: Token binding intended to fulfill that...but token binding is on hold as Google and MS work out issues.
... You can use token binding to ensure a cookie cannot be exfiltrated from browser.

Tony: I propose that we have a task force between our two WGs
... to ensure that we have the use cases and we do the flows
... and that can be brought back to the WG for discussion

NickTR: My use case builds on Gerhard's....you were describing account aggregation
... my vision of payment handlers in the credit transfer space is very similar
... imagine you have a payment handler that is aware of the user's different current accounts with different banks.
... in principle there's a use case where you authenticate once to the payment handler, and you don't have to re-authenticate for each bank account.
... if you read the primary legislation (PSD2), it's the bank's responsibility, but that could be delegated (to the payment handler)
... so the payment handler should be able to pass auth credentials to a bank without more user interaction
... nobody is going to use a flow with multiple authentications
... I'd love to dive into this use case (even if hard)

Jonathan: There is a distinction between "delegation" and "delegation." :)
... e.g., the bank could delegate to the merchant or payment handler who is the relying party
... but the second meaning of delegation is that the relying party is the issuer itself
... so you registered with the issuer, and then in another context the bank says "I allow you to use my credentials"; that's a different form of delegation...the bank still owns the credentials, but they provide them to someone else who can return something to the bank

JohnBradley: We are considering the latter form of delegation
... the iframe could be invisible.
... you could do an invisible iframe to the bank and using post message and a protocol between merchant and bank for credentials
... that has some good privacy properties
... essentially if you allow the second model you enable correlated identifier that may be a backdoor tracking mechanism
... we want to figure out how to give equivalent functionality with privacy

NickTR: In my use case, nothing goes back to the merchant

JohnBradley: Replace "merchant" here with "wallet provider"; same issue
... if I had multiple merchants and multiple wallets and they all used the same credentials they could correlate.

AdrianHB: Raise your hand if you want to be part of the joint task force: Gerhard Oosthuizen, Nick Telford-Reed, Jonathan Grossar, Tomasz Blachowitz, Gildas Le Louarn

<scribe> ACTION: Tony to convene a joint task force on payment use cases that involve Web Authentication

Handling Payments

[Slides by AdrianHB with ideas for handling payments]

AdrianHB: The context for my slides here come from a conversation yesterday where Marcos expressed concern that a lot was going into payment handlers that would make it harder for new implementations to catch up
...First observation is that Basic Card does not fit well with other things...in sheets there's a mix of payment handlers (wallets) and cards (instruments)
... but delegation of merchant-requested data to the payment handler changes the game
... payment handlers should be able to respond to the merchant's request
... this means that payment handlers end up doing everything done by the sheet
... so the question is: do we need the payment sheet?
... The sheet requires an extra click
... the payment sheet has been a blocker for implementation in some browsers
... we've heard from all the browsers that implementing the payment sheet is outside their wheelhouse in terms of localization and because payments are not really the things of browser
... so what would it look like to ditch the sheet?
... I found some examples of how the Share API works
...When I hit "pay" I could get a list of payment handlers I could use
... we could have a number of optimizations like "skip-the-sheet"

Lawrence: How could a payment handler get in the list?

AdrianHB: Through registration via payment handler API
... Instead of getting mix of instruments and wallets in the sheet, you just see wallets [in some type of selector UI]
... Today the payment handler API has a registration flow. Service worker installed. This enables the browser to get a manifest and the browser can do just-in-time install
... As Ian said, how it happens is platform-specific.

Rouslan: Great idea. I think one comment rubbed me the wrong way - that payment handlers are becoming Frankenstein.
... the payment handler is just trying to bring all the options in PR API to Payment Handlers
... we are experimenting.
... overall as an idea that the sheet should go away...I think it could be strange for w3c to dictate UI...but I think it's an interesting idea.

marcosc: I want to support what Rouslan said but wants to shift the perspective.
... PR API on its own and integration with native payment handlers makes a lot of sense
... but what was shown yesterday was that the handler modal was not suitable for some UI requirements.
... so it's becoming like an embedded iframe
... and Airbnb wants to enroll users, too
... so we end up with a component that can be co-opted to do a lot of things
... so let's not get rid of the sheet, but instead have a model browsing context that let's you do all these things
... we just need a bi-directional channel

AdrianHB: One of the things that came out of the discussion is that we've built a payments component that is using a lot of web features, but in a way that is only usable in those flows
... the modal window (of chrome) is special
... I think the modal window is a powerful feature for any cross-origin thing you want to do
... I think it's a valuable platform in general, and it makes the case for building blocks for payment handlers much stronger.
... I'll call this the "modal dialog" feature

<marcosc> "modal browsing context" - fight me

AdrianHB: You could not have popup abuse since only one at a time, and also you only get back to underlying context when you close it

roy: My main comment on that is, one value proposition of the payment sheet is that there's a level of trust
... I trust the browser vendors to do the right thing with that dialog.

<Zakim> nicktr, you wanted to ask about security model. Does this rely still on the method manifest?

nicktr: My question is similar - and payment handlers have a payment method manifest

marcosc: We are showing arbitrary content in something that people thing is secure, but it's not
... we won't present a trusted UI where there is arbitrary content.

<scribe> ACTION: AdrianHB to look into a modal dialog spec, organize testing of assumptions about dropping the sheet.

AdrianHB: Some other ideas: drop instruments, drop modifiers, drop OpenWindow

<marcosc> Today, in order to do certain forms of authentication on the web we require either pop-ups, opening a new tab, a redirect, and so on... Payments introduced another UI component that affords OS-level payment integration (particularly for Apple Pay in Safari). When compared to native applications, most of these UI affordances lead to sub-optimal user experiences.

<marcosc> To improve the situation, a common requirement appears to be:

<marcosc> - a top-level browsing context that displays third party content.

<marcosc> - it's modal.

<marcosc> - it should be possible to position this browsing context at least relative to the top or bottom of the container window, and perhaps have the ability to visually expand the context (or let the user expand it) - and the ability to go fullscreen. The browsing context (not the opener) controls the dimensions.

<marcosc> - the opener context needs to set the feature policy (e.g., allow web authn, camera access, credential management).

<marcosc> - the opener context must a means to have by bi-directional communication channel (i.e., message ports or just post message).

<marcosc> - the opener context must have the ability to close the browsing context.

<marcosc> - an ability to indicate the kind of service that's needed (e.g., "payment", "authentication", "share", "mixed?")

<marcosc> - An ability to open a pop-up (normal pop-up rules apply) - but associated with the browsing context... basically a less crappy tab experience on mobile.


Ian: With chairs we need to review the dense minutes
... I assume we will recharter so next meeting discussion assumes that

NickTR: Remember when we recharter - your AC reps need to step up to say Please Recharter!

Alex: Airbnb could host the next meeting, e.g., in Dublin or Paris

NickTR: +1 to Dublin

<scribe> ACTION: NIckTR to investigate next FTF meeting options with Ian and Adrian

Ian: Minutes available next week

NickTR: Do people read minutes?

[Several people say yes]

NickTR: As Chair it's good to understand what improvements you think we could make in running the group. E.g., who needs to be part of the discussion? We heard yesterday: PayPal, Alipay, WeChatPay
... so we'll work on that.

Rouslan: I think once useful thing at each TPAC is to give a clearer picture of where we are with deployment. So I think some framing would be useful.

NickTR: Maybe we need to start main meeting at 10:00am on day one, and have a crash course before that.

Gerhard: Or do a video

Ian: I collect links to videos on our PR API introduction page.

<jv> Invite UPI from india, and OpenBanking UK we need to get more wallets, perhaps from Nordics where they are quite big too. Then south america, boleto.

IJ: Another idea is a merchant business group.

+1 from Frank

NickTR: Jeff Jaffe also mentioned a series of meetups (with merchants)
... could do them around other events like MRC

Vishal: Another conf is Payments Ed

David: Have we done anything about consumer involvement (e.g., for the UX)?

Ian: Implementers do user testing. But we could have a big show-off-a-thon with lots of users and multiple browser vendors to get feedabck

rouslan: Perhaps what we are looking for is a user experience expert. Some people in the room have "user experience experience." But we could bring UX experts (e.g., from Google) into a meeting to speak about how they think about those things

Justin: I generally agree with Ian that browser vendors and other implementers are on the front line of UX
... I think it could be useful to have them before the group here to point out how difficult it is.

NickTR: We are facing a problem standards efforts share: companies need things to work together but also want to maintain some advantage

Vishal: We user Applause for anonymous user testing.

Alex: We use applause as well

<scribe> ACTION: Jeremy to see whether Stripe could provide any data about PR API

Next Meeting

Ian: Next scheduled teleconference is 3 October. Stay tuned for details.


Summary of Action Items

[NEW] ACTION: AdrianHB to look into a modal dialog spec, organize testing of assumptions about dropping the sheet.
[NEW] ACTION: Ian to work with Justin and Google on writing up payment handler benefits
[NEW] ACTION: Jeremy to see whether Stripe could provide any data about PR API
[NEW] ACTION: Justin to check internally at Google about what can be shared
[NEW] ACTION: NIckTR to investigate next FTF meeting options with Ian and Adrian
[NEW] ACTION: Tony to convene a joint task force on payment use cases that involve Web Authentication

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version 1.154 (CVS log)
$Date: 2019/09/30 16:21:07 $