Fear of PCI/CISP

Being in the business of implementing payment solutions, we all know that adherence to Visa's PCI/CISP security standard is a serious matter (see standard here).  Of specific focus is the matter of encrypting sensitive data like the primary account number ('PAN') and Track II. 

The matter of Track II data is simple: it can never be stored on disk, not even in encrypted form (the PCI/CISP standard is quite clear about that).  But, in adhering to that CISP item, we've seen organizations go too far and trip us up unexpectedly in the process. 

We recently had a situation where we were attempting to implement a Debit/EBT gateway to FDR for a large retail acquirer.  Most notably, in terms of 0400 reversals, FDR (and, indeed ALL gateways by my experience) insist on ISO Field 35 containing the exact Track II contents as the original.  This requirement poses no problem for host-generated reversals (like when your app times out FDR before they can send a reply) because the Track II info is still available in memory.  But terminal-generated reversals are a different story.

Relatively simple POS implementations maintain a small list of open transactions in memory and generate reversals when their timeouts hit.  Howver, larger organizations have store-based controllers which govern the payment operations of a number of registers.  Often times all transactions are written to disk, and reversals generated a significant period later (say, 30 minutes...and any time up 24 hourss later is still okay as long as you've not extracted on the host).  You see the issue here: the reversal is generated from the item on disk, and writing Track II to disk is a no-no, even if encrypted. 

As was the case with our client.  So, following good PCI/CISP compliance, this client truncated Track II to look like this "PAN=0" (where PAN is the 16-digit debit card number).  But PCI/CISP says nothing about removing expiration number.  It's okay to keep that around on disk.  It's what's to the right of expiration date that worries Visa, namely the CVV and, if present, a PVV (PIN Verification Value, aka, PIN offset).

That overzealous truncation of the expiration date caused a huge headache for our application - our acquiring logic parses a track with the understanding that an expiration date will follow the field separator.  Our logic simply did not know what to make of the "=0" and I suspect many - if not all - issuer systems would make a similar stumble, meaning the ability to consummate an online Debit reversal here would be severely compromised.

While the FDR specs do call for the 0400 to contain the exact contents of the related 0200, that clearly can't happen here due to the nature of the client's front-end system.  But removing the expiration date is a step too far.  I suspect most issuers will process the reversal without issue if the Track in Field 35 contains the information through the expiration date.  We've advised our customer to add the expiration date back.

------------------

April 2010 Update:  Since the time of my original post, there’s been a major evolution in the way track data is handled on 04xx series messages -  namely, gateways and authorizers are aggressively undertaking the adaptation of “track data elimination.”  See my July, 2008 post Cracking Down on SAF Queue Content.

Comments

[Cheap Computers Canada]

This requirement poses no problem for host-generated reversals (like when your app times out FDR before they can send a reply) because the Track II info is still available in memory.