See also: IRC log
IJ: Welcome Matt de Ganon, Capital One
https://w3c.github.io/payment-handler/
PROPOSAL
PROPOSED:
* Pull out intro material into an explainer.
* Examples good
* Pull out algorithms and put them in branches; merge
them as there is consensus and tests.
Link to them via issues.
* Leave in modeling / interfaces (which editors can
evolve rapidly as needed, and which stabilizes naturally
over time.)
* Move dependencies toward the end (as in PR API now)
rouslan: I think these are all
good points.
... they will make our life easier in the long term even if
more difficult in the short term
... I would prefer that we wait until Marcos is more fully
onboard in this spec before we adopt those fully.
AdrianHB: +1
IJ: I am comfortable with this proposal (and also waiting for Marcos to be more involved)
AdrianHB: I am strongly opposed to removing some explanation from the text.
https://github.com/w3c/payment-handler/pulls
IJ: How should we proceed with existing pull requests?
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
... and as soon as Marcos is more involved, we will welcome the
test writing expertise.
IJ: Should we pull out algos?
AdrianHB: Let's instead put issues in where they do not yet have tests.
<rouslan> +1 for markers
(IJ is likely to do a PR to move dependencies down)
Summarize:
* We look forward to marcos getting actively involved in this spec
* When he does we are open to making more changes to the spec and editorial process
* In the meantime, we would like to add issues to the spec where algorithms are not tested (rather than remove them)
* Ian plans to move dependencies down the page
* AdrianHB has expressed a strong preference to leave explanatory material in the overview
* We want to start the payment handler test repo and link to it from the spec
https://w3c.github.io/payment-request/
<scribe> ACTION: Rouslan to create https://w3c.github.io/payment-handler/ [recorded in http://www.w3.org/2017/08/29-apps-minutes.html#action01]
<scribe> ACTION: Ian to add test suite link to the respec [recorded in http://www.w3.org/2017/08/29-apps-minutes.html#action02]
<alyver> +1
https://github.com/w3c/payment-handler/pull/207
IJ: Is this implemented?
rouslan: We are currently
implementing
... so far no issues yet found in the algorithm.
IJ: Would you mind adding a note to the PR not to merge until you've reported on implementation experience
IJ: How is the socialization of "static registration" going in Google?
Rouslan: So far no love
... in order to resolve the issue, we've reached out to some
others
... regarding "static" v. "canMakePaymentEvent"
... so I think we should not decide yet until we have more
input.
IJ: AdrianHB has some thoughts on this
(Ian channels Adrian)
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
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)
... I expect all payment apps will support adding
instruments
... 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.
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.
IJ: Frank, is that something you would validate?
Frank: Yes, probably we would not opt out
<alyver> I agree with that statement as well. They will not want to filter themselves out unnecessarily.
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
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
alyver: A merchant might be frustrated by a payment app that says it can do everything but that can't actually do it.
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%.
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.
rouslan: I think for that use
case, if the merchant has a preference for payment methods,
they can use discounts.
... on the topic of preventing bad behavior, we have found that
dumb algorithms behave well if you have a lot of data.
... 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
gate the problem.
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
alyver: correct; I was thinking of other payment methods
MattDG: Agree with Frank re Andre's scenario; decline would happen
IJ: And that type of failure
would not be capturable the way Rouslan described.
... how fast are those things processed?
Rouslan: It could be fast enough
in light of new APIs (re: processing)
... Merchant might authorize a transaction but not complete it
for a day or two
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
IJ: Let's keep thinking/discussing and leave this open for a couple of weeks and come back to it
https://github.com/w3c/payment-handler/issues/173
https://github.com/w3c/payment-handler/pull/206
https://github.com/w3c/payment-handler/pull/206/files
[IJ explains]
rouslan: +1 to userHint; makes
sense and solves our use case.
... but Dave Longley has pointed out that this would not be
useful when all instruments are shown
... another approach is to enable user agents to compute a
hint
... Dave has proposed an ordering in the list of
instruments.
... I'm split between these two solutions
... should the payment handler specify an order of instruments,
or just a user hint?
IJ: Browser-determined hint does not satisfy "payment handler wants to provide the hint"
AdrianHB: I support payment handler determined hint
IJ: Also, calculating order is much more of a hammer.
AdrianHB: I am supportive any clarification about when the hint is used
<deganon> +1
<frank> +1
rouslan: I am convinced to go with userHint
IJ: I will not be available 12 Sep
<AdrianHB> 5th
<deganon> No preference
Next meeting: 5 September
scribe: no meeting 12 September