All Authorize.net API scripts on server not working alll of sudden. Blocked?

[sleeplessmedia]

Hello,

I was directed here by authorize.net chat support, they said I could post here and see about finding an answer.

We have many clients on one Rackspace dedicated server, and today we started getting complaints that their customers are not able to process credit cards.

We set up a testing script on the server having the issues:

https://www.heidisongs.com/test_auth_net.php

and on a separate server:

http://www.listlabs-dev.com.php54-2.ord1-1.websitetestlink.com/test_auth_net.php

And the one on the separate server works perfectly fine.

I've checked with the host, and with an authorize.net chat, and both want to know what the error response is, the problem is, there is none that I know of, it seems like we are unable to communicate with authorize.net - like it's being blocked or something?

Please let me know if anyone can shed some light. We have dozens of clients on this server using auth.net api to take orders and none of them will be receiving any orders while this is not working.

Thanks!

[RaynorC1emen7]

SIM? AIM? DPM?

can you do curl to the url so you can at least get some http response?

[tragichip]

Hi All,

I am currently having the same issue.  Our code has worked for months now, and just the past Sunday, when we send a request ... nothing is sent back in the response ... not even an error.

I am using the sample code  that uses the CURL library for php to establish a connection.

Any help or troublshooting advice would be greatly appreciated.

Thanks.

[RichardH]

Hello

I would recommend contacting your web administrator or hosting provider and check the SSL connection logs for information that might help identify the problem.

Richard

[tragichip · Accepted solution]

Hey Richard,

Thank you so much for the quick reply.

We had already checked that scenario ... we have the post set to ignore the SSL certificate.

Do you know of anything else we could check ... running out of ideas ... we are currently tracking packet dumps and appears that on a network level we are getting a response, but the code no longer displays the information.  Nothing has changed in the code since it has been implemented.

Thanks again.

Ohhh hey ... looks like we figured it out ... the last nss update for Centos 6.5 requires that the apache process be restarted after the update ... it appears that for this update ... the web server does not fully shut down thus breaking curl ... until the restart.

Hope this helps anyone out there with this issue in the near future.  One of the real obscure ones.