PCI Compliance and Clarifications

[checheconleche]

Hello Joomla Community,

I am hoping to reach out and have a general discussion in order to get some clarification into the expectations for PCI compliance on our servers, and the ability to get around it if desired. Just a little background, I run my own servers, host 10 or so sites, one of which I have maintained PCI compliant for a Joomla 1.5 install and ZenCart. I run the quarterly scans, end up having to contest 5 to 10 false positives, wait for approval, etc, etc, etc. It has been my experience that this is a pain, and I would rather outsource to Paypal or Authorize.net to handle this for me.

I have read through everything on the PCI compliance site, and many articles. I am not a lawyer, and honestly it hurts my noggin to try and figure out what is right and what is wrong. It is my understanding that if Credit card information is entered into a form, and the domain name in the browser url at that point is the domain hosted on your server, then you are required to fill out either SAQ C or D and pass a quarterly PCI compliance scan.

I would so much prefer to utilize these 3rd party services to outsource this responsibility, and since you have to pay for a gateway anyway it is an added bonus. I have recently been looking through the subscription services extensions, and although most of them offer integration with Paypal or Authoriz.net, etc. they chose to program the billing information to be entered into the Joomla site and then pass the information off to the gateway using the API.

My questions are: Has it already been decided that sending someone out to a 3rd party is an extra step, that discourages sales, and makes it a detriment to a site? Therefore although PCI compliance is a pain, it is worth it as the returns and actual sales increase? Is everyone just fudging information on their SAQs and not paying attention? I have run into a lot of customers that just pay the $30 non-compliance fee each month because it is cheaper than managing the PCI scans, etc. anyone else see this? Scary right?

I understand that PCI compliance is not going away. I know that the CC companies have realized that there is no security on the web that cannot be breached, and are attempting to pass the liability on to us, their loyal subjects. I understand the importance of server security, maintain security standards, and go beyond the requirements for PCI. I am just sick of having to explain that the Windows program that ComplyGuard Networks says is vulnerable on my linux server, isn't actually there, and that 404 pages are in fact handled properly although their scan says they aren't.

Forgive me for ranting a bit, but any clarification/insight into what others are doing to manage this would be helpful, as I see some discussion on this forum about getting to PCI compliance, but not much about getting around it. Thanks in advance.

-Brad, if you can share some of your wisdom in this matter that would be great. I have seen from your posts that you know PCI compliance well.

[numinousmedia]

Glad to know I'm not alone in my PCI frustration. . . I'd be interested to hear any other input on this topic as well.

[PhilD]

Basically as you mention.
I am not a Lawyer so take the following advice and comments with that in mind.

If you collect credit card data (that is the number and the code), checking account information, or other account info, or have such info captured anywhere on your domain, or servers, backups, etc., you are required to meet certain requirements. This is because it is highly possible to match the numbers with the person in the event of a data breach. Properly keeping certain data is expensive, and a big headache in general.

If you do not collect credit card data (the number and the code), checking account information, or other account info, or have such info captured anywhere on your domain, or servers, backups, etc., you are not required to meet certain requirements. The service used (such as PayPal) is required to meet the requirements. This is because all you are storing on your Joomla site is registration info for later log in to the site and for the convenience of the user just as many community builder type programs store this info for their users. You can call it billing, shipping, registration, community profile, etc. it is still the same thing, just a name and address with no account (cerdit, checking) info associated with the name.

Component stores such as Virtuemart offer the option to finalize the transaction on a service such as PayPal and not enter any information such as credit card numbers into the Joomla site. User billing name and address is just that, nothing is tied to the credit card or checking account of that person on the Joomla site. These same component stores also offer various payment modules that do collect account info and those paymentmodules should not be used as they require the expensive compliance way of operation.

Personally, I prefer to be sent out to PayPal (for example) for the transaction. I feel my credit card and checking account info is safer there than in your site, regulations compliance or not.

[Webdongle]

If you intend to accept credit cards on your site my suggestion would be hire an expert or Company to set up and run your server.

If you intend to continue running the site and servers yourself I would suggest you use a Payment Gateway like Paypal, Worldpay or one of the other well known Payment Gateways. So that the the credit card details are handled on servers run by experts.

By using an extension in Joomla to connect to a Payment Gateway all that is entered into your site are the order details. Which are passed to the Payment Gateway and then the card details are entered on their site.

If any of the Owners of the "10 or so sites" (your servers Host) have shops with PoS for credit debit cards .... then you may wish to contact the terminals in the shop(s) as they may have an internet solution. But if the Owners of the "10 or so sites" (your servers Host) do not have shops that accept cards ... then linking to a Payment Gateway is possibly your best option.

[checheconleche]

Thanks PhilD, I totally agree with you and I feel you gave a very good explanation of where the lines are drawn. I repeat, I'm not a lawyer either, but I feel that this about sums up what I have derived from the PCI compliance site literature and from my experience with various compliance scanning companies that I have dealt with. I agree that the safest solution is to utilize paypal or another secure gateway directly for processing and storing data. They have budgets for lawyers, I don't.

Which is why I wanted to start this discussion and truly hope that further clarity can come from it. My feeling is that CMS's like Joomla appeal to startups and entrepreneurs and give them the ability to get up and running online with a little reading and late night frustration. Many of said newbies likely are on shared hosting, have no idea what a command line is and would probably think that PCI is a new micro-brewery up the street. Then you have extensions that offer the ability to sell stuff, sell subscriptions for content, make donations, etc. These extensions then tell you that they integrate with paypal and Authorize.net, which the newbie assumes are safe, and next thing you know, newbie gets caught with their pants down and a $30 fine/month for not being PCI compliant. Professionals know that shared servers can't be PCI compliant, but not newbies.

I just feel like as a community we need to inform other users to be aware of the pitfalls that can occur and what is expected of them when they begin to accept money on their sites. I would like to encourage extension developers to build in the offsite payment as an option. Perhaps developers of these extensions should be better about disclosing the PCI compliance issue and informing customers who think they are getting a plug and play solution. I would like to hear how others are dealing with this and what their solutions have been.

[Webdongle]

Then you have extensions that offer the ability to sell stuff, sell subscriptions for content, make donations, etc. These extensions then tell you that they integrate with paypal and Authorize.net, which the newbie assumes are safe, and next thing you know, newbie gets caught with their pants down and a $30 fine/month for not being PCI compliant.

But if the extensions 'integrate with paypal and Authorize.net' ... then the newbies site does not need to be PCI compliant, because the newbies site is not accepting the card details.

[PhilD]

The Joomla site (store) itself, the domain and the servers the domain runs on, does not need pci compliance or approval from any card vendor, or clearing house, etc., if and only if you never accept, store, backup, or otherwise capture any account number data associated (card details) with a customer. It is ok to collect the order and address data of a customer.

Since being complaint is cost prohibitive for many small businesses then the best way is to use as a payment gateway to handle the actual money transaction.

I order various products online all the time from various sized companies as well as individuals. Personally, I like to see a PayPal option and will use it instead of giving my credit card number to a site that I have no idea of the security of.

As far as new people getting into selling something; as I mentioned earlier, there are extensions that contain multiple modules and/or ways to make payments. If you collect card details, then you will have to meet certain requirements in order to become approved to accept that data. Laws in other countries may differ with some being more strict and some maybe being nonexistent. Violation of the rules set by the card issuers and/or other authoritative rules governing transactions can result in fines and possible legal action.

One thing I wish developers of extensions would do is to not include payment modules that require a site to collect and store card or checking account data form customers in their product. This would go a long way in preventing unqualified sites from being able to collect card account information.

[checheconleche]

But if the extensions 'integrate with paypal and Authorize.net' ... then the newbies site does not need to be PCI compliant, because the newbies site is not accepting the card details.

This is precisely what I am trying to get clarified. From my understanding this is not always true. Depending on the configuration, the user either:

• 1. Is either taken to the Gateway site, on the gateway's servers to enter their cc information, then returned to the Joomla site upon completion

• 2. or they enter their information into a form on the Joomla site, that upon submission is passed through a curl statement to the gateway

I agree and feel the first scenario does indeed pass all liability to the Gateway, and allows the site owner to use SAQ A, no scan necessary.

However in the second case, the card information is collected on the site owner's servers and this then changes the necessary SAQ to C or D which then requires quarterly scanning and a PCI compliant server. I have observed that many of the extensions choose to use this method, and utilize the gateway's API to make the transaction process more seamless.

I feel that there is a misconception that site owners only need to be PCI compliant if they store the CC data in a database. However it is my understanding that even just passing the cc information directly to the Gateway from a form, not storing it or even temporarily collecting it, but merely transmitting it (even behind a SSL cert) makes them required to be on a PCI compliant server.

[Webdongle]

But if the extensions 'integrate with paypal and Authorize.net' ... then the newbies site does not need to be PCI compliant, because the newbies site is not accepting the card details.

This is precisely what I am trying to get clarified. From my understanding this is not always true. Depending on the configuration, the user either:

• 1. Is either taken to the Gateway site, on the gateway's servers to enter their cc information, then returned to the Joomla site upon completion

• 2. or they enter their information into a form on the Joomla site, that upon submission is passed through a curl statement to the gateway

I agree and feel the first scenario does indeed pass all liability to the Gateway, and allows the site owner to use SAQ A, no scan necessary.

However in the second case, the card information is collected on the site owner's servers and this then changes the necessary SAQ to C or D which then requires quarterly scanning and a PCI compliant server. ...

This is your confusion ... in scenario 2 no card details are not being passed to a Payment Gateway.

1. They (in the case of Joomla extensions) are being stored in the site then the details passed directly to the Card Clearing Bank that the site owner has an account with. The site owner(or employee) accesses the details on the site then passes the details directly to their own bank.
   or
2. If a site takes card details and does not manually process the details to their own bank account ... then their bank's software is placed on the site server.

In the case of 'a' there is no Payment Gateway ... and ... in the case of 'b' the site is acting as the Payment Gateway. In either 'a' or 'b', the site needs to be PCI compliant.

From what you say in your first Post, it appears that the sites you have on your server were interacting directly with the Card Clearing Bank.

There is often confusion between the terms 'Payment Gateway' and 'Card Clearing Bank'. A 'Card Clearing Bank' is the bank that processes the card details and moves the 'money' from the card owners account to your account. A 'Payment Gateway' is the site that has the software that passes the card and payment details to the 'Card Clearing Bank'.

Paypal is a Payment Gateway that processes the details to a card clearing bank (It's own 'Card Clearing Bank').
Payment Gateways do not receive card details from sites. They receive the order details and then the card details are entered into the Payment Gateway's site.

My advise to you would be
If any of the owners of "10 or so sites" that you host accept cards at their Store ... then contact the people who run the PDQ machine that is in their store. and ask them about tying the site into that account. But under no circumstances set their sites to store the card details for them to access and manually process. And do not use software so that your server is acting as the Payment Gateway to the Card Clearing Bank that they bank with.

If the owners of "10 or so sites" that you host do not accept cards ... then do not use software so that your server is acting as the Payment Gateway to the Card Clearing Bank that they bank with. Use a Payment Gateway like Paypal, so that all card details are entered in their site and not sites that are on your server.

Hope this is explained clearly enough to clear up your confusion.

[PhilD]

Perhaps a link to some general overview of requirements and related info on PCI DSS is in order.
http://en.wikipedia.org/wiki/Payment_Ca ... y_Standard
There are many references used within the document that are also worth reading.

Again, any site that processes, stores or transmits cardholder data is subject to PCI DSS and must implement the regulations set forth in the PCI DSS documentation. All merchants that that process, stores or transmits cardholder data fall under the compliance of the PCI DSS. Some merchants will be small enough to not have to validate their compliance with PCI DSS. However, if these smaller sites process, store or transmit cardholder data, then it would be very wise to get and maintain verification to limit liability.

The general public expects a merchant to safeguard their card data ( card number and validation code). If you do not collect or store this data, then your site is automatically stronger than a similar site that does and the customer feels safer for it.

Some confusion I think comes into play here because of the fact that people may confuse just what cardholder data is.

Cardholder data as defined in PCI DSS is:
Full magnetic stripe or the PAN plus any of the following:
• Cardholder name
• Expiration date
• Service Code

The full stripe is the account number shown on the card which is called PAN.

So as one can see, any data stored along with the card number (PAN) such as the Cardholder Name, Service Code, and/or Expiration date is considered cardholder data and must be protected in the same way you would protect the card number under PCI DSS.

If you are not storing the cardholder data as defined above, then you can store the customers information that is related to their address, contact, and website login.

I agree that people should not just create a store (or subscription service etc.) with payment methods that collect the cardholder data as defined above. To do so without compliance and compliance verification in my book borders on criminal or is criminal. If someone wishes to create a site that takes card data then it is highly advisable to find out the currently accepted and legal ways of doing so.

[checheconleche]

But if the extensions 'integrate with paypal and Authorize.net' ... then the newbies site does not need to be PCI compliant, because the newbies site is not accepting the card details.

This is precisely what I am trying to get clarified. From my understanding this is not always true. Depending on the configuration, the user either:

• 1. Is either taken to the Gateway site, on the gateway's servers to enter their cc information, then returned to the Joomla site upon completion

• 2. or they enter their information into a form on the Joomla site, that upon submission is passed through a curl statement to the gateway

I agree and feel the first scenario does indeed pass all liability to the Gateway, and allows the site owner to use SAQ A, no scan necessary.

However in the second case, the card information is collected on the site owner's servers and this then changes the necessary SAQ to C or D which then requires quarterly scanning and a PCI compliant server. ...

This is your confusion ... in scenario 2 no card details are not being passed to a Payment Gateway.

1. They (in the case of Joomla extensions) are being stored in the site then the details passed directly to the Card Clearing Bank that the site owner has an account with. The site owner(or employee) accesses the details on the site then passes the details directly to their own bank.
   or
2. If a site takes card details and does not manually process the details to their own bank account ... then their bank's software is placed on the site server.

In the case of 'a' there is no Payment Gateway ... and ... in the case of 'b' the site is acting as the Payment Gateway. In either 'a' or 'b', the site needs to be PCI compliant.

From what you say in your first Post, it appears that the sites you have on your server were interacting directly with the Card Clearing Bank.

There is often confusion between the terms 'Payment Gateway' and 'Card Clearing Bank'. A 'Card Clearing Bank' is the bank that processes the card details and moves the 'money' from the card owners account to your account. A 'Payment Gateway' is the site that has the software that passes the card and payment details to the 'Card Clearing Bank'.

Paypal is a Payment Gateway that processes the details to a card clearing bank (It's own 'Card Clearing Bank').
Payment Gateways do not receive card details from sites. They receive the order details and then the card details are entered into the Payment Gateway's site.

My advise to you would be
If any of the owners of "10 or so sites" that you host accept cards at their Store ... then contact the people who run the PDQ machine that is in their store. and ask them about tying the site into that account. But under no circumstances set their sites to store the card details for them to access and manually process. And do not use software so that your server is acting as the Payment Gateway to the Card Clearing Bank that they bank with.

If the owners of "10 or so sites" that you host do not accept cards ... then do not use software so that your server is acting as the Payment Gateway to the Card Clearing Bank that they bank with. Use a Payment Gateway like Paypal, so that all card details are entered in their site and not sites that are on your server.

Hope this is explained clearly enough to clear up your confusion.

Webdongle, thank you for your input, but I don't think you are understanding what I am trying to get at. I am not talking about the card clearing bank, I am only talking about gateways and introducing this new level into the subject is possibly adding confusion. Please read my original post again so that you are not taking me out of context and we can be on the same page.

Just to clarify, I am not looking for a solution to a problem where this issue can just be marked as "solved". The sites on my server are all sites that I have created, manage, secure and maintain PCI compliance just fine for as necessary. I am trying to narrow down a difference in utilizing payment gateways that often times I feel is poorly communicated between extension creators and extension users. I am hoping to hear from other users as well and their solutions to this issue.

Perhaps you are not familiar with Authorize.net, but there are 2 different ways to integrate their specific payment gateway with your website. As I mention before,

Depending on the configuration, the user either:

1. Is either taken to the Gateway site, on the gateway's servers to enter their cc information, then returned to the Joomla site upon completion

2. or they enter their information into a form on the Joomla site, that upon submission is passed through a curl statement to the gateway

In scenario 2, the name, cc #, expiration date and CVV are entered into a form on the website. Upon submission by the user, they are passed to Authorize.net through a curl statement, after which authorize.net replies back to the website with approval or denial codes.

Both of these methods use the Authorize.net service, one directly on their servers and the other utilizing their API. Both methods are communicating with the Payment Gateway. One way requires the server to be PCI compliant the other does not.

[checheconleche]

One thing I wish developers of extensions would do is to not include payment modules that require a site to collect and store card or checking account data form customers in their product. This would go a long way in preventing unqualified sites from being able to collect card account information.

I agree and will raise you one. I would like there to be clarification within the extension about hosting needs required depending on the method of payment integration.

I found this article to be very helpful and concise.
http://www.focusonpci.com/site/index.ph ... tions.html

#6 explains very well the point I am trying to get at with all of this.

There are certain payment products that do transfer the burden of PCI compliance to the payment services provider (e.g. PayPal's Website Payments Pro) however they require that a consumer be forwarded to the payment provider's servers to complete their order. If your website integrates with PayPal via an API then you are still liable for PCI compliance since your servers capture and transmit the credit card data first.

[Webdongle]

[quote=checheconleche"]thank you for your input, but I don't think you are understanding what I am trying to get at. I am not talking about the card clearing bank, I am only talking about gateways and introducing this new level into the subject is possibly adding confusion. [/quote]Defining the difference between 'Payment Gateways' and 'Card Clearance Banks' is necessary to clear your confusion.

If card details are not entered in the site then a Payment Gateway is used



If a Payment Gateway is not used and card details are entered on the site then there must be a method of passing the information to the Bank. That is either done manually by accessing the information then using it like they would if a customer rang up ... or by using the banks software on the server.

There are e-commerce extensions for Joomla that allow direct input for card data. For that option of the extension to be useful then the site owner needs an account with a Card Clearance Bank. That is why the definition needs to be made.

The question of Joomla e-commerce extensions (having the ability to be set to) accepting card details only comes into play when ... someone running a server tries to set it up as a Payment Gateway for a site owner who's business is not set up to accept cards.

The answer given to you several times by various posters is use Paypal as the Payment Gateway.
EOF

[PhilD]

Examples of items or combinations of items considered to require PCI DSS and those that do not.

1.) A database stores the cardholder name and the service code of the credit card. This does not require PCI DSS, because they are not stored in conjunction with the PAN.

2.) A dataset file on a computer associated with the site contains the credit card expiration date and the PAN. This requires PCI DSS because the expiration date is stored in conjunction with the PAN.

3.) A flat file contains the PAN, the cardholders name, billing address, and the credit cards expiration date. Is the billing address that is stored considered cardholder data? No, it is not one of the three elements noted as considered cardholder data when stored in conjunction with the PAN. The expiration date and cardholders name is considered cardholder data as they are in the three elements considered cardholder data when stored in conjunction with the PAN.

4.) A site database stores the PAN, the CVV2, and the cardholders name. Is the CVV2 cardholder data? Yes it is, but it happens to fall under a different category of data that must not be stored post-authorization. Some of the other types of data that cannot be stored include full magnetic stripe data, CAV2/CVC2/CVV2/CID, and PIN/PIN block. So if the site is storing this type of data even if for the purpose of collecting and then transmitting the data to something like AuthorizeNet, then the site is not complying with PCI DSS. This is one reason why if an api is used on a site to collect cardholder data and then send it to say AuthorizeNet, then the site is required to comply with PCI DSS.

Bottom line is if cardholder PAN data is ever entered by a customer for any reason and stored for any length of time, even momentarily, then the site has to comply with PCI DSS.

If the site passes off all PAN handling of card to a third party by sending the customer to the third party to enter the card PAN and/or complete the transaction using a pre-defined account (think PayPal for example), then the site does not have to comply with PCI DSS.


For an example, a Virtuemart store component for Joomla has various modules for accepting payment. The checkout process in Virtuemart collects the customer data and the purchase data storing it in the database. One of the offered modules is a PayPal module. This module does not have any place to enter the PAN or any data associated with the cardholder data as defined by the PCI DSS. When checkout is at a certain point the store transfers the customer and the entered customer address data to PayPal to enter their cards PAN and associated details, or to log in to their (the customers) PayPal account to complete the transaction. Once the transactions completed (or is canceled) the customer is sent back to the store site. This scernario does not require the site to comply with PCI DSS as at no time did the data collected on the store site contain the PAN.

Second store, a virtuemart store (not picking on Virtuemart, but it is well known store extension), the site owner selects a payment module that includes fields to enter the PAN and other card details during checkout. These details are then passed to a gateway to finalize the transaction. This store is required to follow PCI DSS.

Just as it is the responsibility of a Brick and Mortar store to know the appropriate policies and required security when dealing with credit transactions, it is also the responsibility of the site owner to know the appropriate policies and required security when dealing with credit transactions.
It is not the requirement of a software developer to make sure that the end user of the software installs and sets up the appropriate modules and complies with the requirements of PCI DSS that may be necessary if the end user of the software selects certain modules.
I do think it would be helpful if a software developer would state within payment modules included with a store component or other payment type component that collect the PAN, that site PCI DSS compliance may be necessary when using the module. Same would go for any gateway that supplies an api that collects the PAN onsite before transmitting the data to the gateway.
However it is ultimately up to the site owner (legally) to make sure the store or payment method complies with any PCI DSS requirements according to they transaction data that is or is not collected within the site.

[checheconleche]

Thank you PhilD.

I truly appreciate you taking the time to run through this and clarify. I am in 100% agreement with you and am glad to know someone else is on the same page. I have read through a lot of documentation to come to this understanding, however I have been challenged about it on numerous occasions and told that I was misinterpreting the PCI standards.

Thanks again