@rfree190
Yes that is the general idea. Ultimately everything happens on your server because that is where your web application is hosted. But yes, the sha512/md5 are not handled by adjusting server settings. They are handled by editing the source code of your web application.
Here is how it works:
-First a transaction is submitted by a customer on your website, when they click the button that charges their credit card.
-Second authorize.net sends your website a response with the result of the transaction. The response will contain a hash, which will be a long string of alphanumeric characters. The purpose of the hash is for your website to identify that the results of the transaction are actually coming from auth.net, rather than a malicious actor who is posting data to your website in an attempt to compromise it. It is a security feature, in other words.
-Third, your website will have server side programming (meaing the actual files that make your website work will have programming scripts that are ran by the server) that gets the hash from the response. You website will then calculate its own hash, again through programming scripts, and if the two hashes match your website will know that the response is legitimate and can be acted on.
In your case, I would recommend hiring a developer to simply remove the hashing function from your code and accept all responses. You are using AIM and your responses are sent over a TLS connection. You are already very secure before the hash.
The reason I say hire them to turn off the hash validation rather than programming a new sha512 to replace md5 is that the latter option will cost you much more money. And FYI, the fact that you ask this question suggests that you do not have regular contact with professionals who help you with your site. This is not a good thing when you have an SAQ D scope integration. I would advise you extremely to look into your PCI compliance status. You self attest to this every year, typically, but at any time you are subject to an external audit.
The list of requirements to be PCI compliant with your integration is 67 pages or so of bullet points and they impose a large cost if you are going to comply. The quarterly and annual vulnerability scans and penetration tests will probably cost $16,000 a year minimum if I were to guess. If someone reports an issue with your store (whether true or false) and it triggers an external PCI assement, you will be fined $200 to $400 each for every single transaction that has passed over your server if you are not in compliance, according to what I have read.
Go to the PCI security council website and to the document library. Look for SAQs then SAQ D. It will have the list of requirements. Disclaimer is that I do not work for PCI and am not qualified to give any advice to anyone on any subject. This is just what I would be doing if I were in your shoes.
