Is anyone using ICVERIFY?

[rdonnay]

I have a customer who wants me to help him put AES encryption into his application.

I don't have days of time to work on this and hope that I can get a simple answer.

He is using ICVERIFY.

His application writes a .REQ file with credit card info. ICVERIFY transmits that to the credit card authorizer.

There is now a requirement that the contents of the .REQ file be AES encrypted.

The documentation I received from ICVERIFY is ambiguous at best.

They say to create a .NET, C++ or VB program to encrypt the file, yet what I understand is that new security requirements say that no file must be written to a local drive. It seems to me that the string should be encrypted instead before writing the file. They say that they recognize 128 bit AES encryption. I know nothing about this.
Has anyone used an AES encryption DLL?

[patito]

Hi Roger

Install API 4400 staff CryptoSysApi (//http://www.cryptosys.net/rijndael.html)
I think that only personal, see link version is free or web page
Compile test.xpj, and then run aes.exe
Ot4xb is free distribuccion

Congratulations
Happy New Year 2011
I am 66 years

Hector Pezoa

[BruceN]

I was told the req/ans file sytem wasn't compliant in any form as the card number should not ever be on the hard drive (encrypted or otherwise).

So we switched systems a year or so ago. We now use ChargeItPro. They are a small company in CA and have been a DREAM to work with. Support has been as good as here (and that's saying a lot!) It should take one of you wizards only a day or so to FULLY integrate with CIP. I would recommend calling them (800) 989-2135 ask for Phil or Anson. Feel free to drop my name.

Hope it helps someone....

Bruce Neuman

[Cliff Wiernik]

That is not correct. The credit card number/expiration date/name on the card can be stored in encrypted form. It is the 3 digit code on the back of the card that can never be stored, even in encrypted form for longer than is needed to process the transaction. That is typically online so it is not stored, but some processes would require storage for small periods of time, but then destruction of the data. As such, we do not gather that date as we do not process instanteneous.

If your statement about the card number was correct, you could never put a credit card number in for a monthly recurring payment, like payment of a cable TV bill. The company has to save it somewhere. If you look at the PCIDSS rules, I think this interpretation is correct.

You can never store, even encrypted, the code from the back of the credit card. However, the other data can be stored, if encrypted, if required for business purposes, which is often the case, the PAN, expiration date and name on the card. Per section 3 and the table on the PCI website.

Cliff

[BruceN]

OK..technically you ARE right... however... I oversimplified.

I should have said: if you have access to the card number then YOU need to be PCI certified. By never having it, we don't need to go thru any certification process. That was the intent - to avoid having to be 'certified' at the cost of MANY thousands of dollars, Deutchmarks, Kroner, or whatever.

I spoke with a certification company about a year ago and they said that if we EVER had access to the number we would technically need to have our program undergo certification to be 'PCI compliant' (they wanted about $10,000 to do it). Also, ANY changes we made would require re-certification. That was something we wanted to avoid.

With CIP we CAN store the card numbers.. up on their server and reference them for recurrent billing (we are doing final testing on that now).

ANYTHING I can do to avoid an expensive, formal 'certification' process (for any sertification) is a plus in my book! CIP allowed me to do it.

Is that more clear

[Cliff Wiernik]

I understand your point of view.