[w3c/webpayments-payment-apps-api] Should merchants be able to limit matching to trusted apps? (#1)

>From @ianbjacobs at https://github.com/w3c/webpayments/issues/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.). 

---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webpayments-payment-apps-api/issues/1