Stripe's September 2026 SDK release drops 7 runtimes across 5 languages and names no pin for any of them

Summary. Stripe's SDK language runtime version support policy schedules seven runtime rows to lose support at the September 2026 major release: Node.js 18, Go 1.22, Go 1.23, Ruby 2.7, PHP 7.2, PHP 7.3 and .NET 6. Every one of those seven rows lists its Last Compatible SDK as "TBD". Every runtime Stripe has already dropped names a concrete version instead, including v20.4.1 for Node 16, v84.4.1 for Go 1.21 and v50.4.1 for .NET 7. That is the practical problem. If your build cannot move off Node 18 or .NET 6 in the next five weeks, Stripe has told you the SDK will stop supporting your runtime but has not told you which release is the last one that works. The same page also contradicts itself on .NET, and three of the five affected SDKs never mention the deadline in their README at all.

What the page actually schedules

Stripe ships new SDK majors alongside its twice-yearly major API releases. The current API version is 2026-07-29.dahlia, and the Dahlia major first landed on 25 March 2026, which puts the next major in September 2026. The runtime policy hangs off that cadence: a language version that reaches its own end of life enters an extended support window of one to two years, and the major release after that window closes drops it.

Seven rows close in September 2026.

Language	Version dropped in September 2026	Last compatible SDK, per Stripe	Current SDK release
Node.js	18	TBD	v22.5.0, 10 August 2026
Go	1.23	TBD	v86.3.0, 11 August 2026
Go	1.22	TBD	v86.3.0, 11 August 2026
Ruby	2.7	TBD	v19.5.0, 10 August 2026
.NET Core	6	TBD	v52.3.0, 10 August 2026
PHP	7.3	TBD ("Likely September 2026")	v21.2.1, 20 August 2026
PHP	7.2	TBD ("Likely September 2026")	v21.2.1, 20 August 2026

Release dates come from each repository's latest GitHub release as of 24 August 2026.

The TBD is the story

Look at what Stripe published for every runtime it has already dropped. Python 3.8 and 3.7 both name v14.4.1. Python 3.6 names v12.5.1. Ruby 2.6 names v18.4.2, and Ruby 2.5, 2.4 and 2.3 all name v15.5.0. PHP 7.1, 7.0 and 5.6 name v19.4.1. Go 1.21 and 1.20 name v84.4.1, and Go 1.19 and 1.18 name v82.5.1. Node 16 names v20.4.1, and Node 14 and 12 name v18.5.0. .NET 7 and 5 name v50.4.1, and .NET Core 3.1 names v48.5.0.

Twenty historical rows, twenty concrete pins across eleven distinct versions. Seven rows due in about five weeks, zero pins.

Drop window	Rows	Last compatible SDK published?
September 2025	9	Yes, all nine
March 2026	11	Yes, all eleven
September 2026	7	No, all seven read TBD
March 2027 and later	19	No, all nineteen read TBD
No date given	4 PHP rows	No, all four read TBD

That asymmetry matters because Stripe's own policy tells you the older SDK still works. The page says previous versions of the SDK "will still be compatible with those older language versions", which makes pinning the correct move for a team that cannot upgrade its runtime in time. The pin is the mitigation, and the pin is the one thing the table does not give you.

There is a second reason to care. The policy warns that an SDK running on an unsupported language version "might break unexpectedly in any release, and the cause of that breakage might not be included in the changelog". So the failure mode Stripe describes is a silent one, and the defence against it is a version number that does not exist yet.

The .NET section contradicts itself

Stripe's .NET prose reads: ".NET 9.0 reaches end of life in May 2026. As an STS version, we'll drop support in the next major release (September 2026)."

The .NET table four lines below says .NET 9 has an end of life of November 2026 and loses Stripe support in March 2027.

Microsoft settles it. The .NET and .NET Core support policy, last updated 11 August 2026, lists .NET 9 as an STS release with end of support on 10 November 2026, and states that STS releases get free support and patches for two years. The 18-month figure the prose implies is not Microsoft's current policy.

Source	.NET 9 end of life	Stripe support dropped
Stripe versioning page, prose	May 2026	September 2026
Stripe versioning page, table	November 2026	March 2027
Microsoft support policy, 11 Aug 2026	10 November 2026	Not applicable

A .NET shop reading the prose plans a September 2026 migration. A .NET shop reading the table plans March 2027. Both read the same page on the same day. Only the table matches Microsoft.

One more .NET trap sits in the same table. Stripe says it supports ".NET 6+", yet .NET 7 is marked unsupported with v50.4.1 as its last compatible SDK, while .NET 6 stays supported until September 2026. That inversion is correct on the dates, because Microsoft ended .NET 7 support on 14 May 2024 and .NET 6 on 12 November 2024, but it means moving from .NET 6 to .NET 7 moves you onto a runtime the current Stripe SDK does not support.

Three of the five SDKs never mention the deadline

The policy makes a specific commitment: "We'll pre-announce all runtime deprecations on this page, in each SDK's README and in each language's changelog."

Two SDKs honour it. The stripe-ruby README states that support for Ruby 2.7 is deprecated and will be removed in upcoming major versions, and links the schedule. The stripe-php changelog is more direct still, marking v21.0.0 as "the last major version to support PHP 7.2 and 7.3" and telling readers to upgrade to 7.4 or later before September 2026.

Three do not.

SDK	"September 2026" in README	Runtime deprecation in README
stripe-ruby	No	Yes, Ruby 2.7 named
stripe-php	No, but named in the changelog	Via changelog entry for v21.0.0
stripe-node	No	No, zero occurrences of "deprecat"
stripe-go	No	No, its only deprecation notes cover the legacy client.API pattern
stripe-dotnet	No	No, zero occurrences of "deprecat"

The Node case is the sharpest. The stripe-node README says: "Per our Language Version Support Policy, we currently support all LTS versions of Node.js 18+." The package on npm agrees. stripe@22.5.0 declares engines: {"node": ">=18"}. A developer who checks the README and the package manifest, which is what most developers check, sees Node 18 supported and no deadline anywhere. The deadline lives only in a docs table they have no reason to open.

What to do before the September release

Work out your exposure first. Node teams that already built a patch-response routine, as in the Node.js July 2026 security release playbook, can reuse it here. On Node, node -v against >=18 is not enough, because 18 is exactly the version being dropped. Check whether your runtime is 18.x specifically, and whether your deploy target pins it. On .NET, dotnet --list-runtimes will show a 6.0.x entry. On Go, read the go directive in go.mod, not the toolchain on the build machine. On Ruby, read .ruby-version or the ruby line in your Gemfile. On PHP, php -v on the actual host, which on shared hosting is often older than the local development version.

Then pick one of two paths. If you can move the runtime, move it now, because the drop only affects the next major SDK and a supported runtime removes the problem entirely. If you cannot, pin the SDK to the last release published before the September major and hold it there. Today those pins are stripe-node v22.5.0, stripe-go v86.3.0, stripe-ruby v19.5.0, stripe-dotnet v52.3.0 and stripe-php v21.2.1. Record the pin with the reason attached, because in six months nobody will remember why the version is frozen. The decision structure is the same one a database team uses when it picks a Postgres end-of-life upgrade target: name the target, name the fallback, date both. Teams that treat this the same way they treat a database upgrade, with a named target and a rollback, get through it cheaply. The real cost is usually the migration you postponed, not the one you planned.

September 2026 is a crowded month for deprecations already, alongside the GitHub Copilot September 2026 model deprecations, so the Stripe work competes for the same maintenance window. Watch two moving pieces. Stripe notes that the Node.js release schedule changes in October 2026 and that its Node table "will be amended accordingly", so the Node rows are the least stable rows on the page. And Go 1.25, which Stripe's prose still describes in the future tense as reaching end of life "in August 2026", reached it on 19 August 2026 according to endoflife.date.

Teams running Stripe inside a regulated payments stack usually find the SDK pin is the easy part and the regression testing around it is not. That work sits with the same people who own fintech payments application development, and it is worth scheduling rather than discovering.

What is still unknown

Stripe has not published the September 2026 release date, the major API release name that follows Dahlia, or any of the seven last-compatible SDK versions. The PHP rows carry the word "Likely", which is the only hedged entry in any of the six language tables, so PHP 7.2 and 7.3 may yet slip past September. Java has no table, no dates and no schedule at all: the page lists LTS versions 25, 21, 17, 11 and 8 with no deprecation plan, so Java teams get no advance notice of any kind. Python is unaffected in September, with 3.9 already deprecated and scheduled to drop in March 2027.

FAQ

Which runtimes does Stripe drop in September 2026?

Seven rows across five languages: Node.js 18, Go 1.23, Go 1.22, Ruby 2.7, .NET Core 6, PHP 7.3 and PHP 7.2. The PHP rows are hedged with the word "Likely" on Stripe's versioning page. Python is not affected in September, because Python 3.9 is scheduled to drop in March 2027 instead.

What version should I pin my Stripe SDK to?

Stripe has not published a last compatible version for any of the seven runtimes, listing all of them as TBD. Until it does, the practical pin is the newest release published before the September major: v22.5.0 for Node, v86.3.0 for Go, v19.5.0 for Ruby, v52.3.0 for .NET and v21.2.1 for PHP.

Why does pinning work at all?

Stripe's support policy states that previous versions of the SDK will still be compatible with older language versions, and that only the following major version removes support. So an older SDK release keeps working on a dropped runtime. Stripe also warns such a combination might break in any release without a changelog entry explaining it.

Does the stripe-node README warn about the Node 18 deadline?

No. The README says Stripe currently supports all LTS versions of Node.js 18 and later, and the word "deprecat" does not appear in it. The published package agrees, declaring engines of >=18 in stripe@22.5.0. The September 2026 date appears only in the docs table.

What is wrong with Stripe's .NET dates?

The prose says .NET 9 reaches end of life in May 2026 and loses Stripe support in the September 2026 major. The table on the same page says November 2026 and March 2027. Microsoft's support policy, updated 11 August 2026, gives 10 November 2026, which matches the table rather than the prose.

Is .NET 6 really supported when .NET 7 is not?

Yes, and the dates explain it. Microsoft ended .NET 7 support on 14 May 2024 and .NET 6 support on 12 November 2024, so .NET 7 entered its extended window first and was dropped in the March 2026 release with v50.4.1 as the pin. Upgrading from 6 to 7 therefore moves you onto an unsupported runtime.

How much notice does a Java team get?

None on a schedule. Stripe's Java section lists supported LTS versions 25, 21, 17, 11 and 8 in a plain list, with no deprecation table, no end-of-life dates and no support-dropped column. Every other language on the page carries a dated table, so Java is the one runtime with no published timeline.

When is the next Stripe major API release?

Stripe issues major API releases twice a year alongside new SDK majors. The current API version is 2026-07-29.dahlia, and the Dahlia major first shipped on 25 March 2026, which places the next major in September 2026. Stripe has not published the exact date or the name that follows Dahlia.

How eCorpIT can help

eCorpIT runs runtime upgrade and SDK migration work for payment integrations, including the regression testing that a Stripe major usually forces. We are CMMI Level 5 and ISO 27001:2022 certified, and our senior engineering teams handle the exposure audit, the pin decision and the upgrade path as one piece of work rather than three. If you are on Node 18, .NET 6, Go 1.22, Ruby 2.7 or PHP 7.3 with Stripe in production, book a Stripe runtime exposure review and we will map your pins before the September release.

References

1. Stripe versioning and support policy, Stripe Docs, retrieved 24 August 2026.
2. Stripe API upgrades, Stripe Docs, retrieved 24 August 2026.
3. Stripe Developer Changelog, Stripe Docs, Dahlia release history.
4. .NET and .NET Core official support policy, Microsoft, last updated 11 August 2026.
5. stripe-node repository and README, Stripe, v22.5.0 released 10 August 2026.
6. stripe-php changelog, Stripe, v21.0.0 PHP 7.2 and 7.3 notice.
7. stripe-ruby repository and README, Stripe, Ruby 2.7 deprecation notice.
8. stripe-go repository and README, Stripe, v86.3.0 released 11 August 2026.
9. stripe-dotnet repository, Stripe, v52.3.0 released 10 August 2026.
10. stripe package on npm, npm registry, engines field for 22.5.0.
11. stripe package on PyPI, PyPI, 15.5.1 requires Python 3.9 or later.
12. Go end-of-life dates, endoflife.date, Go 1.25 end of life 19 August 2026.
13. PHP end-of-life dates, endoflife.date, PHP 8.0 and 7.4 support dates.
14. Node.js end-of-life dates, endoflife.date, Node 18 and 20 schedules.
15. Evolving the Node.js release schedule, Node.js, October 2026 change referenced by Stripe.

Last updated: 24 August 2026.