Payment Apps Task Force

29 Aug 2017


See also: IRC log


Ian, MattDeGanon, Rouslan, AdrianHB, Frank, Ken, alyver



IJ: Welcome Matt de Ganon, Capital One

Spec editing




* 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.


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)


* 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


<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


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

Issue 173




[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

next meeting

IJ: I will not be available 12 Sep

<AdrianHB> 5th

<deganon> No preference

Next meeting: 5 September

scribe: no meeting 12 September

Summary of Action Items

[NEW] ACTION: Ian to add test suite link to the respec [recorded in http://www.w3.org/2017/08/29-apps-minutes.html#action02]
[NEW] ACTION: Rouslan to create https://w3c.github.io/payment-handler/ [recorded in http://www.w3.org/2017/08/29-apps-minutes.html#action01]

Summary of Resolutions

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.152 (CVS log)
$Date: 2017/08/29 22:14:35 $