PCI Compliance

[Russell Glissmann]

I'm aware that Stripe themselves are PCI compliant.  However, from doing a little research it appears that the PCI regulations are changing.  What this may mean is that even though we use Stripe such that the credit card number is never held on one of our servers, we are required to submit to a PCI audit.  I admit I have not thoroughly read the PCI documentation, but surly someone else has a better knowledge of this subject than I do.

Thanks

Russ 

[James Stewart]

In addition to not storing certain CC information, you also need to ensure that certain CC details aren't transmitted through your servers. Stripe allows for this, but it depends upon how it's implemented in a particular environment.

--
James Stewart
CEO / Founder / President
TekStorm Inc.

Sent via Google Apps Gmail from my Samsung Galaxy S4 on the Fido network.

--
You received this message because you are subscribed to the Google Groups "Stripe API Discussion" group.
To post to this group, send email to api-d...@lists.stripe.com.
Visit this group at http://groups.google.com/a/lists.stripe.com/group/api-discuss/.

To unsubscribe from this group and stop receiving emails from it, send an email to api-discuss...@lists.stripe.com.

[Darragh Buckley]

Hi James, Russ,

Thanks for reaching out. We've got some documentation on what you'll
need to do to stay PCI compliant if you're using Stripe here:

https://support.stripe.com/questions/do-i-need-to-be-pci-compliant-what-do-i-have-to-do

Everyone who accepts payments has to be PCI compliant. Stripe makes
this easy for you however.

If you serve your payment page over SSL and solely accept card details
using Stripe.js or Checkout, you've kept the PCI-sensitive information
(and the regulations that go with it) away from your servers.

Beyond that, we'll ask you some questions on how you handle credit
card data once you've been accepting payments. The questions are all
from the standard Payment Card Industry Security Questionnaires [0]
and are to confirm things like you're aware to not keep paper copies
of card info etc. You'll be prompted for these through your Dashboard.

If you or anyone else has any questions about this, feel free to email
us at sup...@stripe.com (we try to keep this mailing list primarily
for API discussion).

Best,

-Darragh

0. https://www.pcisecuritystandards.org/merchants/self_assessment_form.php

[Mike Bellini]

In order to implement third party fraud services (like maxmind or kount), which require the credit card BIN, if the merchant were to capture the truncated credit card and pass to the server, would that then bring the merchant in PCI compliance audits?

Truncating is referenced in the PCI compliance as not capturing a full PAN, if the credit card number is 4242424242424242, then Truncating would provide 424242xxxxxx4242.
I assume capturing just the BIN (first 6) would not be an issue?

And lastly, can Stripe.js be updated so
1) One of the token parameters is the BIN? 
2) The card or charge object make the truncated and/or BIN available?

Stripe only makes the last4 digits available to the merchant, which is pretty non-effective in integrating with a fraud service.

Thanks
-Mike

[Henri Watson]

Even though you use Stripe, you’re still liable for PCI SAQ A level compliance ("Card-not-present merchants, all cardholder data functions outsourced").

The problem is that PCI SAQ requires that the “merchant does not store any cardholder data in electronic format” (PCI SAQ A).

As the PAN is a part of the cardholder data, storing it would push you up to PCI SAQ D compliance, which carries additional validation requirements (you have to complete "a passing vulnerability scan with a PCI SSC Approved Scanning Vendor” and answer a longer SAQ).

The PCI rules are rather complicated so you might want to verify this with Stripe Support or with someone who’s actually accredited by PCI.

However, if I’m right, this is more of a reason for Stripe to provide the BIN in the API responses as it would prevent the need for PCI SAQ D validation.

Cheers,

Henri Watson.

[Mike Bellini]

Hi Henri, thanks for your response.  I concur, having Stripe provide the BIN via the API call is the most preferred way. 

Stripe folks, is there a more formal way to request enhancements?  Lacking the BIN, how would a merchant be able to integrate with third party services who would make use of the BIN for fraud checks, without bringing themselves into a more complicated audit process.  After all, isn't one of the reasons to use Stripe to remove the complication with PCI compliance?

Thanks
-Mike

[Herb Jellinek]

Would the mere existence of such a get-BIN capability on the Stripe API force all who use the Stripe API into some more stringent category of PCI compliance?

As an alternative, what if Stripe connected directly to the (presumably PCI-compliant) anti-fraud service(s), passing them the BIN and whatever else they need, and only provided Stripe API clients the ability to obtain validation results?  Just a thought.

Like Russ, I have not read the PCI docs thoroughly, so I may be speaking from ignorance.  I do like the insulation from full-bore PCI compliance that Stripe provides and would not like to lose it.

        Herb

[Mike Bellini]

The BIN by itself (first 6 characters of a credit card) will not bring you into compliance.  It is not considered the PAN.  In addition, using the information in-memory is usually not problematic, it is when the information is stored.  Even then, storing the BIN in the database, or even the fully truncated (aka masked) is not considered the full PAN and is safe to store.

[Leigh McCulloch]

Hi James, Russ, Darragh,

PCI DSS v3 alters the impact of using a solution like stripe.js. While previously using stripe.js likely meant you only needed to satisfy the requirements in an SAQ A, the new SAQ A-EP is now more appropriate and brings the merchant's website hosting the payment form into scope of PCI. Stripe Checkout on the other hand uses an iFrame and so may be the wiser integration option since you will probably only need to satisfy the limited requirements on an SAQ A.

I'm interested to see if Stripe introduces any changes to stripe.js or a new middle ground between it and Stripe Checkout, that somehow reduce the scope back to the questions on the SAQ A.

Ref: https://www.pcisecuritystandards.org/documents/Understanding_SAQs_PCI_DSS_v3.pdf pages 3 & 5

Best regards,

Leigh