To increase the security when dealing with credit card processing via ICVerify’s request/answer methodology, it is possible to encrypt and decrypt this information. However, the documentation is fairly sketchy on this subject, especially when you’re not working in one of the languages used in the examples in the SDK.
After some hair-pulling on why it doesn’t work, I think I’ve got it figured out now. Here are the steps I used to get it working:
- EncryptionManager.DLL is not a normal DLL, it is a .NET assembly. Trying to register it with regsrv32 will result in an error message, saying that it doesn’t have a DLLRegisterServer entry point. The trick is to use either the .NET gacutl.exe or the icvgacutil.exe supplied on the ICVerify SDK CD.
UPDATE:You also have to use regasm to register the assembly! - Once registered at the Global Assembly Cache (GAC), the name of the DLL is not EncryptionManager. To make things more interesting, I had to link to the name FirstData.Encryption.Facade.EncryptionManager. The only way to figure this out is to dig through the registry after registering the DLL, or to use the option on the GAC utility to write out a registry modification file.
- In Progress, you can use the COM viewer to access EncryptionManager.tlb, and see the different methods defined in the DLL. You’re only going to be using 2 of them most likely: EncryptThirdPartyMessage and DecryptThirdPartyMessage. Both use the creation date of the file you’re working with, so be careful not to copy this file or move it across file systems.
The Progress code I used to encrypt a request file is as follows:
DEFINE VARIABLE vhEncryption AS COM-HANDLE NO-UNDO.
DEFINE VARIABLE vcPrepFilename AS CHARACTER NO-UNDOINITIAL “C:\TEMP\icver001.prep”.
DEFINE VARIABLE vcReqFilename AS CHARACTER NO-UNDO
INITIAL “C:\TEMP\icver001.req”.
DEFINE VARIABLE vcEncrypted AS CHARACTER NO-UNDO.
DEFINE VARIABLE vcRequest AS CHARACTER NO-UNDO.
DEFINE STREAM sOutput.UPDATE vcRequest FORMAT “x(60)”.
CREATE “FirstData.Encryption.Facade.EncryptionManager” vhEncryption.
OUTPUT STREAM sOutput TO VALUE(vcPrepFilename).
vcEncrypted = vhEncryption:EncryptThirdPartyMessage(vcPrepFilename,vcRequest).
PUT STREAM sOutput UNFORMATTED vcEncrypted.
OUTPUT STREAM sOutput CLOSE.
OS-RENAME VALUE(vcPrepFilename) VALUE(vcReqFilename).
The decryption routine is somewhat simpler, since we don’t have to move files around so much:
DEFINE VARIABLE vhEncryption AS COM-HANDLE NO-UNDO.
DEFINE VARIABLE vcAnswerFilename AS CHARACTER NO-UNDOINITIAL “C:\TEMP\icver001.ans”.
DEFINE VARIABLE vcEncrypted AS CHARACTER NO-UNDO.
DEFINE VARIABLE vcDecrypted AS CHARACTER NO-UNDO.
DEFINE STREAM sInput.CREATE “FirstData.Encryption.Facade.EncryptionManager” vhEncryption.
INPUT STREAM sInput FROM VALUE(vcAnswerFilename).
IMPORT STREAM sInput UNFORMATTED vcEncrypted.
vcDecrypted = vhEncryption:DecryptThirdPartyMessage(vcAnswerFilename,vcEncrypted).
INPUT STREAM sInput CLOSE.
These code snippets should have some more error checking. Also, the request can be more than one line, depending on the version of ICVerify and the answer file settings in the configuration.
Related posts:
Hey Ronald, interesting article.. and right where I am mired down
I have an issue with “third party” ICV Requests and need to get more info on teh encryption / dycryption. In particular, I need to figure out why ICVerify GUI works with CVV2, btu request files dont.
The SDK is no help here, and the ICVGui requests are …. encrypted.. so I cant even check them to see what is up with that.
By Any chance, do you have a working request viewer (or code that I can get from you that is close) ? If I can figure out the formatting they are using, I might get this pos working.
Thanks.
Charles…
Hey Charles,
Sorry, the only example I have is the code above. It was hard enough to get that going…
Good luck, and let me know if you get it working on your platform!
Cheers,
Ronald.
Hey Ronald, interesting article.. and right where I am mired down
I have an issue with “third party” ICV Requests and need to get more info on teh encryption / dycryption. In particular, I need to figure out why ICVerify GUI works with CVV2, btu request files dont.
The SDK is no help here, and the ICVGui requests are …. encrypted.. so I cant even check them to see what is up with that.
By Any chance, do you have a working request viewer (or code that I can get from you that is close) ? If I can figure out the formatting they are using, I might get this pos working.
Thanks.
Charles…
Hey Charles,
Sorry, the only example I have is the code above. It was hard enough to get that going…
Good luck, and let me know if you get it working on your platform!
Cheers,
Ronald.
Ronald,
Though I am not a Progress guy, this was very helpful. One thing of note. This technique failed on ICVerify 4.04 returning “NINVALID REQUEST: REQUEST IS NOT ENCRYPTED”. It seems that on the encrypt you now must pass the “request file name”, not the temporary file name “even if that file has not been created” (that according to tech support). Of course the file cannot be extant as you risk ICVerify Multiuser grabbing it before you are done with it. Once I made that change all was well. Just thought I’d pass this along.
Regards,
Michael
Hi Michael,
That’s interesting… since one change I had to make is to use OS-RENAME versus a more elaborate renaming routine, because the creation date of the file was used in the encryption process. So with 4.04 I guess they no longer use the creation date, since support stated that the file doesn’t have to be created.
we haven’t upgraded to 4.04 yet, but I’ll keep this in the back of my mind. Thanks!!
Ronald,
Though I am not a Progress guy, this was very helpful. One thing of note. This technique failed on ICVerify 4.04 returning “NINVALID REQUEST: REQUEST IS NOT ENCRYPTED”. It seems that on the encrypt you now must pass the “request file name”, not the temporary file name “even if that file has not been created” (that according to tech support). Of course the file cannot be extant as you risk ICVerify Multiuser grabbing it before you are done with it. Once I made that change all was well. Just thought I’d pass this along.
Regards,
Michael
Hi Michael,
That’s interesting… since one change I had to make is to use OS-RENAME versus a more elaborate renaming routine, because the creation date of the file was used in the encryption process. So with 4.04 I guess they no longer use the creation date, since support stated that the file doesn’t have to be created.
we haven’t upgraded to 4.04 yet, but I’ll keep this in the back of my mind. Thanks!!