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.

[cwdsl]

@staopix, thanks, i'm not sure what I am supposed to do though. 

Are you suggesting that the HMACSHA512 function in the SIM guide PDF is incorrect?

In theory I could encode the value before doing the initial post to Authorize.Net, so Sãu Paulo would be encoded as S\u00e3u Paulo.  But then on the payment page that Authorize.Net show, the city shows it as S\u00e3u Paulo.  It does validate the SHA-512 check, but far from ideal.  Plus if address checks were turned on at Authorize.Net would S\u00e3u Paulo even pass checks?  So this option is a non-starter.

In the initial post, if I submit Sãu Paulo, it displays as Sãu Paulo on the Authorize.Net payment page.  The issue is that the response that comes back is showing a ? character and it doesn't validate.

[staopix]

@cwdsl 

To be honest I think it is a bug in the Autorize.net hashing algorithm. I think they are not handling multibyte characters correctly. I have logged a support case but still to hear back from them. 

Are there any support people on the forums?

[cwdsl]

@staopix, I think I've actually got it to work in my project.  As a bit of background, I'm doing an ASP.NET MVC application.  I started off by posting Sãu Paulo to a test URL and noticed it was replacing the ã with a ?.  So this was a standard post, not Authorize.Net posting.  Therefore I thought by default the URL was accepting standard ASCII characters only.  In my MVC project I added the following to the web.config...

  <location path="PATH_TO_URL">
    <system.web>
      <globalization requestEncoding="ISO-8859-1" responseEncoding="ISO-8859-1" />
    </system.web>
  </location>

The PATH_TO_URL is replaced with the URL to the Authorize.Net Relay Response URL without a leading forward slash.

At this point I saw the request was coming in correctly with Sãu Paulo.  However the hash was not comparing properly still.  This is because in the Authorize.Net example they are using ASCIIEncoding...

Dim HashedValue As Byte() = hmac.ComputeHash((New System.Text.ASCIIEncoding()).GetBytes(textToHash))

 Changing this to UTF8Encoding seems to fix the issue...

Dim HashedValue As Byte() = hmac.ComputeHash((New System.Text.UTF8Encoding()).GetBytes(textToHash))

I can't help with other languages, but looking at my example I would say Authorize.Net are correctly posting to the relay response.  Their ASCIIEncoding is wrong though.

[staopix]

@cwdsl 

OK got this working now. Converted the encoding from ISO-8859-1 to UTF-8. This gets around the issue with 

São Paulo

However it does not fix an issue where the addres might include a Polish character such as 

Ł

This is due to the fact that the Polish character is out of range of the Latin-1 encoding. 

we send: 

'x_city' => 'Ł',

and get back:

'x_ship_to_city' => 'A',

Surely this has to be a bug in Authorize.net. Our application sends the data in UTF-8 but we get different encoding returned. If Authroize.net sent the data back as UTF-8 then we wouldnt have this issue.

[Renaissance]

@staopix

Just curious, are you converting before the form is submitted so that the customer sees the new character ? For this issue, your solution is to build a custom function to sanitize the response. You are free to PM me if you have questions.

[cwdsl]

@Renaissance  and  @staopix 

I'm not sure if Polish characters should be supported with Authorize.Net or not.  As a temporary solution I am passing the address entered through a function (code below).  This will work with most characters, but ones it doesn't support it replaces with the nearest.  I then post the corrected address to Authorize.Net in the initial post.

            Dim iso As Encoding = Encoding.GetEncoding("ISO-8859-1")
            Dim utf8 As Encoding = Encoding.UTF8
            Dim utfBytes As Byte() = utf8.GetBytes(Value)
            Dim isoBytes As Byte() = Encoding.Convert(utf8, iso, utfBytes)

            Return iso.GetString(isoBytes)

So São Paulo would still return São Paulo and that works fine.  If I use Ł, the function converts it to L.  This is then submitted to Authorize.Net.  That way when it returns back to the relay URL, the hash will compare correctly.

If there is a way for Polish characters to work correctly I will amend, but this gets around the issue for now.

[mahima1990]

There is another issue for me now.

Hash values are not matching if the amount given as Eg: 10.00. It works fine if the second decimal place has a non zero value. ie, if the amount is given as 10.52 then it works fine. What is the solution for this?

Another question, With new SDK how can we redirect back to the parent page once the transaction is complete? In the old php SDK we had a AuthorizeNetDPM::getRelayResponseSnippet($redirect_url) function to do this. In the new one how can we achieve this? Please help.

[Renaissance]

For your class driven redirect I am not sure and do not have time to look at it right now.  For the 10.00 not working but 10.02, etc. working, what is happening is you have a number format issue. You need to add some code in your script to format all numbers to include 2 decimal places. I'd bet high that is exactly your issue.  What is happpening is 10.00 is being formatted as either 10.0 or 10.  To test this validate your response business as usual on a 10.00 order, but instead of taking the post value plug 10.00 in manually.  Your hash will match. 

[mahima1990]

@Renaissance The amount issue solved!! Thanks a lot :) . Can anybody else give a solution for the redirect issue :(

[Renaissance]

@mahima1990

I just read your post again. You use SIM/DPM? If so you can simply put either a relay or redirect url in the merchant interface. Put the url you want them back to