Suddenly getting Security Hash Problem AND Communications Error

[DrByte]

Okay, so you need to show them that. Tell them the curltest URL so they can see it themselves.
All it's doing is attempting to talk to the Authorize.net server over HTTPS. The timeout must be a result of a firewall block by your hosting company.

[Oriontool]

Ok, thanks!

The guy at Hostgator asked me if I knew what port it needed? Also, he is checking with the another tech, but said it all looks good!?!

[stellarweb]

Dr. Byte.... just a little more info on this problem - the server is running PHP 5.2.13 - which is a really uncommon version that was only stable for a short time from what I can tell.

Also, we were able to get the authorize.net to work using the SIM module - not offsite - but onsite.

What I am not sure of is this - is the SIM module as secure and / or PCI compliant as the AIM module for authorize.net? So... is there a reason not to use the onsite version of SIM?

Inquiring minds like mine and Melanie's want to know!

[Oriontool]

HostGator Admin is saying that port 443 is open and everything is working fine. Except for the fact I can't accept credit cards..

[DrByte]

HostGator Admin is saying that port 443 is open and everything is working fine. Except for the fact I can't accept credit cards..

I don't know what to tell you. The problem is clear. CURL is timing out when attempting to talk to the authorize.net server.

Escalate the ticket to a more senior technician who can actually test and see that YOUR server CANNOT talk to the authnet URL shown by the curltest.php results.

[stellarweb]

Do you think it could have anything to do with the php version as I have stated in the post a few up from here?

Also... is he ok to be running it as SIM? Because it works fine that way.

[Oriontool]

When the guy from HostGator goes to http://www.earphoneguy.com/curltest.php?paypal=1 it works. So it is letting some SSL transactions work.

I am totally confused now.

[DrByte]

the server is running PHP 5.2.13 - which is a really uncommon version that was only stable for a short time from what I can tell.

Do you think it could have anything to do with the php version as I have stated in the post a few up from here?

Unlikely to be an issue. Esp since there's confirmation that CURL can talk to other servers fine.
It appears the blockage is specific to authorize.net.

Also, we were able to get the authorize.net to work using the SIM module - not offsite - but onsite.

What I am not sure of is this - is the SIM module as secure and / or PCI compliant as the AIM module for authorize.net? So... is there a reason not to use the onsite version of SIM?

Also... is he ok to be running it as SIM? Because it works fine that way.

SIM in onsite mode is still collecting CC information directly on your site. In the strictest sense that may not be PCI compliant. That's up to you and your scanning company to decide.
At the very least you need to have SSL enabled if you're going to do that.
Running it in offsite mode is less customer-friendly but doesn't collect CC details directly on your site. Some say that using that method shifts the blame away from you if something bad were to happen.
Again, that's up to you and your PCI company to decide.

SIM is certainly less efficient than AIM. So if you intend to do onsite-collection of card details, AIM is definitely strongly recommended.