— No Results

    Integration Security Guide

    Ensure PCI compliance and secure communications between your customer and your server.

    Anyone involved with the processing, transmission, or storage of card data must comply with the Payment Card Industry Data Security Standards (PCI DSS). Stripe has been audited by an independent PCI Qualified Security Assessor (QSA) and is certified as a PCI Level 1 Service Provider. This is the most stringent level of certification available in the payments industry.

    PCI compliance is a shared responsibility and applies to both Stripe and your business. When accepting payments, you must do so in a PCI compliant manner. The simplest way for you to be PCI compliant is to never see (or have access to) card data at all. Stripe makes this easy for you as we can do the heavy lifting to protect your customers’ card information. You can simplify your PCI compliance as long as you:

    Validating your PCI compliance

    All Stripe users must validate their PCI compliance annually. Most users can do this with a Self-Assessment Questionnaire (SAQ) provided by the PCI Security Standards Council. The type of SAQ depends on how you integrated Stripe and which of the methods below you use to collect card data. Certain methods may require you to upload additional PCI documentation to us. If this is necessary, we’ll notify you in the Dashboard. If you’re using more than one of the methods below, there’s no need to upload multiple SAQs. We can determine which SAQ covers all the ways you’ve integrated with Stripe.

    If you’re not sure how to prove that your business is PCI compliant (e.g., your integration was built by a third-party), Stripe determines what documentation might be required based on how you’re processing payments and provides this information in your account’s compliance settings.

    For users that have developed their own integration and are using either Checkout or Elements to collect card details from customers, you are eligible for the simplest method of PCI validation: SAQ A. Stripe automatically creates a combined SAQ A and Attestation of Compliance (AoC) for you, available for you to download in your account’s compliance settings, and no action is required on your part to submit further proof of your PCI compliance.

    This is possible because Checkout and Elements host all form inputs containing card data within an IFRAME served from Stripe’s domain—not yours—so your customers’ card information never touches your servers.

    Stripe’s mobile SDK development and change control is done in accordance with PCI DSS (requirements 6.3 - 6.5) and is delivered via our PCI validated systems. As such, we advise our users to rely on our 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. If you only use our mobile SDKs or an Elements-based WebView, you can inform your PCI auditor that card numbers pass directly from your customers to Stripe.

    Should you do otherwise, such as writing your own code to send card information to the Stripe API, you may be responsible for additional PCI DSS requirements (6.3 - 6.5) and not be eligible for an SAQ A. In this case, we’d suggest you reach out to a PCI Qualified Security Assessor (QSA) to determine how best to validate your compliance according to the current guidance from the PCI Council.

    If your application is intended for your customers to enter their information on their own devices, then you qualify for SAQ A. If your application is used to accept card information for multiple customers on your device (e.g., a point of sale app), consult a PCI Qualified Security Assessor (QSA) to learn how best to validate your PCI compliance.

    The PCI Security Standards Council has published a series 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 the simplest PCI validation method. We’ve designed both Checkout and Elements with these changes in mind so that you can continue to validate using SAQ A without losing much of the flexibility and customizability of a form hosted on your website.

    You can refer to our Elements migration guide to learn how to migrate your checkout flow to Elements. If you continue to use Stripe.js v2, you’ll be required to upload your SAQ A-EP annually to prove your business is PCI compliant. As this is more complex, we recommend you work with SecurityMetrics if you require additional assistance in completing your SAQ A-EP.

    Manually creating card payments through the Dashboard is meant only for exceptional circumstances. This method should not be how you routinely processing payments—your customers should be entering their card information into a suitable payment form or mobile application.

    When card information is manually entered into the Dashboard, we cannot verify that it’s being kept secure outside of Stripe. You are then responsible for ensuring the protection of card data in accordance with the PCI compliance requirements. You’ll be required to upload your SAQ C-VT annually to prove your business is PCI compliant.

    To be eligible for the simplest form of PCI validation, SAQ A, only collect card information using Checkout, Elements, or our mobile SDKs. 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.

    We strongly discourage passing card information directly to Stripe’s API as it means your integration is directly handling card information. Even if you do not store any payment information, we can only help simplify PCI compliance if you’ve integrated with Checkout, Elements, or our mobile SDKs.

    If you continue to send card details directly to our API, you’ll be required to upload your SAQ D annually to prove your business is PCI compliant. SAQ D is the most onerous of all the SAQs, with over 40 pages of requirements you must implement to remain PCI compliant. We highly recommend you migrate to client-side tokenization of card information to substantially reduce the scope of your PCI compliance.

    In addition to the significant PCI burden that this method places on you, it is not supported by Radar, our fraud prevention toolset. Radar’s functionality (e.g., risk evaluation, rules, etc.) is only available when using any of our methods of client-size tokenization.

    For users that exclusively collect card data through a Connect platform (e.g., Squarespace), we can determine that the platform has provided the necessary PCI documentation. Stripe automatically creates a combined SAQ A and Attestation of Compliance (AoC) for you, available for you to download in your account’s compliance settings, and no action is required on your part to submit further proof of your PCI compliance.

    Using TLS and HTTPS

    TLS refers to the process of securely transmitting data between the client—the app or browser that your customer is using—and your server. This was originally performed using the SSL (Secure Sockets Layer) protocol. However, this is outdated and no longer secure, and has been replaced by TLS. The term “SSL” continues to be used colloquially when referring to TLS and its function to protect transmitted data.

    Payment pages must make use of a modern version of TLS (e.g., TLS 1.2) as it significantly reduces the risk of you or your customers being exposed to a man-in-the-middle attack. TLS attempts to accomplish the following:

    • Encrypt and verify the integrity of traffic between the client and your server
    • Verify that the client is communicating with the correct server. In practice, this usually means verifying that the owner of the domain and the owner of the server are the same entity. This helps prevent man-in-the-middle attacks. Without it, there’s no guarantee that you’re encrypting traffic to the right recipient.

    Additionally, your customers are more comfortable sharing sensitive information on pages visibly served over HTTPS, which can help increase your customer conversion rate.

    If need be, you can test your integration without using HTTPS, and enable it once you’re ready to accept live charges. However, all interactions between your server and Stripe must use TLS 1.2 (i.e, when using our libraries).

    Setting up TLS

    A digital certificate—a file issued by a certification authority (CA)—is needed in order to use TLS. When installed, this certificate assures the client that it’s really communicating with the server it expects to be talking to, not an impostor. You should get a digital certificate from a reputable certificate provider, such as:

    Certificates can vary in cost, depending on the type of certificate and provider. Let’s Encrypt is a certificate authority that provides certificates for free.

    Conceptually, setting up TLS is very straightforward: a certificate is purchased from a suitable provider, and then your server is configured to use it. The actual process does tend to be somewhat complex, and we recommend you follow the installation guide of the provider you use.

    As TLS is a complex suite of cryptographic tools, it’s easy to miss a few details. We recommend using the SSL Server Test by Qualys SSL Labs to make sure you have everything set up in a secure way.

    Additional security considerations

    It can be a security risk to include JavaScript from other sites as your security becomes dependent on theirs. If they’re ever compromised, an attacker may be able to execute arbitrary code on your page. In practice, many sites make use of JavaScript for services like Google Analytics, even on secure pages. Nonetheless, it’s something to be aware of, and ideally minimize.

    If you’re making use of webhooks, we recommend using TLS for the endpoint to avoid traffic being intercepted and the notifications altered (sensitive information is never included in a webhook event).

    While complying with the Data Security Standards is important, it shouldn’t be where you stop thinking about security. Some good resources to learn about web security are:

    Out-of-scope card data that you can safely store

    Stripe returns non-sensitive card information in the response to a charge request. This includes the card type, the last four digits of the card, and the expiration date. This information is not subject to PCI compliance, so you are able to store any of these properties in your database. Additionally, you can store anything returned by our API.

    Content Security Policy

    If you have deployed a CSP, the full set of directives that Stripe.js requires are:

    • connect-src, https://api.stripe.com
    • frame-src, https://js.stripe.com
    • script-src, https://js.stripe.com

    If you are loading web fonts for elements via a CSS file, its URL must be allowed by your connect-src CSP directive.

    Further reading

    Congrats! You can now accept card payments with Stripe. You may want to learn more about receiving funds from Stripe and managing your account, handling failed or disputed payments, or making use of recurring billing: