Re: [w3c/browser-payment-api] Should we define nesting/grouping semantics for payment method identifier matching? (#30)

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

---
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/browser-payment-api/issues/30#issuecomment-203084032