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
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]
14:01:24 [Ian]
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]
14:05:51 [Ian]
present+ Ken
14:06:01 [Ian]
present+ alyver
14:07:14 [Ian]
14:07:14 [Ian]
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]
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]
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]
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]
14:21:00 [Ian]
ACTION: Rouslan to create
14:21:12 [Ian]
ACTION: Ian to add test suite link to the respec
14:21:49 [Ian]
topic: AbortPaymentEvent
14:22:23 [alyver]
14:22:25 [Ian]
14:23:07 [Ian]
IJ: Is this implemented?
14:23:12 [Ian]
rouslan: We are currently implementing
14:23:20 [Ian] 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]
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] order to resolve the issue, we've reached out to some others
14:26:14 [Ian]
...regarding "static" v. "canMakePaymentEvent"
14:26:25 [Ian] 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]
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]
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]
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]
14:41:39 [deganon]
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] 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]
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]
14:50:23 [Ian]
14:53:40 [Ian]
14:54:23 [Ian]
[IJ explains]
14:54:29 [rouslan]
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]
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]
15:00:23 [frank]
15:00:24 [Ian]
rouslan: I am convinced to go with userHint
15:01:21 [Ian]
15:01:25 [Ian]
topic: next meeting
15:01:57 [Ian]
IJ: I will not be available 12 Sep
15:02:04 [AdrianHB]
15:02:05 [deganon]
No preference
15:02:12 [Ian]
Next meeting: 5 September
15:02:16 [Ian] 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 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]
16:28:12 [RRSAgent]
I see 2 open action items saved in :
16:28:12 [RRSAgent]
ACTION: Rouslan to create [1]
16:28:12 [RRSAgent]
recorded in
16:28:12 [RRSAgent]
ACTION: Ian to add test suite link to the respec [2]
16:28:12 [RRSAgent]
recorded in