Upgrading MD5 to new hash (SIM)

[cwdsl]

I am trying to upgrade from MD5 to the new hash method as described here:- https://developer.authorize.net/support/hash_upgrade

We are using SIM still do in addition I read the guide at https://support.authorize.net/s/article/Do-I-need-to-upgrade-my-transaction-fingerprint-from-HMAC-MD....  This second link seems to talk about generating the fingerprint with more values than the first link above does, more similar to how wo do MD5 currently.

I’m having trouble validating matching the value I submit to what is returned in the response.  Note: We need this to work with SIM as we can’t upgrade to the new API currently.

I am creating the hash using the new method and submitting it to the x_fp_hash during the post.  I assume my x_fp_hash is correct because I was previously getting error 99’s which is a fingerprint error, but no longer do.

The response comes back after doing the payment in the x_SHA2_Hash field.  It doesn't compare to x_fp_hash.  So I thought there is more to this.  Looking in the SIM guide, on page 73 at https://www.authorize.net/content/dam/authorize/documents/SIM_guide.pdf it mentions generating a hash from 30 fields.

I've done this and it still doesn't compare to x_SHA2_Hash.  So I assume I am doing something wrong, but not sure.  The documentation doesn't really give any examples of how to do this so I am uncertain what my issue is.

[mahima1990]

@Renaissance  Will this method works for applications as well? Ours is not a website.

[Renaissance]

@mahima1990 

Sorry, not following you. If they are not doing this on the web where would you be redirecting them to? Anything that sits on a url online and has server side programming is an application. I think you may be getting tied up in the difference between something you build by hand and something you buy "off the shelf". 

It all works the same in the end, although the commercial products can have very hard to figure out code. I recently did a project that involved a commercial content management system product, and it was 12 hours of research to do 1.5 hours work. 

[mahima1990]

@Renaissance  Yes of course it's on web. It's an EMR based application. Using the previous php SDK we used the AuthorizeNetDPM::getRelayResponseSnippet($redirect_url); function to do the same. But in the new SDK I didn't find any matching function for this. :( That's my issue.

[Renaissance]

@mahima1990 

That's what I figured. There is no difference in your application vs 99% of the websites people are posting about here, in terms of one being an application and the other being a website.  That's what I was getting at. 

If you use SIM, you may not have any purpose for the new SDK. I think the SDKs as of the last few versions have nothing at all for SIM/DPM/AIM.  What benefit was it that you were looking for in the new SDK?  

[Renaissance]

And to answer your question, yes. You want to make sure your API call isn't calling a redirect url because duplicates can cause issues. But given that your web application isn't sending any parameters, yes, put the relay url in the relay response in the interface.  This assumes that each client goes back to the same page.

If you have a system where each client goes back to a page based on their individual account, then you've got some extra work to do. Either use a dynamic receipt url, or have the cookie/session to persist after the customer leaves your site to pay and have the page hosted on your relay url get them to the appropriate place. 

[Renaissance]

@cwdsl

I sent you a PM. I have built a script that validates responses that contain any or all of 120 different diacritics. It is set up to test. Took me about 4 hours to make several weeks ago. It is all done on the response, the customer can enter the values as they normally appear and you do not have to alter them in the API request. I originally thought I had it working on a list of about 220 such characters, and then the tests started failing from time to time. I think it may be when they are used in combination. It is an encoding issue and the way I did it was to capture the raw response without assigning any content type or capturing HTTP headers.

As for the remaining 100 characters, that might be a dealbreaker. I may, when I have time try to work out how to use them.