Stripe Technology partners

Learn about the the requirements to become a Stripe Technology partner.

Requirements

Fulfill the following requirements within six months of applying in order to join the Technology program.

Requirement	Provisional	Stripe partner
Complete a Partner Application
Must not be on the Stripe Restricted Businesses list
Complete the Stripe Partner Ecosystem Agreement
Download and activate a free Stripe account
Submit one Stripe customer story (not required to be public facing)
Take the Stripe Business Foundations course (required by one person in the organization)

Technology Partners must pass the verification assessment to be listed in the partner directory.

Embedded Payments Partners must use Stripe Connect.

Governance

Stripe Technology Partner requirements are reviewed every 12 months, commencing the day you become an official Stripe partner.

Benefits at a Glance

As a Stripe Technology Partner you are eligible to receive the following benefits and incentives.

Benefit	Provisional partner	Stripe partner
BUILD
Sales enablement and payments education
Live webcasts and programming with Stripe partner team and experts
Individual technical training and certification
Solution blueprints to speed time-to-market
Eligible for prioritized pre-sales engineering consultations
MARKET
Marketing launch playbook (Embedded Payments Partners only)
Marketing content, campaign assets, how-to guides, and templates
Directory listing to amplify your company and solution
Eligibility for Market Development Funds (MDF)
Stripe Partner badge and co-branding guidelines
Press release guidance
SELL
Eligibility for new business incentive
Eligible for Stripe Connect revenue share (applies to partners that use embedded payments in their solutions
Deal registration to request co-selling support
Eligibility for co-selling resources such as account mapping with Crossbeam
ENGAGE
Dedicated Partner portal and partner support
Partner awards
Partner-to-partner community engagement opportunities
Eligibility to access to roadmap previews

See Partner benefits for more details on each benefit offered.

Technology Partner Verification Assessment

Use the checklist in this section to ensure you’re ready to submit the Verification Assessment to meet your requirements as a Technology partner. The final submission of the Verification Assessment is from the Stripe Partner Portal.

There are 3 sections that are dynamic to responses submitted. The first section is general business information around your business and how you want to partner with Stripe, then if building a connector there are additional questions to answer (but please skip if this does not apply to your business), and lastly if embedding payments then only answer the last portion of this checklist.

Solution – I have a stand alone solution, and want to extend it with Stripe capabilities. My users have to be Stripe users, providing their own API keys, to leverage these new features.
Connector – I am building a stand alone solution to connect Stripe into a specific vendor. Example: SAP, Salesforce, Quickbooks. My users are Stripe users and I monetize the connector through subscriptions or licenses.
Embedding Payments – I am a software company and want to embed payments and financial services into my product to improve customer experiences, differentiate my offering, and add a revenue stream. I am using Stripe Connect - and possibly other Stripe solutions such as Terminal, Billing, Issuing, and Treasury - to deliver seamless end-to-end payments and financial services to my customers.

The approval guidelines column provides insights on what our review teams are looking for when validating the submissions. Do your best to incorporate those key points to your responses. Our review team diligently reviews each submission and provides responses within 30 business days after receiving the assessment.

If certain questions don’t apply to your business please choose an option that best fits and provide more details why, that helps the reviewer understand why the questions don’t apply to your business.

Technology questions

The general business questions in the following table apply only to Technology partners who selected Build an integration or solution. To view details about the verification assessment for partners that use embedded payments, see Embedded Payments Partners Verification Assessment.

Technology questions	Details	Required
What use case are you addressing? What business problem are you solving?	Describe what is intended for your solution (for example, enable payments for ecommerce solutions)	Yes
What is the value proposition?	Objectives or expected outcomes from the solution with Stripe, including key differentiators. (e.g.Close deals faster in Salesforce with DocuSign eSignature for Salesforce: Send, sign, track and save agreements in Salesforce with the most downloaded electronic signature app on the AppExchange)	Yes
What are your system requirements?	What are specific system requirements to ensure compatibility with Stripe and other platforms if relevant. (e.g. Example: Unlimited, Developer Edition). Easy setup allows you to start sending documents for electronic signature (eSignature) from Salesforce in minutes, activating all users in one step… get started with a 30-day free trial.)	Yes
What is your target customer type? If Other, fill in text.	Options: Finance team, Sales team, Payments or Other. What is the role of the relevant target user?	Yes
What is the size of the audience, the Total Addressable Market (TAM)?	Are users asking for this? What market research have you performed? Why did you decide to build this?	Yes
What is your pricing model? If Other, fill in text.	Options: Annual subscription, Monthly subscription, One-time fee, Transaction-based, Free or Other. How do you price your product?	Yes
What is the marketing plan (go-to-market plan) to ensure user adoption?	Please provide a link to the landing page where users can gain more information.	Yes
Who are your partner stakeholders?	Who are the key contacts in your company that you work with from Sales, Product, Alliances, Marketing?	Yes
Who are your Stripe stakeholders?	Do you have a Stripe contact? If so, list here.	Yes
What are your top 5 opportunities?	Client Opportunities Revenue (Payment Volume) Stripe Sourced vs. Partner Sourced Status	Yes
What are your agreed upon partner success metrics?	Internally what are your goals, metrics and status? Revenue: Pipeline created (Payment Volume) Number of partner sourced opportunities Training and certifications: number of enabled IC/IE Resources Number of certifications for the company User Generating Activities (Marketing and OBA): number of user campaigns Case Studies: number created Joint solutions: number developed	Yes
What are your top partner accomplishments year to date?	Your internal company priorities, details, timelines, and status Build the foundations > Details > Q1 > Complete Partner enablement Lead generation	Yes
Upload your user-facing documentation	User-facing documentation must be updated with each new release and reviewed quarterly for accuracy.	Yes
Provide a list of FAQs to be published on support.stripe.com.		Yes
Upload your support process documentation.	Escalation process for support tier 2 and 3 to redirect customers to Technology partner	Yes
Upload your user support expectation documentation.	Set user expectations for the support that is and is not available from Stripe. Such as the bug filing processes and how Stripe submits user support.	Yes
Upload your first call deck.	This can be found by Stripe AEs to learn more about your solution / integration / connector	Yes
Provide your demo recording URL of your product / solution.	To see an example, view the SCN Billing Integration Pre-Sales Demo video.	Yes
Do you have proper tracking in place to monitor and iterate on the support experience?	Options: Yes or No	Yes
Provide a private sandbox URL	If applicable	No
Are you building a connector to Stripe?	Options: Yes or No	Yes

Connector questions

The questions in the following table apply only to partners that create connectors.

Connector Questions	Details	Required
Which category is most relevant to the connector? If Other, fill in text.	Options: eCommerce, CRM, ERP, Cloud, Analytics & Reporting, Tax, Wallets, iPaaS or Other Choose the category that is most related to the connector	Yes
What are the key features and functionality of the connector? If the connector is compatible with or complementary to other platforms, indicate this here.	Examples include: Maximize your Salesforce investment and streamline your processes with the world’s most trusted eSignature solution for the world’s #1 CRM. Send agreements for signatures: Send agreements directly to Salesforce contacts or specify email addresses. Include messages, reminders, and authentication options. Create agreements with Salesforce data: Create agreements with DocuSign templates that pull in any Salesforce data saved on that record with merge fields. Responsive signing: Signers on mobile phones can access a parallel version of the document that automatically adapts its formatting to the device’s size and orientation."	No
How is this connector different from other solutions in the ecosystem?	Understand competitive differentiation.	Yes
Dependencies on which the connector is built must be under proper licensing and actively maintained by their developers.	Options: Yes or No If the connector relies on a third party package or service to operate (open source or not). These should be properly licensed by the partner.	Yes
API keys used to access the user’s account must be stored in an already secure environment, e.g. database, environment variables, etc.	Options: Yes or No In short, configuration (API Keys, user/password, API urls) should not be part of the codebase to avoid its leakage in software repositories. Instead the connector should fetch all the necessary configuration from the environment or from a config service. This will also guarantee that the same codebase runs in development, test and production environment. To learn more, see API keys.	Yes
Once saved, keep the secret keys obfuscated if displayed in a user interface.	Options: Yes or No Ideally, the secret key should only be accessible from within the Stripe Dashboard. If there is the need to display that in the connector’s admin section, this information should not be explicitly displayed.	Yes
Force least privilege API key access with restricted keys when applicable.	Options: Yes or No The connector has different modules with different roles associated to them. Having API keys with only the necessary authorizations (for instance, read-only, or only access to “balance transactions”), increases the application security and mitigates the risk in case an API key gets exposed. To learn more, see Limiting access with restricted API keys.	No
Provide your `partner_id` using setAppInfo to identify the Connector.	Provide your `partner_id` using setAppInfo to identify the Connector. To learn more about how to build a plugin, see Building stripe plugins.	Yes
Use publicly available features only. Gated features must be avoided as much as possible and in such case, a clear warning must be displayed to invite the user to reach out to Stripe.	Options: Yes or No	Yes
More generally, follow the Webhooks such as signature verification and handling events idempotently.	Options: Yes or No This guarantees the requests the connector receives are genuinely from Stripe and also that every request is just handled once. To learn more, see Check the webhook signatures.	Yes
Use idempotency keys for all POST requests.	Options: Yes or No Allows Stripe to perform a record keeping of requests, required to prevent duplicate operations. To learn more, see Idempotency.	Yes
Specify a Stripe API version for all requests, both server-side and client-side.	To learn more, see Stripe API upgrades and versioning.	No
Do you use our latest APIs, e.g. PaymentIntents instead of Sources. Deprecated APIs must be replaced in a reasonable time after being deprecated by Stripe.	Options: Yes or No You should confirm that you’re not using older version of the API. To learn more, see Older payment APIs.	No
Do you use Checkout or Elements to tokenize payment information?	Options: Yes or No To learn more about the different ways to accept payments, see Accept a payment.	No
Do you offer the possibility to collect the customer’s full billing and shipping addresses such as zip code, name, and email when tokenizing cards to protect against disputes.	Options: Yes or No Learn about how to collect as much payment information as possible to help prevent fraud and disputes.	No
Webhooks must be created by the connector while setting the API version supported by the connector.	Options: Yes or No To learn more about how to set up webhook endpoints, see Create a webhook endpoint.	No
Implement a logging system on rotation which includes request IDs for API errors.	Options: Yes or No This helps troubleshooting and also the creation of alerts in case something goes wrong in the connector.	No
Automatically handle rate limiting using the same pattern as first-party Stripe SDKs.	Options: Yes or No To learn more about how to handle rate limits, see Handling limiting gracefully here.	No
Provide a test report stating the required coverage.	Testing completed on the Connector and proof provided. Proper functional test completed; over 90% code.	No
Use MAJOR.MINOR.PATCH versioning unless specified otherwise by the platform.	Options: Yes or No Following the Semantic Versioning Specification (If applicable): MAJOR version when you make incompatible API changes, MINOR version when you add functionality in a backwards compatible manner, and PATCH version when you make backwards compatible bug fixes To learn more, see Semantic Versioning.	Yes
Provide up-to-date documentation on how to use the Connector on the Stripe documentation site (stripe.com/docs/plugins), including use cases and workflows. The documentation must link to other relevant docs (e.g. managing fx, reconciliation, etc.).	The documentation must link to other relevant docs (such as managing fx and reconciliation.).	Yes
What are your company specific connector definitions?	Provide definitions and clarity on any technical language whether it’s acronyms or company terms to help users reference this as a glossary.	No

Embedded Payments Partners Verification Assessment

The questions in the following table are intended for partners that embed payments and financial services into their solutions.

Requirement	Answer options	Required?
Do you use Stripe Connect to access Stripe accounts and data?	Yes or No	Yes
Have you set up a Stripe webhook endpoint for Connect events?	Yes or No	Yes
Do you use a Stripe API version for all requests that is one of the last two published versions?	Yes or No	Yes
Do you use Stripe Checkout or Payment Element to tokenize payment information?	Yes or No	Not required. Recommended as a best practice.
Do you use Payment Intents?	Yes or No	Yes
Do you use idempotency keys?	Yes or No	Not required. Recommended as a best practice.
Do you have a minimum of 5 active connected accounts?	Yes or No	Yes
Do you have a landing page describing your Stripe integration?	Yes or No If yes please provide URL	Yes Exceptions available for white-label platforms only.

Technical Best Practices

Collect zip code, name, and email when tokenizing cards to protect against disputes
Listen to webhooks events to stay informed about payments events
- Integrations using Payments should listen to events like payment_intent.succeeded, payment_intent.payment_failed or checkout.session.completed
- Integrations using Billing and Invoicing should use subscription webhooks to listen for events relevant to user’s invoices from invoice.created to invoice.paid
- Avoid listening to all events on webhook endpoints
Include measures to prevent card testing when collecting payment information

If you need more information about the Stripe Partner Ecosystem, please contact us at partner-support@stripe.com.