This issue comes from WICG/paymentrequest#35 and was discussed at the F2F.

In #149 @dret said:

the current draft defines/allows identifiers to be used in short or long forms. most experience with identifiers in the wild shows that no matter how clear equivalence rules are defined, they tend to be ignored, leading to problems with identifier recognition, and interoperability issues. unless there is a very compelling reason why non-unique identifiers should be supported, it may be better to forego the convenience of a shortcut notation, and always require identifiers in some canonical form.

I think as a first effort we should forgo short from identifiers. Short form identifiers only become useful when you have a critical mass of payment apps that fundamentally support the same payment method. I believe this is unlikely to be a huge problem at the time of adoption and can be easily appended in a V2 spec.

I also think that that short-form identifiers are troublesome on the response side of the flow. If there are two payment apps that say they can return credit card info, the expectations from the payee is that this info is standardized between the two apps, which in turn means we need to designate what that looks like. I think specing out what the response looks like for a "CC" payment method is going to be tricky and so should also be tackled as a V2 if needed.