[Update: The California Governor vetoed AB 779. See more current information on merchants and the protection of credit card data.]
I am no fan of the part of California’s pending AB 779 that absolutely forbids merchants from retaining certain payment data. It smacks of a legislature precisely (an incompetently) dictating technology. When a legislature dictates technology, it risks misunderstanding. It stifles innovation, and raises problems as technology evolves.
Let’s dig into the details. AB 779 proposes to add Section 1724.4(b)(2) to the Civil Code. The section flatly forbids a merchant from storing:
"sensitive authentication data subsequent to authorization . . . . Sensitive authentication data includes, but is not limited to, all of the following: . . .
(B) The card verification code or any value used to verify transactions when the payment device is not present."
Notice that the quoted language does not definitively tell us what "sensitive authentication data" is. It says the term includes – but is not limited to – certain things. That’s unsettling. Apparently the legislature expects a merchant to make a guess about what does and does not constitute "sensitive authentication data".
In the 1990s a pioneering Internet payment company (one of PayPal's many early competitors) named First Virtual Holdings invented a commercially-viable payment system that involved the payer giving the merchant a semi-secret code to kick-off a transaction. But that code was not really intended to be a hard-core secret. One of the key ways the payer could give the semi-secret code to the merchant was via unencrypted, Internet e-mail. See Benjamin Wright, The Law of Electronic Commerce, page ET1:19, Second Edition, published by Little, Brown & Company, 1995. Clearly the First Virtual system contemplated that merchants would store the semi-secret code, such as in their usual e-mail archives. Furthermore, First Virtual obviously considered the semi-secret code sensitive enough that merchants were not expected to publish it on a bulletin board or in a public directory.
If someone tried to use the innovative First Virtual system under AB 779, new Section 1724.4(b)(2) would prevent the system from working as intended. It would prohibit the merchant from storing sensitive authentication data, which according to the language of 1724.4(b)(2) includes the semi-secret code. The semi-secret code certainly appears to fit AB 779's definition of "sensitive authentication data", which includes but is not limited to things like a "value used to verify transactions when the payment device is not present." Without the semi-secret code, a First Virtual transaction could not be verified.
[At this point we have to take a pit-stop and examine whether Section 1724.4(b) is intended to cover a payment system like First Virtual. Section 1724.4(b) purports to cover any merchant that "accepts as payment a credit card, debit card, or other payment device." Maybe the First Virtual system did not involve a payment "device" because it did not involve a plastic card. However, if that is the case, then Section 1724.4(b) does not cover virtual credit card numbers. With virtual credit card numbers, payers use Internet-only card numbers that are not tied to physical plastic cards. Virtual credit card numbers work on the Internet the same way that numbers associated with plastic cards work on the Internet. They involve all the same data elements. It would seem, therefore, that the legislature intends merchants to protect data related to virtual credit card numbers the same as data related to plastic cards. And if the legislature intends to cover virtual credit card numbers, then it intends to cover First Virtual’s system too. Like virtual credit card numbers, the First Virtual system simply involves the exchange of codes. . . . Now, hang in here with me a moment. Suppose an apologist for AB 779 says that that Section 1724.4(b) is not intended to cover virtual payment methods like First Virtual or virtual credit card numbers because they do not involve physical "devices". Okay. If that is the case, then logically Section 1724.4(b) does not cover any Internet or mail-order payments. The reason is that Internet and mail-order credit card transactions do not literally involve acceptance of physical cards or devices. As I said above, 1724.4(b) covers merchants that accept "cards" or "devices". But if "cards" or "devices" mean only physical stuff, then Internet and mail-order merchants are not accepting those things. Internet/mail-order merchants have no knowledge of or contact with physical cards or devices. When a payer gives credit card data to an Internet or mail-order merchant, the merchant does not know whether the data connects to a plastic card or a virtual card. . . . But surely the legislature intends Section 1724.4(b) to cover typical Internet and mail-order credit card transactions. Thus, it seems certain that the legislature likewise intends to cover things like First Virtual and virtual credit card numbers. {Footnote: As you can see from the analysis in this pit-stop, Section 1724.4(b) is ambiguous on whether it covers Internet and mail-order credit card transactions. Such ambiguity bespeaks poorly-crafted legislation.}]
Let’s go back to the language from Section 1724.4(b)(2) quoted at the beginning of this note. It says data that may not be stored includes "any value used to verify transactions when the payment device is not present." Sometimes, to use my credit card at a physical point of sale device, I have to enter my zip code. My zip code is in fact a value used to verify the transaction. Does this mean merchants cannot story my zip code? If they cannot store my zip code, then how can an Internet or mail-order merchant work out shipping and returns with me? All Internet and mail-order merchants store zip codes.
Now, I acknowledge that when I'm using my card at a physical point-of-sale device, the zip code is not a "value used to verify transactions when the payment device is not present." My card is present.
But think about this . . . Merchants always depend on disclosure of my zip code when they accept my credit card by mail-order or over the Internet. If I don't give them a good zip code, the transaction cannot be verified. So in point of fact, in an Internet or mail-order scenario, my zip code is a value used to "verify transactions when the payment device is not present." When requested in either the mail-order scenario, the Internet scenario or the point-of-sale scenario, the zip code does in fact verify the transaction. Therefore, Section 1724.4(b)(2) -- if understood literally -- forbids the storage of zip codes by mail-order and Internet merchants. {Footnote to people who are skeptical of my argument here: Remember the style the legislature used when it defined "sensitive authentication data". 1724.4(b) tells us what the term means by saying it includes but is not limited to certain itemized things. The legislature left the definition open-ended. That implies the term should be interpreted broadly, not narrowly. Essentially, the legislature said, when in doubt about whether a data element constitutes "sensitive authentication data", you should assume it does. Therefore, a rational person can conclude that a zip code constitutes "sensitive authentication data" that may not be stored.}
Now, hang in here with me. I acknowledge that the legislature probably does not intend to forbid the storage of zip codes by mail-order or Internet merchants. However – and this is my point – the literal legislative language is confusing here. The legislature has not been crystal clear in defining "sensitive authentication data". The words themselves seem to suggest that "sensitive authentication data" includes zip codes, and that suggestion would cause fits for Internet and old-fashioned mail-order merchants.
Confusing language like this threatens to be unduly constricting as time passes and people like First Virtual try to innovate. Section 1724.4(b) is poor legislation.
I am no fan of the part of California’s pending AB 779 that absolutely forbids merchants from retaining certain payment data. It smacks of a legislature precisely (an incompetently) dictating technology. When a legislature dictates technology, it risks misunderstanding. It stifles innovation, and raises problems as technology evolves.
Let’s dig into the details. AB 779 proposes to add Section 1724.4(b)(2) to the Civil Code. The section flatly forbids a merchant from storing:
"sensitive authentication data subsequent to authorization . . . . Sensitive authentication data includes, but is not limited to, all of the following: . . .
(B) The card verification code or any value used to verify transactions when the payment device is not present."
Notice that the quoted language does not definitively tell us what "sensitive authentication data" is. It says the term includes – but is not limited to – certain things. That’s unsettling. Apparently the legislature expects a merchant to make a guess about what does and does not constitute "sensitive authentication data".
In the 1990s a pioneering Internet payment company (one of PayPal's many early competitors) named First Virtual Holdings invented a commercially-viable payment system that involved the payer giving the merchant a semi-secret code to kick-off a transaction. But that code was not really intended to be a hard-core secret. One of the key ways the payer could give the semi-secret code to the merchant was via unencrypted, Internet e-mail. See Benjamin Wright, The Law of Electronic Commerce, page ET1:19, Second Edition, published by Little, Brown & Company, 1995. Clearly the First Virtual system contemplated that merchants would store the semi-secret code, such as in their usual e-mail archives. Furthermore, First Virtual obviously considered the semi-secret code sensitive enough that merchants were not expected to publish it on a bulletin board or in a public directory.
If someone tried to use the innovative First Virtual system under AB 779, new Section 1724.4(b)(2) would prevent the system from working as intended. It would prohibit the merchant from storing sensitive authentication data, which according to the language of 1724.4(b)(2) includes the semi-secret code. The semi-secret code certainly appears to fit AB 779's definition of "sensitive authentication data", which includes but is not limited to things like a "value used to verify transactions when the payment device is not present." Without the semi-secret code, a First Virtual transaction could not be verified.
[At this point we have to take a pit-stop and examine whether Section 1724.4(b) is intended to cover a payment system like First Virtual. Section 1724.4(b) purports to cover any merchant that "accepts as payment a credit card, debit card, or other payment device." Maybe the First Virtual system did not involve a payment "device" because it did not involve a plastic card. However, if that is the case, then Section 1724.4(b) does not cover virtual credit card numbers. With virtual credit card numbers, payers use Internet-only card numbers that are not tied to physical plastic cards. Virtual credit card numbers work on the Internet the same way that numbers associated with plastic cards work on the Internet. They involve all the same data elements. It would seem, therefore, that the legislature intends merchants to protect data related to virtual credit card numbers the same as data related to plastic cards. And if the legislature intends to cover virtual credit card numbers, then it intends to cover First Virtual’s system too. Like virtual credit card numbers, the First Virtual system simply involves the exchange of codes. . . . Now, hang in here with me a moment. Suppose an apologist for AB 779 says that that Section 1724.4(b) is not intended to cover virtual payment methods like First Virtual or virtual credit card numbers because they do not involve physical "devices". Okay. If that is the case, then logically Section 1724.4(b) does not cover any Internet or mail-order payments. The reason is that Internet and mail-order credit card transactions do not literally involve acceptance of physical cards or devices. As I said above, 1724.4(b) covers merchants that accept "cards" or "devices". But if "cards" or "devices" mean only physical stuff, then Internet and mail-order merchants are not accepting those things. Internet/mail-order merchants have no knowledge of or contact with physical cards or devices. When a payer gives credit card data to an Internet or mail-order merchant, the merchant does not know whether the data connects to a plastic card or a virtual card. . . . But surely the legislature intends Section 1724.4(b) to cover typical Internet and mail-order credit card transactions. Thus, it seems certain that the legislature likewise intends to cover things like First Virtual and virtual credit card numbers. {Footnote: As you can see from the analysis in this pit-stop, Section 1724.4(b) is ambiguous on whether it covers Internet and mail-order credit card transactions. Such ambiguity bespeaks poorly-crafted legislation.}]
Let’s go back to the language from Section 1724.4(b)(2) quoted at the beginning of this note. It says data that may not be stored includes "any value used to verify transactions when the payment device is not present." Sometimes, to use my credit card at a physical point of sale device, I have to enter my zip code. My zip code is in fact a value used to verify the transaction. Does this mean merchants cannot story my zip code? If they cannot store my zip code, then how can an Internet or mail-order merchant work out shipping and returns with me? All Internet and mail-order merchants store zip codes.
Now, I acknowledge that when I'm using my card at a physical point-of-sale device, the zip code is not a "value used to verify transactions when the payment device is not present." My card is present.
But think about this . . . Merchants always depend on disclosure of my zip code when they accept my credit card by mail-order or over the Internet. If I don't give them a good zip code, the transaction cannot be verified. So in point of fact, in an Internet or mail-order scenario, my zip code is a value used to "verify transactions when the payment device is not present." When requested in either the mail-order scenario, the Internet scenario or the point-of-sale scenario, the zip code does in fact verify the transaction. Therefore, Section 1724.4(b)(2) -- if understood literally -- forbids the storage of zip codes by mail-order and Internet merchants. {Footnote to people who are skeptical of my argument here: Remember the style the legislature used when it defined "sensitive authentication data". 1724.4(b) tells us what the term means by saying it includes but is not limited to certain itemized things. The legislature left the definition open-ended. That implies the term should be interpreted broadly, not narrowly. Essentially, the legislature said, when in doubt about whether a data element constitutes "sensitive authentication data", you should assume it does. Therefore, a rational person can conclude that a zip code constitutes "sensitive authentication data" that may not be stored.}
Now, hang in here with me. I acknowledge that the legislature probably does not intend to forbid the storage of zip codes by mail-order or Internet merchants. However – and this is my point – the literal legislative language is confusing here. The legislature has not been crystal clear in defining "sensitive authentication data". The words themselves seem to suggest that "sensitive authentication data" includes zip codes, and that suggestion would cause fits for Internet and old-fashioned mail-order merchants.
Confusing language like this threatens to be unduly constricting as time passes and people like First Virtual try to innovate. Section 1724.4(b) is poor legislation.
Computerworld reports that the National Retail Federation has offered a creative new idea for enabling merchants to protect credit card data. NRF says the payment industry can stop demanding that merchants keep lots of data for purposes like audit, dispute resolution and chargebacks. Instead, NRF says, merchants could for each transaction just keep "authorization code" and "truncated receipt". Here is the comment I posted under the article at Computerworld: "NRF proposes the innovative solution of requiring merchants to store just 'authorization code' and 'truncated receipt'. This is the kind of creative thinking the industry needs. However, this solution might be illegal under California's pending Assembly Bill 779. The words of AB 779 are unclear and poorly defined. For example, AB 779 would forbid a merchant from storing various data elements such as 'payment verification code' and 'payment verification value'. The legislation does not define these terms, and my research finds no clear industry definitions for these terms. (Part of the issue is that different industry players use different words. Further, neither PCI version 1.1 nor its Glossary defines 'payment verification code' and 'payment verification value'.) Therefore, AB 779, if it becomes law, would cause confusion and roadblocks as the industry changes and technology evolves. Parties would not know whether the good data elements they want to store will later in court be interpreted as the data elements AB 779 bans from storage."
ReplyDeleteCertain technicalities regarding credit card transactions can be easily sidestepped. for example, if someone is paying with an expired credit card (to which a valid one of the same account has been issued but is not present), you can sometimes manually enter the numbers and then make up a valid expiration date. 90% of the time it works.
ReplyDeletebut yes, sensitive information is not allowed to be stored. if i were to copy my customer's credit card files into a text file and keep them on my pc for ANY reason, i can be prosecuted.
the laws are only going to get more strict, too.