See also: IRC log
this is it!
IJ: Any thoughts on the meeting? Key topics?
[No speakers]
<scribe> New repo -> https://github.com/w3c/webpayments-payment-apps-api
https://github.com/w3c/webpayments-payment-apps-api/issues
<conorh_wp> +q
conor: I also sent comments /
issues
... is email sufficient?
https://github.com/w3c/webpayments-payment-apps-api/issues/1
IJ: Any initial reactions?
Andre: Merchants want to know
exactly what the experience will be like otherwise they will
bypass the mechanism.
... users may have a hard time knowing even what a payment app
is, so the experience has to be good
Max: I think I agree with the
point. Nowadays, merchants who work with Aliababa...we have a
trust relationships with them
... as you mentioned, for card payments, it's not sure how to
establish the trust relationship
... so I think it's a valid concern
<jnormore> lol
Andre: Echoing what Jason said,
there is concern about ensuring the checkout experience though
payment apps is as good as it can be
... from a merchant perspective, question is "is a customer
going to install an app from a third party"?
... it's not clear how people will know that a payment app
(e.g., from some payment service provider) has to be installed
in order to check out with a merchant
jnormore: Merchants want to increase conversion...the more options customers have, conversion drops
<alyver> agree
jnormore: the option to install
multiple payment apps for the same type of payment will lower
conversion
... in particular for first-time experience
... it's a huge deal for smaller merchants who don't have as
many returning customers
IJ: Should we just have merchant preferences that might affect ordering or should we have merchant preferences that affect filtering?
maheshkk: For the merchant,
whether they recommend or prefer an app, it still doesn't tell
me that the user has an app
... if none are available, it's still no good for the
merchant
... merchant may still want a discovery mechanism
... I still come back to the same question asked previously -
should merchants have a way to discover whether a payment app
is available?
<Zakim> Ian, you wanted to talk about related topic of query API
https://github.com/w3c/webpayments/issues/159
<alyver> Also this issue: https://github.com/w3c/browser-payment-api/issues/155
The coding looks like this:
* Browser support API? If no then fail
* User have any apps? If no then fail
* payment request API? If no then fail, otherwise user select
(Related: displaying recommended apps, and how installed recommended apps v. uninstalled are displayed)?
IJ: Do we need a flow diagram?
<conorh_wp> +q
Mahesh: I would also like to be able to answer the question "Can they pay with my app?" with privacy protection. That would be useful.
conorh_wp: Yes, I think the
picture is coming together.
... I think a flow diagram would definitely be useful.
... The concept of a payment app is alien to consumers. Have we
addressed that at all?
... I think users may not care about payment apps...they just
want to use credit cards in their wallet.
jnormore: I have had the same
thought. From a customer perspective, they want to choose the
payment method (card, paypal, alipay, etc.)
... so we show "pay with credit card" and then send users off
to a page
... we also show user-friendly brands
... so is the registration model even necessary?
... if it's up to the merchants to control what payment apps
are visible, is the registration model hurting us?
IJ: Good topic - how to make
registration as smooth as possible (near automatic)?
... Anyone want to work on a flow diagram?
(of how user selects payment apps, and possible queries?)
<conorh_wp> +q
IJ: Proposed that we only send the subset of payment request data that is relevant to the payment app
conorh_wp: Would merchants ever send transaction-specific data for the processor?
(via tha payment app)
https://www.w3.org/TR/2016/WD-payment-request-20160705/#paymentrequest-constructor
IJ: You can send data, but if the
data is not "standardized" you don't interop
... Proposed that we only send the subset of payment request
data that is relevant to the select payment app
<conorh_wp> +1
<maheshkk> +1
<jnormore> +1
<scribe> ACTION: Ian to report back to the issues list that there were no objections to the proposal [recorded in http://www.w3.org/2016/07/20-apps-minutes.html#action01]
https://lists.w3.org/Archives/Public/public-payments-wg/2016Jul/0048.html
IJ: From merchant perspective,
might have a range from "origin only" to "url to identify
specific version"
... From payment app perspective, that can be left to the
payment app
... if you allow payment app to query registration
information
https://github.com/w3c/webpayments/wiki/PaymentApp_Notes
IJ: the more we have merchants wanting to specify app preferences, the more some might want versioning
conor: but that increases coupling which we may not want
https://github.com/w3c/webpayments-payment-apps-api/issues/1
could add a note there
For suggestions, please do pull requests against the spec
Is there a reason .unregister(“request_url”) has not been proposed? => pull request please
<maheshkk> +1 unregister()
[On registration and launch of native app]
IJ: Can have standard registration approach (using web) but launching may just be about good practice documentation
IJ: I mean something like "A user should be able to use any payment app for a given payment method"
<Zakim> AdrianHB, you wanted to ask what these are for payment request, an example would help
AdrianHB: Did we do that for payment request API?
https://github.com/w3c/webpayments/wiki/WPWG-FTF-Feb-2016-Requirements
IJ: We did that for PMIs. Not for
payment request API AFAIK
... it was used for PMIs and I think useful
<AdrianHB> +1 for sincere engagement
I Propose to take a stab at this for our meeting next week
scribe: to clarify, I don't want the task force to stop working on the spec
AdrianHB: I want to avoid going around in circles
IJ: I am looking for new ways to engage others and volunteering time
AdrianHB: Cool
... But we need also to be in fora where key players are...we
need to hear from browser vendors directly, for example.
AdrianHB concrete proposal:
- our communication of this task force happens on the main list
scribe: so the meeting invitation and minutes go on the main list
+1
<alyver> +1
<jnormore> +1
<Max> +1
andre: I agree with AHB
<conorh_wp> +1
RESOLUTION: Send agendas and minutes of these calls to the main WG list
ack
<scribe> ACTION: Ian to announce the minutes of this call to the WG and plan to send agendas and minutes to that list [recorded in http://www.w3.org/2016/07/20-apps-minutes.html#action02]
27 July at 2pm UTC (9am ET)
So sorry :(
The UTC time is pm UTC
The UTC time is 1pm UTC
I APOLOGIZE
rrrsagent, make minutes
This is scribe.perl Revision: 1.144 of Date: 2015/11/17 08:39:34 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/slippery/alipay/ No ScribeNick specified. Guessing ScribeNick: Ian Inferring Scribes: Ian Present: Andre Ian Kapeng Dapeng Jason Conor Mahesh JasonYoung WARNING: No meeting title found! You should specify the meeting title like this: <dbooth> Meeting: Weekly Baking Club Meeting WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Got date from IRC log name: 20 Jul 2016 Guessing minutes URL: http://www.w3.org/2016/07/20-apps-minutes.html People with action items: ian[End of scribe.perl diagnostic output]