A new PCI Compliance Standard—PCI DSS 4—has come into effect over the previous year. If your website has e-commerce you should be aware of the changes that are coming.
PCI DSS stands for "Payment Card Industry Data Security Standard". The e-commerce world has been operating under version 3 of that standard since 2014. Version 4 is the latest version of the standard. It came into effect on March 2024, but its more serious requirements take effect in March 2025. E-commerce websites should have a plan to ensure they remain compliant after that date. Websites that are non-compliant may fail security scans or self-assessment questionnaires, and be subject to fines or suspension of their e-commerce capabilities.
What is the purpose of PCI DSS?
Credit card fraud is a huge problem, especially in e-commerce where card-not-present transactions are the norm. PCI DSS is a set of best practices for ensuring that credit card data is handled safely, and website security breaches do not cause a cascade of additional problems as stolen cardholder data becomes exploitable by cyber criminals.
The single most important issue in PCI compliance is whether you handle sensitive cardholder data (credit card numbers, cardholder names, expiry dates, or CVV numbers). If you do handle such data, you have a large set of obligations in securing your IT environment to ensure that the cardholder data is processed and stored safely.
These obligations can result in a time-consuming and expensive burden for you. Fortunately there are ways to mitigate these requirements, so that you never need to handle cardholder data directly. If you want to reduce your costs and risks, your e-commerce processes can be designed to off-load card handling from your website entirely.
What is new in PCI DSS Version 4?
There are many new changes in version 4. The parts that are mostly likely to affect small- to medium-sized website owners relate to the checkout and payment screens of your e-commerce flow.
Payment providers have been offering newer, slicker methods for integrating their payment methods into websites. To reduce the need to handle cardholder data directly, many now offer tokenized card handling. This lets you store a credit card without actually holding any of the cardholder data. Instead you keep a token, which represents the card, but cannot be used on any other website. This makes it easy to accept payments on previously-used cards, without requiring the buyer to type in their card information each time, and without requiring the merchant to store any of the card details.
Payment providers have also been developing slicker ways to integrate payment forms into websites, so that buyers never leave your web pages in order to pay. The credit card forms are embedded using technologies like Javascript and iframes. They appear to reside on your web pages, but they only talk to the payment provider, so the credit card information never actually passes through your webserver.
Unfortunately, that is no longer considered to be a safe practice, as of DSS 4. The essential problem is that if the payment form appears to be part of your web page, then a hacker could simply replace the form with a different form that looks the same, and the customer would not be able to tell that something was amiss.
PCI DSS 4 now treats anything that could potentially alter the payment page as if it were handling sensitive cardholder data, even if is isn't. As long as there is a risk that a hacker could imperceptibly alter your payment forms, the form is considered insecure. Since your CMS has the power to alter your pages, that means your CMS will henceforth be treated as if it were handling sensitive credit card data, even if it does not.
Is my website affected?
When you reach the credit card payment form of your checkout process, whose domain name is in the browser address bar? If it is your payment provider (for example moneris.com, stripe.com, or authorize.net) then the customer has completely left your website to complete the payment, and you are in the clear.
If you see your own domain name in the browser address bar, then you have an integrated payment form, and your website now falls under the PCI DSS 4 requirements. You should expect to be subjected to much stricter security and IT policies going forward.
If you don't want the added hassle and expense of PCI DSS 4 compliance, then the simplest option is to de-integrate your payment form. Switching to a hosted payment form under your payment provider's URL will move the PCI DSS 4 compliance problem to them instead of you. And since credit card payments are their specialty, you should be able to trust them to live up to their obligations if they are one of the larger, reputable vendors.
The tokenization of credit cards is still considered a safe practice. Many payment providers allow you to continue to utilize tokenization even if you choose to stop using integrated payment forms. Some, however, do not. Since everyone will be reviewing and updating their services in the wake of PCI DSS 4, we can expect payment providers to update their APIs in the coming months. Stay tuned!