The PCI Council has released a new update to the PCI Data Security Standard (version 3.1).

The main changes in version 3.1 are the deprecation of SSL 3.0 and TLS 1.0 as secure protocols. SSL and early TLS (TLS 1.0) are not anymore considered strong cryptography and therefore cannot be used as a security control. 

To remain compliant with the PCI DSS standard, existing implementations that use SSL and/or early TLS must have a formal Risk Mitigation and Migration Plan in place. Effective immediately, new implementations must not use SSL or TLS 1.0 protocols.

  • What is TLS?

    Transport Layer Security (TLS) is a protocol that ensures privacy between communicating applications and their users on the internet. When a server and client communicate, TLS ensures that no third party may eavesdrop or tamper with any message. TLS is the successor to the Secure Sockets Layer (SSL).

  • What is the timeline?
    • For inbound communications (entering the gateway), we already support TLS 1.2. Please note that the system is backward compatible and we do still support previous version of TLS for now. However it is strongly recommended that you upgrade to TLS 1.2 as soon as possible.
    • For outbound communications (coming out of the gateway), TLS 1.2 will be available in our TEST and PROD environment as of April 2017. As of then you are encouraged to upgrade as soon as possible to TLS 1.2 and let us know if you encounter any issue.

    Ingenico ePayments requires all merchants to upgrade their security protocol before April 30, 2018.


  • I use e-Commerce Hosted Payment Page. Am I impacted?

    If you use our e-Commerce Hosted Payment Page product, the transactions are initiated from this product. Therefore there is not impact for the gateway inbound communications. However if you have implemented any of the outbound communications (such as the post-sale or offline status changes), you need to upgrade to TLS 1.2.

  • I use DirectLink (server-to-server). Am I impacted?

    If you use our DirectLink server-to-server product, there is an impact on the inbound communications and you need to upgrade to TLS 1.2.

    Moreover if you have implemented any of the outbound communications (such as the post-sale, or offline status changes), you also need to upgrade to TLS 1.2.

  • Where can I find more information?

    More information can be found in the following official publications:

  • What if the cardholder’s browser is still using TLS 1.0?

    If the cardholder uses a deprecated browser, based on TLS 1.0, the payment page will not be displayed. There will be no specific warning on the issue. The cardholder will have to upgrade to a newer web browser.

  • What if I have or can only use TLS 1.1?

    TLS 1.1 will not be deprecated in the near future and can therefore be used. However, for security reasons, we do recommend to always use the latest version of the protocols, and therefore advise to upgrade to TLS 1.2.

  • Are there external resources available to assess my current implementation of TLS?

    In order to test your implementation you are welcome to use external tools such as https://www.howsmyssl.com.

  • Am I impacted by this change?

    If you are using HTTP post-sales you might be impacted. The following steps will help you identify if you are compatible with TLS 1.2 or not.

    Step 1: Find your post-sale url.

    For static URL

    1. Go to your Ingenico ePayments back office
    2. Click on “Configuration”
    3. Click on “Technical Configuration”
    4. Click on “Transaction Feedback” 
                 
    5. In this view, you will find the static URLs that are used in your post-sale       
    For Dynamic URL
    Ask your integrator/webmaster to give it to you or ask him to review this guide.
    Step 2: Test your URL
    1. Go to the sslLabs website https://www.ssllabs.com/ssltest/
    2. Enter your post-sale URLs
    3. Click on Submit (You should get a summary after a few seconds)
    4. Scroll down to Configuration/Protocols and ensure you support TLS1.2
    5. Ensure you also support other ciphers than TLS_RSA_WITH_3DES_EDE_CBC_SHA
    Step 3: Results are bad. What should I do?
    • If you got a result where you don't support TLS 1.2
    • If the only cipher suite supported is TLS_RSA_WITH_3DES_EDE_CBC_SHA
    You should contact your integrator/webmaster/infrastructure engineer explaining the situation. They should be able to help you getting up-to-date.
  • What are the consequences of not being up to date with security protocols?

    The PCI council requires Payment Service Providers like Ingenico ePayments to depreciate older protocols that are no longer considered secure. This means that post-sale exchanges using TLS 1.0 will be considered as not secure by our payment engines and will fail.

  • Are my shoppers impacted by this change?
    If the cardholder uses a deprecated browser or old device that does not support the TLS 1.1 or TLS 1.2, security protocol, the payment page will not be displayed. There will be no specific warning on the issue. The cardholder will have to upgrade to a newer web browser.
    As a merchant, you could mitigate the risk of lost transactions by advising users to upgrade their browsers.
    The Wikipedia page on TLS provides a complete and comprehensive overview of which browser versions and devices support which security protocols. https://en.wikipedia.org/wiki/Transport_Layer_Security
  • How can I test my POST-SALE integration?

    Make a test transaction
    Step 1: Setup your test account (You can skip this step if you already have one)

    1. Create a test account and set it up to be connected to your test environment.
    2. Set your POST-SALE URL

    i. Static URL

     

    ii. 

    iii. Dynamic URL: Ask your integrator/webmaster to give it to you or ask him to review this guide.

    Step 2: Perform a test

    You can use the Back Office test pages to perform a test transaction or your usual means (ask your integrator/webmaster). Then you can confirm that the postsale has been received and treated normally. 

    Step 3: Troubleshooting (It's not working)

    Examples https://docs.microsoft.com/en-us/aspnet/web-api/overview/advanced/calling-a-web-api-from-a-net-client



This website uses cookies to be able to give you the best user experience. If you don't want to accept these cookies, we allow you to change the cookie settings. Click 'Accept' to allow all cookies from this website.

Cookie settings

Introduction

Functional

Functional cookies are required for the website to operate correctly. These cookies cannot be disabled.

Optimized

Optimization cookies allow us to analyze site usage so we can measure and improve our website.
This is the default level.

Personalized

Personalization cookies are used for social media and advanced personalization. They allow us to show you information related to your company.


Example functionality allowed

  • Store country preference
  • Store language preference

Example functionality not allowed

  • Saving personal data
  • Anonymous tracking via Google Analytics
  • Tracking for remarketing purposes

Example functionality allowed

  • Store country preference
  • Store language preference
  • Anonymous tracking via Google Analytics

Example functionality not allowed

  • Saving personal data
  • Tracking for remarketing purposes

Example functionality allowed

  • Store country preference
  • Store language preference
  • Anonymous tracking via Google Analytics
  • Serve content relevant to your interests
  • Serve ads relevant to your interests
  • Tracking for remarketing purposes

Example functionality not allowed

  • Saving personal data