3

I'm wondering if anyone has any thoughts on a specific question I have. I read a lot about systems that 'store, process, submit' CC data requiring compliance.

If I host a form on my website which takes CC details and posts them to a CC provider, are there PCI implications on my system (even though the CC details do not reach my server?).
The data itself is not stored on my system. It's transmitted between the customer's browser and provider, my system does not participate. My system only sends the form to the customers browser and provides the posting code.

I'd be interested to hear any thoughts or experiences on this if you have any.

Thanks in advance.

Improve this question
5
  • What I can gather is that with the above solution, 'the more complex PCI requirements are avoided'. What does that actually mean in practical terms? If it means 'as long as the form is secured on https your fine', I'm happy.
    – siro
    Nov 9, 2012 at 11:30
  • If your form has errors (code has errors, and when there is money on the table, hackers are happy to discover those errors), and the CC data is leaked, will the CC Provider and CC owner accept your assurances that you didn't store the data?
    – MCW
    Nov 9, 2012 at 12:28
  • That makes a lot of sense Mark. My question was more focused on what my obligations are under PCI and if the compliance rules recognize the vulnerability you've explained. I totally acknowledge the validity of the vulnerability you've highlighted, but does PCI oblige me to address it or just accept the risk?
    – siro
    Nov 9, 2012 at 14:21
  • Unfortunately, I'm not familiar enough with PCI to answer that (I've spent my entire career in the government where different rules apply). That's why I had to make a comment rather than provide an answer. I'm sure that Stack Exchange will locate someone who has more PCI expertise than I do.
    – MCW
    Nov 9, 2012 at 14:37
  • Thanks again for taking the time to respond Mark, I very much appreciate it.
    – siro
    Nov 9, 2012 at 17:05

3 Answers 3

Reset to default
4

How are you handling the cc details? I'm afraid that PCI compliance is a lot more than https,

We used to host a form directly and pass on the information to the processing company within a script, not even storing them as session variables. That was reason enough for our bank to bump up our PCI requirements as we handled the cc details directly. If you imagine somebody put some dodgy code on our server, it could do anything it liked with the credit card details.

We now use an embedded iframe from our card processing company within the webpage. It doesn't look quite as good, but we never see the cc details, so our PCI compliance burden is greatly reduced. It wouldn't matter what code is on our server now, the credit card details can't be accessed.

A good starting point would be https://www.pcisecuritystandards.org/index.php, pick your self see where you put yourself and then go from there.

Improve this answer
1
  • oh crumbs, I have 2 responses to my question and they are mutually exlcusive :(. Thanks so much for your response. I agree with the 'dodgy code' scenario (some simple JS which reads CC fields and posts them somewhere for example), that's why it makes sense that the system hosting the form needs to be subject to some sort of control. The fact you have real life experience of a bank objecting is very enlightening. Just to be clear, when you say 'within a script' im understanding that as a browser side script, is that correct?
    – siro
    Nov 9, 2012 at 14:15
1

Part of the above answer in the comment above is wrong - even if you submit directly to the provider and your servers never see a credit card number or CVV for a single millisecond, you are indeed relieved of significant PCI compliance, but you still have significant compliance left over. Are you storing things like a customer name, email, shipping address?? What if your systems get compromised just enough to reveal a list of your customers' email addresses? The hacker then emails all your customers saying untruthfully that their credit card info has been compromised. Trust me, the card companies will audit you over this - a forensic audit - you will need to prove that card details have NOT been compromised. An assumption of 'guilt' always applies in instances like this.

Improve this answer
1
  • 1
    Thanks for taking the time to respond Ron, I appreciate it. Your answer makes it clear to me that I need to consider (and address) my 'compliance left over' exposure.
    – siro
    Nov 10, 2012 at 19:02
0

It depends. If the form directly posts to the provider, you aren't required to do anything as part of PCI-DSS. If the form posts to your server, which then sends the details to the payment server, you're regulated by PCI-DSS because you're handling the details.

Regardless, you should make sure that the page containing the form is sent over HTTPS, preferably with HSTS enabled. You should also get at least that page reviewed by a competent web application security tester.

Improve this answer
1
  • oh crumbs, I have 2 responses to my question and they are mutually exlcusive :(. Thanks very much for your response. Yes, the form posts directly to the provider and not to me. The documentation I see from my payment provider is that my PCI burden is 'less complex' and 'streamlined' as compared to if I posted to my own server.
    – siro
    Nov 9, 2012 at 14:09

You must log in to answer this question.

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