topic Re: Issue Receiving Transaction Information in Integration and Testing

Issue Receiving Transaction Information

GKElite — Mon, 14 Jul 2014 19:08:22 GMT

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.

Re: Issue Receiving Transaction Information

GKElite — Mon, 14 Jul 2014 19:15:58 GMT

Also, our website (which is working successfully) is using API methods to send requests, where as our ERP environment is using XML.

Re: Issue Receiving Transaction Information

RaynorC1emen7 — Mon, 14 Jul 2014 20:19:24 GMT

Encrypted data? so the xml structure is there?

Last Tuesday? isn't that a windows updated date? can you see if windows updated ran on that day and the time?

do you have something like fiddler2 to look at the http traffic on the ERP server?

Re: Issue Receiving Transaction Information

GKElite — Tue, 15 Jul 2014 14:31:52 GMT

RaynorC1emen7,

Encrypted Data: The information recieved is not in XML format. Like we stated before, it's a mix of alpha, numeric and wingdings.
Windows Update: Our GKERP Server has not done updates since 2013.
Fiddler2: We do not have tools or the expertise at the moment to look at the http traffic on GKERP server.

Let me know if you need any more information.

GKELITE

Re: Issue Receiving Transaction Information

RaynorC1emen7 — Tue, 15 Jul 2014 14:43:05 GMT

That doesn't make sense, both soap and xml url use the same ssl cert.

can you download the sample code CIM XML code to try in your developer's network?

Re: Issue Receiving Transaction Information

GKElite — Tue, 15 Jul 2014 14:51:08 GMT

What sample code are you talking about? Can you elaborate?

Re: Issue Receiving Transaction Information

RaynorC1emen7 — Tue, 15 Jul 2014 15:27:54 GMT

http://developer.authorize.net/downloads/samplecode/

Re: Issue Receiving Transaction Information

GKElite — Tue, 15 Jul 2014 18:31:59 GMT

Ok,

I spoke with our developer. Understand that I'm not a developer myself so there may be some misuse of vocab here.

Our ERP system is written in Visual FoxPro, which doesn't have the ability to access the Microsoft .NET System Objects or the AuthorizeNet.DLL to run the XML code provided in the examples provided by Authorize.Net.

According to our developer we currently run functions that use 3rd party Class Libraries from WestWind Technologies which then uses very low level set of code (OS Level) to Transmit & Receive data from the Authorize.net API URL.

Is there another way to test what you'd like to test? I've asked that our developer do an official write-up of the information when he gets back in the office around 3PM EST.

Once I have that I will post it as well.

Below is a sample XML file which has been used & working since December 2012:

SAMPLE AUTHORIZE.NET:

Sample of the XML File  

  lcXML1=lcXML1+'<?xml version="1.0"?>' 
  lcXML1=lcXML1+'<createCustomerProfileRequest xmlns="AnetApi/xml/v1/schema/AnetApiSchema.xsd">' 
  lcXML1=lcXML1+"  <merchantAuthentication>" 
  lcXML1=lcXML1+"    <name>"+lcLOGIN+"</name>"
  lcXML1=lcXML1+"    <transactionKey>"+lcTRANKEY+"</transactionKey>"
  lcXML1=lcXML1+"  </merchantAuthentication>"+
  lcXML1=lcXML1+"  <profile>"+CHR(13)+CHR(10)
  lcXML1=lcXML1+"    <merchantCustomerId>"+mCUSTNO+"</merchantCustomerId>"
  lcXML1=lcXML1+"    <description>"+mCOMPANY+"</description>"
  lcXML1=lcXML1+"    <email>"+mEMAIL+"</email>"
  lcXML1=lcXML1+"  </profile>"
  lcXML1=lcXML1+"</createCustomerProfileRequest>"

Code used to transmit to Authorize.net
loHttp = CREATE('wwhttp')  
1 - creates & opens http object 

loHttp.nHttpPostMode = 4	  
2 - tells the object posting an XML 

loHttp.AddPostKey(lcXml1)  
3 - add the XML to the Object

lCResult=loHTTP.HTTPGet(lcXMLURL)  
4 - Sends the XML to authorize.net and receives the response 

DO ParseResponse WITH lcTYPE  
5 - parse the XML data being returned 

LoHTTP.HTTPClose()  
6 - Close the HTTP object and connection

I hope this helps. Let me know if you need anything else, and thanks again for helping with this issue.

GKElite

Re: Issue Receiving Transaction Information

RaynorC1emen7 — Tue, 15 Jul 2014 19:58:10 GMT

Look at some doc on https://www.west-wind.com/

the prod server do pass in gzip, it this turn on?

https://www.west-wind.com/webconnection/wwipstuff_docs/_20j0b58l2.htm

Re: Issue Receiving Transaction Information

RaynorC1emen7 — Tue, 15 Jul 2014 20:22:06 GMT

can the developer see what header information is getting pass?

and there also cErrorMsg https://www.west-wind.com/webconnection/wwipstuff_docs/_0jj1auej3.htm

and there is cResultCode https://www.west-wind.com/webconnection/wwipstuff_docs/_0xy0ul6dp.htm

can they see if there is an error?

Re: Issue Receiving Transaction Information

GKElite — Wed, 16 Jul 2014 13:49:06 GMT

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

Re: Issue Receiving Transaction Information

RaynorC1emen7 — Wed, 16 Jul 2014 13:59:26 GMT

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.

Re: Issue Receiving Transaction Information

GKElite — Wed, 16 Jul 2014 15:01:36 GMT

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?

Re: Issue Receiving Transaction Information

GKElite — Wed, 16 Jul 2014 15:12:00 GMT

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?

Re: Issue Receiving Transaction Information

RaynorC1emen7 — Wed, 16 Jul 2014 15:37:43 GMT

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?

Re: Issue Receiving Transaction Information

GKElite — Fri, 18 Jul 2014 17:21:43 GMT

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!