@rsolomakhin, I think we may need to discuss this step: > * If matchingFiltersNumber is equal to len(dataKeys), i.e., all filters match: > * Add method to matchingMethods. A note from previous discussions on this topic for context, an app that wishes to "farm" merchant data or always be presented to the user is simply going to claim support for as many payment methods as it knows about with the bare minimum filters. That way it increases its odds of being selected to handle a payment and can try to enroll the user for a requested method once it is invoked. (i.e. It fakes support to get selected and then tries to "wing it" once it is, by supporting basic card as a fallback). Worst case scenario it gathers data about the merchant and it's accepted payment methods. One way to counter this is to only allow the request to specify a "wildcard". i.e. A merchant can submit a request with the method `bobpay.com` and **no filters** and this will match a payment app that is registered to handle the `bobpay.com` payment method but **does** have additional filters specified. Another possibility is that browsers intelligently order options presented to the user based on how often that option has resulted in a failed request in the past? -- 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/96#issuecomment-276455270
Received on Tuesday, 31 January 2017 18:52:26 UTC