Integration and Testing

[jhoven]

We are also having this exact issue.  I'm going to give support a call and let you know what I find out.

We just need to know how Authorize.Net is treating these characters, in their hash source string.  When we take the character as literally transmitted to us, and compute the hash, we get a non-matching hash value.

[maninder]

@jhoven I tried calling the support but they are of no help. Let me know if you can find something.

[jhoven]

I seemed to get a good rep on my call.

They found an existing case that this was a known issue.  No ETA yet.  But they're going to submit an escalation case looking for an update.

They did have some guidance:

Only submit ASCII characters 32-127 to Authorize.Net.

Apparently there is also some setting on the form to limit to secure chararacters.

In our case, the issue seems to be that two consecutive space characters (ASCII 32) get translated into an ASCII 32 + character outside of the range.  We may try to update our integration to replace consecutive spaces with a single space.

Even if you limit what you're passing, if you're using free-form text fields as part of your check-out process (on the SIM page), you won't be able to avoid the user entering characters outside of the acceptable range.

Falling back to the old hash isn't a good option as they official stop supporting that on June 27th.

I'll try to update you when/if I hear back from the escalation team.

[maninder]

@jhoven 
Thank you very much for the information.

We are using SIM integration and as we have no control over users input, we have to wait for Auth.net to fix it. Is there any escalation case number they provided, in case we want to call them to get an update? 

[Renaissance]

@jhoven

The characters make it to auth.net exactly as the customer types them and then are sent in a url encoded string to your relay response endpoint.

Are you using diacritics in your app? Or just standard U.S. alphabet? The way around it would be to have a message to your customers that says “enter your information here and do not change on the following page” or something like that. Then you could apply your own processing script to leave out the Diacritics. As far as auth.net fixing this on their end, I’m not sure what they could do and if they will do it.

Factors to consider are that most apps work with the sha512 just like they did with md5. It is the diacritics that throw a wrench in it. So if they change the encoding of the response it will break 90%+ of all existing integrations for SIM/DPM. They have said for a very long time now that for SIM/DPM the most you will get are security upgrades, and they are not making further changes to these deprecated products.

Your optimal solution is webhooks. Might take you 2 hours absolute max to set up. This issue doesn’t exist there.

[jhoven]

@maninderI don't have a case number.  They did get back to me and apparently they're not going to fix.  They're sticking to do not send characters outside of ASCII range 32-127.  Hide or make read-only user inputs on the hosted payment form.

@RenaissanceThanks for the input.

In our case, all of our characters are within the 32-127 range.  They're mishanding consecutive spaces.  But I'm resigned to just bite the bullet and switch to Accept Hosted.  Not quite a 2 hour scenario for us, as we have many clients using Authorize.Net through our product.  But I think some of my initial concern with setting up multiple accounts is alleviated since we already have a Signature Key.  If I recall correctly, that should allow us to script generation of the WebHooks.

[Renaissance]

@jhoven 

You can use webhooks for SIM/DPM too, I believe. But I agree with your decision. It is going to get tougher and tougher to have comparable functionality in your web app if you keep using SIM/DPM. The extra work will pile up. And yes, you can loop through your accounts and create webhooks for all of them through a server-side script. You will have a hash validation to set up as well. 

[Renaissance]

And nice to know about making the form read only. I rarely work on SIM/DPM apps and wasn't aware of that. 

[inkeyes]

Hi,

We are hitting the same problem now.  Is there a recommended mechanism to encode the returned POST information, rather than just concatenating fields in the desired sequence?

Thanks

Nick

To sign: ^61970529329^false^1^091696^P^^Y^CC^XXXX2841^9.99^^REDACT^Hernández^REDACT^Austin^TX^78758^US^5125746544^^REDACT^^^^^^^^^^,

SHA2 Hashes do not match: generated: F0434730CF7258D0D9C8B871797CA3022B15E037A44ACE6E314B9237845AC83F9C1945746DF65535163B53A8A1A58117109DA96DD5EB9CE4665537447C5FD8E8  - received: B7A3F0A82A919D0C23FA220F4F9F4740E7D16DE44EAFA5560E5FB58A61960319302D7410E2CCF749EE6C2F22501B2764AD934F7B3CFD833B9CE8EA748ACD360B

[Renaissance]

@inkeyes

I have posted my script, which took me 4 hours to create and test. Try it out. I will post the link. Let me know if it works.