SHA-512 hash mismatch when we enter non-ascii characters in the hosted payment page fields such as Firstname, lastname and address.
Example from Sandbox testing:
Tested with following card information:
Card number: 4111111111111111
Address: 123 main street
x_address: 123 main street
x_response_reason_text: (TESTMODE) This transaction has been approved.
x_description: Brygid - Test Store
Datastring to generate hash = ^0^true^1^000000^^^P^CC^XXXX1111^3.23^^Ren�^brown^123 main street^^^30321^^^^^^^^^^^^^900002667^
Hash generated: 91D06EE60901B000B4308A1A10BBE916A8B2C939C69F5E976D37CB2096887AAA9BAC0F6E7B96A512C5B3650C6A3C11E9F3A9C8AE7939E4234BD36A0CD3C38255
It is an issue with character encoding but we don't know how Auth.net handles the encoding before generating the hash which they send in the response.
Will really appreciate any help from the community to resolve this issue.
This is entirely an encoding issue and something that has to be handled on the developer's end. The auth.net response comes in a url encoded format and server side programming must be implemented to manipulate the encoding of the non-ASCII characters. This step was not needed for md5 due to customer information fields like name, address, etc. not being used to calculate the hash. This issue is not unique to any one developer and there are a few who have commented on how they handle it in their applications.
If auth.net wanted to pick up some of the work, they would need to send the SIM/DPM response in a different format, which would likely break 90% of existing integrations. Or you could change the method used to calculate the hash so it doesn't use customer info fields and have a forum gone wild with irate developers telling you to go to.....
I would recommend you use webhooks. The sha512 validation for that is much simpler and you will find a solution using that much faster than you will grinding your wheels on this. It took me 15 minutes to set up webhooks on the first go round, and it took me 4 hours to write the programming for the relay response you are working with. You are going to find it to be harder and harder to keep the pace with products that are no longer supported.
We are setting testmode in the request. We having the exact same issue in production as well. All of our clients are affected.
As @Renaissance mentioned, it is entirely an encoding issue. We need to know how to handle the non-Ascii characters data coming in the response so we can generate a correct hash.
We are looking for a proper solution which can handle any character being entered by the customer on the payment page.
@Renaissance It will be great to see how you are handling the non-ascii characters. Will it be able to handle single quote ’ ?
@RichardH Can you also give your input on how Auth.net suggest to handle the non-ascii characters in the response so we can generate a correct hash?
This issue is affecting all of our clients which are switched to SHA512 and there is nothing in the documentation which states how to handle the response data for non-ascii characters to generate a proper hash.