Ask HN: Can I use a credit card service that isn't PCI compliant?

[jakem]

I've been checking out chargify, recurly, spreedly and cheddergettar - who all seem to process credit card data in their environments, with some even storing it, but none are on Visa's PCI compliant list for service providers at http://bit.ly/dbKhu . Can I send my customers credit card data to a company that isn't PCI Compliant and on the list?

[dacort]

Short answer - They should be listed on the service providers list if you are using them in that capacity and you want to be fully compliant as well.

Longer answer (disclaimer: I'm a former PCI QSA). You can, of course, do whatever you want to with the credit card data at the risk of not being PCI compliant. Small startups are rarely at risk for a breach, but I'd personally prefer not to be in a position to deal with that liability. As it relates specifically to those companies, they need to apply to be on that list. I know that Recurly is currently working on it and Chargify is still in private beta, so I'm assuming it's something they're working on. That said, I have confidence that some of these companies will "do it right" and obtain PCI compliance/validated service provider status by the time it becomes a legitimate concern.

I've talked to both Recurly and Chargify directly. Recurly is apparently PCI Level 2 compliant and working on the external audit to reach level 1. Chargify is outsourcing storage ( http://chargify.com/blog/adding-payment-gateways-while-maint... ) which addresses a lot of concerns, but I'm not sure if they've gone through the necessary compliance process otherwise. As for CheddarGettar, the only mention of PCI compliance I can find on their site is this - http://support.cheddargetter.com/discussions/questions/39-pc... - which doesn't really indicate an understanding of what is actually required to be compliant. I can't comment on Spreedly as I didn't look at their solution, but I do know one of the devs previously worked at a large PCI shop.

So a service provider like these guys can technically be PCI compliant, but not be on the service provider list if they haven't applied to be. If you use them, though, they best be on the list by the time you reach the point that the PCI assessor (they don't like to be called auditors. ;)) is knocking on your door. This isn't likely to be for a while for most startups, though.

In some of the early data I've seen in a survey I'm doing (shameless plug: http://www.untitledstartup.com/2010/02/payment-security-surv... ), most companies are implementing their own system directly to paypal or similar, but have not actually gone through the process necessary to become PCI Level 4 certified. Most feel that the benefit of keeping the payment flow on their site is more important than the relatively small risk of being compromised. Can't say I agree, but I'm more paranoid than most.

[skennedy]

Why would you open yourself up to that level of liability? Full PCI compliance is a standard that will be used by businesses to determine if your product is a viable solution. If your solution breaks PCI compliance at any point, you open yourself up to big problems when (not if) something goes wrong.

Also, why reinvent the wheel? PayPal and Google Checkout are major vendors with PCI certifications who handle the entire transaction process. Why not use them to handle all the risk? You get a transaction id and collect your money through them. Never touching the sensitive financial information.

[pantsd]

Given that he is asking about recurly, chargify, etc. I'm assuming its because he wants to do reoccurring billing, for which PayPal/Google Checkout are less than awesome solutions for.

[skennedy]

I have not had any problems implementing/using PayPal recurring payments. What specific "less than awesome" functionality are you referring to and how are the other products better? Not challenging you, just looking for a more rounded picture.

[dacort]

I found their documentation absolutely horrendous. Try googling for "recurring paypal" and you get a page that links to a (stated) 682K PDF published in 2006 that in actuality is only 2 pages and includes a link to yet another 300 page PDF.

[skennedy]

Documentation that overwhelms a new developer does not make a product less in functionality or quality. Googling code examples, explanations, and blogs of PayPal recurring payment code/functionality, I found a lot of very useful information during my own development. The functionality and product have been around a while and lots of people who want to help others adopt it.

[pantsd]

Recurly claims to be PCI compliant on there web page [ http://recurly.com/features/ ]. Its possible they are on the list under another name, I'd give there support people a shout. I'm not sure if recurly,spreedly,etc. are actually storing the data, it seems like they might be having the gateway (i.e. authorize.net) store the data, but that is pure speculation on my part.

I am interested in doing some re-occuring billing stuff my self so do post back with your experiences with which ever provider you go with. Best of luck :)

[dacort]

We posted our experiences of three of these here - http://www.untitledstartup.com/2010/02/accepting-payments-on...

We ultimately chose to go with recurly, but are going to look at chargify again once they stabilize a little bit. Recurly is not on the list, but in the process of doing so (I just emailed them ~10 minutes ago specifically about being a validated service provider).

[jakem]

Spreedly is storing data [ http://blog.spreedly.com/2010/2/10/three-new-gateways ]. Others may only be transmitting, but I think PCI applies even if data is only transmitted?