You are on the hook as soon as your code touches credit card data.
You are on the hook as soon as your code touches credit card data.
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 :)
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).
https://www.pcisecuritystandards.org/security_standards/docu...
http://stackoverflow.com/questions/4219636/pci-compliance-an...