Minimizing The Burden Associated With Being Pci Compliant When Stripe Isn'T An Option

[HartleySan]

Larry, I just read part 4 of 4 of your Stripe tutorial, and I must say, very awesome! Stripe really seems like a great JS library... I only regret that it's not an option for me.

 

I'm planning on starting an e-commerce business in Japan in the near future, but since all funds will go into a a Japanese bank, Stripe is not an option (at least, not at the moment). As such, I need a decent alternative.

 

With that said, what really got me thinking when I read the last part of the Stripe tutorial is the fact that Stripe uses Ajax to avoid any payment info ever being sent to your server, thus greatly reducing the burden of handling payment information and making it much easier to be PCI compliant. (I briefly looked at the PCI compliance guidelines, and oh my gosh, I'd like to avoid all of that if possible.)

 

So my question to you (or anyone that can help) is, can I use Ajax to send a payment request directly to a payment gateway without using Stripe (and thus avoid that info ever touching my server)? On the surface (i.e., without knowing the details), it seems very possible as JS/Ajax are more than capable of sending any type of GET or POST request to any specified server.

 

If anyone can offer any insight into this conundrum, I'd be very appreciative.

Thanks a lot.

[Larry]

Yes, Stripe is great and has really figured some things out. On the site for my Yii book, it took me about an hour to get Stripe implemented (maybe 2 after crossing all the T's and dotting all the I's) and a day to get PayPal implemented. And this is after having written a book on using PayPal for e-commerce.

 

And, yes, PCI compliance is really quite a thing and not something most people pay enough attention to (or take seriously for even small businesses). To be PCI complaint while using Stripe, you just have to load the page over HTTPS and use Stripe.js. That's it. Really nice.

 

As for your using Ajax in the same way, that's a good thought. Whether that's possible or not will depend upon the payment processor you use and what they support. One hitch is this: Stripe doesn't accept payment via Ajax; Stripe just associates a token with a set of payment information. The second step is to use PHP and that token to actually process the payment. It would seem like you could do that with Ajax, but the Ajax process in Stripe sends a public key to Stripe; the PHP process sends the private key (your unique identifier) to Stripe. You can't send the private key via Ajax because there's no way to safeguard it.

 

But I would think that if you could find a payment processor that supports two-step payments like Stripe, you could then replicate the Ajax-PHP combination to use it.

[HartleySan]

A very helpful and insightful answer, Larry.

Thanks a lot for taking the time to explain all that.

I'll look into it more.

[HartleySan]

If I can ask a follow-up question, I just finished taking a very close look at Chapter 10 (the Authorize.net chapter) again, and the general feeling I got was the following:

 

As long as the customer's credit card number and CVV/CVC is never stored in the site DB or in the $_SESSION variable, then handling that information temporarily on the server is not a problem. In other words, the CC# and CVV/CVC should only ever be stored in the $_POST variable sent from the form and maybe some other variables, which must all be temporary variables that are deleted when the PHP script ends.

 

Am I wrong? I ask because if I can't use Stripe.js (which is most likely the case) and I'm not able to make a request to the payment gateway directly via Ajax (which is also likely because of most browser's restrictions on cross-domain requests), then I'm going to have to send the customer's credit card information to my server at some point.

 

Larry, any additional info you can offer on this matter would be greatly appreciated, as I don't particularly want to have to become an expert on PCI compliance.

[Larry]

Unfortunately, you are mistaken, and I apologize if that's not made clear enough in the chapter. If you directly accept, handle, or transmit credit card information, even if you never store it, you must be PCI compliant. Even if data is temporarily stored in $_POST, it may also end up permanently stored in (publicly writable) logs. And it's because of this possible vulnerabilities that one has to be PCI compliant.

 

My recommendation to you would be to use a third-party offsite payment processor.

[HartleySan]

Ah, okay. That's my fault. I was looking at only chapter 10, but after starting at the beginning of the book again, I now understand the whole blurb about PCI compliance in chapter 2. Sorry about that.

 

Also, what do you mean by a third-party offsite payment processor? That's just something like PayPal, right?

In my case, I'm planning on using Authorize.net. Isn't that enough?

 

If I can impose a bit more, I would like to confirm each of the 12 points, and how they might apply to my situation.

In general, because I'm planning on using a hosting company for my site, it seems like a lot of the requirements should already be handled by them, but here are my thoughts on each of the 12 requirements.

 

Requirement 1: Install and maintain a firewall configuration to protect cardholder data.

I'm assuming that if I use a hosting company, this is something they will take care of for me. Is that true?

 

Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters.

Again, I don't think this applies to me, since a hosting company already provides me with a unique user name and I have set my own password.

 

Requirement 3: Protect stored cardholder data.

As you recommend in the book, since I won't actually be storing any data, this isn't an issue, right?

 

Requirement 4: Encrypt transmission of cardholder data across open, public networks.

This is a big one, but it seems that so long as I have a valid SSL certificate and use HTTPS for the payment pages, that is enough, right?

 

Requirement 5: Use and regularly update anti-virus software.

Can I assume that the hosting company will take care of this for me?

 

Requirement 6: Develop and maintain secure systems and applications.

This is very subjective, but I imagine that following your advice in the book will more than cover this.

 

Requirement 7: Restrict access to cardholder data by business need-to-know.

Again, if the cardholder data is never actually stored on the site, than this shouldn't be a problem, right?

 

Requirement 8: Assign a unique ID to each person with computer access.

I'm a little confused by this one. Does this mean that if there are multiple site admins, etc., we all need separate logins? What computer are they talking about here? The server? If it's a hosting company, then no one associated with the site would actually have that kind of low-level access anyway, right?

 

Requirement 9: Restrict physical access to cardholder data.

Again, if this even becomes an issue, I imagine it's something that the hosting company would handle, right?

 

Requirement 10: Track and monitor all access to network resources and cardholder data.

Again, this seems like something the hosting company would do. Am I wrong?

 

Requirement 11: Regularly test security systems and processes.

Aside from testing for bugs in individual scripts and applications I write, there isn't anything else to worry about, right?

 

Requirement 12: Maintain a policy that addresses information security.

This seems a bit vague, but if the policy is simply to never save cardholder data in the DB, sessions, etc., isn't that enough?

 

Sorry for all the questions.

All your help is much appreciated.

[Larry]

Also, what do you mean by a third-party offsite payment processor? That's just something like PayPal, right?

 

Yes (and no). By offsite I mean that the user goes to another site and the payment information is taken there. This describes traditional PayPal but other payment systems offer this, too, including Authorize.net.

 

In my case, I'm planning on using Authorize.net. Isn't that enough?

 

No (and yes). Depends upon how you use it. Traditionally, with Authorize.net, you take the payment information on your site and pass that to Authorize.net. But I think Authorize.net has an offsite option, too.

 

If I can impose a bit more, I would like to confirm each of the 12 points, and how they might apply to my situation.

In general, because I'm planning on using a hosting company for my site, it seems like a lot of the requirements should already be handled by them, but here are my thoughts on each of the 12 requirements.

 

That's fine, although to be truly PCI compliant you should hire a PCI compliance expert. I will say that it's a big and erroneous mistake to make to think that the hosting company is taking care of the PCI requirements. I would think that most hosting situations are NOT PCI compliant.

 

Requirement 1: Install and maintain a firewall configuration to protect cardholder data.

I'm assuming that if I use a hosting company, this is something they will take care of for me. Is that true?

 

No. Depends upon the hosting company and the type of hosting.

 

Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters.

Again, I don't think this applies to me, since a hosting company already provides me with a unique user name and I have set my own password.

 

It does apply to you, because you need to be PCI compliant. This doesn't apply to just YOUR password but ALL the passwords and other parameters used on the entire server.

[Larry]

Requirement 3: Protect stored cardholder data.

As you recommend in the book, since I won't actually be storing any data, this isn't an issue, right?

 

This is not an issue so long as you truly aren't storing the cardholder data. That means it's not ending up in logs or even temporarily stored in a session.

 

Requirement 4: Encrypt transmission of cardholder data across open, public networks.

This is a big one, but it seems that so long as I have a valid SSL certificate and use HTTPS for the payment pages, that is enough, right?

 

Right.

 

Requirement 5: Use and regularly update anti-virus software.

Can I assume that the hosting company will take care of this for me?

 

You can't make any assumptions. You'll have to ask to make sure.

 

Requirement 6: Develop and maintain secure systems and applications.

This is very subjective, but I imagine that following your advice in the book will more than cover this.

 

Actually, PCI compliance auditing will cover this.

 

Requirement 7: Restrict access to cardholder data by business need-to-know.

Again, if the cardholder data is never actually stored on the site, than this shouldn't be a problem, right?

 

Yes, assuming it doesn't end up getting stored in logs or sessions or the like.

 

Requirement 8: Assign a unique ID to each person with computer access.

I'm a little confused by this one. Does this mean that if there are multiple site admins, etc., we all need separate logins? What computer are they talking about here? The server? If it's a hosting company, then no one associated with the site would actually have that kind of low-level access anyway, right?

 

Yes, multiple site admins require separate logins. The computer is the server. Everyone that has access to the server also has to have unique logins, including the people at the hosting company. Keep in mind that FTP is computer access.

 

Requirement 9: Restrict physical access to cardholder data.

Again, if this even becomes an issue, I imagine it's something that the hosting company would handle, right?

 

If you're not storing cardholder information, then there's nothing to restrict physical access to.

 

Requirement 10: Track and monitor all access to network resources and cardholder data.

Again, this seems like something the hosting company would do. Am I wrong?

 

Depends upon the hosting company. You'd have to find out.

 

Requirement 11: Regularly test security systems and processes.

Aside from testing for bugs in individual scripts and applications I write, there isn't anything else to worry about, right?

 

No, you have to regularly test the security systems and processes. This isn't a one-time thing and it doesn't just apply to the code you write. It applies to the whole system and server.

 

Requirement 12: Maintain a policy that addresses information security.

This seems a bit vague, but if the policy is simply to never save cardholder data in the DB, sessions, etc., isn't that enough?

 

Look online or talk to a PCI expert for details, but many laws require policies for what to do in case of a security breech, as an example.

[HartleySan]

Wow, Larry! That was all really good. You ever think about making all of this into another tutorial?

This all seems like very valuable information that wasn't really covered in the book.

 

The more I think about it though, the more it seems dang-near impossible to be able to ensure that all of these requirements are met unless you're running your own server, in which case, a whole new level of headaches are introduced.

 

Hmmm... I'm a bit concerned about the prospect of trying to be PCI compliant at the moment, but I will look into it more.

Thanks again for all that great information.

[Larry]

Thanks. Glad it was useful. PCI compliance is a serious issue, not one that any developer should take lightly. The golden (and easiest) rule is simply: never let the user's payment information touch your server. That's the safest route.

[HartleySan]

I thought I had found a solution to my problem with the following link:

http://developer.aut...ze.net/api/dpm/

 

That is, until I noticed that you have to have a U.S.-based merchant account to use DPM. D'oh!

Maybe it's best for me to simply roll my sleeves up and learn all about this PCI compliance thing and do it the right way.

Thanks again, Larry.