Stripe Payment Gateway - Pci Compliance?

[iamp]

I've been testing out the Stripe gateway, and unlike most others I've seen, it looks (from the code) like the credit card details are communicated to the server and then onto Stripe - is this true?

If so, is there any way to implement it so the details go directly to Stripe, as with a WHMCS-style Stripe plugin? And if not, what are the PCI implications of having the credit card numbers touch your server as the client pays?

 

Thanks!

[Timothy]

Hi,

So far as I know, it does pass the card pan through the server and then on to Stripe when the data is initially put in. After that it uses tokenization to charge cards.

The PCI implications are that you have to manage your own PCI compliance. This typically requires filling out a SAQ (type C) and doing quarterly scans from an ASV. Stripe.com will note this under your Account settings > Security section.

 

Hope that helps.

[velaware]

I've been testing out the Stripe gateway, and unlike most others I've seen, it looks (from the code) like the credit card details are communicated to the server and then onto Stripe - is this true?

If so, is there any way to implement it so the details go directly to Stripe, as with a WHMCS-style Stripe plugin? And if not, what are the PCI implications of having the credit card numbers touch your server as the client pays?

 

Thanks!

I've talked to Cody on this about a similar service (Balanced Payments).

 

Right now the way the plugin works, it requires your server(s) to be PCI compliant because it stores sensitive card data.  Though, i have suggested that gateways have the ability to inject HTML into the order form so things like Stripe's javascript can be included which changes the PCI requirement from A/B to C/D, which would make it far more viable for those who want the features of Stripe and similar.

 

If you keep the card info, like you have to now, then you have to follow the QSA guidelines set in by PCI.  If you're interested in learning more, feel free to contact me.  I used to work for a hosting company who performed these tests all the time and I can offer some guidance.  Either ask here (preferably so information can be shared to others) or PM me.

[iamp]

Hi,

Thanks for that. I'm very interested in the requirements for PCI compliance - the Blesta website does not at all make it clear that it doesn't support Stripe in a fully tokenised manner - this is the default selection on the Stripe website and there is no relevant documentation from Blesta, so I'm sure I'm not the only person who was caught by this.

 

What would I have to do in order to make Blesta compliant? I thought PCI compliance was relatively unattainable for small businesses, that's why companies like WorldPay and Barclaycard ePDQ have such domination over the UK payments market?

[velaware]

Hi,

Thanks for that. I'm very interested in the requirements for PCI compliance - the Blesta website does not at all make it clear that it doesn't support Stripe in a fully tokenised manner - this is the default selection on the Stripe website and there is no relevant documentation from Blesta, so I'm sure I'm not the only person who was caught by this.

 

What would I have to do in order to make Blesta compliant? I thought PCI compliance was relatively unattainable for small businesses, that's why companies like WorldPay and Barclaycard ePDQ have such domination over the UK payments market?

PCI compliance, depending on the level of compliance you need/want, is pretty easy.

 

I can't talk about WorldPay or ePDQ because I don't know them or anything, and I don't want to provide false information.

 

To be PCI compliant currently, the best way to describe it is to have Blesta's database be on a separate server that is not accessible outside of a local Intranet and stripped down to the absolute necessaries.  PCI level B would be the minimum I'd say due to the lax that C still allows that puts your user's information at risk.  PCI level A is fine, but is more so if you handle a lot of transactions a day (4 mil. +).

 

If you would like consultation for this I'm happy to assist.  This is one of those things that a lot of people don't think about until its too late, so you looking into this now is very wise.

[iamp]

Hi there,

 

Thanks for that, though I'm not entirely sure I understand. As I see it, using stripe.js or Stripe Checkout, and never handling the credit card details (they are shipped off direct from the user) as well as serving payment pages over SSL makes you sufficiently compliant (source: https://support.stripe.com/questions/do-i-need-to-be-pci-compliant-what-do-i-have-to-do)

 

I was looking at Blesta as a competitor for WHMCS, which is fully compatible with the above setup (albeit by plugin) and as a result is fully compliant with all the questions Stripe ask. Blesta merrily advertises itself as Stripe compatible but does not state that you actually deal with card numbers. I assume this is what requires the PCI compliance above. Similarly, if I didn't realise after a lot of research (I had to deconstruct the payment form before it became obvious to me), how many other users are there out there blindly thinking they are using fully tokenised storage and transmission (and attesting this to Stripe) when they are actually handling card numbers - surely there should be a clear warning to them on the site docs, at the very least? Blesta is very easy to setup and its even easier to get Stripe working with it- most wouldn't even check. 

[velaware]

Hi there,

 

Thanks for that, though I'm not entirely sure I understand. As I see it, using stripe.js or Stripe Checkout, and never handling the credit card details (they are shipped off direct from the user) as well as serving payment pages over SSL makes you sufficiently compliant (source: https://support.stripe.com/questions/do-i-need-to-be-pci-compliant-what-do-i-have-to-do)

You're correct.  The problem is that the current way Blesta works, it doesn't let you use the stripe.js file.  While I can't comment on Stripe Checkout, I'll forward this thread to Cody so he can shed some light on this.  If such features can work, then it'll solve my issue as well.

 

 

I was looking at Blesta as a competitor for WHMCS, which is fully compatible with the above setup (albeit by plugin) and as a result is fully compliant with all the questions Stripe ask. Blesta merrily advertises itself as Stripe compatible but does not state that you actually deal with card numbers. I assume this is what requires the PCI compliance above. Similarly, if I didn't realise after a lot of research (I had to deconstruct the payment form before it became obvious to me), how many other users are there out there blindly thinking they are using fully tokenised storage and transmission (and attesting this to Stripe) when they are actually handling card numbers - surely there should be a clear warning to them on the site docs, at the very least? Blesta is very easy to setup and its even easier to get Stripe working with it- most wouldn't even check.

I can't say anything on how Blesta handles things, but I do agree a warning and such should be stated that the current module requires PCI-B or A compliance (since the fee for not being compliant is very high [$50-100k USD]).

[iamp]

Thanks for this - I appreciate your expertise and am interested to see what Cody says about it.

[Cody]

We've been looking into ways of providing gateways the ability to inject javascript into the payment process for some time. It's coming down the pipeline but to be honest, unless there's more of a demand for it, it's not happening in 3.2 or 3.3.

[velaware]

Thanks for this - I appreciate your expertise and am interested to see what Cody says about it.

No problem, feel free to contact me any time on this.

 

We've been looking into ways of providing gateways the ability to inject javascript into the payment process for some time. It's coming down the pipeline but to be honest, unless there's more of a demand for it, it's not happening in 3.2 or 3.3.

Can't it be possible to at least support the Stripe Checkout, which acts like PayPal's non-merchant systems as well?

[Paul]

Can't it be possible to at least support the Stripe Checkout, which acts like PayPal's non-merchant systems as well?

Stripe is a merchant gateway and does not work like PayPal at all, so it's not possible. A payment account exists in Blesta, and Blesta makes the necessary API calls to Stripe when it wants to charge a card (and passes the token). Allowing Stripe to inject javascript code in the process means that a feature is necessary by which all merchant gateways could do the same.

[iamp]

We've been looking into ways of providing gateways the ability to inject javascript into the payment process for some time. It's coming down the pipeline but to be honest, unless there's more of a demand for it, it's not happening in 3.2 or 3.3.

 

I wonder if the lack of demand is partially down to people not knowing it doesn't support it? There's nothing on your website to indicate this, and while I agree that people should do their own research, many don't and could be using it as though it did. There should certainly be a warning somewhere - like secforus_ehansen said, the fines are pretty steep. I certainly was attracted to Blesta by its Stripe support, and got as far as buying a license and running full payment tests (with the test gateway, luckily) before I realised that it wasn't fully tokenised. 

[velaware]

Stripe is a merchant gateway and does not work like PayPal at all, so it's not possible. A payment account exists in Blesta, and Blesta makes the necessary API calls to Stripe when it wants to charge a card (and passes the token). Allowing Stripe to inject javascript code in the process means that a feature is necessary by which all merchant gateways could do the same.

Didn't know the Checkout thing required the JS library still.  I do know some merchants have offered a non-merchant style payment method too.

 

Why not have the module gain access to the JavaScript helper like widgets and such have?

[Paul]

I wonder if the lack of demand is partially down to people not knowing it doesn't support it? There's nothing on your website to indicate this, and while I agree that people should do their own research, many don't and could be using it as though it did. There should certainly be a warning somewhere - like secforus_ehansen said, the fines are pretty steep. I certainly was attracted to Blesta by its Stripe support, and got as far as buying a license and running full payment tests (with the test gateway, luckily) before I realised that it wasn't fully tokenised. 

 

There probably should be something in the documentation to indicate which API it implements. I don't understand what you mean by "isn't fully tokenized" though. Blesta does not at any point store sensitive card details for Stripe, just the token. (Unless configured to do so instead of tokens). The contention is the pass-through of card details. It's still tokenized, it just isn't using stripe.js to keep your server from seeing those details when the payment account is initially created.

 

The result is that Stripe works a lot like Authorize'net's CIM method. As far as I know, there is no stripe.js equivalent to Authorize.net CIM. There's less risk than storing card details, but some risk because of pass-through, and a requirement for PCI.

 

Didn't know the Checkout thing required the JS library still.  I do know some merchants have offered a non-merchant style payment method too.

 

Why not have the module gain access to the JavaScript helper like widgets and such have?

 

Cody will have to comment on the design aspect of a javascript implementation.

[velaware]

There probably should be something in the documentation to indicate which API it implements. I don't understand what you mean by "isn't fully tokenized" though. Blesta does not at any point store sensitive card details for Stripe, just the token. (Unless configured to do so instead of tokens). The contention is the pass-through of card details. It's still tokenized, it just isn't using stripe.js to keep your server from seeing those details when the payment account is initially created.

 

The result is that Stripe works a lot like Authorize'net's CIM method. As far as I know, there is no stripe.js equivalent to Authorize.net CIM. There's less risk than storing card details, but some risk because of pass-through, and a requirement for PCI.

The problem with this though is that it violates PCI, since card data still has to enter the server to be tokenized and sent to Stripe.  That's the whole issue.  That's the whole point behind the JS library being provided, so that it only passes from the client to Stripe's servers, not client->my server->Stripe's server.

[Paul]

The problem with this though is that it violates PCI, since card data still has to enter the server to be tokenized and sent to Stripe.  That's the whole issue.  That's the whole point behind the JS library being provided, so that it only passes from the client to Stripe's servers, not client->my server->Stripe's server.

 

It requires PCI compliance, sure. I agree that pass-through maintains that requirement and I understand and acknowledge the benefit and need for the stripe.js implementation.

[iamp]

There probably should be something in the documentation to indicate which API it implements. I don't understand what you mean by "isn't fully tokenized" though. Blesta does not at any point store sensitive card details for Stripe, just the token. (Unless configured to do so instead of tokens). The contention is the pass-through of card details. It's still tokenized, it just isn't using stripe.js to keep your server from seeing those details when the payment account is initially created.

 

The result is that Stripe works a lot like Authorize'net's CIM method. As far as I know, there is no stripe.js equivalent to Authorize.net CIM. There's less risk than storing card details, but some risk because of pass-through, and a requirement for PCI.

 

 

Cody will have to comment on the design aspect of a javascript implementation.

 

@Paul - Stripe's terminology states that fully tokenised (at least for the security disclosure) means that card details are never accepted outside of one of their JavaScript APIs (see https://www.dropbox.com/s/8ltquhkkdv0fl9t/Screenshot%202014-03-04%2023.03.59.png) - you say you fully support tokenisation, which you do for storage - and users will check the box and not think twice about it - violating the PCI compliance rules and opening themselves up to huge fines in the event of a breach. I suspect that some of your existing licensees may be in this position. 

 

@secfous_ehansen - Stripe's checkout and stripe.JS payment methods are very similar - they both use JavaScript to take the credit card details, but stripe.JS completes the whole payment on the form submission, handing over a completed payment object to whatever receives the form. Checkout will collect the card details and tokenise them, passing the token to whatever receives the form, allowing its storage and immediate charging via the API. Stripe.JS is effectively a very, very simple way of taking payments, checkout takes it up a notch and gives you some control (ideal for a payment gateway). 

 

Edited to change APIs to JavaScript APIs

Edited March 4, 2014 by iamp

[Paul]

@iamp, fair enough

[Timothy]

Paul,

I was also under the impression that the Stripe implementation was fully tokenized instead of the current setup. I believe I had a open ticket about this back in December. I agree with @iamp, that it is likely, there are other installation that are using Stripe unaware of their PCI compliance obligations.  

So here is my vote for having the stripe module fully tokenized in Blesta.

[Virtovo]

I'd like to add a vote here.  We've recently signed up with Stripe and was about to launch it as a payment gateway.  So glad we didn't.  I think this might be worth sending an email to all clients about or at least adding to the docs.  I'd imagine there are a lot of people who are non-compliant as a result of this.

[Cody]

The problem with this though is that it violates PCI, since card data still has to enter the server to be tokenized and sent to Stripe.  That's the whole issue.  That's the whole point behind the JS library being provided, so that it only passes from the client to Stripe's servers, not client->my server->Stripe's server.

 

This is untrue and misleading. Blesta is entirely PCI compliant, regardless of how you choose to store or not store card details. The only compliance requirement which must be followed (and is entirely outside of Blesta's control) is PCI compliance scans to ensure proper server configuration.

[Cody]

Added CORE-1085 to allow merchant gateways the ability to bypass Blesta when adding/editing payment account details.

[velaware]

This is untrue and misleading. Blesta is entirely PCI compliant, regardless of how you choose to store or not store card details. The only compliance requirement which must be followed (and is entirely outside of Blesta's control) is PCI compliance scans to ensure proper server configuration.

Just to clarify, you're saying having card data be passed through Blesta (which is stored on a seller's server) doesn't violate PCI even if the data isn't stored?

 

Not trying to be a dick, just wanting to verify/clarify this.

[Paul]

Just to clarify, you're saying having card data be passed through Blesta (which is stored on a seller's server) doesn't violate PCI even if the data isn't stored?

 

Not trying to be a dick, just wanting to verify/clarify this.

 

I think what he's saying is that most of the PCI requirements are related to infrastructure. We're not saying that you're off the hook from such requirements, you're certainly not if the card data touches the system in any way.

[iamp]

This is untrue and misleading. Blesta is entirely PCI compliant, regardless of how you choose to store or not store card details. The only compliance requirement which must be followed (and is entirely outside of Blesta's control) is PCI compliance scans to ensure proper server configuration.

 

Cody - my point, and possibly secforus_ehansen's too, is that while you support tokenised storage, you don't support tokenised transmission (at least until CORE-1085 is resolved), so saying you fully support Stripe (which exists as an easy to setup payment gateway allowing you not to have to deal with PCI) leads people to believe you support it in full tokenised mode - transmission and storage. This will lead them to use it without checking and to attest to Stripe that they never touch the details - that is not PCI compliant. I think Blesta is a great piece of software and on its own I'm sure its compliant, but without sufficient documentation, the Stripe module is not. As SusanC said, I think it might be worth sending an email around to warn people before someone gets into serious trouble.

 

Edit - I'm not trying to be a dick either, but am concerned by how close I got to implementing the gateway before I realised how it worked. I'm sure I'm not the only one.