[lug] Letting folks pay from the web.

[Bear Giles]

(First the disclaimer that this isn't legal advice, I work in a different
group, etc.)

First, the chatter in our mail seems to indicate that anything that touches
the CC info is 'in scope' for PCI.  Even if your website does nothing more
than pass it on to a service you still have to have PCI compliance for any
system(s) that see that info.

That brings up the second point, that PCI is a lot more than just deciding
what information to store and how.  It gets into keeping your software up to
date, applying security fixes, using firewalls appropriately, using secure
programming practices, etc.... and documenting everything.  Who does what,
how do they do it, what did they do, etc.?  You're still in deep trouble if
somebody has compromised your server and is intercepting the outbound
traffic to your credit card processor even if you absolutely no records
other than the credit card authorization code.

The system administration is something that everyone here is probably
already doing, maybe excluding the necessary level of documentation.  But
it's definitely a bad idea to think that you don't have to worry if you just
pass the information on to somebody else.

I think my company has (or soon will have) a self-assessment service for
small companies.  I believe it's enough for 'safe harbor' protection if you
are compromised since it shows that you were compliant at the time you did
the assessment.  I don't know how much it costs.

Bear


On Mon, Feb 1, 2010 at 9:25 AM, Landon Cox <landon at 360vl.com> wrote:

>
> Regarding the issues of storing cards:
>
> You can comply with PCI rules fairly easily except in one case.  PCI
> states that you can never store the CSC number, even encrypted.  For
> one-time purchases, not a big deal.
>
> While it's probably not Jeffrey's festival case, if you ever need to
> charge a customer's card on a recurring basis, whether it's a
> subscription or Pay-per-whatever where you keep running the same card
> periodically (pay-per-click is an obvious example where you charge a
> deposit, then over a period of time, virtually exhaust that deposit
> and then charge another to "refill"), you don't want to have to keep
> asking for the customer's card.
>
> In the case of PayPal, they have a subscription-type transaction, but
> that works on a specific interval.  If you have a non-standard,
> sporadic interval like a pay-per-whatever model, PayPal doesn't
> provide anything that helps.
>
> All that said, the thing I've found that works for this model is CIM,
> which is an Authorize.net "Customer Information Manager".  You can
> manually or through an API create customer profiles, payment profiles,
> collect their card info once and let Authorize.net manage the card
> info security issues for PCI compliance....this includes the CSC
> number.  CIM is an extra monthly charge on a merchant account, but is
> worth it to not have to bother with PCI rules at all and you can
> easily insure your customers (via an audit if you have to) you have no
> database or process which stores their numbers on your servers.
>
> Landon
> _______________________________________________
> Web Page:  http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> Join us on IRC: irc.hackingsociety.org port=6667 channel=#hackingsociety
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lug.boulder.co.us/pipermail/lug/attachments/20100201/e42ec684/attachment.html>