Stripe

Stripe Bug Bounty Program Terms and Conditions

The Stripe Bug Bounty Program Terms and Conditions ("Terms'') governs your participation in the Stripe Bug Bounty Program ("Program"). These Terms are between you and Stripe ("Stripe," "us," or "we"). By performing vulnerability research against Stripe's infrastructure, submitting any vulnerabilities to Stripe, or otherwise participating in the Program in any manner, you accept these Terms.

Program Eligibility

• Participants must be at least 18 years old.
• Stripe employees and contractors, as well as their family members, are strictly prohibited from participating in the Program, or sharing information with an external security researcher to bypass this prohibition.
• 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 in the U.S. Treasury Department's list of Specially Designated Nationals or the U.S. Department of Commerce Denied Persons 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.

Eligible Scope and Reward Groups

The exact structured scope, asset instructions, eligibility settings, and Scope and Reward Groups shown on HackerOne control when they differ from general descriptions in this Overview. Only assets marked eligible for submission may be reported through this Program. Only assets marked eligible for bounty participate in a reward group. Inclusion in scope does not by itself establish report eligibility, severity, or a guaranteed reward.

• Tier 1, Core production systems: Designated Stripe-operated production payment, financial, authentication, identity, and sensitive-data services, designated official applications, and the Stripe Apps platform.
• Tier 2, Supported ecosystem: Designated supported Stripe SDKs, developer tools, Stripe-maintained connector and integration packages, supported e-commerce extensions, and individually listed Stripe acquisitions.
• Tier 3, Utilities and public content: Designated maintained non-SDK open-source utilities and lower-impact public or static assets.

Wildcard control: The *.stripe.com wildcard and other unassigned wildcard or missing-asset reports use Tier 3 by default. A report may be elevated after validation when its evidence establishes a named Tier 1 or Tier 2 asset or direct Tier 1 production impact. Stripe may then add a recurring named asset to the structured scope. A researcher does not become entitled to Tier 1 treatment merely by labeling a wildcard report Critical.

Overlapping-scope control: When more than one in-scope target applies, HackerOne Triage and Stripe assign the most specific named target matching the demonstrated affected product or production boundary before applying the reward group. The target selected by the researcher at submission does not independently determine the tier.

Stripe Apps is Tier 1 only for vulnerabilities in Stripe-controlled Apps platform behavior. Third-party app, integration, or developer infrastructure is governed by the separately listed third-party scope and bounty settings.

Reward Ranges and Exceptional Tier 1 Outcomes

Standard award ranges by asset tier and severity are displayed in HackerOne's controlling Scope and Reward Groups. The standard Tier 1 Critical ceiling is $15,000.

The following exceptional Tier 1 outcomes may receive an award above $15,000. These are objective impact categories, not automatic prices or guarantees.

Safe proof and scale: Researchers must use accounts and data they own. An account-takeover or cross-tenant proof may use two researcher-controlled accounts to establish the attacker and victim roles. The researcher must not enumerate or access unrelated live accounts. Stripe may use internal deployment and affected-population data to determine whether the demonstrated path reaches the $20,000 or $25,000 category.

ATO, RCE, IDOR, CWE, CVE, scanner output, and Critical labels do not independently qualify a report for an exceptional amount. Account takeover must produce unauthorized control of a distinct victim role. A path requiring significant victim deception, installation of an untrusted client, deliberate credential entry, or repeated attacker-directed interactions does not automatically qualify as exceptional. Remote code execution must run attacker-controlled code in a Stripe-managed production boundary with useful privileges. Execution confined to a tightly sandboxed workload without meaningful credentials, data, privileges, or downstream reach does not automatically qualify as exceptional. Data exposure must cross an authorization boundary and establish safely repeatable reach. Identifier entropy, required low-level access, and other attack prerequisites affect exploitability and the award. A Tier 2 or Tier 3 report may receive Tier 1 or exceptional treatment only when it demonstrates equivalent live core-production authority, reach, or impact.

For the exceptional categories, low interaction means no more than one ordinary victim action and does not include entering credentials, approving security permissions, installing attacker-controlled software, or completing multiple attacker-directed steps. Meaningful scale for the $20,000 category means Stripe confirms that the affected path reaches at least 100 and fewer than 1,000 live accounts or tenants, or produces equivalent material multi-account financial or control-plane authority. Sensitive records for the $25,000 category means financial, card, identity, KYC, authentication, credential, or comparably protected data, not ordinary public or low-sensitivity fields.

A report confined to a Tier 2 acquisition or ecosystem product remains in Tier 2 even when its severity is Critical. Escalation requires demonstrated authority over a named Tier 1 boundary, equivalent Stripe core-production authority, or the systemic reach defined above.

Severity Assessment and CVSS 3.1

Reports submitted at or after November 5, 2026 at 00:00 UTC are assessed using CVSS 3.1 rather than HackerOne's custom CVSS 3.0 implementation. Reports submitted before the cutoff retain the severity method in effect at submission and are not rescored solely because of this transition.

Stripe evaluates standard severity using CVSS 3.1 and Stripe-specific threat modeling. Eligibility, asset tier, demonstrated security outcome, attack prerequisites, reliability, affected population, Stripe-specific production use, and verified severity are separate inputs to the award. Final eligibility, severity, and reward remain at Stripe's sole discretion.

HackerOne Triage will record the CVSS 3.1 vector used to assign severity. If Stripe adjusts severity based on Stripe-specific context, we will explain the relevant factor. The award within the applicable asset-tier range is then based on the demonstrated outcome, Stripe-specific production use, and affected population. We will not reduce the award solely for a factor already reflected in the CVSS score.

Policy Version Applied to a Report

This policy and its updated scope and reward structure take effect on November 5, 2026 at 00:00 UTC.

Reports formally submitted to the Stripe HackerOne program before that time are evaluated under the policy, scope, and reward structure in effect at submission, even if HackerOne triage or Stripe review occurs later. Reports submitted at or after that time use this policy. A report drafted before the cutoff but formally submitted at or after it uses this policy.

Supported Software and Releases

For source code, SDK, CLI, connector, app, integration, and marketplace targets, bounty eligibility is strictly limited to the supported main branch, active marketplace release, or latest supported published package identified in the asset's structured-scope instruction.

Vulnerabilities in SDKs and libraries must break a security invariant such as cryptographic signature verification, trusted payload parsing, credential handling, release integrity, or an equivalent boundary. Missing generic controls in starter code, including CSP, CSRF middleware, authentication, or rate limiting, are out of scope without a demonstrated security-invariant violation or supported downstream impact.

When a report applies to both a named SDK, CLI, connector, maintained app, or supported integration and the generic Stripe Open Source target, the named supported target controls. Only non-archived and non-demo or non-sample open-source projects are in scope. A repository-specific non-bounty notice controls only when it is linked or quoted in HackerOne structured scope before submission; a README is not a hidden post-submission eligibility override. Projects forked from upstream are not in scope unless the reported functionality is used by Stripe. Reports targeting archived, unmaintained, example-only, unsupported, or experimental repositories are Informational unless direct production impact to a supported Stripe-managed deployment is demonstrated.

Rules of Engagement

Your participation in our program is voluntary and subject to the following:

• Your submission must include a working Proof of Concept to be considered for a reward.
• Avoid harm to others' data and privacy. Specifically:
  • If you encounter any personal data or sensitive information in the course of your research, stop and notify our team immediately so we can investigate. Please report to us what data was accessed and delete the data. Do not save, copy, download, transfer, disclose, or otherwise use this data. Continuing to access others' data or otherwise failing to adhere to this requirement will disqualify you from participating in the Program.
  • If your research is designed to identify and demonstrate a vulnerability that could allow unauthorized access to personal data or sensitive information, make sure to take measures to minimize your access to or usage of such data to what is absolutely necessary to achieve those purposes. For example, if you are injecting code into Stripe's environment to test whether you could exfiltrate data from a Stripe database, limit the potential exfiltration to the first three rows and five columns of the table rather than the entire database.
  • If, even after taking measures to minimize access to personal data or sensitive information, you ultimately end up encountering such data in the course of your research, follow the mitigation measures described above.
• Do not leverage the existence of a vulnerability or access to personal data or sensitive information to make threats or extortionate demands.
• Do not degrade, interrupt, or deny services to our users or take any actions that can affect the availability or integrity of Stripe's systems and data, such as modifying or deleting data. If you notice service degradation or interruption, stop your research and notify us immediately.
• Do not incur loss of funds that are not your own.
• If you are performing research, use your own accounts to do so. Do not interact with other Stripe users' accounts. See the "Creating Accounts for Vulnerability Research" section below for more detail.
• By reporting a vulnerability, you grant Stripe and its affiliates a perpetual, irrevocable, worldwide, royalty-free license to use, copy, adapt, develop, and 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 vulnerability, you also agree to allow HackerOne to share with Stripe information relating to your tax forms so that Stripe can perform compliance checks.
• You will be responsible for any tax implications related to any bounty payment you receive, as determined by the laws of your jurisdiction.
• Whether to provide a reward for your submission, the amount of the reward, and your eligibility to participate in the Program are entirely at our discretion.
• We consider only the earliest, responsibly-disclosed submission of a vulnerability instance with enough actionable information to identify the issue for a reward. All other reports for a given issue will not be eligible for a reward under our Program.
• Your research must not violate any applicable laws or regulations.

Submission Review Process

After a submission is sent to Stripe in accordance with the Rules of Engagement described above, Stripe engineers will review the submission and validate its eligibility for a reward. The review time could vary depending on the complexity and completeness of your submission, as well as on the number of submissions we receive.

Submission severity is evaluated based on Stripe specific threat models, which factors in Stripe's internal usage of the application or domain in question.

As explained in the Rules of Engagement, Stripe retains sole discretion in determining which submissions are qualified for a reward. If we receive multiple bug reports for the same issue from different parties, the bounty will be granted to the first eligible submission. If a duplicate report provides new information that was previously unknown to Stripe, we may award a differential to the person submitting the duplicate report. Stripe will also reopen and reward any report mistakenly closed as invalid if we later receive and reward the same bug reported by someone else. In these situations, we pay both researchers.

Submission Guidance and Qualifying Impact

The working Proof of Concept should include complete reproducible steps and the minimum technical evidence needed to validate the security outcome. State the tested asset and version, setup and navigation, account type and roles, prerequisites, expected behavior, observed behavior, relevant existing mitigations, and resulting security impact. Video may supplement this information but does not replace a reproducible proof of concept.

Use of AI or automation does not determine eligibility. The researcher must personally validate the result, remove fabricated or misleading details, identify the exact tested target, and submit one actionable report rather than a volume of unverified variants.

Eligible reports must demonstrate a concrete security outcome such as unauthorized access, execution, disclosure, financial or integrity impact, security-boundary bypass, or equivalent impact.

• An IDOR can qualify even when object identifiers are unpredictable. Identifier entropy affects exploitability, not whether a demonstrated authorization boundary exists.
• An exploit chain is evaluated by its complete demonstrated outcome, including when the chain uses an otherwise known or out-of-scope element.
• A client network-connection validation failure can qualify when the report demonstrates an exploitable security boundary. Locally disabling certificate pinning alone does not demonstrate one.
• Ordinary self-sign-up does not independently establish privileged access or a special prerequisite.
• Missing generic controls in clearly identified starter or example code are not eligible without a demonstrated security-invariant violation or supported downstream impact.
• A third-party component report must demonstrate a material Stripe-specific configuration or impact, a novel unpatched upstream issue, or meaningful acceleration of a Stripe mitigation. Researchers remain responsible for following HackerOne's Code of Conduct and coordinated disclosure requirements for third-party components.

HackerOne triage or Stripe may place a report into Needs More Information only when an identified missing item prevents reproduction or impact assessment. A request should name the exact missing setup, role, request or response, version, prerequisite, expected behavior, observed behavior, or safe proof needed. A report that is outside scope or lacks an eligible security outcome should be decided under that reason rather than repeatedly requesting unrelated information.

Other Notes on Submission Eligibility

• We accept and reward submissions for valid cross-site scripting vulnerabilities even if they are not accompanied by a bypass of our content security policy. Cross-site scripting vulnerabilities without a content security bypass will be assessed at a lower severity level than those with a bypass.
  • If submitting an XSS vulnerability without a CSP bypass, demonstrate the XSS sink by manually disabling CSP in your own web browser. This can be done with browser extensions or Burp/proxy match-and-replace rules. This technique demonstrates the underlying XSS but does not establish a CSP bypass and must not be represented as one.
• Leaked user credentials: Stripe accepts reports of leaked user credentials, for example from password dumps, GitHub scraping, or third-party exposure, but does not provide a bounty for leaked credentials alone. A separate Stripe vulnerability that causes exposure or crosses an intended security boundary is evaluated on that distinct impact.

As a reminder, you must use your own accounts to conduct any research and not interact with other Stripe users' accounts. For further information, please refer to the "Rules of Engagement" section of our policy.

Creating Accounts for Vulnerability Research

You must create your own account using a HackerOne email address ([email protected]) to help us track security research activity. When opening your own merchant account, please add "bug-bounty" to the end of the merchant name. In addition, inject an X-Bug-Bounty: username header, where possible.

Disclosure

By participating in this program, you agree not to publicly or privately disclose the contents of your submission, your findings, your communications with Stripe related to your participation in the Program, or any facts you have learned about Stripe in the course of your participation in the Program to any third party without Stripe's prior written approval. There are no exceptions.

Researcher Privacy

To protect your privacy, we will not, unless served with legal process or to address a violation of this policy:

• Share your personally identifiable information with third parties
• Share your research without your permission
• Share your participation without your permission

Accountability

Stripe reserves the right to disqualify you from participating in the Program if you violate the Rules of Engagement or other rules specified in this program policy, including the rules about disclosure.

Changes to the Terms

We may change the Terms at any time. Participating in the Program after the changes become effective means you agree to the new Terms. If you don't agree to the Terms, you must not participate in the Program.