The CIM API is timing out for us. Is anyone else having this issue or is it just us?
Have same problem as everyone else. It just hangs and then returns an empty response code. Spend 3 hours yesterday beating my head against the wall only to get a nonsensical email from suppport with basic links to FAQs. Really this is how you roll out an "upgrade"?
06-04-2014 09:23 AM
^ Had an experience very similar to this. Extremely frustrating. Was told to talk to my "Web Master" and that it was our fault.
06-04-2014 09:29 AM
Adding:
curl_setopt($curl_request, CURLOPT_SSLVERSION, 3);
To line 93 of AuthorizeNetRequest.php in the PHP API fixed the problem.
I used bbot's suggestion and uncommented
curl_setopt($request, CURLOPT_SSL_VERIFYPEER, FALSE);
and added
curl_setopt($request, CURLOPT_SSLVERSION, 3);
This would be line 88 in the Sample AIM Implementation as provided by Authorize.
06-04-2014 09:51 AM
Yes lethjakman I got the same email: "You may need to speak to your webmaster or hosting provider to ensure your systems are configured properly".
Since my test account (and my code) had been working fine, I didn't test Authorize before doing a major revision to one of my forms. Then of course I can't make a connection and think it's because of the updates to my code. I end up trashing all the work I did and revert back to my original code, only to find the problem is related to new ciphers used by the developer sandbox. OK back to doing the actual work the client request.
I guess we can expect the same change in the production environment sometime in the near future and have our clients going ape.
06-04-2014 10:10 AM
We couldn't comment until we got approval for the rollback.
The rollback is at 11:30 AM Pacific time. I do not know exactly how long it'll last but the rollback should only take minutes.
06-04-2014 11:17 AM
As for changes to Production, the situation is going to be different there. I cannot comment at length at this time but there were specific challenges in the current setup in Sandbox that caused this to be an issue.
06-04-2014 11:18 AM
Can you explain more about the differences before you plan on pushing these changes to production? If this same thing happens, many people will not be able to complete transactions. My confidence is lacking with the way this was handled so far with the development server.
I'm not sure if I should suggest to my clients that we should move to a different payment gateway.
06-04-2014 11:32 AM
I can confirm that adding this to the curl request worked for me.
curl_setopt($ch, CURLOPT_SSLVERSION, 3);
What is the consequence of this? Is this an old version? Is this as safe?
06-04-2014 11:38 AM
I think it just forces it to use SSL3
http://us1.php.net/curl_setopt
"The SSL version (2 or 3) to use. By default PHP will try to determine this itself, although in some cases this must be set manually."
As for security: http://serverfault.com/questions/178561/what-are-the-exact-protocol-level-differences-between-ssl-an...
06-04-2014 11:42 AM - edited 06-04-2014 11:43 AM
Hello Everyone,
The rollback has been completed and you should now have a normal experience when testing against the sandbox. We appreciate your patience as we leverage the sandbox to test changes prior to deploying to production.
Please confirm if these changes have corrected your issues.
Richard
06-04-2014 11:52 AM - edited 06-04-2014 11:53 AM