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.
https://www.w3.org/TR/2018/NOTE-web-payments-use-cases-20180719/
<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!
<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