PMI_Notes

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

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. Amex Corporate) , 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 declines 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

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