[Tokenized Card Payment] Replace usage of 'last4' with 'suffix'

[nickjshearer]

Ian requested some feedback on this proposal, which I am happy to provide. Note that my feedback should not be taken as an endorsement of the proposal itself.

In https://w3c.github.io/webpayments/proposals/tokenized_cards.html#response

dictionary TokenizedCardResponse : BasicCardResponse {
    required DOMString cardLast4;
             DOMString tokenType;
             DOMString tokenRequesterId;
};

Although many cards and networks sanitize to the last four digits, there are some edge cases where that doesn't happen. I would recommend renaming this to something along the lines of cardSuffix.

[doodi-v1]

While I agree edge cases need to be addressed, cardSuffix seems less intuitive than cardLast4 and has the potential to be less standardized (maybe this will help to push the edges toward the center). To support the edge cases I would recommend adding cardSuffix as an optional parameter (I'm new to this group and this spec so I apologize if optional parameters are not supported).

The other note that I would add, and another can of worms, I would recommend moving away from card references and instead replace "card" with "account". There are many payment types that do not have physical cards and at some point as the payments environment evolves the reference to card may date the spec.

[kphfb]

I tend to agree with Steve on this. cardSuffix feels much less intuitive to me. @nick Can you elaborate bit on the cases where last 4 doesn’t make sense? From: Steve Sommers <[email protected]> Reply-To: w3c/webpayments <[email protected]> Date: Tuesday, February 14, 2017 at 8:51 AM To: w3c/webpayments <[email protected]> Cc: Subscribed <[email protected]> Subject: Re: [w3c/webpayments] [Tokenized Card Payment] Replace usage of 'last4' with 'suffix' (#211) While I agree edge cases need to be addressed, cardSuffix seems less intuitive than cardLast4 and has the potential to be less standardized (maybe this will help to push the edges toward the center). To support the edge cases I would recommend adding cardSuffix as an optional parameter (I'm new to this group and this spec so I apologize if optional parameters are not supported). The other note that I would add, and another can of worms, I would recommend moving away from card references and instead replace "card" with "account". There are many payment types that do not have physical cards and at some point as the payments environment evolves the reference to card may date the spec. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<#211 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AF_3ODvzweOalepXC6vGaIthblh_Ok5Jks5rcduigaJpZM4L_9p9>.

[nickjshearer]

@nick Can you elaborate bit on the cases where last 4 doesn’t make sense?

Because merchants in some jurisdictions may be subject to different requirements, be them lax or more stringent. FACTA in the US, for example, requires five digits or less - there are some merchants (a small number, I'll give you) who truncate to five instead of four. Since the goal for this spec seems to be to allow tokenized cards to plug directly into a basic card processing flow we should probably try and support those merchants with their existing flows.

Putting that aside, there's nothing to stop a regulator in a particular country from deciding that they want to, say, truncate to three digits on receipts. So it's because of those global variations that I'd strongly recommend not placing any assumptions about the length of the number in the property name. If suffix doesn't feel right I'm sure we can find something else that fits?

The other note that I would add, and another can of worms, I would recommend moving away from card references and instead replace "card" with "account".

Given this seems to inherit in part from basic card I'm not sure that makes sense without changing the basic card naming to match (which I think might be a good idea).

[kphfb]

Interesting, so how would the provider of the token know how many digits to include? Also, I’m fine w/ the card vs account change, but won’t make it until it’s also done in the basic card spec so they stay in alignment From: Nick Shearer <[email protected]> Reply-To: w3c/webpayments <[email protected]> Date: Thursday, February 16, 2017 at 11:34 AM To: w3c/webpayments <[email protected]> Cc: Kevin Hurley <[email protected]>, Comment <[email protected]> Subject: Re: [w3c/webpayments] [Tokenized Card Payment] Replace usage of 'last4' with 'suffix' (#211) @nick<https://github.com/Nick> Can you elaborate bit on the cases where last 4 doesn’t make sense? Because merchants in some jurisdictions may be subject to different requirements, be them lax or more stringent. FACTA in the US, for example, requires five digits or less - there are some merchants (a small number, I'll give you) who truncate to five instead of four. Since the goal for this spec seems to be to allow tokenized cards to plug directly into a basic card processing flow we should probably try and support those merchants with their existing flows. Putting that aside, there's nothing to stop a regulator in a particular country from deciding that they want to, say, truncate to three digits on receipts. So it's because of those global variations that I'd strongly recommend not placing any assumptions about the length of the number in the property name. If suffix doesn't feel right I'm sure we can find something else that fits? The other note that I would add, and another can of worms, I would recommend moving away from card references and instead replace "card" with "account". Given this seems to inherit in part from basic card I'm not sure that makes sense without changing the basic card naming to match (which I think might be a good idea). — You are receiving this because you commented. Reply to this email directly, view it on GitHub<#211 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AF_3OKiU5mXsEl6QxIyFzx4Bu7A_7Xo9ks5rdKTUgaJpZM4L_9p9>.

[ianbjacobs]

@doodi-v1 wrote:

'I would recommend moving away from card references and instead replace "card" with "account".'

@nickjshearer wrote:

"Given this seems to inherit in part from basic card I'm not sure that makes sense without changing the basic card naming to match (which I think might be a good idea)."

-1 to this proposal. Basic Card really is meant to address card payments, using PR API instead of
a Web form. Creating a different abstraction that is more generic will dilute that message. It will also slow down the progress of that specification to figure out what abstraction to create to
encompass other payment systems (and what filters are appropriate). I also don't know what
impact this would have on existing implementations.

It's fine to propose new abstraction payment methods for consideration, but I don't think we should disrupt Basic Card at this point.

Ian

[adrianhopebailie]

Interesting, so how would the provider of the token know how many digits to include?

That's not something they'd know from this spec. It's specific to the local scheme rules. The spec must simply accommodate as many of the various rules that are out there.

Another consideration is where this field holds just the "unmasked" PAN values (1234) or a masked PAN including the masking characters (************1234). If it is the latter I'd recommend calling the field maskedPan or similar.

[ianbjacobs]

@adrianhopebailie,

The spec says "the last 4 digits of the original (non-token) primary account number (PAN) for the payment card. This may be used for display purposes during the purchase."

So I think that answers your question: the value does not include the masking characters.

Regarding the name, Basic Card uses "cardNumber" so how about "cardNumberHint" ?

Ian

[ianbjacobs]

Now that we have a tokenization spec repo, I am closing this issue in favor of:
w3c/webpayments-methods-tokenization#4

Ian