[neurotixz]

Very interesting, and I would definitely see a use. Just a few comments:

- How does this fit into the PCI picture, only thing I have seen on the site is a 2 line faq entry. Not enough to help on scoping or identifying requirements that would apply.

- How secure is it, and how are security notifications done? Keeping the software secure and up to date should be considered as critical. I would add a section on the site pertaining to security and addressing vulnerabilities. I did not see on the site information about security updates/patches. They might be on GitHub but it is way to deep to be useful to most people.

This kind of software is a perfect example of a high-value target for intrusion, I am a bit worried for the security of the information it contains, especially for smaller startups with limited resources, as well as zombie installations that can be forgotten in a corner with personal information or cards information inside.

Not saying it's a bad idea BTW, just a few concerns as a security analyst.

[pamonrails]

Good point, we'll update the docs.

Regarding PCI, it's up to you. You can run it inside your PCI environment or delegate it to your payment provider (via CC tokenization).

[neurotixz]

If your company has a PCI environment, i'm not that worried (you probably have a pretty good idea of what you are doing, at least in theory), but most startups do not have this, as far as I know. Most just want to get a product/service out of the door. This is where I get worried :-)

It is very easy to setup a system in a corner (here, we'll install this piece of software, that will save us the 99$/month recurly subscription...) then forget about it until it is too late...

Some guidance would be very important, as well as mentioning ways to make it more secure, including tokenization, logging of CC numbers in server logs, knowing if the data transits through your server or not depending on provider, maybe even keep the software behind a a firewall without internet access, these can make a big difference in managing the risk.

As an open source project, you cannot be held responsible on what the people using the software is doing, but I think making sure that they understand that even if the software is free and easy to install and use, that additional work is required to make sure that the data is safe.

[thwarted]

mentioning ways to make it more secure, including tokenization, logging of CC numbers in server logs, knowing if the data transits through your server or not depending on provider

"logging of CC numbers in server logs" is an almost guaranteed way to make your setup not PCI compliant.

The PCI industry as a whole is missing a lot of this kind of guidance, in general. There's no "here's the minimum you need to do to be PCI Level X compliant". The reason is that the industry considers every situation to be different (I doubt most are all that different or if they are, 90% of them can fit into a handful of buckets), and you're supposed to hire PCI auditors to come in and certify you. Another reason there are no minimum guidelines is that PCI seems to be more about awareness than actual specific architecture. You can sidestep certain things as long as you document them and what your mitigating implementation is. This leads to...

Last time I went through a PCI setup, it was a unspoken spoken rule that if we hired an auditor that didn't certify us even though we thought we should be, we could hire a different auditor, and keep doing so until we got one we liked.