IRC log of apps on 2017-08-29

Timestamps are in UTC.

14:00:08 [RRSAgent]

RRSAgent has joined #apps

14:00:08 [RRSAgent]

logging to http://www.w3.org/2017/08/29-apps-irc

14:00:14 [Ian]

Chair: Ian

14:00:18 [Ian]

Meeting: Payment Apps Task Force

14:00:40 [alyver]

alyver has joined #apps

14:00:57 [Ian]

Agenda: https://lists.w3.org/Archives/Public/public-payments-wg/2017Aug/0019.html

14:01:24 [Ian]

present+

14:01:29 [Ian]

present+ MattDeGanon

14:01:42 [Ian]

Topic: Introduction

14:02:24 [rouslan]

rouslan has joined #apps

14:02:30 [rouslan]

present+ Rouslan

14:02:42 [Ian]

present+ AdrianHB

14:02:44 [Ian]

present+ Frank

14:03:30 [frank]

frank has joined #apps

14:04:20 [deganon]

deganon has joined #apps

14:04:39 [Ian]

IJ: Welcome Matt de Ganon, Capital One

14:05:09 [Ian]

Topic: Spec editing

14:05:38 [Ian]

https://w3c.github.io/payment-handler/

14:05:51 [Ian]

present+ Ken

14:06:01 [Ian]

present+ alyver

14:07:14 [Ian]

PROPOSAL

14:07:14 [Ian]

PROPOSED:

14:07:14 [Ian]

* Pull out intro material into an explainer.

14:07:14 [Ian]

* Examples good

14:07:14 [Ian]

* Pull out algorithms and put them in branches; merge

14:07:15 [Ian]

them as there is consensus and tests.

14:07:17 [Ian]

Link to them via issues.

14:07:19 [Ian]

* Leave in modeling / interfaces (which editors can

14:07:21 [Ian]

evolve rapidly as needed, and which stabilizes naturally

14:07:23 [Ian]

over time.)

14:07:25 [Ian]

* Move dependencies toward the end (as in PR API now)

14:10:02 [rouslan]

q+

14:10:24 [Ian]

ack rouslan

14:10:29 [Ian]

rouslan: I think these are all good points.

14:10:43 [Ian]

...they will make our life easier in the long term even if more difficult in the short term

14:11:43 [Ian]

...I would prefer that we wait until Marcos is more fully onboard in this spec before we adopt those fully.

14:11:46 [Ian]

AdrianHB: +1

14:14:05 [Ian]

IJ: I am comfortable with this proposal (and also waiting for Marcos to be more involved)

14:14:23 [Ian]

AdrianHB: I am strongly opposed to removing some explanation from the text.

14:15:03 [Ian]

https://github.com/w3c/payment-handler/pulls

14:16:10 [Ian]

IJ: How should we proceed with existing pull requests?

14:16:28 [Ian]

AdrianHB: I think we should merge the ones we've been working on for a while and are comfortable with. We can make changes later

14:16:42 [Ian]

...and as soon as Marcos is more involved, we will welcome the test writing expertise.

14:18:00 [Ian]

IJ: Should we pull out algos?

14:18:13 [Ian]

AdrianHB: Let's instead put issues in where they do not yet have tests.

14:18:17 [rouslan]

+1 for markers

14:18:48 [Ian]

(IJ is likely to do a PR to move dependencies down)

14:18:56 [Ian]

Summarize:

14:19:08 [Ian]

* We look forward to marcos getting actively involved in this spec

14:19:17 [Ian]

* When he does we are open to making more changes to the spec and editorial process

14:19:38 [Ian]

* In the meantime, we would like to add issues to the spec where algorithms are not tested (rather than remove them)

14:19:45 [Ian]

* Ian plans to move dependencies down the page

14:20:00 [Ian]

* AdrianHB has expressed a strong preference to leave explanatory material in the overview

14:20:37 [Ian]

* We want to start the payment handler test repo and link to it from the spec

14:20:38 [Ian]

https://w3c.github.io/payment-request/

14:21:00 [Ian]

ACTION: Rouslan to create https://w3c.github.io/payment-handler/

14:21:12 [Ian]

ACTION: Ian to add test suite link to the respec

14:21:49 [Ian]

topic: AbortPaymentEvent

14:22:23 [alyver]

+1

14:22:25 [Ian]

https://github.com/w3c/payment-handler/pull/207

14:23:07 [Ian]

IJ: Is this implemented?

14:23:12 [Ian]

rouslan: We are currently implementing

14:23:20 [Ian]

...so far no issues yet found in the algorithm.

14:23:52 [Ian]

IJ: Would you mind adding a note to the PR not to merge until you've reported on implementation experience

14:24:10 [Ian]

Topic: canMakePaymentEvent

14:25:21 [rouslan]

q+

14:25:34 [Ian]

IJ: How is the socialization of "static registration" going in Google?

14:25:37 [Ian]

Rouslan: So far no love

14:25:53 [Ian]

...in order to resolve the issue, we've reached out to some others

14:26:14 [Ian]

...regarding "static" v. "canMakePaymentEvent"

14:26:25 [Ian]

..so It think we should not decide yet until we have more input.

14:26:51 [Ian]

IJ: AdrianHB has some thoughts on this

14:27:21 [Ian]

(Ian channels Adrian)

14:30:16 [rouslan]

q+

14:30:24 [Ian]

IJ: One thought is to not do filtering on capabilities by payment apps. This would let them, e.g., show up in the UI and allow users to add cards

14:30:27 [Ian]

ack rouslan

14:31:23 [Ian]

rouslan: For payment apps that support basic card, it makes sense to not show instruments that would otherwise be displayed (e.g., mozilla might do this)

14:31:35 [Ian]

...I expect all payment apps will support adding instruments

14:32:24 [Ian]

...regarding "abuse" it's not clear to me that it's a big deal because for URL-based payment methods, the manifest will enforce the relationship between app and URL.

14:34:41 [Ian]

adrianhb: I have to credit dave longley...if you are a payment app you want to appear as much as possible. So most payment apps are unlikely to opt out.

14:35:19 [Ian]

IJ: Frank, is that something you would validate?

14:35:23 [Ian]

Frank: Yes, probably we would not opt out

14:36:00 [alyver]

I agree with that statement as well. They will not want to filter themselves out unnecessarily.

14:37:01 [Ian]

MattDG: It's hard for me to conceive of a situation that applies directly to us, but considering the partnerships that are forming between a variety of players, there's so much calculus here, that to filter seems like it would be hard to anticipate what could be applied based on what the merchant accepts

14:38:43 [alyver]

q+

14:38:56 [Ian]

IJ: I am hearing two points (1) whether a payment app CAN do something and (2) whether a payment app is INCLINED to do something

14:39:18 [Ian]

alyver: A merchant might be frustrated by a payment app that says it can do everything but that can't actually do it.

14:40:33 [rouslan]

q+

14:40:37 [Ian]

ack alyver

14:41:09 [Ian]

IJ: Payment app still gets merchant supplied capability to be able to do the right thing. Not sure how to avoid potential for frustration 100%.

14:41:35 [frank]

q+

14:41:39 [deganon]

q+

14:41:41 [Ian]

alyver: It is still possible for a payment app to get data to do a debit payment even if merchant says they only accept credit.

14:41:43 [Ian]

ack rous

14:41:59 [Ian]

rouslan: I think for that use case, if the merchant has a preference for payment methods, they can use discounts.

14:42:06 [Ken_]

Ken_ has joined #apps

14:42:38 [Ian]

..on the topic of preventing bad behavior, we have found that dumb algorithms behave well if you have a lot of data.

14:43:48 [Ian]

... I think that if the payment app misbehaves (e.g., sending something to the merchant that they have not asked for), the merchant will call paymentResponse.complete with FAIL flag, which will tell the user agent that the payment app has failed. This can be stored in a user profile, and if failures increase over time, I could imagine scenario where a user agent might be discouraged from showing constantly failing payment apps. These market mechanisms can help miti

14:43:48 [Ian]

gate the problem.

14:43:52 [Ian]

ack fr

14:44:32 [Ian]

frank: To Andre's scenario of just supporting debit card....the payment app would return card data, and the processing would not happen on the backend; that's not a payment app issue

14:44:42 [AdrianHB]

AdrianHB has joined #apps

14:44:49 [Ian]

alyver: correct; I was thinking of other payment methods

14:44:56 [Ian]

ack m

14:44:59 [Ian]

ack de

14:45:37 [Ian]

MattDG: Agree with Frank re Andre's scenario; decline would happen

14:46:05 [Ian]

IJ: And that type of failure would not be capturable the way Rouslan described.

14:46:53 [Ian]

...how fast are those things processed?

14:47:04 [Ian]

Rouslan: It could be fast enough in light of new APIs (re: processing)

14:47:17 [Ian]

rouslan: Merchant might authorize a transaction but not complete it for a day or two

14:47:29 [deganon]

q+

14:47:33 [Ian]

ack deg

14:48:11 [Ian]

deganon: I can't think of a scenario where a payment instrument would be sent to merchant, initial auth goes to processor, either merchant or acquirer looks at the bin or the processing and detect incompatibility; that would happen within milliseconds

14:49:24 [Ian]

IJ: Let's keep thinking/discussing and leave this open for a couple of weeks and come back to it

14:49:36 [Ian]

Topic: Issue 173

14:49:49 [Ian]

https://github.com/w3c/payment-handler/issues/173

14:50:23 [Ian]

https://github.com/w3c/payment-handler/pull/206

14:53:40 [Ian]

https://github.com/w3c/payment-handler/pull/206/files

14:54:23 [Ian]

[IJ explains]

14:54:29 [rouslan]

q+

14:54:32 [Ian]

ack rouslan

14:54:55 [Ian]

rouslan: +1 to userHint; makes sense and solves our use case.

14:55:13 [Ian]

...but Dave Longley has pointed out that this would not be useful when all instruments are shown

14:56:48 [Ian]

...another approach is to enable user agents to compute a hint

14:57:32 [Ian]

...Dave has proposed an ordering in the list of instruments.

14:57:36 [Ian]

...I'm split between these two solutions

14:58:10 [Ian]

...should the payment handler specify an order of instruments, or just a user hint?

14:59:09 [rouslan]

q+

14:59:34 [Ian]

IJ: Browser-determined hint does not satisfy "payment handler wants to provide the hint"

14:59:41 [Ian]

AdrianHB: I support payment handler determined hint

14:59:52 [Ian]

IJ: Also, calculating order is much more of a hammer.

15:00:12 [Ian]

AdrianHB: I am supportive any clarification about when the hint is used

15:00:14 [Ian]

ack rouslan

15:00:17 [deganon]

+1

15:00:23 [frank]

+1

15:00:24 [Ian]

rouslan: I am convinced to go with userHint

15:01:21 [Ian]

q?

15:01:25 [Ian]

topic: next meeting

15:01:57 [Ian]

IJ: I will not be available 12 Sep

15:02:04 [AdrianHB]

5th

15:02:05 [deganon]

No preference

15:02:12 [Ian]

Next meeting: 5 September

15:02:16 [Ian]

..no meeting 12 September

15:02:21 [Ian]

RRSAGENT, make minutesw

15:02:21 [RRSAgent]

I'm logging. I don't understand 'make minutesw', Ian. Try /msg RRSAgent help

15:02:22 [Ian]

RRSAGENT, make minutes

15:02:22 [RRSAgent]

I have made the request to generate http://www.w3.org/2017/08/29-apps-minutes.html Ian

15:02:30 [Ian]

RRSAGENT, set logs public

15:06:03 [alyver]

alyver has joined #apps

15:10:38 [cweiss]

cweiss has joined #apps

15:18:32 [alyver]

alyver has joined #apps

15:43:18 [alyver]

alyver has joined #apps

16:16:35 [alyver]

alyver has joined #apps

16:28:08 [Ian]

zakim, bye

16:28:08 [Zakim]

leaving. As of this point the attendees have been Ian, MattDeGanon, Rouslan, AdrianHB, Frank, Ken, alyver

16:28:08 [Zakim]

Zakim has left #apps

16:28:12 [Ian]

RRSAGENT, bye

16:28:12 [RRSAgent]

I see 2 open action items saved in http://www.w3.org/2017/08/29-apps-actions.rdf :

16:28:12 [RRSAgent]

ACTION: Rouslan to create https://w3c.github.io/payment-handler/ [1]

16:28:12 [RRSAgent]

recorded in http://www.w3.org/2017/08/29-apps-irc#T14-21-00

16:28:12 [RRSAgent]

ACTION: Ian to add test suite link to the respec [2]

16:28:12 [RRSAgent]

recorded in http://www.w3.org/2017/08/29-apps-irc#T14-21-12