First, please forgive my ignorance. Until this week, the only "credit card security" I understood was how to hack systems and why to write PHP pages with the types of features I do (msqli, pdo, parameterized query, etc..). As per my involved ignorance, I will make this question as robust as I can, attempting to not over-complicate it. (Maybe too late now)

I've checked every PCI Compliance Q on here, as well as Googled to the extreme for 2 days now and I still have a few questions, before I begin trying to put together a PoA Report to present to my employer at the end of this week.

I was forwarded an email from PayPal about becoming PCI Compliant and have since learned, due to our use of the PP SDK function DirectPayment, we must obtain compliance and certification. Upon doing that, I researched and double checked our current SSL and checkout implementation. We do not store any information beyond the PayPal return, which does include the last four of a CC, but nothing more. There is a short period (from review page to finalization of order) where the information is stored via $_SESSION, and the removed upon completion of final step; whether successful or not.

My Questions

  1. Is this temporary passage of CC user info PCI Compliant?
  2. In becoming PCI Compliant, is it really as simple as it appears:
    • a. Obtain Compliance Scan from Certified Vendor
    • b. Complete a PCI DSS SAQ
  3. About that SAQ, I'm still having trouble, despite much review, understanding exactly which questionnaire we need?
    • a. As I currently understand it, I believe we fit in the category: C-VT
    • b. See Checkout Info below
  4. Our current SSL is with COMODO. Can anyone tell me, if we use the same company for our PCI Compliance scan, would we still be eligible to receive the full set of services we receive from PayPal?
    • a. I've tried asking PayPal about this and I just keep getting templated answers that have yet to answer any question I've asked them. (may be the second worst customer service I've ever experienced)
    • b. Referring to line from PayPal's PCI Compliance Documentation: What happens if my business doesn't comply? From a PayPal perspective, your Website Payments Pro account may be limited and eventually suspended. Thus, I wonder, is any compliance viable, or does it have to be through one of there referenced vendors, of which COMODO is not listed.

Checkout Info We have 3 ways to checkout

  1. Via aforementioned PayPal SDK method DirectPayment. We use a form, filled out client side and stored temporarily to $_SESSION to gather the info needed to "submit payment". Once submitted, all $_SESSION data is erased and return data is saved along with the order data, if successful. If error, order data is maintained in session, but CC info is dropped and user is asked to try again or try a different payment method.
  2. Via PayPal Express button. Simple as that. Again, return data is stored, but unlike the return data of DirectPayment, not even last four of CC is stored. Just the order info, price, and PayPal Express JSON return.
  3. By phone, again making use of DirectPayment. One of our reps simply gathers the same info the user would enter on the public site, enters it in a CRM version of the same form and the same process is followed. Main difference being, the rep is returned to CRM Main Page afterward, AND there is no $_SESSION storage needed, as they just submit the form directly after reviewing the info on the phone with the customer.

Again, most sincere apologies if my questions are already answered here and I'm just overlooking them or if I'm just not understanding something I might should.

Thanks in advance for any and all help.

1 Answer 1

  1. First of all, checkout methods number 1 and 3 require you to become PCI compliant, it doesn't matter how long you store that information, the moment you touch card holder data you need to be PCI compliant. Depending on what you do with the data (e.g. storage) different requirements may apply.
  2. Well the easy part is doing the actual SAQ and being audited, the hard part is actually having your environment set up so you actually pass the audit.
  3. Because you are temporarily storing the CC information in a session, I'm more leaning towards SAQ D. Remember that C-VT requires no storage of CC data and that the terminals used to enter payments are required to be isolated in a single location and not connected to other systems in your environment. The most common implementation is via thin-client terminals or individual systems with dedicated Internet access and host-based firewall restrictions.
  4. If COMODO is an acredited scanning vendor (ASV), they're should be no issue.
  • Was afraid of that. Was hoping I could avoid having to go through 288 questions. Thank you so much for the information provided. Could you add (in your answer) if their are any "gotchyas" I should be aware of in said audit? Naturally I assume their will be SQL injection checks, network security, virus detection itinerary, but are their any specifics I might should check into now, before making my proposed Plan of Action?
    – SpYk3HH
    Nov 11, 2014 at 22:21
  • You are required to perform regular pentests, they will scan your network also for default configurations and SSL ciphers used. 9/10 you will have to fix tons of stuff after the first audit. If you don't have an implementor on site who's experienced in PCI-DSS, you will probably fail first time around. Nov 12, 2014 at 8:43
  • awesome. Lol. Let the fun begin!
    – SpYk3HH
    Nov 12, 2014 at 12:04
  • "the moment you store card holder data you need to be PCI compliant" This is incorrect. PCI compliance is always a requirement if you accept card payments; storing card holder data simply increases your required level of compliance.
    – James
    May 16, 2016 at 11:19
  • 1
    @b3njamin I updated it May 17, 2016 at 0:57

You must log in to answer this question.

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