Card Sub-Brands

[mattsaxon]

No description provided.

[rsolomakhin]

Can you provide links to definitions of these card types?

[mattsaxon]

@rsolomakhin is that question dependant on the merging of this PR? Do you have specific schemes you are interested in, however be aware that I the Mastercard Scheme definition is a 246 page document. http://www.mastercard.com/us/merchant/pdf/TPR-Entire_Manual_public.pdf.

In short, I'm not aware of a nice document that states what fields are required for each scheme. The rules can get quite complex as you may have seen from my Maestro and UnionCard investigations in PR #9. I'm about to start to model the UnionPay PMI when it has authentication, this will fall outside of the BasicCardResponse.

[rsolomakhin]

You can merge this PR without the links. I'm not an editor, so I don't have write access to this repository. I cannot merge this pull request for you.

document that states what fields are required for each scheme.

That's not necessary. Chrome has logic to distinguish between visa and mastercard, but it does not have logic to distinguish between visa/electron and visa/debit, for example. If you have a link to a document that describes this difference, my job as an implementer would be easier :-)

[adrianba]

Merged as 4c4328c

[mattsaxonwp]

@rsolomakhin the logic to distinguish between sub-brands are in the IIN numbers (1st 6 digits of the PAN), just as they are for brands. However it does get quite complex at that level and I believe changes more frequently, you may need to consider using a lookup service from a payment provider.

[ianbjacobs]

(After discussion with Matt Saxon,) I wanted to summarize a few points:

• A mediator job is to compute the intersection between merchant-known payment method identifiers and user-known payment identifiers. The mediator learns about supported payment method identifiers from the user through the payment registration app registration process.
  • How the payment app determines which payment methods it supports, is a separate business decision. However, this thread suggests an additional point needs to be made: when the user types in (for example) card information, the payment app will want to determine the corresponding payment method identifier (for example, for a card sub-brand). How the payment app maps user-supplied credentials to supported payment method identifiers is outside the scope of our work, in my view.
  • I don't think the WG will specify how payment apps are updated (e.g., to support new payment methods). But the group does need to address the question of how the mediator learns about these updates (or, for example, that the user has registered some credentials with the payment app subsequent to registration).

Ian