Payment Apps Task Force

19 Oct 2016


See also: IRC log


Mahesh, Ian, Pascal, Rouslan, AdamR, Andre, jnormore, conor, AdrianHB


and for some reason WebEx UI is not working

<adamR> conorhwp: It looks like the web interface is working now

<conorhwp> adamR: great thanks


Upcoming Meetings

Upcoming meeting schedule:

* 2 Nov, 16 Nov, 23 Nov, 30 Nov, 7 Dec, 14 Dec, 4 Jan 2017

AdamR: Week of 13 Nov is IETF

(so regrets froM IETF participants on 16 Nov)

AdamR: At risk for 23 Nov

Conor: regrets for 2 nov and at risk for 7 Dec

AdamR: At risk for 7 Dec

Filtering in Payment Apps

DISCUSSION: Should filter matching happen in payment apps

Issue 63


<Zakim> rouslan, you wanted to say not so hot about letting apps be mediators

Rouslan: I went through this thought process for native apps as well.
... I was making the browser send the full list of payment methods to the payment apps, and the payment apps would return which ones they support.
... but in the end, I think that model is not clear to me. Then the mediator doesn't do much filtering.
... this opens up the door to abuse.
... for native apps I have locked it down...
... I would like the mediator to do the filtering.

adamR: The mediator would still match on payment method. The proposal here is the filtering happens in the app

<rouslan> ok then

IJ: Yes, my understanding was just the filtering happened in the payment app

adamR: I actually have some of the same concerns that Rouslan has. Namely, that this proposal enables apps to see when a payment request happens, rather than JUST WHEN THE APP IS SELECTED
... I don't know how you would make it work with native apps
... one idea is to have functions at registration that defines what they accept.
... and when it runs, the payment app doesn't know
... the function returns a boolean. It can't access data. It can't access the network, etc.
... it runs with whatever data it had at registration

jnormore: I have similar concerns ... the experience for the user...they might have to wait for apps to talk to servers
... concerns are mostly performance

<Zakim> rouslan, you wanted to ask Adam about how this would work in Firefox

rouslan: How would this work in FF?
... do you envision payment apps that are able to provide cards to be a bootstrapping mechanism for FF?
... I had not imagined basic cards being implemented by third party apps

AdamR: Some banks issue one-time use PANs
... they have to change every time...communication with back end server will be proprietary
... I want to ensure that banks can do basic card via their third party apps

<AdrianHB> Late to the discussion here but I am -1 to payment apps doing filtering, at least for v1, but I really like the following quote from Matt:

<AdrianHB> "For in-browser basic card support, this can also be modeled as the browser-as-payment-app implementing matching rather than the browser-as-mediator."

<AdrianHB> I have always thought of basic card as the browser acting s both mediator and payment app

IJ: I will update the issue with the notes on privacy, performance from this call

<Zakim> AdrianHB, you wanted to ask if there is any clarity on the motivations behind this proposal

IJ: Pro of this proposal - flexibility for new payment methods
... con of this proposal - doesn't scale as well for new payment apps
... and modeled after how things work today (Apple, Samsung, Android)

AdrianHB: The reason I ask the motivation: is the goal to be able to have a standardized filtering mechanism, or a pass-through function for mediator to ask payment apps if they support a payment request?
... if latter, I suggest we move away from concept of "filtering" to "canYouPay()"?

IJ: I don't think it's canYouPay()...it's more "let's allow new payment method filters like networks for credit transfers"

adamR: We are not talking about exposing this to the merchant, right?

Ian: Right.

AdrianHB: That doesn't exist today as cited by MattS
... apple pay's function is available to merchant

IJ: Anyone interested in pursuing this?

AdamR: If we can't figure out how to make this work from native apps, I consider it a hard blocker.

Rouslan's Payment App Integration Experience

Rouslan: I think we have something similar with native payment apps
... one of the important thing for payment apps is to always know where the money is going.
... the payment app is in charge of the money.
... the payment app wants to be sure the money is going to the right payee
... there are several ways to help ensure this:

* Browser can send origin to the payment app, which can log it

However, if the browser is not trusted, payment apps might not want to send money there, so the payment app might want to verify the signature of the browser.

scribe: so payment apps may only support certain browsers

* Another thing that a payment app might want to double check is that the merchant web site is registered with the payment app.

scribe: some payment apps might require a relationship with a merchant. (This is true for Apple Pay and Android Pay...merchant id is tied to origin)
... in order to verify the origin, what I plan to do in Android is for the browser to take requests from the merchant send them to
... android pay, and let android pay whether to say whether they will accept that payment request or not.
... it's essentially "can this merchant request payment" or "can android pay complete this payment"

<alyver> Is this the equivalent of Apple's merchantValidation method?

scribe: it's sort of like AdamR's lambda function, but (1) it's not sandboxed and (2) it's optional
... so I think that answers one direction of trust : from payment app to browser and merchant.
... but there's another direction of trust: when the merchant says "I accept bitcoin"...they may not care which app provides bitcoin, or similarly basic card.
... so there are cases where the merchant doesn't care which payment app the user uses....but there are cases where the merchant cares (e.g., paypal)
... suppose the merchant requests Alipay and I try to launch Alipay as a browser but some other app pops up to steal credentials.
... the way to establish trust between the browser and the payment app is really to do on the Web thanks to origin model
... if a payment app were registered at bobpay.com, then I know for sure that bobpay.com is responsible for it.
... but that doesn't work on android...however, you can use signatures
... we want any payment app to be able to claim support for a payment method, but we want to be able to verify that those payment apps are legit.
... because we are pushing for payment methods to be URLs, we were thinking of putting a file at those URLs that have signatures of the android apps that the payment method owner expects to be launched
... manifests could also declare that the payment method is "open" (anyone can support)

IJ: Have you encountered fine-grain matching ?

Rouslan: Chrome scans apps that are on the phone and determines which are payment apps
... but before listing the app in the chrome UI, it asks whether the app is "set up for payments"

IJ: What do you pass in?

Rouslan: Method name, origin, method-specific data....that includes merchant id.
... so I think it's similar...I am trying to determine whether to display the payment app as an option to the user.
... the payment app can say "I've never been launched so I'm not ready"

IJ: What is your experience and is web based approach we are talking about in the right direction?

Rouslan: Yes, I think it's moving in the right direction.
... I wanted some extension points in the manifest file where platform specific payment apps can put data
... I removed payment options

(I wanted one line per payment app)

IJ: I believe AdamR suggested that option data be available and optional for browser vendors

AdamR: Also, I think that some may really want to display card art as separate options

Rouslan: I can see that argument. It think the reason people want the card art is increased conversion
... The other topic was location of manifest....

<adamR> As a final note on the lambda functions we were discussing before, the restriction I’m asserting we need is that such functions should be “pure functions”.

Pascal's PR API Experience

IJ: Pascal, want to talk about your experience with payment apps?

Pascal: I played role of "small merchant" to try to use the PR API. First observation is that it was easy to use!
... so that was great
... as a merchant, I also feel that a few things are missing, and that I would have to send lots of information to a PSP to manage it.
... the user experience that I am used to integrates everything into one page
... I might need something like 3D Secure
... I am wondering whether, for example, it would be possible to write a web-based payment app and have it integrated into the mediator UX
... same thing with 3D Secure
... so I think consistent UX is important.

IJ: I heard Zach also say that integration of ux for third party web-based payment apps is an important issue.

adamR: Imagine you have a window or other UI that comes up that says "there are three payment apps"
... do you imagine that the third party web app renders in the same window?

Pascal: If it's web-based app, yes, it could be integrated into the same graphical environment where the mediator displayed the choices

AdamR: That is, to a limited degree, what I was talking about in the spec about opening a payment window
... there will probably have to be some iteration on the user experience to make clear that "this stuff here is being rendered by the browser with special permissions"
... and that compared to "this is just a web page"
... today there is a strong distinction between browser chrome (and its permission) and the content. ... we don't want to muddle that message
... will require tweaking but come down to implementation details
... so I agree that it will be complex but it's on our radar

jnormore: The piece about 3D secure...the way I envision that, and why I think it's important to recognize that basic card will be implemented by third party payment apps
... there are things like 3D Secure where you will need payment apps since I don't think browsers will support it.

IJ: Any other comments on your experience?

Pascal: Thanks for letting me know that the UX is on the radar.

Next meeting

2 nov

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.148 (CVS log)
$Date: 2016/10/19 14:28:45 $