PMI_Notes

Status: These are notes on Payment Method Identifiers. These are intended for discussion and do not represent group consensus. Contributions from Ian, MattS, others.

See also:

• Spec Notes
• Payment App Notes
• Extensibility Notes

Creation

• It must be possible for the Working Group to mint a payment method identifier for any payment method.
  • The WG has resolved to use URLs, satisfying this requirement.
• It must be possible for the anyone to mint a payment method identifier for a payment method under their control.
  • The WG has resolved to use URLs, satisfying this requirement.

Extensibility

• It must be possible for someone minting a non-standard identifier to make it globally unique in a cost-effective manner.
  • The WG has resolved to use URLs, satisfying this requirement.

Dereferencing

• If PMIs are URLs, it is not a requirement that software deference these URLs.
  • The WG has not yet resolved whether to provide guidance about what information one SHOULD provide for these URLs.

Short aliases

• The WG has resolved not to define short aliases for PMIs in version 1.

Matching

Use Cases

• The merchant accepts both Visa Credit and Visa Debit. Merchant wishes to charge a differential price for specific types, most commonly credit vs debit.
• BigShop accepts many forms of Visa payment except one sub-brand (due to terms and conditions). Merchant wishes to decline a setoff card sub-types, commonly Corporate and high-value purchasing cards.
• There is a surcharge if you choose a mobile OS wallet and then the instrument type of credit (cf UK train use case).
• New scheme is added to the world. What happens to previous declarations?

Challenges

• 1. How do we allow for card types to be added to the eco-system with the minimum amount of effort for merchant
• 2. This is closely linked to having an elegant solution as the more PMIs you have, the more chance that it feel cumbersome (most non-payment people and consumers think in terms of “isn’t it just Visa!”)
• 3. How we allow a merchant to control detailed acceptance rules, without compromising the user experience (user: “you said you accepted my card,, but now it’s been declined”)

Options

Simple scheme PMIs, [Visa, MC, Amex etc.]

Pros:

• Simple, meets challenges 1 & 2
• Easy to define and implement

Cons:

• Where merchant want to charge extra for specific types or sub-schemes (e.g. Surcharge for Credit), this is not supported
  • IAN: This would be supported by identifiers for types or sub-schemes.
• Where merchant want to decline a sub-type (e.g. Corporate Credit) , this is only supported by returning an error to the authorisation request, the mediation matching that occurs prior to authorisation cannot spot this and so the user experience suffers

Complex PMIs, [Visa-Debit-Corporate etc.]

Pros:

• Common differential charging is supported (Credit Surcharge)
• Common decline types would be supported

Cons:

• Each specific type needs calling out in the API, so for Credit surcharges, you would need to specify [Visa-Credit, MC-Credit, Amex-Credit etc.] so this doesn’t allow easy extension of the ecosystem
• How do we go about defining all the PMIs needed to bootstrap the system

Hierarchical matching

Note: This could be augmented with "not" functionality at payment request API level.

Pros:

• Reduced API call complexity for simple use cases (“Visa” acceptance matches “Visa-Debit” presentation)

Cons:

• Doesn’t support common cross brand types (so Visa-Debit and MasterCard-Debit and Maestro need calling out separately to add a surcharge to

Category matching

Pros:

• Meets all functional use cases with an elegant API call

Cons:

• Complex implementation, potentially difficult to understand for web developers
• Difficulty agreeing/aligning categories across brands

Matching Notes

• Because PMIs are URLs, some aspect of matching will involve URL equivalence. For this, IJ strongly urges the group to adopt a standard algorithm for URL equivalence testing.
• If we choose to support subclassing and grouping, we will need to define a more complex matching algorithm. One approach in discussion constraint-based.

Related issues: #110 and #111.

Design notes

• Subclassing data is sticky and it is costly to re-express it for each transaction.
  • Allow merchant to reference a cacheable registry (e.g., define a property in the PMI spec that allows merchant to refer to a list of registries). The PMI spec could also define terms for the registry, e.g., "superclass" that takes a list of PMIs.

Proposal

• The PMI specification defines matching as URL equivalence, but indicates that implementations MAY augment matching by taking into account payment-method specific matching semantics.
• In the payment request API specification, the PaymentDetailsModifier dictionary includes an optional field called "constraints" (of type "data").
• The basic card payment specification defines the following terms and values that are used to specify constraints:
  • network: visa, mastecard, amex, discover, maestro, diners, jcb, unionpay
  • type: credit, debit
• The basic card payment spec also says that these constraints are specified in the "constraints" field of PaymentDetailsModifier as a "constraint list" of network/type pairs.
• The basic card payment spec also defines matching as follows:
  • If either (or both) constraint list is empty, there is a match.
  • Otherwise, there is a match if at least one network/type pair from one constraint list matches one network/type pair from the other. Two network/type's match if there is at least one common network AND at least one common type. String matching is case-insensitive.

Rationale, Variations, and Limitations

• This proposal does address the differential pricing use case. That is because there is no mechanism for specifying a new total in the presence of constraints. One way to achieve this is to allow duplication of payment method identifiers (since they might have different constraints). That would mean removing this statement (or modifying it appropriately): "If a payment method identifier appears more than once in the methodData or details.modifiers sequences, then throw a TypeError." Assuming that both "total" and "additionalDisplayItems" may be constraint-sensitive, it seems we would want a mechanism that allows specialization for both of those, not just total.
• One could specify the constraints within the "data" section of methodData. However, by keeping it outside of "data" it helps avoid conflicts with fields that might be used inside of "data".
• Notice that the matching algorithm is defined in the basic card payment spec. It would not be hard to abstract the matching algorithm (e.g., "OR" between constraint list items, "AND" between terms, "OR" between values) and define it in the payment method identifier spec. This would make it easier for other payment methods to adopt this approach, and make it more predictable for browsers. However, it may be premature to add this to the payment method identifier spec since we have only heard real-world needs for basic cards at this point.
• This proposal calls for enumerations rather than open-ended lists. It has been argued that open-ended lists create security issues. An enumeration in the spec has the disadvantage that we would need to revise the specification to augment the list. An alternative is to define an enumeration by reference to a (Working Group managed) registry. This would have the benefit that we could update the registry without updating the spec, and we would move proprietary names out of the specification. If the registry is on the Web, browsers could cache it and only reload it periodically. Note that even with an enumeration, it is possible to create and identify another payment method that behaves like "basic card" and to match on PMIs for that payment method.
• This proposal does not address sub-brands (e.g., "Visa Electron"). This seems hard to accomplish easily if we do not allow for matching of an open-ended set of values. So the question arises of how we might get some more flexibility in value lists while preserving security. Would it help to limit what data can be provided in the lists, e.g.,
  • Characters limited to ascii 26 letters and 10 digits
  • List length limitation.
• Another constraint term that might be interesting for basic card payments is "purpose" (or some other appropriate name) that could have values personal, business, commercial, purchase.
• "network" and "type" are suggested names for discussion but there may be better term names.