Do I Need PCI Compliance with Stripe? – Question & Answer
Do I Need PCI Compliance with Stripe?
Question: Do I Need PCI Compliance with Stripe?
Answer: Yes, you do, but you need to qualify exactly what your question means when asking “do I need PCI compliance with Stripe.” Let’s dig a little deeper to answer your question, providing you the necessary guidance in becoming compliant with the Payment Card Industry Data Security Standards (PCI DSS) mandates.
First and foremost, let’s discuss what Stripe is, and how using Stripe can assist your organization in becoming PCI DSS compliant.
What is Stripe?
Stripe is essentially a company that has developed a software platform for payment processing; a platform that connects all relevant parties in the overall buying process. Buyers, sellers, developers – and more – they’re all a part of the Stripe software platform for payment processing. More specifically, Stripe touts their platform as “One Solution to Cover your Payment Needs”, effectively providing the following services relating to the full payment lifecycle for cardholder data (i.e., credit cards):
- Settle and Reconcile
So, to answer the question “Do I need PCI compliance with Stripe,” this would be determined by exactly what services you are using from them. So, let’s take a look at the following credit card services offered by Stripe:
Per Stripe, “Checkout is an embeddable payment form for desktop, tablet, and mobile devices. It works within your site—customers can pay instantly, without being redirected away to complete the transaction.” What’s great about “Checkout” is that it can reduce – but not entirely eliminate – your PCI DSS reporting requirements. Specifically, “Checkout” securely accepts a customer’s payment details and directly passes them to Stripe’s servers. Stripe then returns a token representation of those payment details, which can then be submitted to a server for use. Therefore, with Stripe, sensitive cardholder data does not hit your server, ultimately minimizing (but again, not eliminating) one’s PCI compliance reporting requirements.
The Stripe “Checkout” service essentially takes care of some of the most demanding aspects and parts of PCI compliance, such as the reporting requirements, if you store cardholder data. Merchants using Stripe Checkout can therefore greatly reduce many aspects of PCI DSS compliance reporting, such as tests in Requirement 3, and other requirements. The key is to NOT store cardholder data, and if you don’t, then yes, you can reduce your footprint in terms of PCI DSS compliance reporting. You can therefore use SAQ-A if you’re using “Checkout”, but you’ll still need to obtain PCI policies and procedures for SAQ-A, for which we offer, so download the pcipolicyportal.com SAQ-A packet today and get started!
Stripe’s mobile SDK development and change control is done in accordance with PCI DSS (requirements 6.3 – 6.5), thus delivered through Stripe’s PCI DSS validated architecture and supporting systems. As such, Stripe advises customers to rely on their official SDKs for iOS or Android, or to build a payment form with Elements in a WebView, to be eligible for the simplest form of PCI validation: SAQ A.
Bottom line: If you only use Stripe’s mobile SDKs or an Elements-based WebView, this essentially means that cardholder data passes directly from customers to the Stripe platform.However, if you decide to develop your own code and then transmit cardholder data to the Stripe API, you may be responsible for additional PCI DSS requirements (6.3 – 6.5), which would require compliance with SAQ A-EP or SAQ-D. And lastly, if your application is intended for your customers to enter their information on their own devices, then you qualify for SAQ A. pcipolicyportal.com offers industry leading SAQ policy packets for SAQ-A, SAQ A-EP, SAQ-D, and more.
The PCI DSS Security Standards Council has put forth a number of changes to eligibility requirements for SAQ A. These require that businesses use input fields hosted by a payments provider in order to be eligible for SAQ A, which is by far the quickest, easiest, and simplest method for PCI DSS compliance. Luckily, Stripe has designed both Checkout and Elements with these changes in mind so that you can continue to validate using SAQ A, however, for Stripe.js v2, you’ll need to work a little harder in terms of PCI DSS compliance.
Bottom line, if you continue to use Stripe.js v2, you’ll thus be required to perform an actual SAQ A-EP annually to prove your business is PCI compliant. This is a much more complex endeavor, so working with a proven and trusted PCI DSS consultant, such as the professionals at pcipolicyportal.com, is highly recommended.
Please note that Stripe reminds users of their platform that manually creating card payments through the Dashboard is meant only for exceptional circumstances. This method should essentially never be how you routinely process payments, specifically, your customers should be entering their card information into a suitable payment form or mobile application.
Keep in mind that when cardholder data is manually entered into the Dashboard, Stripe ultimately cannot verify that it’s being kept secure outside of Stripe, therefore customers are responsible for ensuring the protection of cardholder data in accordance with the PCI DSS compliance requirements. Ultimately, merchants will be required to perform an SAQ C-VT annually for purposes of PCI DSS compliance.
Note that to be eligible for the simplest form of PCI validation, SAQ A, you are only allowed collect card information using Checkout, Stripe.js and Elements, or the mobile SDKs. Additionally, you can also make use of a third-party integration, such as an invoicing service or online marketplace, to ensure that you’re processing charges in a secure manner.
Directly to the API
Stripe discourage passing card information directly to Stripe’s API as it means one’s integration is directly handling card information. Even if merchants do not store any cardholder data, Stripe only help simplify PCI compliance for merchants if they have integrated with Checkout, Elements, or Stripe’s mobile SDKs.
If you continue to send credit card information directly to your API, you’ll ultimately be required to upload your SAQ D annually for purposes of proving PCI DSS compliance. Keep in mind that SAQ D is the most comprehensive and time-consuming of all the SAQs, with over 50 + pages of requirements you must implement for becoming – and remaining – PCI DSS compliance. Thus, pcipolicyportal.com recommends migrating to a client-side tokenization of card information to substantially reduce the scope of your PCI DSS compliance.
In addition to the significant PCI burden that this method places on businesses (specifically, merchants) it is not supported by Radar, which is Stripe’s fraud prevention toolset. Radar’s functionality (e.g., risk evaluation, rules, etc.) is only available when using any of Stripe’s methods of client-size tokenization.
Why pcipolicyportal.com when it comes to PCI Compliance for Stripe?
Simple? Because whatever the level and type of PCI DSS compliance you need to comply with when using stripe – from a simple SAQ A to a full-blown Level 1 onsite assessment by a PCI-QSA, pcipolicyportal.com has the documentation you need. We are the world’s leading provider of high-quality, professionally developed PCI policies, procedures, forms, checklists, and so much more.
If you want to save hundreds of hours and thousands of dollars on PCI DSS compliance, then it starts by utilizing our award-wining PCI policy toolkits. Visit pcipolicyportal.com today to learn more about the dozens of PCI policy toolkits and templates that are available for instant download today.
Using stripe for payment processing for transactions? Great, because it’s a highly secure tool, but don’t forget the importance of documentation for becoming compliant with the Payment Card Industry Data Security Standards (PCI DSS).
With documentation being one of the most time-consuming mandates for PCI compliance, you’ve now got a company that offers industry specific PCI Policy Toolkits, along with the following PCI SAQ Policy Packets:
- SAQ A
- SAQ A-EP
- SAQ B
- SAQ B-IP
- SAQ C
- SAQ C-VT
- SAQ P2PE-HW
- SAQ D for Merchants
- SAQ D for Service Providers