OK for those of you who frequent the IRC channel you probably saw me asking this yesterday but I wanted to make sure I had everything right in my mind.

I want to accept payments on a website I am developing (it is entirely custom code using the Django framework). I've decided to accept PayPal and credit and debit cards directly using PayPal Website Payments Pro. From reading the PayPal documentation when you accept credit and debit cards directly on your website (rather than offloading it onto PayPal's servers) you have to be PCI DSS compliant. This is perfectly reasonable.

The question is really do I need to adhere to SAQ C or SAQ D? Originally I thought I'd need to adhere to SAQ D but I was lead to believe that SAQ C would be sufficient. Also I have also been told that PCI DSS compliance places some requirements on your web hosting provider, so does Linode meet these requirements? I really want to make sure I do this correctly but it seems such a minefield. The technical points are pretty easy to implement (frankly I do meet most of the requirements for normal servers anyway) it is just making sure you adhere to the correct requirements.

So any hints and tips relating to PCI DSS compliance particularly when it is concerned with hosting sites on the Linode infrastructure? How does Linode itself handle PCI DSS compliance? I notice that you (Linode) save my credit card number and expiry date in the admin panel so what level of PCI DSS compliance do you adhere to in regards to that as that is the sort of thing I'll be storing?

Any help is very much appreciated .

This thread doesn't cover all you asked but at least some of it: viewtopic.php?t=8070#p46013

(Personally I would suggest avoiding the liability of having to handle/store the actual CC data, if that is an option.)

Thanks for the link. Some useful information there.

As for not storing / handling CC data I'd love to be able to avoid it (and it would actually save me money) I am just concerned that just having PayPal as the only payment option would lose me sales. I'd probably also have Google Checkout as well but that still does not solve the problem. My target market is pretty tech savvy (developers and sys admins mainly) so they will likely be a bit more paranoid about payment methods and PayPal seems to have a poor reputation in those sectors.

Take a look at someone like Braintree. They'll do transparent redirection (your form submits to their server, which redirects back to you with go/no-go decision), and they are ridiculously easy to integrate with. They've also got a "vault" for recurring payment stuff. You don't have to handle credit card data at all to accept credit cards.

And it's not so much that PayPal is inherently insecure or anything like that, it's just that they do an end-run around the whole security issue by stealing your money themselves before someone else can.

_________________

/* TODO: need to add signature to posts */

I don't mean to turn this into some kind of silly argument but I believe I fit your description of the intended target audience well (as do probably most of the people frequenting this forum) and I think the reasoning was a little strange (how you went on from people being paranoid about Paypal so you want to roll your own thing) so here are my $0.02 / €0.02 / whatever:


Just speaking for myself, I find an Amazon/Google/Paypal (probably in that order) payment option preferable, or for that matter one of these payment systems that I suppose are really designed to be easy to implement on sites where you as part of the checkout process get sent to some known payment processor to complete the payment.

I just don't like having this info stored in even more random places than it already ends up, places where it may or may not be appropriately protected. Therefore I'm not really a fan of when especially lesser known sites want to manage this information on their own.


I suppose my point is just that I would consider handing this information directly to you to probably be the single most paranoia-inducing alternative (nothing personal obviously, I have no idea who you are or what site/business this question pertains to).

Would love to use them but they appear to be US only based on the fact that they ask for your social security number on the sign up form. I'm based in the UK so this is out of the question. I actually looked at them in the past, I just forgot why I ruled them out originally.

I see your point, but I can't afford to lose any sales so I'm in a bit of a catch 22 situation. Frankly I could do without the hassle of handling the credit card details but at the same time if people decide not to go with me because I only offer payment options that they do not want to use (and you can never offer them all there are far too many options) then that will cost me dearly.

The primary question is what is happening with the cardholder data (and more specifically the PAN - Primary Account Number). PCI will apply to any system that stores, processes, or simply transmits the information.

If you're going to store the PAN, jump right to the full SAQ D, no question. It's the only SAQ level that permits electronic storage of card data.

If your systems are just processing or transmitting the PAN, you can use SAQ C.

If you're offloading the processing entirely (payment form hosted by other provider, or using a provider where you supply a form that posts to the providers servers so your servers never see card data) you should be able to get away with SAQ A, or maybe even justify your server being completely out of scope for PCI entirely if it never deals with card data. Though SAQ A is pretty trivial and deals with ensuring your processors are themselves compliant so probably better to have filled out.

As others have mentioned, doing the most you can to avoid storing card data is your best option. If not, I'd probably suggest that you dedicate a node solely for secure storage of the card data and no other function at all (e.g., implement your own version of the Braintree vault and avoid your main application stack from touching raw card data). My own opinion is that you won't quite be able to meet all the technical requirements of SAQ D (A/C is doable), but that's personal opinion, and PCI in general is self-certification, plus the downside risk is only on the back-end in terms of possible penalties in the event of a breach.

In any case, once a system is within PCI scope, any other accessible system that might have any chance or possibility of access to the network traffic or systems involved will also need to be compliant. In a default configuration that would probably include all other Linodes on the same local network, which is clearly impossible to control, so it's important that you carefully firewall everything (and/or draw encrypted boundaries with SSL) to avoid scope creep involving more machines than necessary or possible to address.

In addition to the other thread already referenced, here, an earlier one (viewtopic.php?t=5622) may also be useful. Also, the PCI site (http://www.pcisecuritystandards.org) is the main reference - the SAQ instructions and guidelines document can help in identifying which SAQ you need to meet.

-- David

I don't have much first hand knowledge of non-US support (though I've been a long term US customer), but I know they've been making progress in that direction, so I'd try dropping them a note. The pricing page indicates they're in Europe, though I don't know how widely and/or for what pricing. But it couldn't hurt to ask.

-- David

Just took another look at their website and it appears they do support the UK which is awesome although they do have some rather stringent requirements (no sole traders for instance and having to provide a financial planning document which was something I was hoping to keep private for the time being).

https://www.braintreepayments.com/tour/international

It does look like BrainTree has recently added Canada and Europe (which they didn't support last time I looked, automatically completely ruling them out), but there is still one major problem.

Their rates suck. PayPal goes down to 1.9% + $0.30, while BrainTree charges 2.9% + $0.30. That makes a pretty big difference. If they could even match (forget about beat) PayPal's rates, we'd consider switching, but why should I pay enormously more to BrainTree than PayPal?

Because Braintree is less of a hassle for your customers, and probably won't screw you over for arbitrary reasons. I ain't gonna be all LEB with customer money, that's for sure.

_________________

/* TODO: need to add signature to posts */

I don't see how Braintree can provide any differentiation in the user experience as compared to PayPal whatsoever, let alone less hassle. They click the payment button on our website, they enter their credit card info, they get redirected back to the website. How does Braintree make "type in the numbers and letters on the piece of plastic in your wallet" any easier?

Heck, if we were willing to take the effort, we could do the entire thing without the user ever leaving our website and use PayPal only as a fully external payment processor, but we don't want to be accepting credit card info through our server. How a different webservice API from BrainTree can provide a better customer experience is beyond me. In that case the customer probably doesn't even have any way of knowing PayPal is involved.

TR is indistinguishable from collecting the credit card data yourself; the form is submitted to Braintree, and the POST response redirects back to your site. On the other hand, I've not yet seen a PayPal redirect that didn't scream "HEY WE'RE USING PAYPAL!" and make me dig up my PayPal creds, but obviously that doesn't mean I haven't experienced it yet.

In any case, this is straying quite far off-topic, and we haven't even gotten into PayPal's legendary TOS yet...

_________________

/* TODO: need to add signature to posts */

If you're using PayPal as a credit card processor, there are no paypal credentials involved. Yes, it does scream "HEY WE'RE USING PAYPAL!" because with the basic implementation you redirect to a PayPal page, but that page simply collects the credit card data and does the payment. PayPal also has a "direct" method where you collect the credit card data and send a webservice request to PayPal to do the processing; the user has no way of knowing, really, what payment processor your application is contacting in the background.

There are certainly a bunch of concerns to using PayPal, and we'd like to move off them some day if we can find somebody with a better rate, but most of the advantages you've listed are actually already supported by PayPal when used purely as a credit card processor. Using BrainTree over PayPal might have a greater peace of mind, but a business would have to evaluate if that peace of mind is really worth 1% of all your credit-based revenue. To us, as a non-profit who is always strapped for cash (no matter how much money we take in, it all goes into making the event better, and we're always saying "if only we had a bit more budget we could do this and this and this better"), that extra 1% would hurt.