Issue Receiving Transaction Information

[GKElite]

Since last Tuesday we have been unable to access our authorize.net CIM information via our internal ERP system. The transaction goes out to authorize.net and is accepted, however, when returned we are unable to decrypt what is being sent back. So, the result looks a mixture of different types of characters including wingdings, alpha and numeric. We have run several tests. The results were as follows, which includes testing from our internal network and our developer’s network:

Pointing to the sandbox/test authorize.net environment everything worked successfully.

• Created a new customer - PASS
• Added a credit card - PASS
• Charge a credit card- PASS
• Selecting existing credit cards - PASS

Pointing to the production authorize.net environment we received encrypted data, which we are unable to decrypt

• Created a new customer – Returned encrypted data
• Added a credit card - Returned encrypted data
• Charge a credit card- Returned encrypted data
• Selecting existing credit cards - Returned encrypted data

Additional Information: We’ve made no changes within our internal ERP environment. Our ERP system is developed in FoxPro 9(vfp9). We are utilizing pieces of a 3rd party widget/plugin called West Wind, for our authorize.net integration.

Note, we've also confirmed the same transaciton key and login information is being used on our website, and the results are being passed back readable with no issues.

[GKElite]

RaynorC1emen7,

Our developer says that by default the HTTP Header does have gzip turned on in both Production & Sandbox and specifically  noted.  On a side note, our developer ran a test that manually removing “Accept-Encoding: gzip, deflate” and replaced it with 'Content-Type: text/XML; charset=UTF-8' in the HTTP Header and lo and behold human readable data was returned from the AUTHORIZE.NET production URL.

This would be a minor 2 line change in the program that calls out to the AUTHORIZE.NET API.

Also, no error message “cerrormsg” was returned and the Result “cresultcode” was returned as 200 (ok). But data still not human readable.

GKElite

[RaynorC1emen7]

My guess it that authorize.net update their server last Tuesday and returning data with gzip if the request ask for it.

So have your developer removed it from the header as they tested will fixes this problem.

[GKElite]

Authorize.net is insisting that they have rolled back every change they made and that in no way could their change have had any impact on the issues we're having.

Any suggestions on how to best prove otherwise?

[GKElite]

ANOTHER QUESTION: If the request asks for GZIP, what would it hand to us?

Essentially, could the jumbled response (wingdings, alpha, and numeric) be a GZIP-ed file?

[RaynorC1emen7]

Authorize.net is insisting that they have rolled back every change they made and that in no way could their change have had any impact on the issues we're having.

 Any suggestions on how to best prove otherwise?

If you have the https log of the response header from before.

If the request asks for GZIP, what would it hand to us?

If the request ask for gzip, the server(authorize.net) can response with gzip or they can also said no, don't want to and response with no compression(just text).

So if your request ask for gzip, your code should handled gzip response, but it sound like it wasn't. so either stop the request from asking for gzip or fix the code to handle gzip response.

there wiki on this too http://en.wikipedia.org/wiki/HTTP_compression

Essentially, could the jumbled response (wingdings, alpha, and numeric) be a GZIP-ed file?

Yes, did the reponse have something like a diamond with a question mark?

[RaynorC1emen7]

Authorize.net is insisting that they have rolled back every change they made and that in no way could their change have had any impact on the issues we're having.

 Any suggestions on how to best prove otherwise?

[GKElite · Accepted solution]

Authorize.net has confirmed that they made a change to IIS which in turn affected GZIP.

They are not rolling back the change they did so we did need to modify our code to work around their change.

The Westwind code change we made:

**************************************************************

** 07/17/2014 force the HTTP request to only

** have 'Content-Type', 'text/XML; charset=UTF-8'

** and no ref to gzip

**************************************************************

loHTTP.addheader("")

loHTTP.addheader('Content-Type', 'text/XML; charset=UTF-8')

**************************************************************

This fixed our issue and we are no longer receiving jumbled responses.

THANK YOU RaynorC1emen7 for your help in identifying and fixing this issue for us!