Unless you do more than 20k CC transactions/year, OR store CC numbers directly on your server, no one is going to require much of anything from you except one of those fake website scans.
Right, there's always the option to just ignore PCI and live with the possibility of being fined if something goes wrong. But you're right, that's not always a big risk.
It looks like Paypal takes care of PCI compliance only if you use; PayPal Website Payments Standard, Email Payments, or Payflow Link. Otherwise you're on your own.
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.
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.
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 :)
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).
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.
