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

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

• 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 is:
  • Treat subclassing and grouping as "constraints" on a payment method. So conceptually there are two pieces of information that both merchant and payment app would represent: payment method and constraints. How we encode the constraints (e.g., in a query string or in JSON) is an important question but secondary to the constraint language.
  • The constraint language might look like this:
    • A PMI is a pair: URL + optional constraints.
    • When the mediator looks for matches, it processes each PMI separately. Thus, there is an implicit "OR" between all PMIs. This means that one can specify the same URL part of a PMI multiple times, with different constraints.
    • Within a given PMI, the constrain is a list of name/value pairs. There is an implicit "AND" between all the pairs, so the more pairs you have, the more constraints you have.
    • A match occurs when:
      • A name "N" appears in both sets of constraints.
      • The value of N is the same in both sets of constraints, or One value is a subclass of the other.
    • A subclass is defined as a left string match of values. Proposed: use a "." as a separator for the purposes of readability.

Related issues: #110 and #111.

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.
• The merchant accepts "all cards" and the payment app has MC and Visa.
• The merchant accepts MC and Visa and the payment app supports "All cards".
• BigShop accepts many forms of Visa payment except one sub-brand (due to terms and conditions).
• 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?