There is a great deal of misinformation with regard to PCI compliance or, more formally called PCI DSS compliance. Let’s talk about what PCI compliance actually means and also how the various aspects of your online business affect your PCI compliance requirements. We’ll go over the role of SSL certificates, the difference between payment gateways, and how Cart66 goes beyond all other WordPress ecommerce plugins to provide the most security for your WordPress store.
SSL Certificates and PCI Compliance
Let’s start with the biggest misunderstanding there is right now about PCI compliance. The biggest fallacy that I hear all the time is that all you need to do is install an SSL certificate on your website and your PCI compliant. People say this all the time, even people who are often regarded as “experts” in the field say that an SSL certificate is all it takes. While it would be very convenient for this to be true, all you have to do is look at the PCI compliance self assessment questionnaires (SAQs) and it will be immediately obvious that there is a lot more to PCI compliance than simply installing an SSL certificate.
It really all depends on how you handle collecting and transmitting your customers credit card information. As we’ll talk about in a minute, Cart66 provides you with your own secure hosted payment page that works with over 100 different payment gateways. Perhaps best of all, the payment page is skinned with your WordPress theme so it looks exactly like the rest of your site. When using Cart66 you don’t even need an SSL certificate on your own site because Cart66 handles all the security for you. Sort of like if you used PayPal, but Cart66 keeps all of your design and branding and gives you the freedom to pick from over 100 different payment gateways.
Bottom line: Installing an SSL certificate does not make your website PCI compliant.
What Is PCI Compliance Anyway?
The Payment Card Industry, lead by Visa and MasterCard, have come up with a set of requirements which an organization has to meet to ensure the security of processing, storing, collecting, and transmitting cardholder information, or credit card data. The more involved your organization is with credit card data, the more requirements you have to meet. For example, if you store credit card numbers (PANs – primary account numbers) in your database then there is a very large number of requirements you have to meet in order to comply with all of the PCI DSS requirements. The good news is that you can offload a great deal of this burden by using 3rd party processors. So, if you want to store credit card numbers so your repeat customers can checkout without having to re-enter all of their billing information or so that you can charge customers on a recurring basis for subscription services, rather than storing the credit card numbers in your database, you can store the credit card numbers with your payment gateway.
Of course, if you don’t have the need to store credit cards, that reduces the number of requirements you need to meet, but it does not eliminate all of the requirements. We will talk more about other ways that you can dramatically reduce the burden of PCI compliance on your business, but if you have any customers that pay you with their credit cards, you are – what they call – “in scope” and need to comply with the PCI compliance requirements that pertain to the ways you handle cardholder data. We’ll talk about the four different ways you might handle cardholder data and what that means for your business.
Bottom line: If any of your customers pay you with their credit cards, you will need to be PCI compliant.
PCI Compliance Is At The Organization Level
While people often focus on their website when considering PCI compliance, the truth is that PCI compliance is not just for your website, it applies to your business or organization as a whole. This is because there may be more ways that you handle credit card data than just through your website. For example, you might take orders over the phone where customers tell you their credit card numbers. That whole process has a set of PCI compliance requirements. Or, maybe you accept mail in orders where you receive credit card numbers in the mail. Perhaps you have point of sale terminals that process credit card payments. There are a wide variety of ways your business might come into contact with cardholder data and all of that impacts what you need to do to meet the PCI compliance requirements for your business.
Many business are e-commerce business only. So the only way they every come into contact with credit card data is through customers purchasing products or services through a website. Even if you don’t store the credit card information, even if the credit card information never even touches your web server at all, there are still requirements you need to meet in order to be PCI compliant. So, it’s really a misleading thing to say that your website is PCI compliant. Your website certainly plays a role in what is involved with getting your business to be PCI compliant, but the proper way to understand PCI compliance is at the organization level. In other words, it is not your website that is PCI compliant it is your business that is PCI compliant.
Bottom line: Your business is PCI compliant, not your website.
Four Ways You Might Handle Cardholder Data
The PCI compliance requirements apply to your business if you store, process, collect or transmit cardholder data. Let’s go over each one of those actions so you will know if it applies to your business.
Store: People generally know that it is a really bad idea to store credit card data on your server or in your own database. Storing credit card data is pretty much exactly like what it sounds like it is – writing credit card data to your server’s file system or database. Most people avoid doing this and storing credit card data is generally not something WordPress ecommerce sites do. With most payment gateways providing a secure vault to store credit card data on your behalf, storing credit card data on your own server is usually not even something you need to do.
Process: Most people running WordPress e-commerce stores use payment gateways like Authorize.net, Stripe, PayPal, etc. to handle all the credit card processing. Credit card processing is the action involving banks, approving transactions, and moving money around. This is not something that you would be doing directly on your website.
Collect: Collecting cardholder data is essentially the form where your customers enter their credit card information to pay for an order. If your customers enter credit card data on a web page that you host, like a page of your WordPress site, then you are most likely collecting cardholder data.
Transmit: Passing the credit card information from your website to the payment gateway is transmitting cardholder data. Even if the information does not touch (or pass through) your web server, your website may generate the code that is responsible for the security of transmitting the cardholder data to your payment gateway.
Wile storing and processing cardholder data is almost always handled by 3rd party services like payment gateways such as Authorize.net, Stripe, PayPal, etc. many WordPress stores are involved in collecting and transmitting cardholder data. This is one of the reasons why you can’t just install an SSL certificate and assume that your website has met all of the requirements for PCI compliance. There are several different ways your website might collect and transmit cardholder data. How you implement the process has a big impact on the requirements you must meet in order for your business to be PCI compliant.
Bottom line: Even though you don’t store or process credit cards, you may collect and transmit credit card data and that puts your business in scope for PCI compliance.
What Is Scope?
PCI compliance has an entire vocabulary all to itself which makes the whole thing even more confusing. You often hear people talking about being “in scope.” PCI Compliance “scope” is used in a way very much like the “scope” of a web development project. If you are web developer or work at a web development agency, or even if you have done some freelance projects, you are probably familiar with the term “scope creep.” If your project has experienced scope creep, that generally means you have to do more stuff than you originally planned to do. In other words, the number of features or quantity of work has increased from what you and your client originally talked about. If you have a statement of work, or a proposal that described what you were going to provide, and your client then comes back and says they want some additional stuff, you might say, “OK, but that is outside the scope of our project and we’ll have to adjust the price.”
In the same way the a web development project’s scope is the agreed upon amount of stuff you need to do, PCI compliance scope is basically the amount of stuff you need to do to meet the requirements that the payment card industry has established to ensure the security of credit card transactions. Your business is considered “in scope” if you have customers that pay you with their credit cards. That means, if you accept credit card payments, then there is stuff you have to do to ensure that those payments are kept safe and secure. You can “reduce scope” by offloading various aspects of accepting credit card payments to 3rd party services. That means, there are various things you can do and services you can work with that reduce the amount of stuff you have to do to make sure your customers credit card payments are secure. Check out this video / article to learn more about how to make PCI compliance easier.
Bottom line: Scope just means the amount of stuff you have to do to make sure your customers credit card payments are secure.
Four Ways To Limit PCI Scope
Now, let’s talk about the four main approaches people take to secure their payments an then see how effective each approach is and what impact they have on your PCI compliance.
First, let’s identify the main problems. The main thing you are trying to avoid is having cardholder data hit your server where WordPress is running because that puts you in the SAQ D which literally takes several months of full time effort to complete. SAQ D is required if your payment form is on your server, it posts back to your server which then passes the cardholder data to your payment gateway. It doesn’t matter that you aren’t storing the credit card data – that’s a-whole-nother can of worms. We’re just talking about “transmitting” the data.
So how can we move down the scale towards SAQ A? Well, at the start of the SAQ A it says “Before you begin” and, with regard to e-commerce merchants, it says “All elements of the payment page delivered to the consumer’s browser originate only and directly from a PCI DSS validated third-party service provider.” So what does that mean for the four common ways people try to secure their payments?
Direct Post
Direct Post is where you set the action URL in your form tag to post directly to your payment gateway. This gets the cardholder data to your payment gateway without touching your WordPress server, but it doesn’t meet the requirements for SAQ A because you are still hosting the “elements” of your payment page.
If you are going to take this approach then you need to use SAQ A-EP because while your site does not, itself, receive cardholder data, your site does effect the security of the payment.
So what’s the difference between SAQ A and SAQ A-EP? SAQ A-EP is 50 pages long, contains over 130 questions and your WordPress host is almost guaranteed to fail the test. You have to answer questions about firewalls, disabling insecure protocols (like FTP), all software has to be up to date. I answer support tickets all day long from folks still running PHP 5.2 which hit it’s end of life over 5 YEARS AGO!
Authorize.net and SecurePay are both examples of payment gateways that offer direct post as one way to use their payment gateway.
JavaScript
OK, so what’s the next option?
Rather than posting the data to the payment gateway directly from our form tag, we could use JavaScript to pass the credit card data. An example of this would be BrainTree JS and the original Stripe.js. But here we still have the problem where we are hosting elements of the payment page. So this doesn’t get us down to SAQ A either.
iFrames
Behind door number 3, we have iFrames. If you listened to Tony’s talk yesterday from Sucuri you will see that I echo his same sentiments regarding iFrames. In the same way that it would be easy change the action URL on a form tag with transparent redirect, all you have to do to is swap in a bogus source URL for the iFrame. It’s a change to one line of code that could easily be done with just a snippet of JavaScript. Worst of all, you wouldn’t even know it because everything would still look exactly like it did before. But now you’re pulling in a couple of form fields from a bogus server. Be that as it may, this is how the new Stripe.js works and apparently – at least according to Stripe – it’s enough to get you into the SAQ A. I suppose it all comes down to how you define a payment page, but since your WordPress server is rendering the code that includes the iFrame, and the source of the iFrame could be change with just a snippet of JavaScript, you still run a pretty high risk when taking this approach.
Hosted Payment Pages
The final option is to use a 3rd party hosted payment page. The first example of a hosted payment system you might think of is PayPal. Also, our product Mijireh which provides hosted payment page that integrates with a bunch of different gateways. We have a new product that we’re about to launch in partnership with WooCommerce called Secure Hosted Payments which is like Mijireh 2.0 and built exclusively for WooCommerce.
The idea behind hosted payment pages is that you send your customer to an entirely different server and all the payments happen over there.
A secure hosted payment page clearly satisfies the requirement of having all the elements of the payment page originating only and directly from a PCI compliant server. Of the two options that get you down to the SAQ A, a secure hosted payment page is also the most secure and hardest to hack. Unlike the iFrame approach, it can’t be done with a snippet of JavaScript. You would first have to implement a bogus hosted payment page, implement our API to pass in the items and prices in the shopping cart, then modify server side PHP code to call the bogus API then redirect to the bogus page.
Also, unlike an iFrame, which could be swapped out without making any visual changes at all to your site, you, as the store owner could look and immediately see that the hosted payment page doesn’t look like your site and isn’t hosted at the proper domain.
There are a few downsides to traditional hosted payment pages, primarily around customization. You’re on a totally different domain and the payment page looks nothing like your site at all. At best, you might be able to upload a company logo.
The main thing that sets Secure Hosted Payments apart from other hosted payment services is that you skin the secure payment page with your WordPress theme. It all happens in a single click. You get all the security benefits of a hosted payment page, including being able to use the SAQ A, without losing any of your branding.
How Cart66 Makes PCI Compliance Easy
PCI compliance, and self-assessment questionnaires can seem really complicated and be very intimidating. There are lots of technical questions that are confusing. Cart66 makes PCI compliance as easy as possible by handling all the technical details for securing the payments and e-commerce data for your online store. Other WordPress plugins might say that they help you with PCI compliance. But, as we have already discussed, installing an SSL certificate is not all it takes to be PCI compliant. You have to take into consideration how you are handling the credit card information. In particular, how you collect and transmit credit card data makes all the difference. Cart66 provides a secure hosted payment page that looks exactly like the rest of your WordPress site. In other words, Cart66 hosts one page – the payment page – for your WordPress store and that page is skinned with your own WordPress theme so it literally looks exactly like all of your other pages that you host yourself.
With Cart66 you aren’t burdened with lots of paperwork and technical PCI compliance issues. You are free to do what you love – build your business.
