stripe@beta on npm still resolves to a 2025 alpha, four majors behind 22.5.0

Summary. As of 24 August 2026, npm install stripe@beta resolves to 18.6.0-alpha.2, a build published on 17 September 2025 — 11 months old and four major versions behind the current stable release, 22.5.0 of 10 August 2026. Thirty-one stable versions of the package have shipped since that alpha was cut. The version it names, 18.6.0, was never released as stable at all: the 18.x line stopped at 18.5.0 on 27 August 2025. The tag is also mislabelled. Stripe's own SDK versioning page reserves the -alpha.N suffix for the private preview channel and the -beta.N suffix for public preview, so the tag named beta serves a build marked as an alpha. Neither the stripe-node README nor the versioning page documents stripe@beta anywhere; both document stripe@public-preview and stripe@private-preview instead.

What the registry actually returns

The npm registry exposes four dist-tags for the stripe package. Read against the publish timestamps in the same packument, they do not line up the way the names suggest.

Two things fall out of that table. The obvious one is the age of beta. The less obvious one is that public-preview is currently behind latest: under semantic versioning precedence rules, 22.5.0-beta.1 sorts lower than 22.5.0, because a pre-release identifier always ranks below the release it qualifies. The GA build shipped on 10 August has overtaken the 29 July preview build that is still sitting on the preview tag. Only private-preview, at 22.6.0-alpha.2, is genuinely ahead of stable right now.

Why the beta tag is worse than merely stale

Age alone would be a nuisance. The metadata inside 18.6.0-alpha.2 makes it a behaviour change.

That build declares engines: { node: ">=12.*" }. The current 22.5.0 declares engines: { node: ">=18" }. It also carries a runtime dependency on qs ^6.11.0; 22.5.0 has an empty dependencies object and ships no runtime dependencies at all. So a Dockerfile that pins stripe@beta installs an extra transitive package and an engine floor six Node majors lower than the one the current SDK expects. Nothing errors. The install succeeds, the types resolve, and the API version baked into an April-2025-era SDK is what your integration talks to.

The 18.6.0 version number is the tell. Stripe's 18.x line ran from 18.0.0 on 1 April 2025 to 18.5.0 on 27 August 2025, and then 19.0.0 shipped on 30 September 2025. 18.6.0-alpha.2 is a pre-release of a minor version that was abandoned three weeks after it was cut. Searching the stripe-node CHANGELOG for 18.6.0 returns nothing, which matters because the versioning page promises that Stripe will "pre-announce all runtime deprecations on this page, in each SDK's README and in each language's changelog." A build that never reached the changelog is a build nobody is announcing anything about.

The suffix rules the tag breaks

Stripe documents its pre-release channels by version suffix, not by npm tag. The SDK versioning page states that to reach public preview features you "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," and that private preview features require "versions of our SDKs that have the alpha or a suffix."

Paul Anderson, a Software Engineer on Stripe's API Services team, put the same rule in the launch post for the channel: "Going forward, Stripe's beta SDKs will use these new preview versions. The beta SDK releases are differentiated from their GA counterparts by special suffixes in their versions, such as 5.2.0-beta.1."

By that definition, the artefact on the beta tag is not a beta SDK. It is an alpha, which is the private preview channel, and Stripe's release phases page describes private preview as "restricted to a subset of accounts" with "access by invitation only" and "breaking changes expected over time." Public preview, by contrast, is "open to any user with a Stripe account." The tag name promises the open channel; the artefact belongs to the invitation-only one.

How to tell if this is you

Grep your dependency manifests and container images for four patterns: stripe@beta in a Dockerfile or CI step, "stripe": "beta" in package.json, an npm install stripe@beta in a bootstrap script, and any lockfile entry resolving stripe to an 18.x version. The last is the strongest signal, because a lockfile records what the tag resolved to on the day it was written, and the tag has not moved since September 2025.

The exposure is narrow and specific to npm. Python, Ruby, PHP, Go and .NET have no dist-tag mechanism, so there is no equivalent name to mistype. pip install stripe ignores pre-releases unless you pass --pre or pin the exact pre-release version, gem install requires --prerelease, and NuGet requires an explicit pre-release flag. In every other language the developer has to opt in deliberately. On npm, a four-character tag does it silently.

One package, six version numbers

There is a second trap sitting behind this one, and it bites teams that write internal upgrade policies. The same Stripe release lands under six unrelated version numbers depending on the language. A policy that says "pin the Stripe SDK to v22" means nothing outside Node.

Note the Packagist row. Sorted newest-first, the top entry for stripe/stripe-php is the alpha, not the stable — the alpha was published on 19 August and the stable v21.2.1 on 20 August, but a listing that mixes channels puts pre-releases in the reader's line of sight. Composer's default minimum-stability: stable protects the install; it does not protect the engineer reading the page.

What to do this week

Pin exact versions, not tags. Stripe's own README says so for the preview channels: npm install stripe@public-preview --save-exact, with the note that "there can be breaking changes between two versions of the public preview SDKs without a bump in the major version." The same reasoning applies with more force to a tag that has not moved in eleven months.

Concretely: replace any stripe@beta reference with stripe@22.5.0 if you want GA, or with the exact pre-release string you actually tested if you are on the preview API version 2026-07-29.preview. Add a CI assertion that fails the build when the resolved stripe version does not start with 22.. If your lockfile currently resolves stripe to 18.6.0-alpha.2, treat the upgrade as a four-major migration and read the changelog entries for 19.0.0, 20.0.0, 21.0.0 and 22.0.0 rather than assuming a minor bump. This is the same discipline that the September 2026 Stripe SDK runtime drops require, and the same failure mode we documented in the Anthropic Python SDK 1.0 httpx 2 break: a version string that reads as routine and is not.

The real cost here is usually the migration, not the code change. Four majors of a payments SDK is four sets of removed methods and renamed parameters against a live revenue path.

India-specific considerations

Indian teams building on Stripe for cross-border collections are frequently running the SDK inside container images built once and reused for months, which is exactly the pattern that freezes a bad tag resolution in place. Under the Digital Personal Data Protection Act 2023, an SDK on an eleven-month-old alpha is also an unpatched dependency inside a system processing personal data, and "the tag said beta" is not a defensible answer to a security review. Rebuild base images with pinned SDK versions on a fixed cadence, and record the resolved version in the build log so an auditor can see it.

What is still unknown

Stripe has not deprecated the beta tag on npm. The packument shows no deprecated field on 18.6.0-alpha.2, so npm install stripe@beta prints no warning. It is not documented anywhere we could find, and it is not clear whether it is a deliberate legacy alias or a tag that was simply never removed when the public-preview and private-preview tags replaced it. We have not found a Stripe statement either way. Until there is one, treat the tag as unmaintained rather than as a supported entry point, and check the npm dist-tag documentation if you maintain tags on your own packages — the same drift is easy to create and invisible once created.

FAQ

How eCorpIT can help

Dependency drift inside payment integrations is the kind of defect that passes every test and surfaces during an incident. Our teams run dependency and version-pinning audits across polyglot estates as part of API integration modernization work, including lockfile forensics and CI assertions that fail a build when a resolved version leaves the approved range. If your Stripe integration was containerised more than a year ago, book a dependency review and we will start with what your lockfiles actually resolve to. Related reading: Interop 2026 web platform guide and npm install-script approvals in CI/CD.

References

1. npm registry dist-tags for the stripe package

1. Stripe SDK versioning and release channels

1. Stripe product release phases

1. Introducing Stripe's new public preview release channel, Paul Anderson, Stripe

1. stripe-node README, public preview SDKs section

1. stripe-python README, public preview SDKs section

1. stripe-node CHANGELOG

1. stripe on PyPI

1. stripe on RubyGems

1. Stripe.net on NuGet

1. stripe/stripe-php on Packagist

1. stripe-go releases on GitHub

1. npm dist-tag command reference

1. Semantic Versioning 2.0.0 precedence rules

Last updated: 24 August 2026.