Stripe Payment Gateway - Pci Compliance?

[Virtovo]

I must admit I am shocked this is not clearly stated on the main pages of Blesta's website. I've just spent 2 hours looking through features and comparing Blesta with WHMCS and I was so close to making the switch until I discovered this thread.

Having the choice to use Stripe.js is a must have feature I am afraid.

I hope you can implement this change ASAP and rescue lots of unsuspecting users.

 

I'm not sure Blesta consider this a priority.  We're not using Stripe as a result and it's actually really frustrating. 

[Cody]

We have something in the works, but it's a big change to the inner workings of the payment system so will take some time.

[Mdhsmith]

Can someone confirm whether these statements on the matter is correct please?

1. Blesta's Stripe Gateway will currently send through the card details to the Stripe server but will not store them locally.

2. If I have a SSL certificate on my Blesta install the card details are encrypted when they are submitted and sent to Blesta.

3. This means my customers are safe and I am safe from potential legal fines.

Is this correct? O the Stripe website support.stripe.com/questions/do-i-need-to-be-pci-compliant-what-do-i-have-to-do it seems like this is all that needs doing to make them happy.

Has anyone got any comments, observations or advice?

[Michael]

Can someone confirm whether these statements on the matter is correct please?

1. Blesta's Stripe Gateway will currently send through the card details to the Stripe server but will not store them locally.

2. If I have a SSL certificate on my Blesta install the card details are encrypted when they are submitted and sent to Blesta.

3. This means my customers are safe and I am safe from potential legal fines.

Is this correct? O the Stripe website support.stripe.com/questions/do-i-need-to-be-pci-compliant-what-do-i-have-to-do it seems like this is all that needs doing to make them happy.

Has anyone got any comments, observations or advice?

 

I'm not sure but I believe if you do the right security you can get PCI compliant: https://www.ssllabs.com/ssltest/analyze.html?d=domain-name.com

 

Eg: https://www.ssllabs.com/ssltest/analyze.html?d=licensecart.com (I can help you on InterWorx or cPanel (I've not tried it but a mate said it should work on a cPanel server)).

[Max]

the Stripe website support.stripe.com/questions/do-i-need-to-be-pci-compliant-what-do-i-have-to-do it seems like this is all that needs doing to make them happy.

 

From that site:

 

 

Use Stripe.js or Checkout to accept payment information and transmit it directly to Stripe's servers.

 

Stripe.js is not used, nor is Checkout.

The payment information is not transmitted directly to Stripe's servers, but it is transmitted indirectly to them through your servers instead.

 

This has the consequence that your servers are the ones needing quarterly security testing.

And you need to be able to answer "yes" to at least all the questions on: https://www.pcisecuritystandards.org/documents/pci_saq_c_v2.doc

(and if you take the definition of "storing card holder data" literally these: https://www.pcisecuritystandards.org/documents/pci_saq_d_v2.doc )

 

 

Note that if you are processing a low number of transactions, compliance validation is not required, meaning your credit card processor is not required to ask you to submit proof that you actually did the testing or completed the SAQ.

You still have to be in compliance though, meaning you can get into trouble if there is an incident, and it turns out you "forgot" to do them.

[Max]

I'm not sure but I believe if you do the right security you can get PCI compliant: https://www.ssllabs.com/ssltest/analyze.html?d=domain-name.com

 

Eg: https://www.ssllabs.com/ssltest/analyze.html?d=licensecart.com (I can help you on InterWorx or cPanel (I've not tried it but a mate said it should work on a cPanel server)).

 

That merely tests your SSL settings, not the rest of your server.

Need a quarterly scan from an approved provider from this list: https://www.pcisecuritystandards.org/approved_companies_providers/approved_scanning_vendors.php

Starts at around $ 250 / year (Comodo)

[Cody]

Can someone confirm whether these statements on the matter is correct please?

1. Blesta's Stripe Gateway will currently send through the card details to the Stripe server but will not store them locally.

If you check "Store Card Information Offsite" when configuring Strip in Blesta, Blesta will not store card details locally.

 

2. If I have a SSL certificate on my Blesta install the card details are encrypted when they are submitted and sent to Blesta.

You must enforce the HTTPS protocol. An SSL cert itself is useless if you're not forcing people to use it. See Forcing HTTPS in the User Manual.

 

3. This means my customers are safe and I am safe from potential legal fines.

You still need to perform PCI compliance scans if you accept credit card payments. The only way you can get around that is if you only use non-merchant gateways (paypal, skrill, etc.).

[Bit Bayou]

If you check "Store Card Information Offsite" when configuring Strip in Blesta, Blesta will not store card details locally.

 

To Clarify:

I have this checked. Yet, Blesta still lets clients set up a Payment Account and store their credit card information. This information is not stored on my server? Stripe saves that for me, so I can then bill them later, correct? Therefore, none of the credit card data is stored on my server?

[Cody]

To Clarify:

I have this checked. Yet, Blesta still lets clients set up a Payment Account and store their credit card information. This information is not stored on my server? Stripe saves that for me, so I can then bill them later, correct? Therefore, none of the credit card data is stored on my server?

 

Blesta will not store the card number in that case. Blesta has to store some card information, though. This includes the card type, last 4 of the card, and expiration date. This is required so that Blesta can send card expiration notices to clients, identify the card to the user for proper selection, and process refunds and voids.

[Bit Bayou]

Blesta will not store the card number in that case. Blesta has to store some card information, though. This includes the card type, last 4 of the card, and expiration date. This is required so that Blesta can send card expiration notices to clients, identify the card to the user for proper selection, and process refunds and voids.

 

OK, and I am still required to have all of the other PCI compliance requirements? I was liking Stripe in the fact they did most of that for me! Is this not correct?

[Bit Bayou]

OK, and I am still required to have all of the other PCI compliance requirements? I was liking Stripe in the fact they did most of that for me! Is this not correct?

 

I apologize for the double post, but I want to readdress your attention here because I think this is where the most confusion is coming from? I have nothing stored on my server, except for the Blesta configured information. Are all of the compliance requirements still required, as discussed for legal compliance? I know it's recommended, but in the most basic legal / technical terms, is it?

[Paul]

I apologize for the double post, but I want to readdress your attention here because I think this is where the most confusion is coming from? I have nothing stored on my server, except for the Blesta configured information. Are all of the compliance requirements still required, as discussed for legal compliance? I know it's recommended, but in the most basic legal / technical terms, is it?

 

You are required to do PCI scans because card data touches the server, even though it is not stored. The proposed stripe.js implementation passes the card details directly to Stripe so they don't technically go through your server. In that case, you wouldn't have to do the scans at the moment. We have not implemented the stripe.js method yet. Since your server renders the markup, I believe even stripe.js implementations will be required to do PCI scans in the future. It's a sort of loophole that I expect they will close before long. (If your server was compromised, an attacker could alter the javascript and intercept the card details anyway)

 

So, short answer. Yes, you should do PCI scans

[velaware]

You are required to do PCI scans because card data touches the server, even though it is not stored. The proposed stripe.js implementation passes the card details directly to Stripe so they don't technically go through your server. In that case, you wouldn't have to do the scans at the moment. We have not implemented the stripe.js method yet. Since your server renders the markup, I believe even stripe.js implementations will be required to do PCI scans in the future. It's a sort of loophole that I expect they will close before long. (If your server was compromised, an attacker could alter the javascript and intercept the card details anyway)

 

So, short answer. Yes, you should do PCI scans

To expand on what Paul said:

 

1. Stripe.js acts on the client-side (thus it being JavaScript which is a client-side language, unlike PHP which is server-side).  This is why services like Stripe and Balanced can let you circumvent PCI, because with these JavaScript files, the data never touches the server and goes from your browser directly to Stripe's servers.

2.  As for an attacker altering the JavaScript, this depends.  If you load it directly from Stripe's servers then data theft would be more of a risk if the file gets modified from Stripe's end (but at that point your worries are more than just a modified JavaScript file...).  That is one of the reasons why its not suggested to load those files locally.  However, JavaScript is one of those easily-hacked technologies if you know the right techniques.

 

From experiences working with eCommerce web hosting, I would say do PCI compliance audits/scans.  If people are interested I can assist in it (compliance C & D [which this would be] is pretty straight forward).

 

Ideally you should do it quarterly, but I believe the maximum delay between audits is 6-12 months depending on the level of PCI compliance you're after.

[Cody]

2.  As for an attacker altering the JavaScript, this depends.  If you load it directly from Stripe's servers then data theft would be more of a risk if the file gets modified from Stripe's end (but at that point your worries are more than just a modified JavaScript file...).  That is one of the reasons why its not suggested to load those files locally.  However, JavaScript is one of those easily-hacked technologies if you know the right techniques.

 

This is completely irrelevant. If the CC number field is sent by your webserver, it can be compromised regardless of where you load stripe.js from if your server is vulnerable.

The point Paul is making is that your webserver is serving content to the client for a page that requests credit card information. As long as that is the case you are at risk if your server is vulnerable. This is why it is inevitable that stripe.js and other work-arounds will be squashed by PCI compliance.

[Hostlumina]

I think part of the issue is that there is no warning that the .js is not been used and some think that the module is PCI compliant. 

 

Personally, I didn't know until i ran into this post a couple of months back as i was setting up blesta. at this point to be honest I stopped spending money on further site development and decided to wait for bootstrap and hope to see significant changes with this module + the support module that I am to checkout this weekend

 

If it doesn't exist yet, a warning should be made on the module of this or better yet update the module to use the .js to make use of this "loophole" while still open and still make the warning if needed + have the option to use the stripe checkout (https://stripe.com/docs/checkout) which will go trough stripe directly.

 

Just my 2 cents

[Michael]

I think part of the issue is that there is no warning that the .js is not been used and some think that the module is PCI compliant. 

 

Personally, I didn't know until i ran into this post a couple of months back as i was setting up blesta. at this point to be honest I stopped spending money on further site development and decided to wait for bootstrap and hope to see significant changes with this module + the support module that I am to checkout this weekend

 

If it doesn't exist yet, a warning should be made on the module of this or better yet update the module to use the .js to make use of this "loophole" while still open and still make the warning if needed + have the option to use the stripe checkout (https://stripe.com/docs/checkout) which will go trough stripe directly.

 

Just my 2 cents

 

I like the idea about the checkout feature.

[Virtovo]

I think part of the issue is that there is no warning that the .js is not been used and some think that the module is PCI compliant. 

 

Personally, I didn't know until i ran into this post a couple of months back as i was setting up blesta. at this point to be honest I stopped spending money on further site development and decided to wait for bootstrap and hope to see significant changes with this module + the support module that I am to checkout this weekend

 

If it doesn't exist yet, a warning should be made on the module of this or better yet update the module to use the .js to make use of this "loophole" while still open and still make the warning if needed + have the option to use the stripe checkout (https://stripe.com/docs/checkout) which will go trough stripe directly.

 

Just my 2 cents

 

This

[Max]

From experiences working with eCommerce web hosting, I would say do PCI compliance audits/scans.  If people are interested I can assist in it (compliance C & D [which this would be] is pretty straight forward).

 

Ideally you should do it quarterly, but I believe the maximum delay between audits is 6-12 months depending on the level of PCI compliance you're after.

 

Read the SAQs carefully.

The security scans need to be done quarterly at a very minimum and after any software upgrade or network/firewall settings change.

 

Some other things need to be done less or more often.

E.g. if you are storing card holder data yourself (SAQ D), you need to review the log files of all your systems daily.

The SAQ itself needs to be done annually.

 

Again, if you process a low number of transactions they are not going to ask for proof you are actually doing all that beforehand.

But it is still a requirement, and if things go wrong, they might.

 

 

I think part of the issue is that there is no warning that the .js is not been used

 

Yes, and that goes for other payment modules that Blesta is offering as well.

What integration method is used by each module and what the consequences are may not be sufficiently clear.

I think most smaller providers are better off with the non-merchant integrations all major processors offer.

Even if that means less pretty, less integrated payment pages.

[Bit Bayou]

Yes, and that goes for other payment modules that Blesta is offering as well.

What integration method is used by each module and what the consequences are may not be sufficiently clear.

I think most smaller providers are better off with the non-merchant integrations all major processors offer.

Even if that means less pretty, less integrated payment pages.

 

I can understand the argument that it would be the same for any other merchant gateway (module) as well... But here's what most are reading (found at https://stripe.com/us/features#seamless-security)

 

 

No-hassle security & compliance

By using any of Stripe’s client libraries, such as Stripe.js for the web or the mobile APIs, you’re automatically compliant with the strictest PCI requirements.

 

No sensitive data hits your servers, saving you hours of security headaches.

 

The whole [quick/easy] selling point behind Stripe here is the you’re automatically compliant with the strictest PCI requirements and now the general attitude here that people should know better-- "better" being the opposite of what is advertised directly on their website

[Bit Bayou]

Also found at https://stripe.com/us/help/faq#my-pci-requirements

 

 

Anyone involved with the processing, transmission, or storage of credit card data must comply with the Payment Card Industry Data Security Standards (PCI DSS). Stripe makes it easy to do so:

 

Serve your payment page over SSL, i.e., the page's web address should begin with "https", not "http".

Use Stripe.js or Checkout to accept payment information and transmit it directly to Stripe's servers.

 

This sounds awesome! Just get an SSL Certificate, use Stripe, and I can accept Credit Cards without much else hassle! 

 

But that's apparently not the case in Blesta, which is not advertised, and people are being critical about those who read this FAQ answer, and still didn't know any better

[Max]

But that's apparently not the case in Blesta, which is not advertised

 

Yes, what integration method is used by Blesta exactly should be better documented.

 

Not just for Stripe, but also for the other processors like Authorize.net, BluePay, eWay, Quantum Gateway and PayJunction

Virtually all gateways support multiple integration methods, which require a different number of requirements one needs to comply with.

[Ken]

I'm more concerned with the fact that they're telling you all that it's not secure but a loop hole. It's not PCI compliance but rather avoidance.

As a business owner/manager and credit card merchant your primary goal should be keeping customer data secure.

Stripe has multiple methods for integration. Why would anyone just assume it's using stripe.js?

I really don't see the big deal with documenting it to make everyone happy, it seems simple enough, but I also don't get the witch hunt here.

If you didn't know before, you know now.

[Bit Bayou]

Stripe has multiple methods for integration. Why would anyone just assume it's using stripe.js?

I really don't see the big deal with documenting it to make everyone happy, it seems simple enough, but I also don't get the witch hunt here.

If you didn't know before, you know now.

 

I realize the mistake of assuming there, and I was one of them in this case (Though as a local, small business, the gateway hasn't been used yet because my clients mostly prefer check payments).

 

Stripe does a great deal of advertising of saying how easy it is to accept credit cards and be compliant! I was following this story line (since it's their website, their gateway, etc).

 

I'm not sure about any witch hunt here either, I was simply trying to clarify this information since it was brought up and being discussed. I do agree it could be documented better, but I usually only glance at those when there's a problem with the system...

 

I do know now, and I could absolutely get behind a version of this gateway that does use their Strip.js library since they claim all I need to do with that is use an SSL certificate!

[Bit Bayou]

Have we abandoned this topic already? I'm not here to blame anyone, point fingers, or none of that!

 

I'd just like to see either the stripe.js method as an available option or at least discuss and address the reasons why it won't / can't be?

 

Should this be pursued as a 3rd party add on option? Let me know!

[Cody]

Have we abandoned this topic already? I'm not here to blame anyone, point fingers, or none of that!

 

I'd just like to see either the stripe.js method as an available option or at least discuss and address the reasons why it won't / can't be?

 

Should this be pursued as a 3rd party add on option? Let me know!

 

Why are we still talking about this? As I've already said, it's in the works. CORE-1085.

 

/thread.