Redefinition of BasicCardResponse to address Issue 9

[mattsaxon]

Also revised property names for nameOnCard, pan and securityCode to be
more descriptive and consistent.

[zkoch]

Thanks, Matt. I just noticed that in the response we still don't have anything that indicates the scheme. Do we want to have this returned explicitly? Or should we rely on merchants using the BIN to figure it out?

[mattsaxon]

@zkoch isn't the scheme represented as the methodName is the PaymentResponse object? I presume this would come from the Payment Method Identifer and I've added to the list of these in the basic card payment spec in this pull request

[mattsaxon]

@zach, though we do need to discuss what happens for extensions to basic card details, e.g. tokenisation. I need to review Adrian's proposals and will get back to you post reading those

[adrianhopebailie]

I suggest we namespace these for this payment method because it's quite possible (likely) that we'll have a "tokenized card payments" or "encrypted card payments" spec pretty soon.

<tr><td>basic-card-visa</td><td>Visa (Credit, Debit, Delta or Electron)</td></tr>
<tr><td>basic-card-mastercard</td><td>MasterCard and EuroCard</td></tr>
<tr><td>basic-card-amex</td><td>American Express</td></tr>
<tr><td>basic-card-discover</td><td>Discover</td></tr>
<tr><td>basic-card-maestro</td><td>Maestro</td></tr>
<tr><td>basic-card-diners</td><td>Diners Club</td></tr>
<tr><td>basic-card-jcb</td><td>JCB</td></tr>

[mattsaxon]

Let me have a think on that, there was talk of a hierarchical naming too rather than the flat structure you're suggesting, perhaps "card.plain.visa", "card.encrypted.visa", "card.token.visa". I'll read Adrian B's proposals and comment further

[adrianhopebailie]

That could work but I think we can't enforce something like that I don't think. What would Bitcoin be for example? "cryptocurrency.bitcoin"?

[mattsaxon]

I read Adrian B's proposal now, so appreciate we need the domain name in there to make the minting feasible outside of w3c, my examples were effectively shortnames, but I appreciate my use of the dotted naming made it unclear.

Using Adrian's Option 1 as a template, here are some examples

visa.com/card/plain
visa.com/card/tokenised
mastercard.com/card/plain
worldpay.com/tokenised
w3.org/card/visa/plain
bitcoin.org/V1

visa/plain would be the shortname for http://w3.org/card/visa/plain

[adrianhopebailie]

I'm less concerned about the format and more that we don't spread the idea that "Visa" is a good example of payment method identifier. That's an important point to come to consensus on (we started drilling into it late in the afternoon at the F2F).

Payment Method Identifiers (PMI) serve 2 purposes so their design must consider both:

1. To indicate request and response message format for the interactions between the website, browser and payment app. A single specification of these message formats could apply to a set of many payment method identifiers (as is evidenced in this spec).
2. To indicate specifically which underlying payment instruments (brands) are supported by the website. i.e. A merchant can process card payments but might not accept all card brands.

From an architectural perspective one could think of PMIs as foreign keys that provide a many-to-many link between payment instruments and the messaging protocols that can be used to pass payment data back and forth for those instruments.

I can imagine people minting new PMIs for two reasons:

1. They have developed a new messaging protocol and have documented it in a specification like this one and need to provide PMIs that link payment instruments that can be used with this protocol to the protocol.
2. They have a payment instrument that can be used with an existing messaging protocol and so they mint a PMI that they get added to the list of supported PMIs in the existing protocol's spec.

[burdges]

I suppose "Verified By Visa" is an actual PMI though, no?

[adrianhopebailie]

I suppose "Verified By Visa" is an actual PMI though, no?

Could be, if there is a message protocol spec for how it would work using the browser API

[mattsaxon]

@adrianhopebailie, I agree that visa is not a good PMI without some namespacing, it is a good example of a "brand" though and the naming does to some extent have the brand as a separately identifiable part of the PMI.

Are you not happy that my examples are reasonable PMIs?

[mattsaxon]

Verified By Visa is the 3DS implementation of Visa's, depending on the implementation, it could be done in various ways, but if we want the payment application to support it, we would need either new PMI defined, or an extension to the BasicCardResponse that allowed for additional authentication data to be added.

[adrianba]

Merged as 0469d92 for further discussion in #9.

[mattsaxon]

Added UnionPay as PR 90