MD5 hash and OpenCart (2.2.0.0)

[jwyatt]

Good afternoon!

We have an OpenCart 2.2.0.0 site and also received the lovely and ominous MD5 email notification from Authorize.net.

We've done a lot of digging, both in this forum and on the developer/API links provided by Authorize.net and unfortunately we are still completely stumped as to what we must do to make the necessary changes to our site.

One Authorize.net live chat person told us there are Evangelist Developers here on this forum who may be able to help us.

I sincerely hope this is true =)

Thanks for your help!

Jacob

[Renaissance]

Your first step would be to determine which integration method your OpenCart 2.2.0.0 site uses. There are the deprecated methods SIM/DPM which use one hashing process, and then there is the deprecated AIM method, and also the modern integation methods which use a different hashing process.

I have no clue at all about open cart. Questions to ask would be - does your customer type full payment card numbers on a webpage hosted on YOUR server? If yes, are those card numbers transmitted by your server, or are they tokenized in the browser?  If they are transmitted by your server then you are AIM or the modern API. 

If they are tokenized you are using Accept js or possibly DPM.  If you answer no to that first question you are most likely using SIM. 

And here's another shortcut, do you have to send an md5 fingerprint in order to make a successful transaction? That narrows things down a lot. Yes means use the DPM/SIM hashing method, no means use the modern API hashing method.

The hashing techniques have been beaten to a bloody pulp all over this forum, and once you narrow down how you are integrating you'll be on your way.  

[jwyatt]

Renaissance, thank you so much for your kind answer.

Our IT person who built this site has informed me that our site is using the AIM method. He also said the crux of his knowing how to move forward is: Which file needs to be changed/recoded to transmit the md5 hash information?

Thanks again, Renaissance!

[Renaissance]

Ok here are a few pointers. First you don’t have to transmit anything in your transaction, MD5 or sha512. Second, there IS a verification step you can do with the sha512 and the old MD5, until MD5 goes and you will be able to do only sha512.

However, this AIM verification, per authorizes developer guide is “a redundant security check”. It’s not really that Important. An attempt at the AIM verification process recently turned into an 8 day or longer nightmare for another user. This user is using a very uncommon programming language, so that may be the source.

The API method I use has the same parameters for what has been released so far. I have 100% tested and working php code on a thread I started, for that method. Find that thread and it’s the very first post. That’s what you use.

If it doesn’t work very fast, give up and wait for the AIM guide to be updated. There may still be info we are missing. And this isn’t worth that many hours in the frying pan. It’s not required and has a very limited benefit.

[jwyatt]

Thank you once again, Renaissance!

I went to your user profile to see your (many) posts - do you remember any key words pertaining to the 100% tested and working php post which would help me narrow down my search? :)

(Is this the one? https://community.developer.authorize.net/t5/Integration-and-Testing/Working-php-hash-verification/m... -- if so I'll pass this on to IT)

[Renaissance]

That’s it.

[jwyatt]

Thank you, Renaissance

This still falls way outside our expertise. We've reached out to some local developers for help. But in the meantime, I noticed two things:

1. Our Authorize.net's MD5 settings are completely blank

2. The MD5 setting in the Payments settings in our OpenCart back-end is also completely blank.

This leads me to believe we have never used MD5 - and perhaps it is not even needed for what we're doing?

Any thoughts about that? =)

[Renaissance · Accepted solution]

The MD5 is the old hash. The setting has been taken out of the merchant inferface as it was schedule to is most likely what's happening. That or you never used it.  The new hash is the sha512.  You probably never used the MD5 hash. It's not required to do business, and neither is the sha512.

For AIM, this is something that you work on a few hours, and then if it doesn't work don't worry about it is how I see it.  Your transaction responses already come over SSL encryption. The DPM/SIM users have to do the hash just to submit a transaction, so they're in the frying pan for however long it takes to figure this out and have no choice. 

If you go to the authorize.net support page and do a search for sha512 hash you'll get some info. Also google "authorize.net AIM developer guide". And that guide you will get info.  It is described in terms of "there isn't as much benefit" and "is a redundant security check" in reference to your integration. 

[Renaissance]

https://support.authorize.net/s/global-search/sha512

[jwyatt]

Many thanks again, Renaissance! I believe this clarifies that, for us, we need not concern ourselves further - since we never have used the MD5 hash. Thanks again and wishing you all the best!