Sign in
An image of the Stripe logo
Create account
Sign in
Home
Payments
Business operations
Financial services
Developer tools
No-code
All products
Home
Payments
Business operations
Home
Payments
Business operations
Financial services
Developer tools
Support
Overview
Developer tools
    Get started
    Quickstarts
    Stripe Shell
    Stripe CLI
    Dashboard
    Stripe for Visual Studio Code
    Webhooks
    File uploads
    Error handling
    Security at Stripe
      Integration guide
      Request permissions
      Python library PGP key
    API
    API keys
    Upgrades
    Changelog
    Rate limits
    Automated testing
    Data Availability
    Expanding responses
    Domains and IP addresses
    Search
    Building With Stripe
    Prebuilt iOS UI
    Prebuilt Android UI
    Extensions
    Samples
    Checklist
    Feedback
SDKs
Sample projects
Videos
Stripe Apps
Stripe Connectors
Partners
HomeDeveloper toolsSecurity at Stripe

Integration security guide

Ensure PCI compliance and secure customer-server communications.

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:

  • Use one of our recommended payments integrations to collect payment information, which is securely transmitted directly to Stripe without it passing through your servers.
  • Serve your payment pages securely using Transport Layer Security (TLS) so that they make use of HTTPS
  • Review and validate your account’s PCI compliance annually.

Validate 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 (for example, 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.

Requirement: SAQ D

We strongly discourage passing card information directly to Stripe’s API as it means your integration is directly handling card information. Even if you don’t 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. Migrate to client-side tokenization of card information if you want to substantially reduce the scope of your PCI compliance.

In addition to the significant PCI burden that this method places on you, it isn’t supported by Radar, our fraud prevention toolset. Radar’s functionality (for example, risk evaluation, rules, and so on) is only available when using any of our methods of client-side tokenization.

If you’re processing more than 6 million transactions per year with Visa or MasterCard, or more than 2.5 million transactions with American Express, or are otherwise deemed to be a Level 1 provider by any of the card networks, you’re not eligible to use a SAQ to prove PCI compliance. Payment brands require you to complete a Report on Compliance (RoC) to validate your PCI compliance annually.

Use 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 Secure Sockets Layer (SSL) 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 (for example, 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).

Set up TLS

Serve resources securely

You should make sure that any resources (for example, JavaScript, CSS, and images) are also served over TLS to avoid a mixed content warning being shown to your customers in their browser.

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:

  • Let’s Encrypt
  • DigiCert
  • NameCheap

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’ve everything set up in a secure way.

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:

  • OWASP
  • SANS
  • NIST

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 isn’t subject to PCI compliance, so you’re able to store any of these properties in your database. Additionally, you can store anything returned by our API.

Content Security Policy

If you’ve deployed a Content Security Policy, the full set of directives that Checkout and Stripe.js require are:

  • connect-src, https://checkout.stripe.com
  • frame-src, https://checkout.stripe.com
  • script-src, https://checkout.stripe.com
  • img-src, https://*.stripe.com

See also

  • Managing your Stripe account
  • Declines and failed payments
  • Disputes overview
Was this page helpful?
Questions? Contact us.
Watch our developer tutorials.
Check out our product changelog.
Powered by Markdoc
You can unsubscribe at any time. Read our privacy policy.
On this page
Validate your PCI compliance
Use TLS and HTTPS
Set up TLS
Security considerations
See also
Stripe Shell
Test mode
Welcome to the Stripe Shell! Stripe Shell is a browser-based shell with the Stripe CLI pre-installed. Login to your Stripe account and press Control + Backtick on your keyboard to start managing your Stripe resources in test mode. - View supported Stripe commands: - Find webhook events: - Listen for webhook events: - Call Stripe APIs: stripe [api resource] [operation] (e.g. )
The Stripe Shell is best experienced on desktop.
$