cancel
Showing results for 
Search instead for 
Did you mean: 

Using SIM, sandbox AuthorizeNet is timing out on redirection..

We are not sure exactly when this started happening, but whenever we try to redirect to an AuthorizeNet payment form there is a 550 error using this URL:

 

test.authorize.net/gateway/transact.dll

 

We know SIM is deprecated but as far as we know it should still be working. Does anyone know why this might be happening? We've seen this happen on multiple servers of ours.

 

Is the server down? If it is, how could we check the status of the server in the future?

 

In the header after we POST all of the information needed to that URL it will wait for about a minute and timeout with the following information in the header:

 

  1. Request URL:
  2. Request Method:
    POST
  3. Status Code:
    550 Unknown
  4. Remote Address:
    104.107.43.135:443
  5. Referrer Policy:
    no-referrer-when-downgrade

If we put the wrong login information it will return instantly that there is an authentication error so the URL seems to still be working.

 

lightwave365
Regular Contributor
13 REPLIES 13

Hi @lightwave365,

 

Is this a problem you're only seeing on sandbox, or also in production?

Aaron
All Star

We currently don't have a production account. We are trying to demo a feature for our customers using a test account.

lightwave365
Regular Contributor

We are also experiencing this error in sandbox/test only.

 

I have not checked production directly, but given that we've continued to process orders there throughout the day, I don't think that there is an issue.

 

In the last test, there was pretty much an exact 90-second wait for a return (90.076, as measured by Fiddler). 

 

I would rather not post the body of the request here, but the request header should be fine :

 

POST https://test.authorize.net/gateway/transact.dll HTTP/1.1
Host: test.authorize.net
Connection: keep-alive
Content-Length: 1489
Pragma: no-cache
Cache-Control: no-cache
Origin: null
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36
Content-Type: application/x-www-form-urlencoded
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.8
Cookie: UnicaNIODID=rZjHKm2zRjY-acpJVey; __utma=195058876.558140473.1502668515.1505320144.1505327112.3; __utmc=195058876; __utmz=195058876.1502668515.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); _ga=GA1.2.558140473.1502668515; _gid=GA1.2.1925465041.1505320144

 

Here's the response, in its entirety :

 

HTTP/1.1 550 Unknown
Content-Length: 0
Date: Wed, 13 Sep 2017 19:16:42 GMT
Connection: close

 

Hi @ansira_dev_2,

 

I'm still trying to duplicate on my end and haven't been able to get a failure. Is there any body in the response when you get the 550, or is the connection closed right after it sends the headers?

There is no body. That is the response, in its entirety.

 

Here's the size of information requested and received, per Fiddler :

 

Bytes Sent: 2,311 (headers:822; body:1,489)
Bytes Received: 99 (headers:99; body:0)

 

I haven't checked to see if the connection is actually closed after this - I know that, per HTTP spec, the connection may be left open after a repsonse is completed. Is it actually important to see if the connection is closed?

 

(Edit : oops, forgot that the response asks for the connection to be closed. Regardless, I haven't checked, and I don't know if that's important.)

The error continues to reproduce on our side. Please let me know what other information you need.

 

For the record, the connection does in fact close, although Chrome immediately decides to open a new connection immediately afterwards. I guess the browser's trying to outsmart us there - get a connection ready just in case. We should probably discard that bit of information.

Just in case : what IP address does test.authorize.net resolve to for you?

Hello,

 

This issue was also reported to our developer support mailbox and escalated to a product support engineer.  When we learn more, we'll update this thread.

 

I would recommend subscribing to this topic so that you'll be alerted via email if anyone from the community is able to respond with any comments. To subscribe, click Topic Options at the top of this thread and then select Subscribe. You'll then receive an email once anyone replies.

Thanks,

Richard

Hello @lightwave365 @ansira_dev_2

 

Our support specialist has asked that you send the HTTP headers to them at developer@authorize.net so they can do some further investigation.

 

Please refer to this thread in your email.

 

Richard

RichardH
Administrator Administrator
Administrator