Stripe API 2026-09-30.endive: Breaking Changes to Payment Method Types and Checkout Buttons

On September 30, 2026, Stripe published API version 2026-09-30.endive, the first version in a new major release it calls Endive. Major releases are the ones where Stripe is allowed to break things, and this one removes a parameter that a very large number of checkout integrations have relied on for years.

If your online store, subscription product or marketplace takes payments through Stripe, nothing stops working today just because the release exists. The changes apply when your integration moves to the new version. The practical question is how much work that move will be, and that depends on how your checkout was built. For companies running a custom storefront or e-commerce application, it is worth finding out now rather than during the next library update.

This article summarizes what Stripe released, which changes are most likely to affect a typical US or UK business, and what to ask your developers.

What Stripe released on September 30, 2026

Stripe's developer changelog lists 2026-09-30.endive as the current API version, dated September 30, 2026. It follows the Dahlia series, whose first version the same changelog dates to March 25, 2026.

Stripe's versioning documentation explains the rhythm. New API versions ship monthly with no breaking changes, and twice a year Stripe issues a major release that starts with a version containing breaking changes. Stripe says monthly releases can be adopted without code changes, while a new major release can require changes to an existing integration. Endive is one of those twice-yearly releases.

The changelog for this version is long. It covers Payments, Billing, Connect, Financial Connections, Tax and Treasury, and by our reading more than two dozen entries are marked as breaking. Most businesses will only be touched by a handful of them.

The payment method types parameter is removed

The change with the widest reach concerns how an integration tells Stripe which payment methods to offer. Until now, many integrations passed a fixed list, for example cards only, in a parameter named payment_method_types. In Endive that parameter can no longer be set.

Stripe's changelog entry for Checkout Sessions states that passing the parameter when creating a session now returns a 400 error. A separate entry for Payment Intents and Setup Intents says the same for the create, update and confirm calls, and notes that the field remains on those objects as a read-only property. A third entry removes the equivalent option in Stripe Elements, where Stripe.js will throw an integration error instead of rendering the payment form.

What replaces it

Stripe points to two replacements. The first is dynamic payment methods, where the available methods are managed in the Stripe Dashboard and Stripe works out which ones suit each transaction based on details such as currency, amount and customer. The second is a new parameter, allowed_payment_method_types, for teams that still want to name a specific set in code. There is also an exclusion parameter for removing individual methods.

One behavioral difference matters for testing. According to Stripe, the old parameter returned an error when an incompatible payment method was listed, whereas the new one silently filters out methods that do not fit the transaction. A misconfiguration that used to fail loudly may now simply result in a payment option not appearing.

The Payment Request Button is removed

The second change that will reach many storefronts concerns the Payment Request Button, the older Stripe Elements component for wallet-style buttons. Stripe's entry on deprecating the payment request button says support is removed in Endive and that creating the element throws an error from this release onward, including for sites using the React component.

Stripe directs developers to the Express Checkout Element as the replacement and says the migration should be completed before upgrading. It also states that Stripe.js versions through Dahlia continue to support the old button, so a site that has not moved to Endive keeps working for now.

One change that is not tied to the version: SEPA Direct Debit addresses

Most Endive changes only apply once you upgrade. One is different and deserves attention from UK businesses in particular. Stripe's entry on SEPA Direct Debit billing addresses says that payments using IBANs from outside the European Economic Area, with UK and Swiss IBANs named explicitly, must now include city and postal code in addition to the first address line and country.

Stripe attributes this to the European Payments Council's structured address requirement and states that the change affects all API versions. Requests that previously succeeded with a partial address now fail, and so does confirming a payment with a saved payment method that lacks those fields. If you collect SEPA Direct Debit from customers with UK bank accounts, this is the item to check first.

Other breaking changes and new features

The remaining breaking changes are more specialized. Marketplaces and platforms built on Stripe Connect have the longest list, including new rejection reasons and statuses on connected accounts and changes to how verification requirements and errors are reported. Subscription businesses should look at the entry that unifies the billing cycle anchor format across subscriptions and invoices. There are also changes to Financial Connections defaults, Stripe Tax error handling and dispute evidence validation. Each is described in the changelog.

The release is not only removals. The same changelog lists, among other additions:

• trial offers for subscriptions moving to general availability
• the ability to pause and resume subscriptions on demand, and to pause automatically after payment failures
• a standalone 3D Secure API
• thin events for API v1 resources moving to general availability

Stripe also maintains a separate preview version, 2026-09-30.preview, for features that are not yet generally available. Anything that exists only there should be treated as subject to change.

What this means for your business

The points below are our interpretation, not statements from Stripe.

For most businesses, Endive is a planned maintenance task and not an emergency. Stripe's upgrade guide recommends that code specify the API version it integrates against, and explains that current server-side SDKs use the API version that was current when that SDK version was released. In practice, the upgrade tends to arrive when a developer updates the Stripe library as part of routine dependency maintenance. That is where the risk sits: an apparently harmless package update that changes checkout behavior.

The size of the job depends on the integration style. A store using a hosted platform or a maintained plugin relies on that vendor to adapt. A custom checkout that hard-codes a list of payment methods, or that still uses the Payment Request Button, will need code changes and a round of testing. A marketplace on Connect should expect the most review.

There is also a decision hiding in the migration. Moving to dynamic payment methods hands control of the payment method mix to Dashboard settings and Stripe's own eligibility logic. That can be convenient, but finance and operations teams should agree which methods are switched on, because each one carries its own settlement, refund and dispute characteristics.

What to do next

A short review will tell you where you stand:

• Ask your developers which API version your integration and your webhook endpoints use. Stripe's upgrade guide says this is visible in Workbench in the Dashboard.
• Search the codebase for the payment method types parameter and for the Payment Request Button, in both server and front-end code.
• If you accept SEPA Direct Debit, confirm that your forms collect city and postal code, and check saved payment methods for UK customers.
• Test the new version in a Stripe sandbox before changing production, including webhooks, which Stripe versions separately from API requests.

When you do upgrade the account's default version through Workbench, Stripe's changelog notes that the version can be rolled back for 72 hours. That is a useful safety net, but it is not a substitute for testing a full purchase, refund and subscription renewal before the switch.

Conclusion

Stripe's Endive release of September 30, 2026 removes the long-standing payment method types parameter and the Payment Request Button, tightens address rules for SEPA Direct Debit from non-EEA accounts, and adds several billing features. Existing integrations keep running on their current version, so the sensible response is to audit the checkout code, schedule the migration, and test it properly.

If you would like a second opinion on how exposed your payment integration is, or help planning the upgrade, you can get in touch with Entrant Technologies.