PCI DSS questions

This thread doesn't cover all you asked but at least some of it: http://forum.linode.com/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.)

@hawk7000:

This thread doesn't cover all you asked but at least some of it: http://forum.linode.com/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.

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

@hoopycat:

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.

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.

@hawk7000:

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

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.

@Cromulent:

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.
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 (http://forum.linode.com/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

@Cromulent:

@hoopycat:

Take a look at someone like Braintree. (…)

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

@db3l:

@Cromulent:

@hoopycat:

Take a look at someone like Braintree. (…)

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

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…

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.

I say you avoid the PCI-DSS subject altogether and use something like https://www.stripe.com. You use your own hosted payment form, but the credit card data is never actually posted to your server. You can accept PayPal too, if you'd like, but these guys have a top-notch API that makes things much, much simpler. The best way to deal with PCI-DSS is to not introduce it at all.

@swaj:

I say you avoid the PCI-DSS subject altogether and use something like https://www.stripe.com. You use your own hosted payment form, but the credit card data is never actually posted to your server. You can accept PayPal too, if you'd like, but these guys have a top-notch API that makes things much, much simpler. The best way to deal with PCI-DSS is to not introduce it at all.

Only available in the US and Canada.

@Guspaz:

(…) 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.
I think the sort of direct method you're talking about requires your application to see the card data though, right? In that case, it's not really comparable to the Braintree transparent redirect method, either in terms of PCI exposure, or simplicity of implementation. With TR you have absolute control over how you design the UI of your form (well aside from requirements like definitely having a field somewhere for the card number), but it still posts - just a standard HTML form post - directly to Braintree servers so you have no exposure to card data. The only new application logic needed is to generate security/hash information for use in the form.

TR is closer, I expect, to what you can do with the seamless checkout option with PayPal Advanced or Pro accounts. If I understand it correctly, that's where you can embed a form in your site that posts to PayPal. So no complete redirect to a PayPal hosted site to collect the card data. But it's not clear to me how much you can customize that form and hide any PayPal indication even when embedded on your site. The sample images still seem fairly heavily branded, but that might not mean anything.

In relation to this thread's topic, either the standard (PayPal hosted) or PayPal seamless checkout / Braintree transparent redirect are much better than collecting the card data and doing direct processing requests from your application, since the latter will force your application in-scope for PCI (to SAQ C at a minimum, assuming you're just processing/transmitting the card data in memory, SAQ D if it ever ends up stored anywhere including logs), whereas the other approaches at worst require SAQ A.

> 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.
If I'm reading your prior post correctly, this 1% gap is based on an "as low as" rate from PayPal versus the default rate from Braintree. Presumably you're generating some volume to reach that low with PayPal (if not, kudos on negotiating that rate for ecommerce). For example, the US PayPal merchant page seems to quote the same 2.9% as Braintree - or even 3.1% if you use a VT - as a baseline, going down to 2.2%. And it seems like standard UK rate is actually 3.4% but goes down as low as 1.4% with very high transaction volume.

While they don't publish a specific discount schedule, Braintree's page does indicate that lower rates are available for volume. Historically their default model was two tier (2.29/2.87 I think most recently) but with a minimum, and they specifically didn't aim at the smallest merchants. I suspect their new approach is for simplicity, and to better match others in the space. But it's also not terribly aggressive, and I'm sure there's wiggle room for volume.

Of course, PayPal may still make more sense for any given merchant, but if it's purely a rate question, some individual research may be necessary to ensure as apples to apples a comparison as possible.

– David

PayPal automatically grants you the better rates if you do more than a certain volume, and it's not very high to get the first level or two. In Canada, it starts at 2.9%, $3k a month gets you 2.5%, $12k a month gets you 2.2%, and $125k a month gets you 1.9%. I don't think we quite hit the 1.9% rate, but the 2.2% rate is far better than Braintree's listed default. If they or Stripe could quote us rates as good as PayPal or better, we'd consider them. Otherwise, a better API is zero reason to switch from an already implemented and working solution that costs less.

Braintree just threw down the virtual gauntlet. It's now available in 31 countries (including many in Europe). They accept 130+ currencies. And best of all it's now 2.9% + 30 cents per transaction with no minimums and no monthly fees. They even reduce the rate when you get to higher volume levels. Sounds like all your problems are solved. Go with Braintree. Their API is really, really good.

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

https://www.braintreepayments.com/pricing

Unless they are going to tell me what those "reduced rates at higher volume levels" are, they're more expensive than PayPal… The fact that they don't advertise their real rates in public seems rather shifty to me.