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

[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.)

Ian

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

[mattsaxon]

PR #95 added to show how this would work for cards

[ianbjacobs]

Some additional thoughts based on helpful chat with @mattsaxon:

• In my mind, the base functionality that we need to support includes:
  • The ability to identify supported payment methods ("payment method identifiers")
  • The ability of the mediator to compute the intersection between merchant-accepted and user-registered payment methods by determining "equivalence" of identifiers. (The equivalence computation should be simple.)
  • It has been pointed out that for card payments each card brand can have a lot of "subbrands". I understand there may be use cases where people want to indicate support for some subbrands, for example because they want to change the price for some subbrands, or because they don't support certain subbrands because of the terms and conditions.
  • Given the number of subbrands (shown to me by Matt), I think it is inevitable socially that some merchants will want to simplify by saying "I take card of type X" with a payment method identifier intended to be broadly recognized, rather than send a long list of finer-grain identifiers at each transaction. I can imagine that in the market, these types of broadly applicable payment method identifiers will be acceptable, even if nobody defines precisely what is included.
  • If this happens in practice, then we are likely to see the following scenario:
  • Merchant says "I accept card type X"
  • Payment app supports card type X
  • User enters subbrand X-gold into the payment app
  • When the user choose X-gold to pay, the data goes back to the merchant who says, "in fact, while I accept most cards of type X, I happen to not support X-gold."
  • This leads to an error message and a bad user experience since the user thought that they could pay with the chosen payment instrument.

Here are two ideas (largely from Matt I think :) for which I'd like some initial feeback, and which could lead to concrete proposals:

• The API should support the concept of a payment method identifier that is NOT supported. This would enable people to use the "broadly understood" payment method identifiers but carve out exceptions. This would help reduce (but probably not eliminate) the number of poor user experiences.
• Because they would be known to be "not supported," they could straightforwardly be taken into account by the mediator during the "intersection" computation.
• I have as a design goal that there be no relationship between payment method identifiers (OTHER THAN EQUIVALENCE) that can be determined merely by looking at them together. Supporting "not accepted" semantics in the API (and in payment app registration) would satisfy my design goal.

In short: "not supported" might provide the right amount of functionality to facilitate the use of "broadly applicable payment method identifiers" without significant additional complexity in defining "grouping semantics".

Matt also suggested that the ability of the payment app to send payment method specific response codes (in case of failure in particular) could help ensure adequate communication to the user about what's happened. This is discussed in a separate issue: https://github.com/w3c/browser-payment-api/issues/17

Ian

[zkoch]

While I agree with your set of necessary functionality, I don't think I agree with the proposal that we need a way to explicitly say what payment methods are not supported. If a merchant says, "I accept card type X", the assumption should always be (for clarity sake) that they support all subtypes of X. If they don't, then they shouldn't say they support "X" - they should list exactly what they support. I don't think that's an unnecessary burden to place on merchant (they are doing it currently, after all).

I would be interested in more real-world use cases, though. The most prominent example I can think of is that a merchant supports Visa Debit but not Visa Credit. Are there other examples that you can point to that would merit the complexity of a "not supported" addition to the API?

[ianbjacobs]

@zkoch,

If a merchant says, "I accept card type X", the assumption should always be (for clarity sake) that they support all subtypes of X.

I understand completely a world where there is no grouping (and thus no subtypes). There are only atomic payment method identifiers. That world is verbose but easy to understand.

I want to avoid the need to define (and maintain) groupings. So when you say "they support all subtypes of X" that assumes that someone has defined a grouping somewhere and people have to know where and it has to be maintained, etc.

"Not supported" functionality does not require any grouping definitions. It is an extension of the "no subtypes" world where all computations can be done merely with two lists of identifiers ("supported" and "not supported") and no other information.

I would be interested in more real-world use cases, though. The most prominent example I can think of is that a merchant supports Visa Debit but not Visa Credit.

Matt referred me to this long list of subtypes: https://www.bindb.com/bin-list.html

One use case he referred to was a merchant not supporting a particular subtype due to terms and conditions.

...the complexity of a "not supported" addition to the API?

I have not yet spent time thinking about or discussing the cost and complexity of this approach. That's an important activity.

Ian

[zkoch]

Matt referred me to this long list of subtypes: https://www.bindb.com/bin-list.html

I think this page makes the problem look much worse than it really is. There are many different issuing banks out there in addition to dual branded cards (e.g. United Airlines' Chase Visa Card). But this is the whole value add of the card network - by and large, if you're in the network, things work.

I'd still like to better understand real world use cases and how prevalent those use cases are before adding the complexity of a "not supported" type into the API.

[ianbjacobs]

@zkoch,

Agreed: let's hear from folks about the use cases!

Ian

[mattsaxon]

I was relayed on an example by Jean-Vves about a certain card sub brand that charges 7% interest rate and is designed for purchase of high end goods.

Another example is the acceptance on the Discover network for UnionPay credit cards. A merchant may not want to be able to decline those even though the network can accept, e.g. Because of different Ts&Cs.

An alternative is to simply decline the card at the acquirer. This decline approach demonstrates the need for some more refined return codes rather than just success, failure, pending etc. That have been said used, perhaps a failure reason with an enumeration of reasons.

Lastly. I prefer the grouping semantics, though I do appreciate the challenge of modelling this. However grouping might still benefit from a 'not supported' approach so you can say, I accept all Visa cards apart from electron.

[webpayments-specs]

P-cards and corporate cards are other good examples here. Again, merchants may decline because they attract much higher fees (and are unregulated). The reverse can also be true - where a merchant will only accept a p-cards because of the line item capability those this is very rare.

We had a project a few years back that had to split out and enumerate each of these categories. Let me see if I can dig them up

(Reply posted by email) Nick

---

From: mattsaxon Sent: Wednesday, 30 March 2016 07:39 To: w3c/browser-payment-api Subject: Re: [w3c/browser-payment-api] Should we define nesting/grouping semantics for payment method identifier matching? (#30)

I was relayed on an example by Jean-Vves about a certain card sub brand that charges 7% interest rate and is designed for purchase of high end goods.

Another example is the acceptance on the Discover network for UnionPay credit cards. A merchant may not want to be able to decline those even though the network can accept, e.g. Because of different Ts&Cs.

An alternative is to simply decline the card at the acquirer. This decline approach demonstrates the need for some more refined return codes rather than just success, failure, pending etc. That have been said used, perhaps a failure reason with an enumeration of reasons.

Lastly. I prefer the grouping semantics, though I do appreciate the challenge of modelling this. However grouping might still benefit from a 'not supported' approach so you can say, I accept all Visa cards apart from electron.

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHubhttps://github.com/w3c/browser-payment-api/issues/30#issuecomment-203275890 This e-mail and any attachments are confidential, intended only for the addressee and may be privileged. If you have received this e-mail in error, please notify the sender immediately and delete it. Any content that does not relate to the business of Worldpay is personal to the sender and not authorised or endorsed by Worldpay. Worldpay does not accept responsibility for viruses or any loss or damage arising from transmission or access.

Worldpay (UK) Limited (Company No: 07316500/ Financial Conduct Authority No: 530923), Worldpay Limited (Company No:03424752 / Financial Conduct Authority No: 504504), Worldpay AP Limited (Company No: 05593466 / Financial Conduct Authority No: 502597). Registered Office: The Walbrook Building, 25 Walbrook, London EC4N 8AF and authorised by the Financial Conduct Authority under the Payment Service Regulations 2009 for the provision of payment services. Worldpay (UK) Limited is authorised and regulated by the Financial Conduct Authority for consumer credit activities. Worldpay B.V. (WPBV) has its registered office in Amsterdam, the Netherlands (Handelsregister KvK no. 60494344). WPBV holds a licence from and is included in the register kept by De Nederlandsche Bank, which registration can be consulted through www.dnb.nl. Worldpay, the logo and any associated brand names are trade marks of the Worldpay group.

[maoyanhua]

I do think an 'non supported' case is common. for example merchant may not accept certain card brand, e.g., amex due to high transaction cost.

[adamroach]

I do think an 'non supported' case is common. for example merchant may not accept certain card brand, e.g., amex due to high transaction cost.

Presumably, they wouldn't indicate American Express in the list of supported payment types.

[maoyanhua]

as discussed above, there are so many card brands out there, in practice it would be difficult for the merchant to specify ALL brands they accept. In many cases, merchant usually say "we accept all major credit cards except amex". In implementation, usually translate into:

  def can_accept(pmi):
    return is_creditcard(pmi) and not is_amex(pmi)

[msporny]

In general, -0.75 for any sort of grouping semantics in version 1 (we can add this later in v2).

The exception to the above is if we can get a fairly comprehensive list of all payment methods we're going to support in v1 (which I think would be very difficult). If we're going to support grouping semantics, we're going to have to either ask the card brands to manage that, or we're going to have to manage it ourselves. Neither one seems like a good use of this WGs time. Instead, we should push this complexity out to implementations. I'd rather that implementations have convenience methods to generate lists for supported payment methods. For example, having a convenience function (NOT in the spec, but in software implementations) that does something like this:

var acceptedPaymentMethods = paymentlib
  .generateMethods('visa').except('https://example.com/pmis/visa/esoteric-card').list();

-0.5 to card exclusion features (as it makes the matching logic harder more complex)... unless it's provided by an external library.

In short, we should punt on grouping - let helper libraries define the behavior and we can pull those features in after we get some field use for v1.

[dlongley]

+1 to letting third party libraries figure this out for v1.

[ianbjacobs]

I just attended the Card Not Present Expo this week. The more I speak with merchants and PSPs, the more I hear they would value grouping/subclassing.

Ian

[adrianhopebailie]

I am hearing increasing interest in having grouping semantics to support real-world use cases however there have been a number of members that feel we shouldn't do this in v1.

Unless I have missed it I don't think anyone opposed to grouping has said why. Can those opposed to grouping provide some reasons why?

[adamroach]

@adrianhopebailie

Unless I have missed it I don't think anyone opposed to grouping has said why. Can those opposed to grouping provide some reasons why?

Sure; that's easy: if the list of potential identifiers that people want to use is manageable (such as the list Zach proposed), adding a grouping mechanism is a fairly complicated task. Simply enumerating supported types is much simpler to specify, much simpler to implement, and much simpler to use.

On the other hand, if we're going to allow granularity that in any vague way approaches the size of the list that Matt pointed to -- where I count 1,427 different identifiers -- then simple enumeration is clearly too cumbersome, and the extra complexity of grouping is warranted.

If we're talking about O(10) identifiers, then I don't think the complexity of grouping makes any sense. It's just too much work for not enough payoff. If it's O(100) or O(1000), then that's a very different story.

I propose that we need to shelve this question for the moment, and start a conversation about card payment type identifier granularity. After we've reached some kind of conclusion on that, we come back to this issue, and I think will have the information we need to make a sensible decision. Until then, we're just stabbing blindly into darkness.

[adrianhopebailie]

@adamroach I think we are tending toward something like what @mattsaxon pointed to and much much more.

This is only limited to card payments and there are already too many to justify needing to explicitly name them all.

Consider that third party payment apps will allow payments on this API that are completely outside the current payment ecosystem and may have semantics we can't even consider today. The set of PMIs and the way they are used by payment methods is going to explode (a good thing) and our matching algorithm should allow for this not restrict it.

Right now we have ignored the fact that payment methods may want to allow apps and merchants to define what currencies they can transact in (card networks deal with this out of band or through DCC). So if I have http://hopebailie.com/adrianpay/USD do I need a separate PMI for all of the currencies I support (http://hopebailie.com/adrianpay/EUR etc)? As soon as I have more than 2 or 3 sub-classes the number of PMI's grows exponentially.

[adrianhopebailie]

Migrated to https://github.com/w3c/webpayments-method-identifiers/issues/1