[w3c/webpayments-method-identifiers] PROPOSAL: PMI identifies payment method specification, constraints for additional granularity (#5)

Replaces #2 

## Background

The current proposal of basic string matching has placed unnecessary restrictions on how PMIs can be used.

Under the current system both of the following PMI's reference the Card Payment Method Specification: 
https://webpayments.org/card/visa
https://webpayments.org/card/mastercard

This is redundant because the PMI is fulfilling two roles:
1. Identify the payment method that is supported ([Card Payment Method](https://w3c.github.io/webpayments-methods-card/)) as defined in a single Payment Method Specification.
2. Pass additional semantics about how that payment method is supported (support for Visa and Mastercard branded cards)

It would be better if a payee or payment app could advertise their support for the card payment method by simply using the PMI; https://webpayments.org/card/ and then use some other mechanism to pass those additional semantics.

## Caveat

The mechanism for passing additional semantics needs to be understood by the payment mediator (browser). 

__Example:__ If the supported card brands was passed in the payment method specific data then it would only be possible to evaluate if there is a match after invoking the payment app.

## Proposal

Matching should be done against two distinct pieces of data:
 1. A payment method identifier (PMI) that identifies the payment method as defined in a payment method specification (Eg: Cards, SEPA direct debit, Alipay)
 1. A set of filters/constraints that can be used to pass additional meta-data into the matching algorithm allowing the payee and payment app to provide additional granularity to the matching

Definition of the allowed meta-data would be done at a payment method level (i.e. in the payment method specification) but the matching algorithm would still support matching without needing to understand the semantic of the meta-data. (i.e. simple matching rules based on the names and values of the meta-data)

## Implementation

There are numerous ways this could be implemented which can be decided upon later if this concept is adopted in principal

So the following PMIs might be implemented as follows:

```javascript
[
  {
    supportedMethods: [
       "https://web-payments/methods/card/visa",
       "https://web-payments/methods/card/cup",
       "https://web-payments/methods/card/mastercard"
   ]
  },
  {
    supportedMethods: [
      "https://web-payments/methods/card/bitcoin/v1",
      "https://web-payments/methods/card/bitcoin/v2"
    ],
    data: {
      bitcoinWallet: "XXXX",
    }
  }
]
```

### 1 - PMIs allow query string parameters as matching meta-data

Match by first matching the URL portion without the query string and then find the intersection of query string parameters.

```javascript
[
  {
    supportedMethods: "https://web-payments/methods/card/?brand=visa,mastercard,cup"]
  },
  {
    supportedMethods: ["https://web-payments/methods/card/bitcoin/?ver=v1,v2"],
    data: {
      bitcoinWallet: "XXXX",
    }
  }
]
```

### 2 - Simple PMIs with additional meta-data in the JSON of the request

Match the PMI which is a simple URL and then look in a standard field in the request for additional 

```javascript
[
  {
    supportedMethods: ["https://web-payments/methods/card/"],
    methodMetadata: {
      "https://web-payments/methods/card/" : {
        "brands" : ["visa", "mastercard", "cup"]
      }
    }
  },
  {
    supportedMethods: ["https://web-payments/methods/card/bitcoin/"],
    methodMetadata: {
      "https://web-payments/methods/card/bitcoin/" : {
        "versions" : ["v1", "v2"]
      }
    },
    data: {
      bitcoinWallet: "XXXX",
    }
  }
]
```


---
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-method-identifiers/issues/5