PMI_Notes

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

Requirements

These are proposed in the PMI specification:

• It must be possible for the Working Group to mint a payment method identifier for any payment method.
• It must be possible for the anyone to mint a payment method identifier for a payment method under their control.
• It must be possible for someone minting a non-standard identifier to make it globally unique in a cost-effective manner.
• It should be possible to use a standard short string to identify common payment methods.

Priorities

In this order:

• Equivalence testing (required)
  • IJ strongly urges the group to adopt a standard equivalence test for URLs
• Dereferenceability (nice to have)
  • Note: One cannot prevent people from trying to dereference a URL.

Design Goals

• The only computational requirement for identifiers is equivalence testing.
  • The definition of equivalence may vary in complexity, but the goal is to limit requirements for processing the identifiers themselves to that comparison.
  • Any short form identifier should be mappable into a "full form" identifier for equivalence testing.
• Embed no semantics in the identifier
  • Do not use identifier syntax to create hierarchies.
  • Do not require other forms of comparison beyond equivalence to determine the relationship between identifiers.
  • Other semantics are specified outside the identifiers. For example, if we include the ability for a merchant or payment application to indicate "do not support" a payment method, this information would be recorded outside of the identifiers.
• Limit the need to access the network.

Payment Method Relationships and Implication on Matching Algorithm

• A simple system of payment methods excludes any standard way to specify relationships among them. In a simple system, the "matching algorithm" is reduced to computing the intersection of two sets of payment methods: those supported by the merchant and those registered by the user. This can be done with payment method identifier equivalence testing. The complexity of the equivalence test depends on the nature of the identifiers (are they strings? URLs?).
  • One implication of a simple system is that merchants who support many payment methods will have to send a lot of data through the API.
• A more complex payment method system allows the definition of payment method groups. In this ecosystem, organizations publish payment method specifications that declare relationships such as "Payment method A includes payment methods X, Y, and Z." This is useful for several reasons: (1) it allows the merchant to specify support for A, and if the payment method supplier augments the definition, the merchant will not need to change code (2) it allows the merchant to send less data through the API since one PMI can represent a set of payment methods. However, merchants may also want to explicitly indicate lack of support for elements of a set of payment methods, leading to the idea that the merchant might declare both supported and unsupported payment methods.
• A more complex payment method system allows subclass matching. Suppose Payment Method A includes methods X, Y, and Z. A merchant may wish to declare support for A, and a user may have a payment app that declares support for Y (but does not explicitly declare support for A). Ideally the standardized matching algorithm (used by the mediator) would recognize a match between "A is accepted by the merchant" and "User has Y."

Related issues: #110 and #111.

Other considerations

• URLs make it possible to associate useful resources with these identifiers (e.g., payment method specifications). However, there is a cost to servicing URLs. That cost may be high in practice if, for example, we start to see software dereferencing a URL on a significant scale, even though we may provide guidance to implementers against doing so.

Stories

• At checkout on her favorite online store, Mary has an option to choose Visa. The merchant accepts both Visa Credit and Visa Debit.
• At checkout on her favorite online store, Mary has an option to choose between Visa Credit and Visa Debit.
• BigShop accepts many forms of Visa payment except one sub-brand (due to terms and conditions).