Support

February 15, 2016 at 5:03 am

Hi, I can see there is some inconsistency in what is reported and what is shown. We’ll work on updating that.

—
Lorenzo

February 15, 2016 at 7:26 am

Hi Alex,

We’ll update this support post once we have discussed this further.

Thanks

—
Lorenzo

February 22, 2016 at 5:42 am

Hi Calex,

Are you referring to removing all of the billing info?

From what I could make on it, the documentation said that any card information recorded from the front of the card needs to be encrypted (please correct me if you know better).

That only applies if storing the full PAN number (card number) Event Espresso only stores the last 4 digits of the card number and not the full PAN number.

I see no benefit of having this info on my server and your own documentation clearly says no card numbers are recorded (the last four are) so I am not sure why they are there.

The last 4 digits of a card number is not a full card number, we do not store full card numbers.

The addon we speak of records – card number last four, card type, exp month, card holder name. I really don’t see the point in collecting any more than the address as you will have a record in sagepay and keeping it just creates a compliance headache.

We no longer store the Exp month however you can store that data as long as you do not also store the full PAN number, as mentioned EE does not. PCI compliance covers both transmission and storage of card details, storing the details that EE does adds no more additional complications to compliance with on-site payment methods as they already transmit the card details from your server to SagePay, meaning you must be PCI compliant anyway.

Most of the requirements for PCI compliance are outside the scope of Event Espresso, for example, are you using shared hosting? If so, its likely your not compliant on that fact alone. (It possible, but most are not)

There’s 12 steps to PCI compliance – http://take.ms/YbXMt

I’ve highlighted the 3 steps that can effect EE, all of the others are outside the scope of Event Espresso.

3. Protect stored cardholder data

We do not store the full PAN number its is truncated, which is fine.

4. Encrypt transmission of cardholder data across open, public networks

Event Espresso allows you to secure your checkout pages if you have an SSL cert:
https://eventespresso.com/wiki/espresso-sslhttps/

12. Restrict access to cardholder data by business need to know

Event Espresso has a capabilities system built into core as does WP, if a user should not have access to the transactions you can prevent that easily using the capabilities.

This table shows the data you are allowed to store from card details – http://take.ms/3VJ3s

We do not store any data classed as sensitive data there.

Those images are taken from the PCIDSS_QRGv3.1 PDF here:

https://www.pcisecuritystandards.org/documents/PCIDSS_QRGv3_1.pdf

So based on the document above, even if we remove the billing information section, you still need to be PCI compliant as your using an on-site payment method. Again PCI covers both transmission and storage of card details, as far as I can see, we don’t store enough details for EE to cause further problems with PCI compliance.

Could we request to get rid of ‘card holder name’ and ‘card type’ too? I would like card last four gone too but I am less concerned as it is partial info.

This won’t apply to all users, nor all use cases but the registration Fname + LName = Cardholder name for the majority of users, it is not considered sensitive information if it is not stored with the full PAN number. Same goes for Card Type.

I have looked at and tested Stripe – I like it so far. I have to say that one of the main reasons EE was chosen for this project is because it supports Sagepay so I need this to be right please.

Can you explain this further please?

Stripe is easier to ensure you are PCI complaint with as it uses a checkout hosted securely on the Stripe servers to take the payment details.

If you have any information that indicates any of the above is incorrect please do let me know and I will investigate to ensure EE is as compliant as we can make it.

Note: I’ve updated the SagePay documentation as it stated you do no need a PCI Compliance cert, that is incorrect.

February 22, 2016 at 7:48 am

1. Having the option to store none of the card details would be reassuring to those who don’t want to keep any billing data from the card (surely storing card holder name isn’t necessary). I do note that some of this only applies in conjuction with PAN but – the question of necessary is still there.

It still does not change the steps needed to be PCI compliant, removing those details does not help in any way towards compliance.

The question of whether or not it is necessary becomes clear when for some reason there is no record of the payment within SagePay (or another payment processor) and you only have the details within EE to rely on (yes it happens, its rare but it’s one of the reasons we save some details)

If you have a business transaction with a user there is nothing wrong with saving details of said transaction, obviously as long as that does not impose a risk to the user, such as as saving full credit card details.

Unnecessary would saving those details, just in case, maybe, one day that user might possibly want to make a purchase and you already have the details on file 🙂

2. SSL is present and not an issue

Great.

3. Server is private

Great, but again depends on how its setup.

4. Your documentation was confusing – which implied pci requirements would be at a lower level than needed

I’m sorry about that, I’ve updated it.

One thing I can you is on-site payment methods, regardless of whatever the documentation states from which ever plugin, needs to be PCI compliant. With offsite payment methods that take the user to their site to make the payment they then take responsibility of PCI. (Although you still need at least SAQ_A)

Stripe is an odd payment method in that it works around that differently than most but again still needs SAQ_A

5. Wanting it to be right meaning that all was working securely and as it should be – there were bugs and incorrect documentation

Just to be clear for future readers the bugs were not security issues, the exp date can be stored but we no longer do with other add-ons so update SagePay to do the same. The email not being sent to SagePay has also been fixed.