cancel
Showing results for 
Search instead for 
Did you mean: 

MD5 Hash & SIMResponse.Validate Returning False

Hello,

 

I'm creating an Authorize.net integration using Asp.net and VB with the SIM API running on .net 4.0 on an Amazon EC2 Win 2008 server.  This is my first time developing an integration with Authorize.net, so I'm using the C# .net SDK binaries in a few places on the assumption that they'll make things go more smoothly.  I am running Authorize.Net in test mode.

 

The entire purchase process works properly in test mode except that SIMResponse.Validate always returns false on our Relay Response page.

 

Here is the relevant VB code:

Order = new SIMResponse(Request.Form)
MerchantHash = ConfigurationSettings.AppSettings("AuthorizeGUID")
AuthorizeAPILoginID = ConfigurationSettings.AppSettings("AuthorizeAPILoginID")
AuthorizeRepsoneVerifiedF = Order.Validate(MerchantHash, AuthorizeAPILoginID)

 

 If I print out the values of these variables and object I get:

Order.TransactionID = 0
Order.Amount = 5.00
MerchantHash = 0C1D523871B045AA932BC1F0ADC2964E
'This is the actual and correct value set in the Authorize.net Merchant Account settings.
AuthorizeAPILoginID = The correct API Login ID, as used to generate the transaction.

 

The order amount is numerically correct.  I use Doube.ToString("0.00") to format the amount for x_fp_hash and I set the form value in the original request with the following line of javascript (which would return "5.00" in this case).

$Form.children("[name='x_amount']").val(parseFloat(record.TotalPrice).toFixed(2));

 

I'm running out of thoughts, except for trying to manually generate the hash instead of using the SDK method.

 

Any suggestions or insights would be appreciated.

 

Thank you.

 

 

Ardemus
Member
1 ACCEPTED SOLUTION

Accepted Solutions

Solved

 

It turns out that the Authorize.net Merchant Services page truncates the MD5 Hash value (AKA Merchant Hash)  to 20 characters.  This doesn't appear to be documented.  I asked two Authorize.net Integration Technical Support agents if there were any limitations or requirements for the value, and they didn't specify a 20 character limit either.

 

Combining everything I"ve learned:

 

The Merchant Hash / MD5 Hash value is not a hash.  It is actually part of the string that gets hashed.  It must be a 3-20 character alpha numeric string (symbols can sometimes cause problems).

 

My site is now working.  I also implemented my own MD5 hashing before finding the problem.

View solution in original post

Ardemus
Member
5 REPLIES 5

Solved

 

It turns out that the Authorize.net Merchant Services page truncates the MD5 Hash value (AKA Merchant Hash)  to 20 characters.  This doesn't appear to be documented.  I asked two Authorize.net Integration Technical Support agents if there were any limitations or requirements for the value, and they didn't specify a 20 character limit either.

 

Combining everything I"ve learned:

 

The Merchant Hash / MD5 Hash value is not a hash.  It is actually part of the string that gets hashed.  It must be a 3-20 character alpha numeric string (symbols can sometimes cause problems).

 

My site is now working.  I also implemented my own MD5 hashing before finding the problem.

Ardemus
Member

Ardemus,

I'm not sure I understand your solution. Are you saying that all you did was use the response MD5Hash and truncate it to the first 20 characters?

 

For Example:

Response MD5Hash:                   C2D03ADC1E90F1221BA95F3AAEE93DA0

Response MD5HashTruncated: C2D03ADC1E90F1221BA9

 

[HttpPost]
public ActionResult Sim(FormCollection post) {
   var response = new AuthorizeNet.SIMResponse(post);

   bool isValid = response.Validate(response.MD5Hash.Substring(0, 20), ConfigurationManager.AppSettings["AuthorizeAPILoginID"]);

}

He saying the MD5 setting on the merchant account settings is 20 char max. Not the MD5 hash that is returning from a transaction.

 

It will be easier just change the MD5 settings to less than or equal to 20 chars.

So it is now 5 years later and your support still does not know there is a limit?

 

I had a client mad at us because "our software" was the issue when it was that you actually let them enter an MD5 hash longer than YOUR OWN ALLOWED LIMIT. Put a limit on what they can enter!!!

 

This is why we recommend BluePay to our clients. Thank You!

Hi @swdesign,

 

You make an excellent point. We're in the processing of deprecating SIM with an eye toward eventually ending that integration method. We've been steering all new integrations towards either our Accept.js JavaScript solution or the Accept Hosted payment form. So, it's not surprising that not everyone at the company knows the ins and outs of that system.

 

Still, though, you'd expect support to be able to at least find information about field limitations. Please accept my apologies that they're not aware of this. While the Merchant Interface field does limit input to 20 characters, we can perhaps do more on our side to make this clear.

 

I'll pass this along to those in charge of the Merchant Interface as well as those in charge of support so they can all be aware of the real world problems our developer partners are experiencing.

 

If you're interested, I'd be happy to take some time to go over some of the alternatives to SIM with you. You may be interested in the above options, or I could demo for you an upcoming feature that lets you call a hosted form using JavaScript within the browser.

 

If you'd like, email me directly at aawright@authorize.net and I'd be happy to set up a call.