Re: [w3c/webpayments-method-identifiers] Should we define nesting/grouping semantics for payment method identifier matching? (#1)

@rsolomakhin, 

Let's separate the concerns for a moment:

1) Is there a (standard) way to represent a relationship such as "subclass"?
2) What entity or entities use that information in computations?

The discussion that Matt, AHB, and I have been having to date answer those questions as follows:

1) There is a (standard) way to represent a relationship such as "subclass". We are modeling that information as "constraints" atop a payment method. We've not reached any conclusions on how to write the constraints down (e.g., as JSON in the payment request or in URL query params).

2) The mediator uses that information in computations to determine a match.

Here are questions I have about how your proposal speaks to those points:

1) It is not clear whether in your proposal you have a standard mechanism for representing relationships. You might be saying implicity "When you see a slash in any payment method spec, you know it's a sub-class." Or you might be saying "When you see a slash in the basic card spec, you know it's a sub-brand." Or you might be saying "There is no standard; people are just expected to know how to map their constrained identifiers to unconstrained identifiers...let's let people figure it out socially rather than through a standard."  Did you have one of those in mind?

2) It is clear from your proposal that you are moving "constraint matching" out of the browser and requiring payment apps to normalize before the browser slurps up data for matching.

I'm not sure your approach works in this case:

 * User has Visa Debit
 * Merchant accepts Visa Credit

If the user's payment app normalizes to "Visa" it might look like a match, but it's not.

Ian

---
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/1#issuecomment-227633024