ianbjacobs
commented
8 years ago @adrianhopebailie, thanks for writing this up.
Some additional notes:
- In both approaches (query string or JSON in the payment request), there are payment method specified terms that participate in the matching algorithm. For instance, the basic card payment method spec would allow people to use the term "brands" with a list of (arbitrary) values. In the above example, the bitcoin payment method spec would define the term "version" and explain how that term is used (e.g., a list of strings that represent version numbers).
- One of the ideas we discussed is that when payment request API is called, payment method identifiers could be repeated N times, but with different constraints each time. (Thus they would not be "duplicate PMIs" as long as the constraints are different.) A mediator would then invoke the matching algorithm for each of these PMI/constraint pairs.
- In a world with payment method specific terms (e.g., brands or version) the mediator running the matching algorithm needs some semantics beyond "URL matching" for testing the constraints. Here are some thoughts on that:
- Subclass matching is likely to be symmetric: There should be a match both when the merchant accepts a superset of what the user has, and when the merchant accepts a subset of what the user has. In both cases, there is some some common subset, justifying the match.
- Similarly, when there is a given type of constraint on one side (e.g., on brands) and no constraint on the other, that should constitute a match.
- For a given constraint, if the nature of the constraint is not subclassing and the values are otherwise different, that should not constitute a match.
- In pseudo-code, a mediator-implemented matching algorithm (independent of any
given payment method) might look like this:
- Let PMI_M be the set of PMIs-and-constraints specified by the merchant.
- Let PMI_U be the set of PMIs-and-constraints specified by the user. (Note: The payment app spec will define how this user-side set is computed as input to the matching algorithm.)
- The algorithm will loop over PMI_M, looking one by one for matches with members of PMI_U. The result of the loop will be the set of all matching members of PMI_U. This data is most useful from the perspective of the matching payment apps.
- Within that loop, let A and B each be any two PMIs-with-constraints that we are comparing. Here is what I expect the mediator will need to know how to do and thus would be part
of the PMI standard:
- Do an equivalence test on the URL portion.
- Identify the constraint sets for A and B (which may be empty)
- Collect the contraint terms common to the A and B constraint sets.
- Parse each constraint term treating the values as a list of one or more items.
- Compare items for equivalence or subclass relationships.
Here's a syntax for discussion: A{term1=item1, item2, term2=item2/itemN} which means:
- A is the the URL portion, the contraint is between curly braces.
- The constraint is a list of term/value pairs.
- Each value is a list of one or more items.
- Each item may be composed of a series of subclasses separated by "/", with the root class on the left. Thus, "itemN" is a subclass of "item2" in the example.
We want the following to match:
- A, A
- A{}, A
- A{term1=item1}, A
- A{term1=item1}, A{term2=item5}
- A{term1=item1}, A{term1=item1}
- A{term1=item1, item2}, A{term1=item1, item2}
- A{term1=item1}, A{term1=item1, item2}
- A{term1=item1}, A{term1=item1/item5, item2}
- A{term1=item1/item5}, A{term1=item1}
- A{term1=item1}, A{term1=item1, item2/item5}
And the following not to match:
- A, B
- A{term1=item1}, A{term1=item2}
- A{term1=item1/item5}, A{term1=item1/item6}
The following test by the mediator would result in a match between two PMIs-with-constraints:
1. The URL parts match (using a simple URL equivalence test) AND
2. Any of the following is TRUE:
a. No overlapping constraints. This includes the following cases:
- Empty contraints for A or B (or both)
- No overlapping constraint terms between A and B.
b. At least one successful match for a term T that appears in both A and B. This includes:
- There is at least one value for T in A that is string equivalent to one value for T in B.
- There is at least one value for T in A that is a subclass of a value for T in B.
- There is at least one value for T in B that is a subclass of a value for T in A.Ian
msporny
adrianhopebailie
dlongley
rsolomakhin
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:
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), at least in as much as the mediator must be able to execute the matching algorithm.
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.
However, it's not necessary that the mediator (browser) understand what the meta-data actually means, just how to use it for matching.
Example: The browser doesn't need to know what a card brand/scheme is, just how to perform matching on the set of values ["visa", "mastercard"] named "brand".
Proposal
Matching should be done against two distinct pieces of data:
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:
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.
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