The CIM API is timing out for us. Is anyone else having this issue or is it just us?
The Sandbox environment is not down--if you try to load https://test.authorize.net/gateway/transact.dll in a web browser you'll get Response Reason Code 13, which is expected behavior since there's no x_login info being passed.
If you try it with the CIM API URL in Sandbox (https://apitest.authorize.net/xml/v1/request.api) you'll get similar results--a successful connection with an error from us due to a lack of actual content in the connection.
But can you provide us with more details, such as whether you're seeing SSL errors when trying to connect to Sandbox?
06-03-2014 11:05 AM - edited 06-03-2014 11:09 AM
It was working for us yesterday (and we didn't change any code).
After about a minute or two it times out and returns an empty response. The same code is working on our production site with the live authorize.net
AuthorizeNet\Service\Cim\Response Object
(
[xml] =>
[response] =>
)
06-03-2014 11:20 AM
I'm asking about SSL errors because we added new ciphers to Sandbox, and it's possible that affected servers are having issues using these ciphers.
These are the ciphers we added, so please ensure your solution properly supports these:
EDIT: There are a few ciphers we will be removing because they are weak ciphers, but all the weak ciphers were part of the new update. I've updated this post to reflect the ciphers we previously supported, plus the strong ciphers we will be keeping and supporting moving forward.
06-03-2014 11:25 AM - edited 06-03-2014 11:59 AM
Are these new ciphers a reason I may be getting an error "The SSL certificate for the host could not be verified."
From my question http://community.developer.authorize.net/t5/Integration-and-Testing/SSL-certificate-for-the-host-cou...
06-03-2014 11:27 AM
I found that there is a response, at the bottom there is this:
[error_message] => Error connecting to AuthorizeNet
I am unsure what we would need to do to get everything working with the new ciphers. We two developers with local development accounts and one VPS development server that all have this issue. The developers are on WAMPs and the VPS is Linux...
Here is the full response:
[approved] =>
[declined] =>
[error] => 1
[held] =>
[response_code] =>
[response_subcode] =>
[response_reason_code] =>
[response_reason_text] =>
[authorization_code] =>
[avs_response] =>
[transaction_id] =>
[invoice_number] =>
[description] =>
[amount] =>
[method] =>
[transaction_type] =>
[customer_id] =>
[first_name] =>
[last_name] =>
[company] =>
[address] =>
[city] =>
[state] =>
[zip_code] =>
[country] =>
[phone] =>
[fax] =>
[email_address] =>
[ship_to_first_name] =>
[ship_to_last_name] =>
[ship_to_company] =>
[ship_to_address] =>
[ship_to_city] =>
[ship_to_state] =>
[ship_to_zip_code] =>
[ship_to_country] =>
[tax] =>
[duty] =>
[freight] =>
[tax_exempt] =>
[purchase_order_number] =>
[md5_hash] =>
[card_code_response] =>
[cavv_response] =>
[account_number] =>
[card_type] =>
[split_tender_id] =>
[requested_amount] =>
[balance_on_card] =>
[response] =>
[error_message] => Error connecting to AuthorizeNet
06-03-2014 11:30 AM
You may need to discuss this with your webmaster. This is typically at the server level, not the code level.
06-03-2014 11:46 AM
Peter, that is a possibility. Are you using OpenSSL? If so, which version? We're researching this and knowing the OpenSSL version number would help.
If you aren't using OpenSSL, which version of IIS are you using?
06-03-2014 11:48 AM
I'm having the same issue: manually visiting https://apitest.authorize.net/xml/v1/request.api works just fine, but submitting both GetCustomerProfile and CreateCustomerProfile requests are timing out (via curl through php api). No code has changed since yesterday, and the code did work yesterday. I'm glad I'm not the only one.
Fustrating, it's killed about 4 hours of development time today because I thought it may be our fault, somehow.
06-03-2014 11:58 AM
Are you using OpenSSL? If so, which version?
06-03-2014 12:02 PM