Should we define nesting/grouping semantics for payment method identifier matching?

[adrianhopebailie]

Migrated from https://github.com/w3c/browser-payment-api/issues/30 by @ianbjacobs

There is a generally interesting question of how we will define payment method identifier matching. There are many possibilities, ranging from exact string equivalence, to complex URI matching schemes, to regular expressions.

This particular issue is focused on a suggestion from the 24 Feb FTF meeting [1]: should there be a way to define a sort of hierarchy so that one payment method identifier will match more than one other identifiers. (e.g., "match any payment method identifier related to Visa").

(If people want to raise issues for other matching semantics, please create new issues.)

[1] https://www.w3.org/2016/02/24-wpwg-minutes

[rsolomakhin]

A simple approach (from the browser perspective).

1. Browser matches the identifiers exactly.
2. A payment app that contains visa debit card details can tell the browser that it handles both "visa" and "visa/debit".

As a result, if the merchant requests "visa", then they always get "visa" identifier back, even if it's actually "visa/debit".

Thus we're pushing this question out to the payment app's responsibilities.

[ianbjacobs]

@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

[rsolomakhin]

I hope to leave the subclassing semantics to the payment method specifications. In case of Basic Card Payment Method spec that we're writing in the working group, I hope to use "/" for subclasses.

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.

Exact matching in browser should take care of that.

                                browser<---["visa","visa/debit"]---user's payment app
merchant----["visa/credit"]---->browser
                            (no exact match)

I admit that I have not thought through this proposal thoroughly. I am open to suggestions and other proposals as well.

[ianbjacobs]

@rsolomakhin wrote:

I hope to leave the subclassing semantics to the payment method specifications.

I agree for some part of the semantics (at least). The question I have is: are there any bits you need in the mediator to enable that? For instance, do we need "substring matching" so that different payment method specs can specify subclasses in some capacity?

In your proposal you use "/" for subclass matching and that syntax would enable anyone using that payment method spec to know that. But it would not enable the mediator to do anything with that syntax unless the mediator somehow specially implemented that payment method spec. If other payment method specs wanted to use other syntax, the mediator would have to know about that other syntax too. I believe your point is that "the mediator doesn't have to know about it." That's fine, but then my question is: what software component makes use of that information? Your answer might be: "The payment app". What algorithm does the payment app use to determine which URLs to provide to the mediator for matching?

Thanks for working on this. I am very happy to have a simple solution if it meets our needs!

Ian

[ianbjacobs]

Closing this issue because we answered "no." We are using filters (cf basic card as an example) to address a subset of the use cases.