

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...](http://chargify.com/blog/adding-payment-gateways-while-
maintaining-data-security/) ) 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...](http://support.cheddargetter.com/discussions/questions/39-pci-
compliance) \- 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...](http://www.untitledstartup.com/2010/02/payment-security-survey-for-
startups/) ), 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...](http://www.untitledstartup.com/2010/02/accepting-payments-on-the-real-
time-web/)

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).

