Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Card Sub-Brands #95

Closed
wants to merge 2 commits into from
Closed

Card Sub-Brands #95

wants to merge 2 commits into from

Conversation

mattsaxon
Copy link
Contributor

No description provided.

@rsolomakhin
Copy link
Collaborator

Can you provide links to definitions of these card types?

@mattsaxon
Copy link
Contributor Author

@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
Copy link
Collaborator

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
Copy link
Contributor

Merged as 4c4328c

@adrianba adrianba closed this Mar 24, 2016
@mattsaxonwp
Copy link

@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
Copy link
Collaborator

(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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants