I'd like to use this module, but I'm confused as to whether I need SAQ A or SAQ A-EP PCI compliance

Stripe say that by using Stripe.js you're still SAQ A compliant, but I can't see whether that still applies for Ubercart. According to the module page the Commerce version is SAQ A-EP, so I was wondering if it was the same for this module?

Comments

Anonymous’s picture

mattkevan created an issue. See original summary.

robertmaynord’s picture

Thanks for asking this question! The issue has been discussed at length in Drupal forums, but I'm not sure it has been completely resolved. In part, it seems that compliance confirmation is something that is determined by your bank or merchant account supplier - in this case, Stripe. So far, I haven't heard anything from Stripe requesting documentation of compliance. They do, as you note, seem to present the idea that stripe qualifies for SAQ-A.

Here is from the stripe web site: "Instead of requiring you to fill out the more complex SAQ A-EP, we’ve worked with our Qualified Security Assessor and others to update Stripe.js to meet the new requirements and security constraints of the simpler SAQ A, while still keeping it easy to use. The new version of Stripe.js meets these criteria by performing all transmission of sensitive cardholder data within an iframe served off of a stripe.com domain controlled by Stripe. This in turn allows our users to continue to be eligible for SAQ-A (the older questionnaire)."

SAQ-A is extremely important for a small merchant. Even SAQ-EC would require very substantial paperwork, scans, and server upgrades, costing in the thousands of dollars. That's why I dropped my bank and Authorize.net a few months ago....

Anonymous’s picture

Following up, I contacted Stripe for more information:

My message

I'm using your service with Ubercart, one of the Drupal ecommerce platforms, and I have a question about PCI compliance.

I'm using AWS which is a PCI compliant host, and I know that you say that Stripe.js meets SAQ A, but I can't get a clear answer as to whether the implementation of stripe.js in Ubercart is SAQ A or SAQ A-EP. I don't know enough to look at the module code and be able to tell.

Is this something you can help with? I'm keen to continue using your service, but as a small ecommerce side-project I don't have the time or resources to go down the EP route.

Their response

Thanks for writing in about this, I'm happy to help! I'm not really familiar with Ubercart myself but you'd fall under SAQ-A as long as:

  1. you serve the payment form over HTTPS
  2. you load Stripe.js directly from our server
  3. you never send card details to your own server.

The #2 you can check in Chrome developer tools whether it's loaded from our servers and the #3 is based on making sure that the input fields in your payment form have no `name` attribute.

Looking at my site, the payment form is over HTTPS, so tick number one. Stripe.js is loaded from the Stripe server, so tick number two. Three is where I'm less sure, however the input fields don't have 'name' attributes which looks reassuring.

So, from Stripe's guidance it seems the module is SAQ-A compliant, but I would really appreciate input from someone who knows more than me about how it works.

robertmaynord’s picture

I appreciate your continuing research on the SAQ-A question. The stripe response is helpful. A few thoughts I had:

1) In the PCI documentation it specifically mentions iframes as just about the only way to qualify for SAQ-A. When I look at the chrome development tool display for my Ubercart web site, it clearly shows that UC Stripe is using an iframe --- "iframe name="stripeXDM_default653779_provider"

2) It does seem odd that the Drupal Commerce Stripe module is not SAQ-A compliant. Not sure on that one.

3) The Stripe situation reminds me a little bit of the Square card reader. Square card readers are no where near SAQ-A compliant, and if something goes wrong, Square takes on the responsibility. Square users have never heard of PCI compliance , yet Square is owned by VISA! In the case of Stripe, they seem to be going with the "iframe rules", but haven't (so far) pushed the compliance issue very hard on their customers. For example, there is an "official" SAQ-A reporting form, but Stripe doesn't seem to mandate it, at least I haven't heard from them so far asking where mine is. In contrast, my previous bank and authorize.net wanted full documentation and scanning or they would close my account.

Just food for thought....

rfay’s picture

Status: Active » Fixed

Every effort has been made to achieve all the compliance that Stripe can offer, which is pretty good.

@mattkevan, yes, #1, #2, and #3 should be totally fine. The HTML "name" attribute is explicitly removed from the form elements to prevent any credit card info from being accidentally submitted. The entire form is disabled if Javascript is not available.

Marking this fixed, but any further conversation is fine.

As far as why Commerce Stripe doesn't claim PCI Compliance... perhaps it uses the PHP API for everything (as the 1.x versions of uc_stripe did) and therefore has no compliance at all.

Thanks for the important questions!

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

RaySilver’s picture

Hi,

I believe there is some confusion or misleading information here.. at least it seems that way to me. On the module page it says "On a properly configured site and server with https configured, Ubercart with uc_stripe 7.x-2.x and 8.x-2.x should be PCI SAQ-A compliant since no credit card information passes through your server at all. Further discussion and details are in this issue"

it is saying "should be PCI SAQ-A complaint" but it is not. I'm not sure if this is old information? On stripe's site it says if you use stripe.js AND elements or if you use checkout then it is. I've installed and configured this module and it's not using elements. Further, I reached out to stripe and got them to take a look at my setup and they verified that it is does not meet the requirements and would not qualify for SAQ-A. Here's the response directly from stripe:

"I've taken a look over your test transactions for your account, as you've yet to go live. If these transactions are indicative of what your live transactions will look like, then it appears your current integration is using Stripe.js v2.

Stripe.js v2 is not eligible for the simplest form of PCI validation, Self-Assessment Questionnaire A (SAQ A)."

So back to the drawing board. Is there another module that does use Stripe.js and Elements or one that uses checkout.js? Or is this module being updated so that it uses elements or will it ever?

Thanks for any and all feedback.

rfay’s picture

Hmm, this hasn't been actively changed in some time, but Stripe.js v2 certainly was considered compliant by them at last touch. It would be helpful if you provide links for the assertions to the contrary. And contributions are welcome.

RaySilver’s picture

Hi,

Thanks for the response. Well I have a dozen emails back and forth from them indicating it's not and what would qualify for SAQ-A. Here's a reference to it on this page https://stripe.com/docs/security As you can see Strip.js v2 which is being used by this module would not qualify for SAQ A but SAQ A-EP. The 500+ sites listed using this at some point may encounter a big surprise :) I would love to contribute to get this module up to specs but unfortunately do not have enough drupal / ubercart skills to do so or there would already be a patch attached here. It's kind of disheartening to have a platform but then one of the most necessary elements such as credit card processing that would qualify for SAQ-A is non-existent really.. I've looked at pretty much all there is and none of them are up to par or safe to use, with the exception of PayPal checkout well for Drupal 7 & Ubercart at least.

RaySilver’s picture

Hello,

I'm wondering if there's any followup, answers or comments on the issue I brought up?

Thank you!

rfay’s picture

I don't think there's anybody actively maintaining this; I haven't had a site using it for a few years, so am not paying any attention. If you're interested in stepping up to maintaining it, and you think you can do that for a while, I'll grant you privileges.

robertmaynord’s picture

Well, I wish I had the skills to work on it. I use it, and I know there were some folks at the Backdrop CMS talking about it. One person was planning on porting it to Backdrop...

RaySilver’s picture

Hi rfay,

Well .. as I had mentioned in my previous message.. if I could have I would have and wouldn't be here seeking help :) I would just fix it and upload it for everyone to use. I'm not clear as to what you mean "I haven't had a site using it" are you saying out of your personal clients nobody is using Drupal 7, Ubercart 3 and stripe? Or are you saying your not using it on any of your own sites? It's showing there's 809 sites using this module and from the description which states "should be PCI SAQ-A compliant" is incorrect.. it is not. At any rate.. kind of stuck here to only be able to use paypal which not everybody is happy with.. and trying to port an ubercart to drupal commerce seems like is not even worth the time since most of the things will not get moved over.. one might as well just start from scratch. I'm not sure who's the maintainer is for the module? is it you? I'm sorry i'm just not well versed enough to know all these things. If it's you.. are you willing to update this so that it's using stripe.js and elements so then it would be SAQ-A compliant? I'm willing to chip in and pay for the work.. perhaps other people are too? Is there a possibility for that to discuss?

rfay’s picture

I don't have any clients using this (I really don't have any clients any more). I don't use this, don't have any recent experience with it. Haven't used Stripe in at least 3 years.

The way these things work is that people have to be interested and take ownership, and if they don't they die.

Ubercart itself hasn't reached beta status for D8, so probably won't survive in D8.

All I'm saying is that somebody who is actually using uc_stripe is going to have to pick up the ball and maintain this module, or it will just die. I changed the status to "Seeking maintainer". It's possible I should change it to abandoned if nobody picks it up soon.

RaySilver’s picture

Got it. Thanks for the explanation! By not answering what I asked.. I'm assuming you're not interested in updating it for pay. Thanks for leaving it at seeking maintainer perhaps somebody that's interested in what I said will see it and reply.

Ubercart D8. Yes I've realized that.. and I guess anybody that is using ubercart now.. at some point (which will happen) they need to update and upgrade will not be able to.. since it's not worth the time and effort port over to D8 & commerce since you can't move over quite a few important data.. then we'll have to go elsewhere.

Thanks for taking time to reply.

robertmaynord’s picture

Well --- it is indeed a challenging situation. Regarding "we'll have to go elsewhere", Ubercart has been ported over to Backdrop, and supposedly works fine. They say that porting D7 modules to Backdrop is very easy - it was built for that. Backdrop is actually a bunch of Drupal people - they do presentations at many of the Drupal conferences. Since D8 has moved more to the large institutional setting, Backdrop is trying to appeal to the small business crowd.

Here's an idea: what if the Ubercart Stripe module was ported to Backdrop, and then someone in the Backdrop community was hired to update it? That way, you (and I) might be able to fairly easily transfer our D7 Ubercart sites to Backdrop and keep rolling. (We would have some breathing room as far as the D7 to D8 change because Backdrop will continue to upgrade independently.) They even have a list of "Contractors for hire" on the Backdrop web site.....https://backdropcms.org/support/resources (The Paypal Payment module has been ported over, but I don't know any details.) They also have a forum where ideas such as this can get discussed....

I know this idea is a stretch, but so far I have not been able to convince myself to use Wordpress.....

rfay’s picture

Backdrop should be easy, and should be a good long-term solution. The problem is maintenance for Ubercart and uc_stripe. You really have to have somebody that is using it and has the capability to maintain. As we've seen here, Stripe changes a lot over time, and the module has to be maintained to keep up.

RaySilver’s picture

@16robertmaynord - I had taken a "quick look" at backdrop.. it just looked so young and not mature yet and didn't really see a lot of development on the eCommerce section.. I could be wrong.. I think you have a good idea.. BUT what I dread is taking on something just to find out it wasn't well thought out and nothing works.. (talking about taking an existing site and porting it over there) I inherited this drupal site and it was on d6. Though I would not call myself a full on developer, I have been in the eCommerce and IT world for over 30 years and have used many platforms.. it took me nearly FOUR months just to be able to take D6 to D7.. NOTHING worked.. starting from scratch.. upgrading.. when a site is old and has lots of data and modules.. and most of them don't function or break when you're trying to move forward it almost becomes a waste of time to do and it's better to just start from scratch :) which in itself its lots of work too. This wasn't only me.. I read countless posts from many different people claiming the exact same thing.. saying they've been developers for years and they have never used a platform/framework that has given them so much pain.
Regardless.. I think we can try to collaborate and do a test run to see if what you're suggesting is possible and if it doesn't look like it would be a waste of time.. we can round up a few more people and that way it would be easier on everybody to pitch in to get development done. let me know if you're interested (or anybody else reading this) then we can exchange contact info.

Honestly.. (this is just my viewpoint) I think the problem is that EVERYBODY tries to do EVERYTHING to make everything and everybody happy but then at the end they fail and everybody is unhappy. after using drupal for 3-4 years now.. I see it's strengths and it's a very powerful platform where you can do a quit bit of fancy stuff you can't elsewhere.. but it wasn't really intended for ecommerce at the get to.. then WHY add that functionality??? As a business owner when I run a site.. put aside my IT skills.. I am trying to run a site and a business not spend 90% of my time chasing things that never work properly and when you get it to work the following week something is outdated. so that's just my opinion.. I see it happen on different platforms and I get it.. everybody's time is valuable and time is scarce so they can't worry about everything. But as a site operator.. if I'm trying to sell stuff but then I can't offer my customers a safe way to use their credit card.. who cares if I have the power to do a million things drupal can do?? :)

robertmaynord’s picture

Ray:

Thanks for the response! It appears that we are in a difficult spot - for all the reasons you mention. You are correct, Backdrop doesn't have a large amount of development for ecommerce. It looks like Drupal 8 will only have Drupal Commerce. A small business is in the middle - not needing an enterprise solution, but still needing a commerce environment.

The only thing I can think of is this - maybe one of us could post the Ubercart Stripe idea on the Backdrop forum and see if we get a response. Maybe someone else will see the merit. If there is no interest or response, it might be a sign that the project would be an up-hill climb.

What do you think?

andraeray’s picture

Please see this related ticket. #2959726: Upgrade to stripe v3 to achieve SAQ A PCI compliance

Version 7.x-3.x is SAQ A. It's based on Stripe Elements and Payment Intent.