Should merchants be able to limit matching to trusted apps?

[adrianhopebailie]

From @ianbjacobs at w3c/webpayments#168

A new topic was raised at the July FTF meeting about merchant trust of payment apps. Today, merchants that support payment methods in checkout have established a relationship with all the parties (e.g., paypal) that might be involved in completing a payment. In the world of payment request API and third party payment apps, that could change:

• In the case of a proprietary payment method where there is only one app for that payment method, then the merchant would still have knowledge about the user experience with that app.
• In the case of open payment methods (e.g., payment apps that support card payments or SEPA transfers), there might be multiple payment apps and the merchant would have less a priori knowledge about the user experience associated with those apps.

I strongly support our effort to create an open ecosystem for third party apps. However, if it is the case that merchants might be reluctant to adopt the API because of concerns about not knowing the exact user experience in some cases, then we should try to address those concerns.

One idea for doing so extends the idea of "recommended payment app" that is discussed in the Payment App API [1]. As a reminder, we introduced this concept to help enable a smooth experience for installing payment apps, and also to help bootstrap the system when people don't yet have payment apps installed.

If we agree it is useful to codify the idea of "identifying payment apps" then another use of the mechanism would be to enable the merchant to express payment app preferences. Here is an example of the sort of algorithm we could consider to balance merchant and user preferences:

• The merchant provides a set of preferred apps as input to the payment request API. The set of matching user apps is limited to members of that set. If the set is empty, this means the merchant has no preference (and matching is unconstrained by merchant app preference).
• The same set of preferred apps could (automatically) be treated as a set of "recommended" payment apps, and be displayed to the user as options for installation.

One way to "identify payment apps" is by origin (domain name). This has the advantage
of simplicity and extensibility. My hope is that merchants will say "I just need to know that
CompanyX published the App; I don't need to know specifics about the app" and that origin
is a sufficient piece of information. We could, of course, increase granularity by allowing people to identify apps (and specific versions) with URLs; that may increase brittleness at the same time (e.g., around case sensitivity, trailing slashes, etc.).

[ianbjacobs]

At the 10 August 2016 app task force call, the consensus was that we should not support merchant-specified app filtering. Ian plans to update the draft spec accordingly.

https://www.w3.org/2016/08/10-apps-minutes#item03

[ianbjacobs]

I am adding to this issue some data from recent discussions:

• Ian discussed this with a large merchant who expressed concern about third party apps mining data. Presumably the merchant would like to limit which apps the user can use.
• Matt Saxon has made the point that there are benefits to using the API even if merchants want finer grained control over which apps the user may use, and those benefits include both filtering and consistent user experience.
  • For pull payments, Matt Saxon has an idea that perhaps the payee origin could only be shared with payment apps from the same origin as the payee, and that the user agent could display that origin information to the user in the context of the payment app display, but without sharing via the API. Note that for push payments, the payment app likely needs to know the origin.