Web Payments Working Group

02 May 2019



Ian Jacobs (W3C), Krystian Czesak (Shopify), Dean Ezra (Barclays), Danyao Wang (Google), Matt Detert (MAG), Adrian Hope-Bailie (Coil), Rouslan Solomakhin (Google), Danny Russell (Worldline), Laura Townsend (MAG), Zouhir Chahoud (Microsoft), Justin Toupin (Google), Puneet Shah (Adyen), Ken Mealey (American Express), Nick Telford-Reed, Ramesh Gorintla (Discover)
Adam Solove (Stripe)
Adrian Hope-Bailie


AdrianHB: Post face-to-face prioritization, in particular based on some high-level comments from merchants at the FTF meeting.
... what is the target merchant? Large merchant with development teams or mid-to-small merchants?
... we hope this discussion will help us prioritize work going forward.
... we'd like to serve as many members of the ecosystem that we can, as well as we can, but some prioritization will help us
... we discussed this last week to some extent
... we see a challenge in addressing some of the requests of the largest merchants (e.g., in terms of data access flexibility)
... if we cater to "tier 1" merchants we would likely have to change the API design to allow for finer grain control

rouslan: We'd of course love for large merchants to adopt the API. When we designed it several years ago we decided against decomposed APIs. We wanted to focus on payments use cases. If someone wants to collect shipping separately, I think APIs for autofill and auto-complete are more well-suited
... I don't think we should go in the direction of splitting the API into smaller APIs for data collection.

danny: Can you summarize feedback from large merchants?

lte: I feel as though the merchant community would support the WG pursuing the current path because overall we want this API to gain adoption.
... you need to get this in market to start to get adoption
... smaller merchants will likely value this capability; they may not have the expansive skill set necessary to streamline checkout
... we support that because we'd like you to get adoption.
... large merchants have some concerns around particular payment methods (e.g., we support tokenization but there are issues)
... but we want you to be successful in the market
... Large merchants have some limited use cases where the API would have significant value
... PR API would fit best for guest checkout
... There are are some other use cases where more data would be appreciated so large merchants can model what they currently do

<AdrianHB> ian: I think this is captured well in the minutes from the end of the f2f

<AdrianHB> ... we had notes from Target which were added

<AdrianHB> ... it boils down to fine grained control over checkout

1) When you want fine-grain control (of timing, style, presentation), use forms + autofill

2) When you want bundled ease-of-use, use PR API

<AdrianHB> ... some things could be transported into PR API but the use cases are too variable

AdrianHB: Concretely what would change in the API design is that there is one initiation and you hand over control; an alternative is to break data collection and "initiate payment" in different APIs

<Zakim> rouslan, you wanted to ask more about tokenization

<AdrianHB> Ian: this process may help us to re-characterize some of our existing

<AdrianHB> ... feature requests

rouslan: I agree with Ian and AdrianHB points....we want a "one shot API" but with some parameterization by the merchant

<scribe> scribenick: Ian

rouslan: But our assumptions would break down if people wanted just a shipping address outside the context of payment
... we would have to think differently about privacy, security, UX
... regarding tokenization, I have a question
... I know one issue that people are referring to (e.g., one-time use v. recurring payment)

[IJ thinks that's not the issue here]

<Zakim> Ian, you wanted to move to push some discussion to task force

IJ: Let's focus here on the overall direction of PR API which is designed for maximum payment method flexibility
... we can move tokenization questions to the card payment security TF

PuneetS: I think that for big merchants or even mid-size merchants, I think it's useful to start from use cases and work backwards. PR API is a holistic solution. I think that flexibility will matter, even in the short run
... I think that targeting use cases will be the best framework for getting adoption
... for big merchants, guest checkout is a big use case. Another use case is "Adding a card to an account"
... I think Trent (Walmart) cited this use case
... would PR API functionality differ for the "Add a card" use case?
... another set of use cases involve gathering individual data pieces; I think that will matter for more merchants than just large merchants
... I realize that the API allows for flags at construction time, but if they want data later, merchants may run into issues

[^^^IJ thinks we should talk more about that]

PuneetS: It's still unclear to me that autofill is the right substitute for PR API

<AdrianHB> ian: we concluded sometime ago that the WG was mostly focused on EMVCo-type tokens. We could explore others though

PuneetS: Guest checkout is a big use cases, adding cards, adding more details (shipping, billing) as separate steps....I think big and mid-tier merchants will value those functionalities

<jtoupin> +q

lte: I agree with everything that's been said. I would like the group to consider broadening tokenization discussions to other types of tokens.
... that would help alleviate some concerns of medium to large merchants
... I also agree with the additional use cases noted by Puneet (but as priority 2)

<Zakim> AdrianHB, you wanted to ask about revisiting use cases as a WG?

AdrianHB: So I am hearing:

- The API in its current form services slightly different markets

- There is value (to all merchants) for guest checkout flows

- The long term view is that you'd like to see the API succeed, and that we should broaden the options available for secure payments, in particular more tokenization options for cards

Justin: An open question based on a comment from Puneet - should we address the API to get piecemeal data...I would love for people to say why doing that via an API would be more helpful than the declarative autofill approach

AdrianHB: I think it would be good to step back, identify clearly the current use cases we address with PR API, and then enumerate the "nearby" use cases or that are high priority enough to do the work to support the use cases.

[IJ always happy to help with communications and synthesis]

danny: I think Justin's question is a good one....you have to consider the UX of multiple consents

<AdrianHB> scribenick: adrianhb

<Ian> IJ: Puneet, when does "late request" for billing happen?

<Ian> scribenick: Ian

PuneetS: Justin's question is great: What should autofill do v PR API?
... the way that I think of the user journey through checkout (let's remove guest checkout for now)
... entry of card details, shipping, billing...those don't typically happen in one step
... sometimes you may have shipping address but the customer needs to add card details
... you may want to collect an address as the last step
... you may want them to store credentials and billing address (or at least part of it; some merchants use postal code when validating card credentials)
... I see that some functionality could be divided up in those cases
... merchants might want to break those out into steps, to reduce cognitive load, prefill....

<AdrianHB> ian: could these things still exist under PR API with a slightly different user experience?

<AdrianHB> ... its seems like a very small variation from what we already have

IJ: That sounds like it might be achievable under PR API as variants I want to look at flows in more detail

<scribe> scribenick: Ian

Zouhir: My browser team works on lots of PR API. What's unique about PR API is that there's more of a user experience
... what I would really like is what AHB said...document the use cases and our hypotheses
... I am happy to support documentation of what we believe are unmet needs
... we have hypotheses and should validate them with merchants
... so I support that effort to build up our use cases, hypotheses, and then validate them (without breaking too much what we have)

AdrianHB: I am hearing from Zouhir, Ian, support for us dusting off our use cases
... revisiting and focusing some efforts on revitalizing that
... the change to our WG composition is also interesting; fresh eyes and fresh perspectives should make this a valuable effort
... then we can evaluate feature requests

<Zakim> AdrianHB, you wanted to mention the importance of context for privacy and to mention the early vision of a "wallet" for both payment and identity credentials

AdrianHB: With regard to composable APIs, one thing to bear in mind: when we talk about collecting personal details...the fact that those are done in the context of a payment is a valuable signal to the browser about whether this is for something valid or a mere phishing expedition
... so understanding checkout context helps browser
... we also had previous conversations about payment handlers as general "wallets" that can hold other forms of credentials.
... the browser, as the user's agent, has access to a lot of capabilities that the user wants to express, and can this be done in a unified and frictionless way
... can it be done in a privacy-protecting way
... I would be interested in this general conversation

Danny: +1 to effort to document use cases, and then tweaks to help increase use case support
... also assessing where use cases are met through payment methods

AdrianHB summarizing:

- Hearing support for enumerating today's supported use cases

- Hearing support for then documenting hypotheses about nearby use cases

- And then prioritizing them

<AdrianHB> scribenick: adrianhb

ian: This is where a task force is likely the best approach
... if there is support for a TF doing use case documentation

<rouslan> +1

<krystosterone> +1

<Zouhir> +1

<jtoupin> +1

<Ian> IJ: Who would like to help?

ian: then we can figure out where auto-fill etc are a better fit but somewhere in between we may find API changes that address use cases

ian: we need help from different parts of the ecosystem

<Ian> IJ: I volunteer

<PuneetS> I volunteer

<lte> Mag volunteers

<rouslan> i vol

<danny> I volunteer

<Ian> Zouhir: I volunteer, too

<jtoupin> I volunteer

<Ian> Volunteers: Ian, Puneet, Laura, Rouslan, Justin, Zouhir, Danny, AdrianHB, someone from Shopify

ACTION: Ian to work with volunteers to start up a task force to document payment request use cases today and tomorrow

<Ian> AdrianHB: I propose that we use this meeting time for the task force in general

<Ian> (IJ +1)

<Ian> Web Payments Overview

ian: chairs and I chatted about how useful this is
... it could be that one of the outputs of this use case work is to also update this
... perhaps this could be subsumed with a study of the API as it is today

<Ian> (IJ: In short, we may wish to subsume that document since I think we will include some flow descriptions)

<Ian> AdrianHB: So I am hearing use cases + flows + gap analysis

<Ian> ...and also "how to do other use cases with autofill"

<Ian> AdrianHB: I do think in looking at the use cases, we can discuss what can be met through OTHER APIs (e.g., use case is addressed by PR API + Web Auth + Payment Handler)

<Ian> IJ: I plan to take over the PR API GitHub wiki for this deliverable.


<Ian> AdrianHB: I think it would help to review those previous IG use cases and also make sure to cover terminology

<Ian> IJ: +1 to terminology inclusion due to FTF meeting feedback

<Ian> AdrianHB: Thanks all!

Next meeting

<Ian> 16 May

<Ian> AdrianHB: I expect we'll touch on this topic again at 16 May meeting...but in general I think we will work async on this deliverable

Summary of Action Items

[NEW] ACTION: Ian to work with volunteers to start up a task force to document payment request use cases today and tomorrow

Summary of Resolutions

[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version 1.154 (CVS log)
$Date: 2019/05/02 15:47:55 $