The Authorize.Net Developer Blog

Posts from Authorize.Net employees, community members and experts about integrating with the Authorize.Net Payment Gateway: sample code, tutorials, and problem-solving techniques, just to name a few.

Important POODLE Information - Updated

by Administrator Administrator on ‎10-27-2014 03:22 PM - last edited on ‎11-12-2014 09:27 AM by Administrator Administrator (685,815 Views)

Final Update: The POODLE vulnerability is being tracked by the Common Vulnerabilities and Exposures database. See CVE-2014-3566 for details.


Update: SSLv3 has already been disabled in the sandbox so you may test your solution. We have added a section to explain in greater detail how to perform testing in the sandbox.


If you have further questions about POODLE, please visit our Integration and Testing forum at


X-Cart users may download an upgrade that fixes SSLv3 issues. You may find it here:


Zen Cart also has an upgraded AIM payment module that fixes SSLv3 issues. You may find it here:!!!&p=1263564#post1263...



As you may be aware, an Internet-wide security issue, commonly referred to as POODLE, has been identified in the last two weeks that creates a vulnerability that could allow hackers to gain access to any connection using this outdated Web browser.


Authorize.Net itself is not vulnerable to POODLE, but we are making changes to our systems to assure that we are providing our merchants and their customers with the highest degree of security possible.


To that end, on November 4, 2014, we will be disabling the use of SSL version 3 within our systems. This means that if your website or payment solution uses SSL version 3 to send transactions to Authorize.Net, your merchants will no longer be able to process transactions. You will also no longer be able to access any secure Authorize.Net pages.


Please be sure to update any sites or solutions that may be using SSL version 3 to post transactions to Authorize.Net.


The following information is provided to help you test whether you use SSL version 3, and to help you disable it.





To encourage security best practices, Authorize.Net strongly recommends using the highest version of TLS your configuration will support. For most configurations this should be TLS 1.2.


We also recommend including support for TLS 1.1, in case there are issues with your current TLS 1.2 configuration.


We will allow TLS 1.0 connections as well, but as a best practice we recommend using TLS 1.0 as an option of last resort. We may discontinue support for TLS 1.0 at a future date.


Connections that require SSL v3 will be refused. However, your server may continue to support SSL v3 as long as it uses TLS as its preferred protocol. We recommend disabling SSL v3 as a security best practice, regardless.





To test your externally facing server configuration for TLS support, visit


You can compare the results to the Authorize.Net SSL configurations to maximize compatibility with the protocols and ciphers we support:


For internal servers, a vulnerability scanner or vulnerability management suite may be needed. Here are a few possible options for you. (Note, these are not recommendations--Authorize.Net does not endorse the use of a particular product, nor do we claim a product is suitable for all uses.) (commercial) (commercial) (commercial) (open source) (open source)





Once you have tested your solution and have determined it does not depend on SSL version 3, you may want to connect to our Sandbox environment and confirm that it works. All API endpoints in Sandbox have SSL version 3 disabled already, so testing here will confirm you can connect to our Production servers once we disable SSL version 3 there.


Note: You will need a Sandbox account to validate against these API endpoints. Visit to create a Sandbox account.


Name-Value Pair API connections (AIM, Card Present API):


XML connections:


SOAP connections:





Use the SecurityProtocol property to enable TLS.


For details on how to use the SecurityProtocol property, visit:


As an example, to force TLS 1.2 in a C# .NET implementation, you'd use: 


System.Net.ServicePointManager.SecurityProtocol = System.Net.SecurityProtocolType.Tls12;




NOTE: TLS 1.2 was first supported in JDK 7, and will be default in JDK 8:


Use the SSLContext.getInstance method to enable TLS.


For details on how to use the SSLContext.getInstance method, visit:,...


For example, to use the default security layer provider to enable TLS, you'd use:


object = SSLContext.getInstance("TLS");


To force TLS 1.2 while using Sun's Java Secure Socket Extension (JSSE), you'd use:


object = SSLConnect.getInstance("TLSv1.2", "SunJSEE");




Use the CURLOPT_SSLVERSION option to enable TLS.


For details on how to use the CURLOPT_SSLVERSION option, visit:


As an example, to force cURL to use TLS 1.0 or later, you'd use:







curl_setopt($curl_request, CURLOPT_SSLVERSION, CURL_SSLVERSION_TLSv1);



In cURL 7.34.0 or later, to force TLS 1.2, you'd use:




curl_easy_setopt(curl, CURLOPT_SSLVERSION, CURL_SSLVERSION_TLSv1_2);



curl_setopt($curl_request, CURLOPT_SSLVERSION, CURL_SSLVERSION_TLSv1_2);