URGENT - PRODUCTION TRANSACTIONS FAILING BECAUSE OF HASH MISMATCH.

[maninder]

Hi,

We upgraded our integration to support SHA512 hash and we noticed that the non-ASCII characters entered by the customers on the hosted payment page are not being posted back to us in proper UTF-8 encoding. This causes a mismatch between the hash generated on our end and the hash which is coming back in the response, causing us to reject the response.

Example for the following Transaction ID, we received the following last name:
 x_trans_id: 61722174838

 x_last_name: M�s

Non-ASCII characters are not being handled properly on AUTH.net side. 

Approved transaction response comes back with wrong user input values causing hash mismatch and orders rejection.

Will really appreciate any help asap.

Thanks

[Renaissance]

See this thread-

https://community.developer.authorize.net/t5/Integration-and-Testing/Validating-European-Diacritics-...

I made a script that will handle about 120 of these characters. The exception is that Lithuanian I with a squiggly bottom.

[maninder]

@Renaissance  

Thanks for the link you provided.

Do you know how Auth.net handles the non-ASCII characters on their end before they generate the SHA512 hash?

During testing, I noticed that we recieve unicode characters in the transaction responses if customers inputs any on the payment page, we are using whatever comes back in the response as it is when generating the hash and its not working.

Maybe Auth.net handles the non-ASCII characters differently on their end when they generate the hash. 

How are you validating the responses with non-Ascii characters in the API response?

Will really appreciate your help.

[Renaissance]

@maninder

Authorize uses the exact characters exactly how the customer inputs them. I have a script that will validate responses with every single character, save one.  It took me 4 hours to make and set up for testing. It is a php script, but could be adopted to any language. IM me if you want to talk about this in more detail. 

[Renaissance]

I could probably work on the script a little more to get the Lithuanian I to validate. I just gave up because it was taking too much time.  You have to pull the raw response and do encoding manipulations. I couldn't find an encoding manipulation that would distinguish the Lith I from a period.