[dangrossman]

It's common sense once you boil it down to this:

If someone's credit card number hits your server at any time, you are liable for a proper level of care for that information. The proper level of care in this case is set by the payment industry in the form of PCIDSS (the Payment Card Industry's Data Security Standards).

So setups where the data goes through you, you're on the hook.

Where you're sending someone to an external site to pay, in a frame or otherwise, then you're not.

A quick glance at the implementation guide for any payment system, present or future, is enough to know who's on the hook for PCIDSS just by seeing whether the card number's gonna get POSTed to your server or someone else's.

[lsh123]

I think the better description would be:

You are on the hook as soon as your code touches credit card data.

[yangez]

Is this true? I was under the impression that if we used Stripe's javascript function to tokenize credit cards, we get to skip a lot of PCI compliance stuff we would otherwise be responsible for.

[lsh123]

You might want to talk to your PCI QSA to get a professional opinion. My views are explained here:

http://news.ycombinator.com/item?id=3332001

Said that, you might want to think beyond PCI. Security is as strong as your weakest link and you might want to "play" in your mind a few scenarios: what if there is an XSS attack? what if your employee goes "rogue"? what if your server is hacked? Then you will need to decide what is important for you and how much risk you are willing to tolerate. Different solutions (Stripe + javascript, WePay + iFrame or redirect, PayPal, traditional payment gateway, etc.) will give you different upsides and downsides in usability, security, international support, price, customer support experience, ... There is no silver bullet :)

[airlocksoftware]

I used to work as a low-level tech for one of the largest PCI compliance providers. For smaller merchants (I think less than 20k? transaction per year) there's 4 levels of compliance: A, B, C, and D.

A is for merchants who redirect to another site or use an iframe (like paypal). B is for merchants who use a dial up terminal. C is for any merchant who accepts credit card information electronically (i.e. an internet connected terminal or a website with no redirect / iframe). D is for anyone who stores credit card information.

A & B just require you to fill out a self-assessment indicating you're aware of the rules and following them. C & D both require "scans", probably of your website or server (at least a couple hundred dollars, if not more).

[lsh123]

I am not familiar with A/B/C/D levels but PCI spec clearly defines PCI 1-4 levels based on volume/number of payments:

http://www.pcicomplianceguide.org/pcifaqs.php#5

[airlocksoftware]

Ah, yes. What I'm talking about above applies to level 4 merchants, (less than 20k ecommerce transactions), who can get away with lower level compliance. The ABCD levels refer to the self assessment questionnaires (SAQ) these level 4 merchants are required to completed.

https://www.pcisecuritystandards.org/security_standards/docu...

[lsh123]

I guess I never bothered to look at anything below level 1 :)

[saurik]

Some discussion:

http://stackoverflow.com/questions/4219636/pci-compliance-an...