Different card schemes have different mandatory field requirements

[adrianba]

This issue comes from WICG/paymentrequest#20 and is now called out in the basic-card-payment document.

[mattsaxon]

@adrianba
I've submitted a pull request with a proposed update to address this

[mattsaxon]

The PR has a flat structure for the data with some optional fields.

I've done some further research and it appears that the only card types that use this data structure today are Meastro cards. There were other brands before such as Switch and Solo, but these are no longer issued.

We should discuss if Maestro should be a specific type (e.g. sub-class of BasicCardResponse) of PaymentResponse object.

What are your views?

[adrianba]

I've done some further research and it appears that the only card types that use this data structure today are Meastro cards. There were other brands before such as Switch and Solo, but these are no longer issued.

This is what I found too but it wasn't clear to me from a quick look where Maestro still had this requirement. For this reason, I didn't include the fields in the initial draft.

We should discuss if Maestro should be a specific type (e.g. sub-class of BasicCardResponse) of PaymentResponse object.

I think this is a good question. First I wonder whether there are other fields used in other geos that would also need to extend the response. If we end up with a myriad of options fields that are rarely used then that might not make the spec very easy to consume. On the other hand, if most implementations will need to consider start date or issue number then including it in the basic data structure might be considered beneficial.

It would be good to get more data before deciding but equally we should pick something soon and change it if new information arises later. We need to address this to determine what to do with #25.

[mattsaxon]

Adrian, I've dug deeper and found the following: Whilst Maestro is still a brand, Maestro cards that need issue number or start date to be submitted were actually using the Switch network scheme (even though the brand was Maestro), this network was closed in 2011, this effectively means that these card went out of circulation sometime in 2014.

I think this closes the issue and we can stick to the simpler format. I'll edit my PR to remove these, but will leave the revisions to the field names.

[adrianba]

Adrian, I've dug deeper and found the following: Whilst Maestro is still a brand, Maestro cards that need issue number or start date to be submitted were actually using the Switch network scheme (even though the brand was Maestro), this network was closed in 2011, this effectively means that these card went out of circulation sometime in 2014.

That matches the results of the research we've been doing too.

[nickjshearer]

I think there's still a problem here, irrespective of Maestro. Expiration month, expiration year, and cardholder name are all optional fields for a UnionPay card. As it stands the spec therefore won't work for basic card payments in mainland China (or Russia, for that matter, where UnionPay cards are also issued).

The only required field you can have for a basic card payment is the PAN.

[mattsaxon]

To add some detail here, UnionPay credit cards do conform to the 'usual', ie. BasicCardResponse, it's the UnionPay debit cards that don't have name and expiry. However what concerns me with modelling is that this level of specification is volatile as we have seen from the Meastro investigations.

These discussions raise a few questions for me;

1. Do we need a list of specific card types that we are going to support as part of our 'ubiquitous methods' (note, I've added these in a PR 25, and they don't include UnionPay because of the issue Nick highlights)?
2. Should we really be defining the standard for these card types at all, or should we be getting the card schemes more involved? (I realise this question has been posed a few times, but we've never got down to some real examples of why this is needed before)
3. Could separating the idea of Payment Method Identifier from 'Brand' assist us here to move forward? This might help address the example that UnionPay credit cards can be accepted on the Discover network.

I still propose we accept my PR as it standard as it is more explicit about the problem as it has a fixed list of brands rather than an empty list and therefore calls out the absence of UnionPay from this model.

This does not imply this is the version that will go to FPWD as we may have some more time to consider this further prior.

[adrianba]

I think there's still a problem here, irrespective of Maestro. Expiration month, expiration year, and cardholder name are all optional fields for a UnionPay card. As it stands the spec therefore won't work for basic card payments in mainland China (or Russia, for that matter, where UnionPay cards are also issued).

This is a good example of where we have to decide whether this is the same schema or a different one. The goal shouldn't be to create one universal data structure. We can have multiple different ones (and should where it makes sense).

[adrianba]

Should we really be defining the standard for these card types at all, or should we be getting the card schemes more involved? (I realise this question has been posed a few times, but we've never got down to some real examples of why this is needed before)

I expect it to be necessary to support card types from schemes who have never heard of W3C and are not participating in the group.

[nickjshearer]

I still propose we accept my PR as it standard as it is more explicit about the problem as it has a fixed list of brands rather than an empty list and therefore calls out the absence of UnionPay from this model.

I am happy to defer to the editors, but it would be nice if FPWD was able to accommodate China in its basic card model. That being said, I appreciate time is of the essence so maybe a commitment to resolve the issue in a future draft is enough.

[adrianba]

@nickjshearer, do you think we should be using the same response type (with lots of optional attributes) or a different type? We could certainly define a variety of types in the spec or write multiple specs (there doesn't have to be only one). Just looking for your view of the pros and cons.

[mattsaxon]

With regard to UnionPay, there are some specific features of the Scheme when used for ecommerce transactions, that may dictate, or at least encourage a specific Payment Application for it.

I'll get some more details, but the 1st time a card is used with a merchant, there is a One Time Password sent via SMS that needs entering.

I'm not clear that the card can be used with just the usual PAN, Expiry, CVC, certainly there are a few references to UnionPay not being usable for ecommerce transaction out there.

The nature of UnionPay leads me to suggest that whilst it is important, I don't believe it qualifies as ubiquitous. However I'm not suggesting we don't cater for it, in fact quite the opposite, I think it is a really good use case to model how it would work with registration and the creation of payment applications.

For this reason I suggest that we model this at FPWD as something outside of the BasicCardResponse and try to asap work out how we would create a Payment Application to support this registration process.

[dezell]

I am happy to defer to the editors, but it would be nice if FPWD was able to accommodate China in its basic card model. That being said, I appreciate time is of the essence so maybe a commitment to resolve the issue in a future draft is enough.

+1 to the sentiment about China here.

Also, the variability of requirements across card schemes is something that writers of payment applications have had to accommodate for decades. The brute force way of handling it is to write a specific application for a specific acquirer that is hard-coded to (e.g.) require expiry information.

Proper layering of service (which knows what fields are required) and the application (browser?, which should be agnostic) has proven the only mitigating tactic I've seen so far. "Service" need not (in this case) mean a web server - could be a customizable worker. Please ignore any architecture references.

The choices are clear:

1. make everything optional and let the PSP indicate that something is missing.
2. create a service that is configurable, or
3. bake into the application that "this kind of card requires PAN only."

That's our world, and it's a slippery slope.

[dezell]

The choices are clear:

Oops, left one out, maybe the most important one.

4. create an API and hope that everybody will use it as is.

Not to sound glib, this is what we really hope for.

[nickjshearer]

@nickjshearer, do you think we should be using the same response type (with lots of optional attributes) or a different type? We could certainly define a variety of types in the spec or write multiple specs (there doesn't have to be only one). Just looking for your view of the pros and cons.

I do think the same response type should be used. After thinking about this, I don't think they would have to be optional in terms of the JS response, it could simply be noted that those properties may be empty. That is, cardholder name and expiry are required properties, but they may contain empty strings. I'm not sure if that's necessarily better than being explicit in the data model that they're optional fields, but it's another approach.

The nature of UnionPay leads me to suggest that whilst it is important, I don't believe it qualifies as ubiquitous.

@mattsaxon - I do understand it has its challenges, but in terms of transaction volume and cards issued it outranks all the other card networks...the basic card flow should account for the primary card used in China. Like I said, I'm happy to leave it as-is for FPWD and revise it in the future, as long as we take care of it at some point.

[zkoch]

I agree with Nick. We should use the same response and permit empty values. The payment app can be responsible for discerning when to require certain fields and when not to. We already assume that if a merchant supports a given payment method they know how to parse the response for that method, so this just means for Union Pay you may only get a PAN.

[adrianhopebailie]

The content of any payment card is defined by ISO7813 (https://en.wikipedia.org/wiki/ISO/IEC_7813).
eCommerce is effectively a manual capture of what's described in this standard so I think we can define which data is the minimum standard for any payment card but also allow for a bunch of additional data that is useful for non-standard cards.

That said, we need to balance a very flexible format that is very accommodating with a rigid format that potentially forces us to define a new payment method spec for certain cards because they can't be accommodated by the basic spec.

The only benefit of being rigid is that the website can have better defined expectations about what data they will receive. In my opinion, if a website supports UnionPay cards then they expect to do a null value check against certain fields anyway so this value is negligible.

My suggestion is that we define the set of fields that accommodates the most use cases (so at least we standardize on field names) and don't make anything mandatory.

I don't advocate even making the PAN mandatory because we may add an "encrypted_pan" or "tokenised_pan" field which can be used instead of the PAN.

TL;DR: I see no value in mandatory fields. The real value we are getting out of this standard is a set of standardized field names and formats.

[mattsaxon]

The only benefit of being rigid is that the website can have better defined expectations about what data they will receive. In my opinion, if a website supports UnionPay cards then they expect to do a null value check against certain fields anyway so this value is negligible.

A couple of points of clarity;

1. UnionPay cards may have all the fields, it is just UnionPay Debit cards that don't. PR Card Sub-Brands #95 covers this
2. I'd expect this data to be passed and processed by an acquirer rather than the merchant.

-1 to not making the PAN mandatory, when we have tokenised or encrypted PANs, that probably needs another data structure, it will need another PMI for sure. I think it should be clear in the spec that the Payment Application must return a PAN to use the BasicCardResponse format.

[adrianhopebailie]

We should think carefully about why we make any field mandatory. I think you're overstating the value this provides in this context which is why I'm also in favor of using a dictionary here and not an interface.

Making fields mandatory or conform to some format is very useful when gathering direct user input but less so when simply defining a data structure that we are exchanging between the payment app and web app.

What happens if the payment app submits a response with no PAN? Who does the validation and throws an exception? The browser? That seems like a complex flow to handle as a developer.

Why not just leave it to the developer in the website code?

[dlongley]

@adrianhopebailie,

I think you're overstating the value this provides in this context which is why I'm also in favor of using a dictionary here and not an interface.

My understanding is that the algorithm used to copy a dictionary will cause any fields not specified in the Web IDL to be dropped. This sounds like a problem for extensibility. We may need a new Web IDL type that is "just data" but preserves unspecified fields.

[adrianhopebailie]

@dlongley

This sounds like a problem for extensibility

Can you explain why?

[dlongley]

@adrianhopebailie,

Can you explain why?

If you use a dictionary that only defines the field x and you pass {"x": 1, "y": 2} to the API, then the y field gets removed. You can't add arbitrary other fields -- which means you can't easily extend the object.

[adrianhopebailie]

@dlongley

If you use a dictionary that only defines the field x and you pass {"x": 1, "y": 2} to the API, then the y field gets removed. You can't add arbitrary other fields -- which means you can't easily extend the object.

If that's the case then I agree with you. I am not a WebIDL expert but we need something along the lines of how a dictionary/map would work in higher level languages. My understanding is that an interface is even less flexible.

Put differently, I agree that there is absolutely a requirement to be able to pass in fields that are not specified in the WebIDL definition of the object and expect those to be passed on/returned and not simply dropped.

I think @adrianba suggested a new WebIDL type at some point which is likely our only workable solution.

[rsolomakhin]

If you want to pass arbitrary data through the API, the correct syntax object. For example, that's how payment-specific optional object data works in PaymentRequest constuctor.The spec describes in words what the data contains.

5 - If data is not a JSON-serializable object, then throw a TypeError.
6 - If the name of any top level field of data does not match one of the payment method identifiers in supportedMethods, then throw a TypeError.
7 - If the value of any top level field is not a JSON-serializable object, then throw a TypeError.

[halindrome]

But doesn't this mean that any additional data would need to be bundled into some pre-defined field? I think it is important that additional items are able to be added as primary entities. Otherwise it will be challenging to extend the data with, for example, JSON-LD context etc. At least that is my understanding. @dlongley ?

[dlongley]

@halindrome,

Yes, we want to be able to add additional information as we see fit and use well-defined interoperable standards, not relegate extensibility to a corner. I'm not quite sure how this is going to work moving forward with the current API. It seems like we might have to repeat all of the other inputs again in the data section. There's another issue about combining the inputs (#15) which could enable better extensibility vs. the current mechanism, which is fairly rudimentary.

Perhaps one thing we could do in the future is add an overloaded PaymentRequest constructor that takes a payment request message (a fully extensible message that would be defined by the Messaging/HTTP API spec proposals). This message would then be forwarded to a Payment App.

[adrianhopebailie]

This issue has gone from a discussion of the specifics of the Basci Card Payment Method spec to one of general extensibility.

@dlongley and @halindrome let's move conversations about extensibility to PR #133 and Issue #146

@mattsaxon as you have made concrete PR to resolve your initial issue I am going to close this in favour of the thread on PR #114