See also: IRC log
Issue 8: Is registration "necessary"?
https://github.com/w3c/webpayments-payment-apps-api/issues/8
register payment apps, calling out merchant recommendations, browser
recommendations, and user initiated registration
JNormore: I will have it for 10 August meeting
jnormore: I chatted with Zach
about this. From a merchant perspective, especially in the
early days (while still working on adoption of payment
apps)
... some merchants may want to show a single button, for
example.
... I would (as a merchant) want to have a single button to
instantiate the payment app without the customer having to do a
second thing.
IJ: +1; that's what this issue is
about.
... There's a second case where the payment app returns
immediately based on what the user has selected in the user
agent's display
jnormore: "Headless app"
IJ: Questions
1) Do we need to specify anything related to the user experience (or just guidance)?
2) To enable the desired UX, do we need to specify anything (e.g., some data that payment apps need to do the right thing)?
jnormore: +1 to guidance
... I think most payment apps will seek the best experience
IJ: I can see the spec saying
"when only one matching app, UA SHOULD bypass the selection box
and go straight to launch"
... E.g., does the user agent need to tell the payment app
"This one was selected"? If so that seems to be part of the
standard.
Tommy: We're talking about
skipping selection in the UA and headless payment apps...what I
want to avoid happening is to enable the user to click a button
and then payment happens without consent from the user.
... if user agent and payment app are both at liberty to
automate, you might have too easy of an experience
jnormore: There are two views on whether that experience is great or dangerous.
<ben> would be good to see some UX mock ups - is that possible? thx
IJ: +1 to calling out the consent
point and letting the UA or payment app manage it
... +1 to writing up how different experiences will work
... I am happy to be part of a team to write that up.
Ben: I can help
... it would be worth documenting them to be on same page and
see whether we've thought through the potential
experiences
<scribe> ACTION: Ian to organize a chat with Ben on writing down different user experiences [recorded in http://www.w3.org/2016/08/03-apps-minutes.html#action02]
Ben: Let's try to look at the
whole user experience
... will help get consistency and interop
What should be the user experience when an app is
recommended for two methods? (issue 11)
https://github.com/w3c/webpayments-payment-apps-api/issues/11
IJ: +1 to tommy's suggestion we remain silent on this
<jnormore> +1
jnormore: There are two sides to
this question ...
... from a merchant perspective I definitely want control and
to tweak which payment apps I accept
... which payment apps convert the best
... from the customer experience, if we allow merchants to
restrict payment apps, it requires that the customer install
multiple payment apps for the same payment method. So that will
complicate the user experience for the same payment method
IJ: How might this play
out?
... E.g., will merchants gravitate towards a small number of
apps?
jnormore: Today merchants have "multiple payment apps" today
ben: If you look at what goes on
in the real world: merchants accept payment methods, and users
have preferences ... but it's up to the merchant who decides
what they accept
... I think that consumers are used to transacting that
way...if you take that experience and put it into that
scenario, it will mirror today's world
... I think having options is the right way to go
... give consumers options
... each option will have strengths
... Some options will work better in some scenarios than
others
<Zakim> Ian, you wanted to ask whether merchant can help instantiate the user's payment app
IJ: Would it be useful if a merchant already has this data (e.g., card info stored) that the merchant can recommend an app and the data is already in the app
jnormore: I'm not sure that we'll find any merchants willing to pull stored data out of a vault and pass it to another vault.
ben: Also some PCI issues
... and privacy as well
IJ: The merchant could share a token and the payment app could send that back
Ben: If the PSP can act as TSP that might be interesting.
IJ: What is the app identification mechanism? What do we need? URLs? Origins sufficient?
jnormore: I would lean towards granular approach. I don't think domain will suffice
Two app identification use cases:
* recommended apps
* I only support X, Y, Z (filter by merchant)
<scribe> ACTION: Ian to add to design considerations the app identification bits for this issue [recorded in http://www.w3.org/2016/08/03-apps-minutes.html#action03]
Review action - Conor and JasonN will send comments on the text.
JasonN: I will send notes later
today
... most of my comments are around open and proprietary
... I think we should dig into that more..the industry is
currently weighted towards proprietary and standardization
effort are weighted towards open
- app identification
- merchant filter on apps
- user experience recommendations
- registration bits
- JavaScript listener
- proportion of payment request data sent to app (resolved)
IJ: we have editors for some of
those things, not all.
... maybe AdrianHB needs to write up the JS bits
... I can write up the "subset of payment data" part
What goals should we have?
<Max> +q
Max: Does "user experience recommendations" include what we discussed in London?
Ian: Yes.
Max: I can help with user experience bits
IJ: One goal would be to have (1) mature spec and (2) strong design considerations that have support so that => there is strong support at TPAC for going to FPWD.
<jnormore> +1
10 August
(Any regrets?)