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

@jakearchibald --

Sure. There is context here that has probably been lost, since a lot of this arose from discussions between this document, the Payment Request document, and the Basic Card document. Even worse, some of the context is in PR and/or issues rather than being in any current version of the specs, and a lot of it is difficult to keep up with unless you're on the calls.

The driving case for this is the ability to filter payment apps in several dimensions. Using "basic-card" as the example (because it's one that people understand the most simply due to their role as credit card holders); payment apps will want to take into account things such as:

- Payment Network (e.g., Master Card, Visa, American Express, etc)
- Billing Type (Credit, Debit, Prepaid)

I've heard other attributes floated (e.g., payment providers that are tied to region, or merchants that can't accept business cards), but those seem a bit exotic. What's important, though, is to keep in mind that the list of attributes is not fixed at these two, and may well grow over time.

Syntactically, the way this would be indicated by a merchant is as is shown in [example 2 of the Payment Request spec](https://w3c.github.io/browser-payment-api/#constructor):

```javascript
const methodData = [{
  supportedMethods: ["basic-card"],
  data: {
    supportedNetworks: ['visa', 'mastercard'],
    supportedTypes: ['credit']
    // Any other payment-method-specific fields go here.
  }
}];
```
...although there has been some discussion of having a separate field for the criteria that will be used to filter payment providers; e.g.:

```javascript
const methodData = [{
  supportedMethods: ["basic-card"],
  filters: {
    supportedNetworks: ['visa', 'mastercard'],
    supportedTypes: ['credit']
  },
  data: {
    // Any payment-method-specific fields go here.
  }
}];
```

So basically, what we're trying to avoid here is having a merchant say "I can take 'basic-card', but only Mastercard and Visa, and I don't accept debit cards" and then have payment providers that only provide basic-card American Express and/or basic-card debit show up in the list.

The discussions we had basically laid out two options:
1. Come up with a general algorithm in which the payment app indicates, at registration time, the precise combination of payment method filters it matches; or
2. Allow the payment app to register a pure function that evaluates the filter.

I personally prefer the first option, and think it can be made to work; but there was overall consensus from others to go in the second direction. The rationale, as I can best explain it, is that coming up with a usable syntax for payment apps to indicate which filters they should match is going to be incredibly complex for anything beyond the most trivial cases, while registering a pure function to evaluate filters is much easier for app developers to understand.

The question that is the subject of this issue is whether we have erred in this evaluation, and should instead attempt to pursue option 1.

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