Accepting payments is getting harder

Actually Visa's Global Registry is in the doghouse right now. They have a very slow, antiquated process to get listed (only update it once a month, must be ready to go two week prior to that update, you go into a blackhole and never know if you'll actually get swept up in the latest update) which used to be ok but this year they began with a more aggressive approach of marking you orange and delisting you. It's impacting a lot of folks right now and I wouldn't read anything into this and Stripe's status.

The biggest thing to remember when dealing with PCI DSS is that it's not the law.

Your PCI obligations come out of a commercial agreement that you have with your processor, which comes out of commercial agreements they have with VISA/MC/et al. That's not to say that it's not a well-defined standard that you're going to end up having to follow in some way, but rather that statements like "Both Litle and Recurly flat out say that you need SAQ A-EP" have more wiggle-room than it would sound like, depending on the rest of the deal you're presenting them with.

If you're a Level 3, I'd argue the goal should be to keep yourself on SAQ-A - the methods of which are pretty well-understood now. Pick a vendor which has a tokenization service designed to be hit from JS (they all work the same way at their core - download JS which contains an implementation of RSA and a public key, browser-side encrypt the CHD using that, send it off, get back a token). Put your payment form inside an iFrame which is served from a PCI-compliant host (like S3). Once tokenization is complete, send the token from inside the form back out to the containing page using postMessage or in the querystring.

Do all that, and you're fine to stay on SAQ-A (https://www.pcisecuritystandards.org/documents/Understanding...):

Examples of e-commerce implementations addressed by SAQ A include...[merchant] website provides an inline frame (iFrame) to a PCI DSS compliant third-party processor facilitating the payment process...Examples of e-commerce implementations addressed by SAQ A-EP include...[merchant] website creates the payment form, and the payment data is delivered directly to the payment processor (often referred to as 'Direct Post')

Will they change PCI DSS again to remove the iFrame rules? Maybe, but given the speed the PCI council moves at (and the warnings they give before changing things), I'd deal with it then.

Lastly, if you're thinking of building a service which white-labels credit card processing and sells that processing as a service which your customers can then resell...don't forget about PCI PA-DSS

This is a great article. I would add a couple of data points for context:

- Visa won't come after you. Your merchant account provider is on the hook. They let you process cards so they need to ensure you're PCI compliant. That's how the flow works.

- PCI 3.0 kicked in in January. People reassess annually. So if you reassessed last year under 2.0 standards you're still good until your renewal comes due. That's why this is slowly creeping across the payments space in terms of realization.

- The card networks saw longer, sustained ongoing fraud happening in online commerce from .js or transparent redirects than they did from hosted payment pages. So the big change in PCI 2.0 to 3.0 was this idea of wanting to make it harder to completely build your own custom payment pages vs using a hosted payment page. HPP's are SAQ-A and customized payments pages - A EP

- iFrame's and checkouts are really trying to be the best of both worlds. That's why they're currently treated as SAQ-A. There was definitely a lot of thrashing around how they would be treated when the 3.0 specs were being drafted and published.

Again, I really enjoyed the article and appreciated Spreedly being included as a reference. I would agree with the major premise that in general merchants are unaware that the way they implemented their payments pages now mean they're in greater scope and that the providers aren't doing a good job educating them. It's an open secret in the industry that many payment gateways add a (pure margin) fine for $20 to $50 per month onto your account if you don't have valid certification. In a low margin business that reduces motivation to push small and medium merchants to ensure they're PCI compliant.

yes but it is more akin to paying by bank transfer. A Hotel will not expect you to show a card if you paid by bank transfer.