[w3c/webpayments-payment-apps-api] Revisiting payment app filtering (#96)

The current spec includes a function that a payment app can optionally register for itself (`canHandle()` in the existing `setManifest()` method) for the purpose of determining whether the payment app is applicable to the payment method _and its filters_. This is one of several mechanisms that have been discussed to date.

@marcoscaceres correctly points out that, as specified, the current mechanism is somewhat problematic, in that we're assuming basically a "pickling" of this function for use in future contexts in a way that's not obviously supported by ES.

In practice, when I proposed this approach (and, to be clear, it was my second-favorite choice out of options on the table), what I had in mind was something very similar to how [PAC files](https://en.wikipedia.org/wiki/Proxy_auto-config) operate, both from a persistence and execution environment perspective. While there are probably ways to specify `canHandle()` in a way that is more palatable (e.g., by having it point to an external file that is evaluated independently), there is some question as to whether doing so is worth the effort it is likely to take.

The alternate approach is to more concretely define a payment filtering algorithm based on a generic understanding of the `filter` parameter passed as part of the `PaymentRequest`.

I'm opening this issue to re-kindle the discussion regarding these two potential approaches, in light of the newly highlighted difficulties we are likely to encounter. Of course, alternatives approaches beyond the two I describe are welcome as well.

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