7

I have a client that wants me to build her a simple e-commerce site for her small quilt store. I'm going to use Stripe for the credit card handling. The only info I'm going to keep on my system is the user's name. Everything else will simply be funneled to Stripe.

Because the payment processing will be handled offsite, am I required to be PCI compliant? I'm basically just worried about any hidden costs on her part. She can't afford an audit or penetration test on top of the site development costs. I know that there's a self-assessment form for really small businesses like hers, but I'm not sure if that's all I need or should do.

tldr; I'm not sure how to proceed in a way that's cost effective for her, and need some guidance.

3 Answers 3

10

Coming from a person that is in the middle of PCI compliance issues right now .. no. You don't need to be pci compliant if you are using a third party service to input and handle your credit cards. One if my smaller clients runs an commerce site specializing in jewelry.

As long as no cardholder data (the PAN, magnetic strip, PIN block, etc) is entered (and especially stored) on your systems you let the vendor that processes the payment handle all the burden.

To check if this is true you should only be handing a specific amount of funds owed or an itemized list to your provider. If you are handing them any details of the transaction beyond this you will need to look at at least a basic compliance questionnaire.

Note that I'm not familiar with your vendor. If it is anything like PayPal this will be true.

2
  • 2
    Just to clarify, when Tim says 'No Data' I presume he's refering to payment information. You can still capture and store orders / orders statuses / the outcome of payment processing. I assume that storing delivery address is not a PCI-DSS issue - but I'm not sure about invoice address - but I expect that payment processors will have set up their servcies to avoid these issues - and should provide documentation.
    – symcbean
    Commented Dec 7, 2012 at 11:51
  • from Navigating DSS v20 Document: The primary account number (i.e. credit card number, op. AI) is the defining factor in the applicability of PCI DSS requirements. PCI DSS requirements are applicable if a primary account number (PAN) is stored, processed, or transmitted. If PAN is not stored, processed, or transmitted, PCI DSS requirements do not apply. Commented Dec 7, 2012 at 13:13
1

If I understand your situation correctly, your client's site doesn't need to be PCI compliant itself, but your client is responsible for selecting a third party payment service provider (PSP) that is PCI compliant. The safest way to check for compliance is by looking at the VISA global list of compliant PSPs and confirm that the company you're planning to use is listed. The list is here https://usa.visa.com/merchants/risk_management/cisp_service_providers.html It used to be a pdf document that you had to download and search, but they recently switched to an searchable online list.

Your clients acquiring bank (where the funds from card transactions end up) is the final arbiter of what exactly your compliance requirements do or don't include so it's best to check with them too.

Updated: Actually I just re-read your original question and your client's site MAY need to be PCI compliant after all, depending on how you're implementing the payment functionality. PCI compliance is required if a site is either PROCESSING, STORING or TRANSMITTING card numbers. From what you say you're not processing or storing card details, but your site may be transmitting them. When your client's customer places an order, if they will type their card number into a form that gets posted to your site and then you resend it to Stripe, then you are now transmitting card details, even if you only have it on your site for a microsecond. However, some PSPs have a way of doing the payment functionality where the card details get posted direct to them and the card details never touch your site. If what Stripe is doing is the latter then my original answer above still applies. if it's the former then your client's site will likely need to have quarterly scans. Again, I go back to the fact that it's the acquiring bank who actually makes the final decision on what your compliance requirements are.

1
1

To understand your own compliance burden, you must understand PCI's goals. The comment above that you have a compliance burden since you TRANSMIT card data is true. However if you are careless with your (non-credit card) data that you store - cardholder name, shippng address, email, etc. then you could find yourself in the middle of an expensive PCI audit (or rather your client will). Hackers by definition are not honest people.

What if they simply hack into your database, get all the shopper emails, then email all your shoppers that they have hacked your client's eStore and gotten everybody's credit card information (even if the credit card data part is a lie) and present accurate shipping adderss info as proof they they have the data? Your client's store will lose a lot of business and have to pay for a PCI audit.

PCI compliance places the burden on you to keep this from happening. I've seen this happen to a few (former) clients - 'former' because I quit the project when they would not foot the bill for proper security measures. Was called back post-compromise. If they don't keep their data safe, the hackers will find a way to make them pay...

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .