Knowledge Base Testing & Certification Tools

TLS Help Center

TLS 1.0 Permanently Disabled

Just before 7AM EDT on Sunday July 1 2018, TSYS permanently disabled TLS 1.0 in both of our data centers, per PCI's industry-wide mandate. If you attempt to process a transaction using TLS 1.0 through any of the TSYS-offered API's, the request will fail and your transaction will not be processed. Additionally, attempting to access any Merchant or Partner portal from a workstation which does not support or have TLS 1.2 enabled, will result in failure of the page loading.

Please refer to the below topics for additional information on why this change has been implemented, what systems are impacted and suggestions for configuring and resolving issues which may be related to this change.

What is TLS?

Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer (SSL), both frequently referred to as "SSL", are cryptographic protocols that provide communications security over a computer network.
  • Encryption protocol that ensures privacy between communicating applications and their users online
  • Ensures no 3rd parties can eavesdrop or tamper with messages when servers and clients communicate
  • Successor to SSL (Secure Socket Layer)

Did PCI 3.1/3.2 make a change regarding TLS?

In 2014, the US National Institute of Standards and Technology (NIST) declared TLS 1.0 to be unacceptably weak and unsafe cryptographic protocol. Accordingly, the PCI SSC has mandated that TLS 1.0 must be disabled by June 30, 2018 (per PCI 3.1 and PCI 3.2). All payment application providers are required to update to (at least) TLS 1.1 - if not TLS 1.2 - by this deadline.

Does this change affect TSYS' services?

The TSYS gateway has supported TLS 1.1 and 1.2 since at least mid-2014. In accordance with the PCI SSC's mandate, on July 1, 2018, TSYS will be disabling support for TLS 1.0 in all of its products, including (but not limited to) Genius, Transport.Web, MerchantWare, and its portals.

On July 1, 2018, will TSYS support TLS 1.1, 1.2, or both?

We've seen some payments providers take the stance that they will only support TLS 1.2. Our present position is to support both TLS 1.1 and TLS 1.2, while strongly encouraging its merchants and ISVs to support TLS 1.2. Should NIST or PCI deem TLS 1.1 to be an "unacceptably weak and unsafe cryptographic protocol" as TLS 1.0 was, we will of course take approprate action to discontinue supporting that protocol.

As a pragmatic matter, TLS 1.1 and 1.2 were rolled out in all major operating systems (eg. Windows 7), frameworks/runtimes (eg. Java 7), and libraries (eg. OpenSSL) simultaneously. Combined with the fact that these protocols are designed to auto-negotiate the strongest possible encryption possible by default, in practice, this has resulted in very little TLS 1.1 adoption in the marketplace. Indeed, TLS 1.1's usage on our payment gateway is presently a rounding error (< 1%), compared to TLS 1.0 (roughly 60% as of 2017Q2) and TLS 1.2 (roughly 40%), andbecause of this, we expect that after the July 1, 2018 deadline, over 99% of our gateway's traffic will be secured using TLS 1.2.

TSYS is also eagerly monitoring TLS 1.3's status, as it is quickly moving from being a working draft to being an official RFC, in our desire to provide the utmost security for its merchants and partners' payment transactions.

My/my merchant's acquiring bank/stored value provider is sunsetting TLS 1.0 sooner than TSYS is. How does that affect me?

Some payments providers (eg. Elavon) and stored value/gift card providers are discontinuing support for TLS 1.0 earlier than the PCI mandated mid-2018 deadline. TSYS does not expect this to present any challenges for its merchants or ISVs. TSYS has made preparations in advance of these cut-over dates, and already uses TLS 1.2 when communicating with all of its payments partners. Your terminals and points of sale can continue to connect to TSYS using TLS 1.0/1.1/1.2 until mid-2018. Behind the scenes, our payment gateway makes a connection using TLS 1.2 to your acquiring bank (eg. First Data, Elavon, Chase, etc...), so no disruptions to your processing are expected due to these cut-overs. By using our gateway, merchants and ISVs are insulated from any early TLS 1.0 sunsetting dates done by acquirers.

We do want to note that some of these payments providers also offer web browser based portals in which merchants can review their transactions. These portals are not controlled by TSYS, and if merchants wish to continue to use these portals, their browsers/operating systems must be updated as per below to support TLS 1.1 (or in many cases, TLS 1.2) on the schedule dictated by their respective payments providers.

As a POS provider, how does this change affect me?

Our products are largely provided as a collection of HTTPS based web services. All communications between your POS and our payment gateway are thus secured using TLS. If your POS is deployed on a system that doesn't support newer TLS versions (eg. any version of Windows before Windows 7), you may be unable to make payments using our solutions come July 1, 2018.

What guidance has the PCI SSC provided?

Fifteen years ago, SSL v3.0 was superseded by TLS v1.0, which has since been superseded by TLS v1.1 and v1.2. To date, SSL and early TLS no longer meet minimum security standards due to security vulnerabilities in the protocol for which there are no fixes. It is critically important that entities upgrade to a secure alternative as soon as possible, and disable any fallback to both SSL and early TLS.

Please see the PCI SSC Guide on Migrating from SSL and Early TLS.

As an eCommerce shopping cart provider, how does this change affect me?

Our primary online shopping solutions, Checkout and TransportWeb, both communicate with our servers using HTTPs. If your users are using older browsers or operating systems (eg. Windows before Windows 7), they may be unable to make payments using our solutions come July 1, 2018.

If your web servers communciate with our payment gateway, these will also need to use TLS 1.1/1.2.

How can I tell which version of TLS my application is using?

A tool like Wireshark can help. See

Is there a quick way to tell if my POS might be affected?

You (or your merchants) are more likely to be affected if your POS or server:

  • Uses an older version of Windows (i.e. before Windows 7 or Windows Server 2008 R2). This includes:
    • Windows XP
    • Windows Server 2003
    • Windows Vista
    • Windows Server 2008 R1
    • Windows POSReady 2009
  • Uses an older version of Java (Java 6 or earlier)
  • Uses an older version of OpenSSL on a Linux/MacOSX/Unix environment (i.e. before OpenSSL 1.0.1).
You (or your merchants) are less likely to be affected if your POS:
  • Is based on tablet or mobile technologies (i.e. Android or iOS)
  • Is browser-based, and you are using a recent version of your web browser
    • This is especially true for Chrome and Firefox. If you use Internet Explorer, please see the notes about "older versions of Windows" above to see if you're likely affected.
  • Uses recent versions of Windows, Linux, MacOSX, or Java

Can I test if my POS works with TLS 1.2 using the TSYS gateway?

Absolutely. We have a lab available for partner testing that only requires you to edit your point of sale's "hosts file" or DNS within your control (eg. a wireless router within your lab). The lab's IP is You'll need to create an entry in your hosts file for


This lab points at our Chicago production envionrment, and is not subject to any SLAs, including uptime. Please reach out to our Integrations Team via for assistance.

While TSYS is committed to supporting both TLS 1.1 and TLS 1.2 in our production environment come July 1 2018, our TLS lab will only support TLS 1.2, and we will be working with our ISVs to ensure that they support TLS 1.2 as they validate their points of sale and shopping carts in our lab. This will help ensure that our merchants will not experience any issues if/when TLS 1.1 is found to be cryptographically weak, and the protocol must be sunset. In practice, less than 1% of our traffic is secured using TLS 1.1 today, so we do not anticipate this more stringent requirement being a problem for our ISVs.

TSYS recommends you test against the TLS lab from all operating systems that are supported by your customer base if possible. TSYS also recommends you test against the TLS lab while using all APIs you are certified for or plan to certify.

My POS/Web Server uses Windows. Help?

The Microsoft Security Team has written several articles on the state of TLS 1.2 support at Microsoft.

The below table is a quick reference guide regarding which versions of Windows support TLS 1.1 and 1.2.

Please note that if you are using Windows 7, Windows Server 2008 R2, or Windows 8, Windows has support for TLS 1.1 and TLS 1.2, but it is disabled by default. These can be changed in a number of ways - the simplest being the "Internet Option" dialog in your Control Panel. One can also push these registry changes to your workstations via Group Policy. Please note that Windows maintains different registry settings for 32 vs. 64 bit programs, and depending on how your POS is implemented, one or both registry settings may need to be updated.

Tools such as IIS Crypto can help enable your IT team enable or disable protocols, ciphers, hashes and key exchange algorithms on Windows Server 2008, 2012 and 2016. It also lets you reorder SSL/TLS cipher suites offered by IIS, implement best practices with a single click, create custom templates and test your website.

On October 5th, Microsoft announced that it has enabled TLS 1.1 and 1.2 support on Windows POSReady 2009. More details, including instructions for applying and enabling TLS 1.2 and 1.2 are available from their Security Team's post Announcing support for TLS 1.1 and TLS 1.2 in XP POSReady 2009.

Below are a number of resources from Microsoft regarding TLS support on Windows

API changes for .NET, Java, and cURL to enable TLS v1.2


Use the SecurityProtocol property to enable TLS v1.2.

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

For example, to force TLS v1.2 in a C# .NET implementation, you would use:
System.Net.ServicePointManager.SecurityProtocol = System.Net.SecurityProtocolType.Tls12;


NOTE: JDK 8 will use TLS v1.2 as default:

For JDK 7, use the SSLContext.getInstance method to enable TLS v1.2.

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

For example, to use the default security layer provider to enable TLS v1.2, you would use:
object = SSLContext.getInstance("TLSv1.2");

To force TLS v1.2 while using Oracle’s Sun Java Secure Socket Extension (JSSE), you would use:
object = SSLConnect.getInstance("TLSv1.2", "SunJSEE");


Use the CURLOPT_SSLVERSION option to enable TLS v1.2.

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

In cURL version 7.34.0 or later, use the following examples to force TLS v1.2:

curl_easy_setopt(curl, CURLOPT_SSLVERSION, CURL_SSLVERSION_TLSv1_2);

curl_setopt($curl_request, CURLOPT_SSLVERSION, CURL_SSLVERSION_TLSv1_2);

Third Party TLS Libraries

Even if the underlying operating system doesn't support TLS 1.2 (eg. Windows POSReady 2009), there's still hope. There are a number of 3rd party TLS libraries that a POS developer might employ in your solution so that your software can support TLS 1.2, without requiring merchants to go through expensive hardware & operating system upgrades. Using this approach, TSYS was able to make its Store & Forward product support TLS 1.2 on Windows POSReady 2009, with only a few days' effort.

Without making any endorsement or claims of fitness, below are several such libraries that you might consider:

Other Resources

  • Partner Presentation - PCI 3.2: Disabling TLS 1.0
    • Slide Deck
    • Webinar (available after April 12, 2017)