Security at Stripe

Learn about security at Stripe.

Stripe has been audited by a PCI-certified auditor and is certified to PCI Service Provider Level 1. This is the most stringent level of certification available in the payments industry. To accomplish this, we use the best-in-class security tools and practices to maintain a high level of security at Stripe.

HTTPS and HSTS for secure connections

Stripe forces HTTPS for all services using TLS (SSL), including our public website and the Dashboard.

  • Stripe.js is served only over TLS
  • Stripe’s official libraries connect to Stripe’s servers over TLS and verify TLS certificates on each connection

We regularly audit the details of our implementation, including the certificates we serve, the certificate authorities we use, and the ciphers we support. We use HSTS to ensure that browsers interact with Stripe only over HTTPS. Stripe is also on the HSTS preloaded lists for both Google Chrome and Mozilla Firefox.

Encryption of sensitive data and communication

All card numbers are encrypted at rest with AES-256. Decryption keys are stored on separate machines. None of Stripe’s internal servers and daemons can obtain plaintext card numbers but can request that cards are sent to a service provider on a static whitelist. Stripe’s infrastructure for storing, decrypting, and transmitting card numbers runs in a separate hosting environment, and doesn’t share any credentials with Stripe’s primary services (API, website, etc.).


We have two PGP keys to encrypt your communications with Stripe, or verify signed messages you receive from us. Which key you use depends on the information you need to transmit:

If you’re unfamiliar with PGP, check out GPG, and start by importing a public key.

Vulnerability disclosure and reward program

Stripe maintains a private, invite-only bug bounty program, with the assistance of HackerOne. Invited researchers are eligible for a payment. While those who were not invited to the program may still submit a security bug or vulnerability to Stripe via HackerOne, such reports may not be eligible for a payment. To learn more about obtaining an invitation to the private bug bounty program, please see HackerOne’s website on invitations.

By submitting a security bug or vulnerability to Stripe via HackerOne, you acknowledge that you have read and agreed to the Program Terms and Conditions set forth below. By providing a submission, you agree that you may not publicly disclose your findings or the contents of your submission to any third parties without Stripe’s prior written approval.

Submit Vulnerability via HackerOne

You are about to submit a report to Stripe via HackerOne. Detailed and quality reporting is important to Stripe. You must include a working Proof of Concept.

Submit a vulnerability here.

Program Terms and Conditions

Your participation in our program is voluntary and subject to the below terms and conditions:

  • You need to show that you could exploit a vulnerability, but you must not actually exploit it. You must not: access, modify, copy, download, delete, compromise or otherwise misuse others’ data; access non-public information without authorization; degrade, interrupt or deny services to our users; and/or incur loss of funds that are not your own.
  • If you are performing research, please use your own accounts and do not interact with other users’ accounts or data.
  • You must not leverage the existence of a vulnerability or access to sensitive or confidential data to make threats, extortionate demands, or ransom requests.
  • Your testing must not violate any applicable laws or regulations.
  • You are prohibited from participating in the program if you are a resident of any U.S. embargoed jurisdiction, including but not limited to Iran, North Korea, Cuba, the Crimea region, and Syria; or if you are on the U.S. Treasury Department’s list of Specially Designated Nationals or the U.S. Department of Commerce Denied Person’s List or Entity List. By participating in the program, you represent and warrant that you are not located in any such country or on any such list.
  • By providing a submission, you agree that you may not publicly disclose your findings or the contents of your submission to any third parties without Stripe’s prior written approval.
  • You will be responsible for any tax implications related to any bounty payment you receive, as determined by the laws of your jurisdiction.
  • You must be 18 years of age or older.
  • You must not be employed by Stripe or any of its affiliates. You must also not be an immediate family member of someone employed by Stripe or any of its affiliates.
  • By reporting a bug, you grant Stripe and its affiliates a perpetual, irrevocable, worldwide, royalty-free license to use, copy, adapt, develop, create derivative work from, or share your submission for any purpose. You waive all claims, including breach of contract or implied-in-fact contract, arising out of your submission.
  • By reporting a bug, you agree to allow HackerOne to share with Stripe the personal information that you provide to HackerOne relating to your tax forms so Stripe can perform compliance checks.
  • Whether to provide a payment for the disclosure of a bug and the amount of the payment is entirely at our discretion, and we may cancel or modify the program at any time.
  • Only the first, responsibly-disclosed submission of a vulnerability instance will be marked as valid, any subsequent reports will not be eligible for our program.

Ineligible Vulnerabilities

Furthermore, Stripe does not consider the following to be eligible vulnerabilities:

  • Denial of service
  • Reports of spam
  • Social engineering
  • Self-XSS
  • Content/text spoofing
  • Unconfirmed reports from automated vulnerability scanners
  • Disclosure of server or software version numbers
  • Hypothetical sub-domain takeovers without supporting evidence
  • Session invalidation or other improved-security related to account management when a credential is already known (e.g., password reset link does not immediately expire, adding MFA does not expire other sessions, etc.)
  • Perceived security weaknesses without concrete evidence of the ability to compromise a user (e.g., missing rate limits, missing headers, etc.)
  • Reports exploiting the behavior of, or vulnerabilities in, outdated browsers
  • User/merchant enumeration
  • Best practice reports without a valid exploit (e.g. use of “weak” TLS ciphers)

In Scope

Valid reports for assets in the following domains are eligible for reward:

  • *
  • *

Valid reports of critical vulnerabilities for assets in the following domains are eligible for reward:

  • *
  • *

Out of Scope

Reports for assets in the following domains are not eligible for reward: