Skip to content
Create account
or
Sign in
The Stripe Docs logo
/
Ask AI
Create account
Sign in
Get started
Payments
Revenue
Platforms and marketplaces
Money management
Developer resources
Overview
Versioning
Changelog
Upgrade your API version
Upgrade your SDK version
    Versioning and support policy
    Stripe.js versioning
Essentials
SDKs
API
Testing
Stripe CLI
Sample projects
Tools
Stripe Dashboard
Workbench
Developers Dashboard
Stripe Shell
Stripe for Visual Studio Code
Features
Workflows
Event destinations
Stripe health alertsFile uploads
AI solutions
Agent toolkit
Model Context ProtocolBuild agentic AI SaaS Billing workflows
Security and privacy
Security
Stripebot web crawler
Privacy
Extend Stripe
Build Stripe apps
Use apps from Stripe
Partners
Partner ecosystem
Partner certification
HomeDeveloper resourcesUpgrade your SDK version

Stripe versioning and support policy

Learn about Stripe's versioning and support policy.

Stripe API versions

Starting with the 2024-09-30.acacia release, Stripe follows a new API release process where we release new API versions monthly with no breaking changes. Twice a year, we issue a new release (for example, acacia) that starts with an API version that will have breaking changes.

You can expect new minor versions of the SDKs with each monthly API version and new major versions of the SDKs with each of the twice a year major releases.

You may sometimes see a major version update to the SDKs with the monthly API version updates if the SDKs have breaking changes to ship.

To understand what to expect from a new API version, see API upgrades.

Stripe SDK versions

Stripe’s SDK versioning policy is based on the semantic versioning standard. For example, in version 4.3.2, 4 is the major, 3 is the minor, and 2 is the patch. When we release a new SDK version for new features or bug fixes, we increment one of these three version components depending on the type of change introduced.

  • Major. We increment the major version component when the version contains breaking changes that are backwards incompatible with the latest version: to add a required parameter, change a type, property, method, or parameter. For example, renaming the SDK’s exception classes.
  • Minor. We increment the minor version component when the version contains new features that are backwards compatible with the latest version: to add a new type, property, method, optional parameter, or supported parameter value. For example, clarifying the SDK’s metadata deletion message.
  • Patch. We increment the patch version component when the version contains backward-compatible bug fixes: to modify a behavior if correcting that behavior doesn’t change any documented types, properties, methods, or parameters. For example, fixing a bug where file uploads weren’t listed properly.

Each SDK version uses the API version that is current at the time of its release to make API requests. Refer to the versioning page to see how to override this.

Stripe SDK support policy

New features and bug fixes are released on the latest major version of the SDK. If you’re on an older major SDK version, we recommend upgrading to the latest major version to take advantage of these features and bug fixes. Older major versions of the package continue to be available for use, but won’t receive any additional updates.

Migration guides

We provide migration guides to help you upgrade from older major SDK versions. You can find them in the wiki section of our SDK GitHub repositories. The same wiki also has the mapping between SDK major versions and the API versions.

  • Python SDK wiki
  • .NET SDK wiki
  • Java SDK wiki
  • Go SDK wiki
  • PHP SDK wiki
  • Ruby SDK wiki
  • Node.js SDK wiki

Stripe SDK language version support policy

To provide better predictability, as of September 2025 we’ll provide details about how long we plan to support each version of a language, and pre-announce all upcoming support removals.

As versions of a language reach end of life status, we’ll gradually drop support for those versions from the corresponding SDK. Previously released SDK versions will continue to work as they always have, but you’ll need to upgrade your runtime to use the latest SDK version.

When a language version reaches its end of life, we’ll mark it as “deprecated” in the tables below and will begin its “extended support window.” During this period, we’ll continue to test the SDK against that version and make sure all of our dependencies continue to work. The exact length of the extended support window varies by language, but they’re all between 1 and 2 years.

After the extended support window for a version ends, the SDK will drop support as part of the next scheduled major version. We’ll pre-announce all runtime deprecations on this page, in each SDK’s README, and in each language’s changelog.

Though an SDK might continue to work on an unsupported language version, don’t continue to use it. SDKs run using unsupported versions might break unexpectedly in any release, and the cause of that breakage might not be included in the changelog.

Language policies

For example

Node 22 reaches end of life in April 2027. We’ll keep supporting it for the September 2027 and March 2028 API releases. We’ll drop support for it in the September 2028 major release.

We support LTS (even numbered) versions of Node 16+* This includes all versions of Node that are currently receiving support, plus those within the extended support window.

Node.js versions that have reached their end of life dates will begin an extended support window of 1 year (two major API releases). After we catch up with our schedule, we’ll drop support for the oldest supported Node LTS version each year with the September API release.

Deprecation schedule

Node versionStatusEnd of lifesupport droppedLast Compatible SDKNotes
20supportedApril 2026September 2027TBD
18supportedApril 2025September 2026TBD18 is the first version to lose support on the schedule defined in this policy.
16deprecatedSeptember 2023March 2026TBDTo ease the transition into this policy, we’re lengthening the support window for 16 to give users more time to update their integrations.
14unsupportedApril 2023September 2025v18.5.0The decision to drop 14 predates this policy and as a result, doesn’t follow the above pattern.
12unsupportedApril 2022September 2025v18.5.0The decision to drop 12 predates this policy and as a result, doesn’t follow the above pattern.

Public preview release channel

We have a public preview release channel, which uses preview API versions that are distinct from general availability (GA) versions. For example, 2025-04-30.preview instead of 2025-04-30.basil.

To access the new features and enhancements in the preview stage, use versions of our SDKs that have the beta or b suffix. For example, 5.1.0b3 in Python and 5.1.0-beta.3 in other language SDKs.

For installation instructions and details about passing preview headers in the Stripe-Version header, see the Public Preview SDKs section in the README files in the respective SDK GitHub repositories.

  • Python SDK public preview
  • .NET SDK public preview
  • Java SDK public preview
  • Go SDK public preview
  • PHP SDK public preview
  • Ruby SDK public preview
  • Node.js SDK public preview

Private preview release channel

We also publish features in the private preview phase that require invite-only access. These features also use the preview API versions.

To access private preview features and enhancements after invitation, use versions of our SDKs that have the alpha or a suffix. For example, 5.1.0a3 in Python and 5.1.0-alpha.3 in other language SDKs.

For installation instructions and details about passing preview headers in the Stripe-Version header, see the Private Preview SDKs section in the README files in the respective SDK GitHub repositories.

  • Python SDK private preview
  • .NET SDK private preview
  • Java SDK private preview
  • Go SDK private preview
  • PHP SDK private preview
  • Ruby SDK private preview
  • Node.js SDK private preview

See also

  • Handle webhook versioning
Was this page helpful?
YesNo
  • Need help? Contact Support.
  • Join our early access program.
  • Check out our changelog.
  • Questions? Contact Sales.
  • LLM? Read llms.txt.
  • Powered by Markdoc