PCI DSS 3.1: An Important Incremental Change to Payment Security Standards

December 04, 2015 Risk & Fraud
Atit Shah
By Atit Shah, Head of Security
Atit Shah
By Atit Shah, Head of Security


Open safe door

What is HTTPS?

Have you ever wondered what that little “s” at the end of HTTPS in your browser address bar stands for? Think back to when you last made a donation or purchased something online. You probably saw both the URL of the webpage you visited likely preceded by the letters “HTTPS” and maybe even a green lock icon. Back in the day, there was no “s” — only HTTP. So what happened, why the change, and why should you care?

It all boils down to security. The “s” at the end of HTTPS stands for secure, and it means that all communications between your browser and the website you’re visiting is securely encrypted. A secure connection is important when you’re transmitting sensitive data such as payment information over the Internet. This is why HTTPS is a standard — especially for all reputable online businesses today.

Improving security

When it comes to security, standards continue to evolve. As new vulnerabilities are discovered in the underlying protocols used to encrypt cardholder data, the Payment Card Industry (PCI) Council responds with updates to its Data Security Standards (PCI DSS) that reflect new best practices. Two months ago, we took to our blog to help you understand the most important changes in PCI DSS 3.0. While it may seem too soon to start thinking about another update to the security standards, the newly released PCI DSS 3.1 contains information that we think is worth the deep dive.

PCI DSS 3.1 is an incremental update to the standards that primarily addresses web browser security. The focus is on basic but commonly used Transfer Layer Security (TLS) protocols that no longer meet the criteria for strong cryptography required by the PCI Council. This means that the susceptible protocols, SSL 3.0 and its early successors, TLS 1.0 and 1.1, are prohibited from being used to encrypt cardholder data. By extension, the PCI Council is requiring anyone involved in the handling or processing of payments — including WePay and our partners — to disable support for the aforementioned protocols and enable support for TLS 1.2 in their place.

Working together

In response to this mandate, we plan to end support for all earlier versions of TLS by June 30, 2016. This means that all incoming API requests or web portal (e.g. logged in site) sessions will need to use TLS 1.2.

To ensure continued access to WePay services, partners may need to update internal technology stacks to support TLS 1.2. This may entail updating servers and/or programming language environments. Partners may also need to update lists of supported browsers (or versions) to ensure a fully functional WePay experience for merchants and payers.

We will send out periodic communication to guide your efforts during this time of transition to TLS 1.2. In case of any questions, contact us at security@wepay.com.

UPDATE 12/21/2015: The PCI Council has recently announced that the migration deadline for older versions of SSL and TLS has been extended from June 2016 to September 2017. In accordance with this update, we now plan to end support for all earlier versions of TLS by September 2017. 

About the author

Atit Shah

Atit Shah, Head of Security

Atit Shah is Head of Security for WePay. He has more than 11 years of combined experience in technology, security and leadership. Prior to WePay, he held security-related positions at Microsoft, Deloitte, and Ernst & Young.

More blog posts by Atit Shah