Our authorize.net processing is done in some OLD perl cgi code - any perl programmers out there?
We are trying to convert to the SHA-512 hashing. Our current processing uses MD5, via the perl module Digest::MD5.
I use LWP::UserAgent to POST directly to the secure.authorize.net gateway transact dll URL.
What I get returned is an array of values. The MD5 hash is currently in the 38th array element. Authorize.net has been unable to tell me where I can find the returned SHA-512 hash value to compare to what I am generating in the program.
For my test:
I changed it to use Digest::SHA for the hashing. I generated the signature key and have it stored in hex in our database.
my $sha512_string = '^' . $auth_net_login_id . '^' . $tranid . '^' . $grandtotal . '^';
my $key = pack 'H*', $sig_key; ##to convert the store hex value to binary - as recommended here
my $sha512 = Digest::SHA->new;
my $sent_sha512_hash = $sha512->hmac_sha512($sha512_string, $key);
When I display that value, it just shows a bunch of weird characters on the screen - I don't know if that's expected or not. I am only displaying it to compare to what comes from authorize.net.
When the values are returned from Authorize.net (in the array), I display all the elements. There is a value in element 68 that looks like a hex value but that isn't what is in the hash that I generated.
So, isn't the hash returned from Authorize.net in the array? If not, then how do I obtain it using the methods we currently have in place? I don't consider this as using the API. Or is the problem that I am hashing it wrong on my end?
I obtained the perl code for our current processing via Authorize.net MANY years ago from one of their perl customers. It has worked fine ever since. I do not have the knowledge, experience or brain power to change the whole process, unless someone could provide all the perl code (I know that's asking a lot). I also have a general knowlege of php but unfortunately the examples on this forum are too different from our perl process to be able to correlate the two.
I hope someone can help! Thanks in advance!
Solved! Go to Solution.
01-16-2019 11:07 AM
I'm not the expert here or do I know what the rest of your code is doing.
However, if you find that you want to try the CGI example I would just leave the LWP as is and see if the CGI test results are somthing that you could then use, just for processing the name/vaules, while leaving the rest of your script alone. Others on here may be able to better help with the use of LWP or even counter my CGI code.
01-23-2019 11:19 AM
@airman81 @Renaissance @jgoebel
Thanks. I'm now to the point where I'm just building the hash with array element numbers of the response returned to me (based on the order of response fields in the AIM Developer Guide), plus for some, I'm just using the values that I sent in the first place. Regardless, in checking, I am using the right fields according to the the HMAC SHA512 Hash feature from the SIM developer guide.
I have that coded and tested and STILL can't match the SHA-512 hash that they're sending back. I've checked and re-checked and I'm hashing the correct fields in the correct order.
The only other thing I can think of is that I'm using the wrong hashing method.
Since the hash they are returning (returned in element 68) is a hex value, I am generating mine as a hex hash.
After I build the SHA hash string which looks like this:
^0^TRUE^1^000000^^^P^CC^XXXX0002^39.00^^Sharon^SHAtest^123 Somewhere Street^
Anywhere^PA^19666^US^6109876543^^sharon.test@test.com^^^^^^^^^8479^
I convert the stored signature key from hex to binary:
my $key = pack 'H*', $sig_key;
then I hash it using Digest::SHA using the hmac_sha512_hex method (I also uppercase it since that's what is in the hash they send back to me).
my $sha512 = Digest::SHA->new;
my $sent_sha512_hash = uc($sha512->hmac_sha512_hex($sha512_string, $key));
I print out the hash I generated and the one they sent to me - and no match.
Any other suggestions? I have to stop in a bit, so I may not response to your posts on a timely basis. But I appreciate ANY and ALL help.
01-23-2019 12:33 PM
01-23-2019 01:25 PM
Yes, I generated the signature key online and saved it in our database. That part I'm sure I got ok.
Then I use the pack statement to convert it to binary and use it as the $key in my prior code. I'm pretty sure that's ok, too, since the pack was recommended by several different people (on this forum and elsewhere).
I send through the string that I provided and the binary key and hash it using the perl module Digest::SHA.
The old MD5 method (still implemented in live version) does it a little differently, and uses Digest::MD5. It started out with a straight ASCII hash value for the md5-hash. It builds a string:
my $md5_string = $md5_hash . $auth_net_login_id . $tranid . $grandtotal;
then:
my $md5 = Digest::MD5->new;
$md5->add($md5_string);
my $sent_md5_hash = uc($md5->hexdigest); #this is what was compared to what they sent.
But the SHA method is a little different. I don't know if I'm doing that wrong - but it uses a string and a key so it's a bit different from MD5.
To be honest, I'm not sure that having you do this on your end is going to help. If it's the data, maybe so - but if it's the hashing method, then your PHP code will do it completely differently and I won't be able to correlate it to what I'm using.
So, I guess what I need is someone who is possibly using the Digest::SHA module in their perl program and can tell me if I'm doing this wrong. OR a perl programmer who can share how they calculated the hash value if using something other than Digest::SHA. I'm open to all suggestions.
I have to stop for now. My brain is fried after 6 hours of solid coding/testing without a break. Thanks.
01-23-2019 01:45 PM
01-23-2019 01:46 PM
01-23-2019 01:51 PM
01-23-2019 01:55 PM
This is getting crazy!!! Everything I read said that the 3 fields that Authorize.net said to use (if you were using the API) would not work - that I needed all 30 fields as is done with SIM!!
I will try it - but it will have to wait until tomorrow at the earliest.
The wheels just keep spinning and spinning and spinning and I'm getting nowhere!! .....
01-23-2019 02:25 PM
01-23-2019 02:25 PM
01-23-2019 02:33 PM - edited 01-23-2019 02:34 PM