Integration Security Guide

    Ensure PCI compliance and secure communications between your customer and your server by using these best practices. If you need help after reading this, search our documentation or check out answers to common questions. You can even chat live with other developers in #stripe on freenode.

    Anyone involved with the processing, transmission, or storage of credit card data must comply with the Payment Card Industry Data Security Standards (PCI DSS). Stripe makes this easy for you to do, and you can set up a fully PCI-compliant integration by taking the following steps:

    • Serve your payment pages securely using Transport Layer Security (TLS) so that they make use of HTTPS
    • Use Checkout, Elements, Stripe.js, or our mobile libraries to accept payment information, which is securely transmitted directly to Stripe’s servers without it passing through your servers

    Using TLS

    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 SSL 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.

    PCI DSS guidelines

    All Stripe users must be compliant with the PCI Data Security Standards (PCI DSS). If you’re using either Stripe Checkout or Stripe Elements to collect payment details, you are eligible for the simplest PCI validation method: Self-Assessment Questionnaire A (SAQ A). Elements and Checkout host all form inputs containing card data within an IFRAME served from Stripe’s domain.

    As long as you serve your payment pages over TLS, and use either Checkout or Elements as the only way of handling card information, Stripe automatically creates a combined SAQ A and Attestation of Compliance (AOC) for you. This pre-filled document is available in your account’s compliance settings.

    If you store, process, or transmit card data directly, you are responsible for following PCI DSS guidelines and validating using payment brand rules. We’ll prompt you through the Dashboard to upload any applicable PCI self-assessment forms.

    Out-of-scope card data

    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.

    Content Security Policy

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

    • connect-src:
    • frame-src
    • script-src

    Mobile SDKs

    Stripe’s mobile SDK software 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 Stripe Elements in a Webview, to be eligible for the simplest form of PCI validation, Self-Assessment Questionnaire A (SAQ A). If you only use Stripe SDKs or a Webview, you’ll be able to tell your PCI auditor “card numbers pass directly from our customers (the cardholder) to Stripe”.

    If you plan to do otherwise, such as writing your own code to send card numbers to the Stripe API, you may be responsible for additional PCI DSS requirements (6.3 - 6.5) and you may 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 PCI Council guidance.

    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/sensitive 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: