| [ Web Proxy ] |
| Viewing: https://docs.stripe.com/building-plugins#setappinfo | [Back] [Original] |
The plugin integration pattern is deprecated. This means you can no longer request secret API keys from users.
Stripe Apps is the new method for authenticating users and includes support for both restricted API keys and OAuth 2.0. For more information, see the migration docs.
Plugins are any integration between a third-party solution and Stripe that requires a user to authenticate with their secret API keys. A plugin typically interacts with Stripe APIs either by making API calls or responding to Stripe API events on behalf of its users. Plugins often run code that allows Stripe to interact with other software, such as accepting payments on WordPress. They can also take other forms, like open-source libraries or website builders.
Follow these best practices to help your users safely process on Stripes platform without disruption if our API upgrades or changes. If you have questions, contact us at plugins@stripe.com.
setAppInfo and registerAppInfo so we can alert you to any potential issues we noticeYou can also take a few steps to improve the quality of your connector:
Become a Stripe Partner to reach businesses on Stripe who are looking to add capabilities to their platforms.
Provide identifying information so that we can contact you if theres an issue with your connector or critical update to the API.
If you use the APIs to create server-side requests, use setAppInfo with a hash containing the following options:
name (required): your plugins namepartner_id (required for Stripe Verified Partners, optional otherwise): your Partner ID from the Partners section of the Dashboardversion (optional): your plugins versionurl (optional): the URL for your plugins website with your contact detailsStripe.set_app_info( 'MyStripePlugin', partner_id:, # Used by Stripe to identify your connector version: '1.2.34', url: 'https://example.com' )'{{PARTNER_ID}}'
If your connector is designed for a particular platform, include that platform in the name field (for example, WordPress MyStripePlugin or WooCommerce MyStripePlugin).
If youre building a connector and not using one of our official libraries, set the value of the User-Agent header on requests made to the Stripe API as name/version (url).
The following is an example:
User-Agent: WordPress MyStripePlugin/1.2.34 (https://example.com)
For frontend libraries that use Stripe.js, use registerAppInfo with the same options as setAppInfo above. For example, using JavaScript:
stripe.registerAppInfo({ name: "MyOSSLibrary", partner_id:, // Used by Stripe to identify your connector version: "1.2.34", url: "https://example.com", });"{{PARTNER_ID}}"
Your plugin should use the setApiVersion function, which will set the Stripe-Version HTTP header on all requests. Your users will use their own API keys to access Stripe, but this header will be included with every request. We recommend that you use the most recently published version of the API. The current API version and details on our versioning policy can be found in the API reference.
# Don't put any keys in code. See https://docs.stripe.com/keys-best-practices. client = Stripe::StripeClient.new('sk_test_wU7nrJCZspk1NPDxiQgAF05q', stripe_version: '2022-08-01')
New Stripe users automatically default to the latest version of the API. This header ensures that your connector is pinned to a specific API version, which keeps the occasional backward-incompatible change from breaking your connectors functionality.
Users can upgrade their own API version through the Stripe Dashboard. If your connector relies on webhook events, their data format and structure depend on the users account API version. You should instruct your users to set the version in their Dashboard to match your plugin.
API versions cant be downgraded. You should regularly release new versions of your connector to correctly handle any changes to JSON responses.
We regularly release new versions of the Stripe API that bring new features and bug fixes. You can subscribe to the api-announce mailing list to be notified of updates that might affect users of your connector.
Stripe users are subject to PCI compliance, which specifies how credit card data should be securely stored, processed, and transmitted. Their businesses could face stiff penalties for noncompliance or potential breaches, so its important to help them safely process on Stripe.
Since your connector will make API calls on behalf of a Stripe user, you must transmit credit card data securely using client-side tokenization. Customers submit their personal information through their web browser or mobile app directly to Stripe, and in exchange a simple token will be sent to the Stripe user. This allows your users to securely collect card details without sensitive data ever touching their server.
If your connector includes a client-side payment form in the browser, we recommend that you use either Stripe.js and Elements or Checkout:
Both of these options provide client-side tokenization.
If your plugin only operates in a backend environment, include a note in your connectors documentation asking users to tokenize payment details using Elements or Checkout. Tokenization helps Stripe users process as safely as possible on our platform.
The Express Checkout Element gives you a single integration for accepting payments through one-click payment buttons, including Apple Pay, Google Pay, Link, or PayPal.
The Express Checkout Element allows you to display multiple buttons at the same time. Customers see different payment buttons depending on what their device and browser combination supports.
Stripe supports multiple payment methods, aside from credit cards. Weve published a guide to payment methods that introduces terminology, key considerations, and how we support each method on our platform.
The Payment Methods API enables your users to collect payments using additional payment methods (for example, Alipay, iDEAL, Sofort). You can add these payment methods using one integration path.
If your plugin presents a payment form in a web browser, it should check if the form is being served over HTTPS. We require our users to enable HTTPS: you should present a clear error to your user if theyre not properly secured.
Here are a few examples to verify whether your users have HTTPS enabled:
If your connector has a front-end component, check whether HTTPS is being used from the browser. For example, using JavaScript:
// This example checks for HTTPS from the browser if (window.location.protocol !== "https:") { // Present an error to the user }
| Web Proxy Viewer | New URL | Original Page |