Stripe "The payment_method_types parameter is no longer supported": the Endive fix

The Checkout wording: "no longer supported when creating a Checkout Session"

Stripe's support article quotes the message below. Checkout Sessions return it with "when creating a Checkout Session" after "no longer supported", as an invalid_request_error on param payment_method_types, in error bodies developers posted on GitHub in October 2026. Stripe's PaymentIntents and SetupIntents changelog entry names the error code payment_method_types_no_longer_supported; its list of error codes did not include it when we checked on 2026-10-24.

The `payment_method_types` parameter is no longer supported. Payment methods are now managed from your Dashboard settings (https://dashboard.stripe.com/settings/payment_methods). For migration guidance, see https://docs.stripe.com/payments/payment-methods/dynamic-payment-methods.

TypeScript: payment_method_types does not exist in type SessionCreateParams

In a TypeScript app the type check fails before any request is sent: stripe-node 23 removed the parameter from the Checkout, PaymentIntent and SetupIntent param types. On 2026-10-24 we compiled a Next.js checkout route that passes payment_method_types: ['card'] against stripe 23.0.1, and tsc exited with code 2 and this error. With allowed_payment_method_types it compiled, and on stripe 22.6.2, which pins 2026-08-26.dahlia, the original route compiled too.

app/api/checkout/route.ts(9,5): error TS2561: Object literal may only specify known properties, but 'payment_method_types' does not exist in type 'SessionCreateParams'. Did you mean to write 'payment_method_data'?

Why it started after an npm update

Stripe picks the API version for each request from the Stripe-Version header if you set one, then the version your server-side SDK pins, then your account's default. The account default is set by your first request and changes only when you upgrade it in Workbench. So a checkout that worked for months breaks when a dependency update moves stripe-node to 23.x, even though nothing changed in your Stripe account. Staying on stripe-node 22 keeps the old version while you migrate.

Cards only after Endive

Pass allowed_payment_method_types: ['card'] on the Checkout Session, PaymentIntent or SetupIntent. Unlike the old parameter, it silently drops types that do not fit the payment instead of returning an error. It opts that payment out of Dashboard-managed payment methods, so a method you turn on later does not appear until you change code, and it cannot be combined with excluded_payment_method_types, automatic_payment_methods or payment_method_configuration. To drop only a few types, keep dynamic payment methods and pass excluded_payment_method_types.

Confirming a PaymentIntent on the server now needs a return_url

Removing payment_method_types makes redirect-based payment methods eligible, and confirming one on the server without a return_url fails. Add a return_url, or set automatic_payment_methods[allow_redirects] to never to keep those methods out. Payments that use off_session do not need one, and Checkout Sessions handle the return flow themselves.

Stripe.js: paymentMethodTypes in Elements

The same release removed the paymentMethodTypes option from Elements: Stripe.js throws an integration error and does not create the Elements instance. Use allowedPaymentMethodTypes or the Dashboard settings. Endive also removed the Payment Request Button, so elements.create('paymentRequestButton') and the React PaymentRequestButtonElement throw as well.

Checklist

Migrate a checkout route to Endive

1. 01
   Find every place the app sets the old parameter, on the server and in Stripe.js code:

   grep -rnE "payment_method_types|paymentMethodTypes" --include=*.ts --include=*.tsx --include=*.js --exclude-dir=node_modules .

2. 02
   Check which API version your calls use. stripe 23.x pins 2026-09-30.endive; also look for an apiVersion option or a Stripe-Version header that overrides it.

   npm ls stripe

3. 03Delete payment_method_types from each create, update and confirm call, and turn the methods you accept on or off in the Dashboard under Settings, Payment methods. Stripe filters them for each payment's currency and amount.
4. 04Where you need a fixed list, such as cards only, pass allowed_payment_method_types instead, and drop automatic_payment_methods and payment_method_configuration from that call.
5. 05If your server confirms PaymentIntents or SetupIntents, add a return_url, or set automatic_payment_methods[allow_redirects] to never.
6. 06Run a Checkout Session in a sandbox and check the payment page shows the methods you expect. Stripe's upgrade steps also say to move your webhook endpoints to the new version.
7. 07If you upgraded your account's default version in Workbench and something else breaks, Workbench lets you roll it back for 72 hours.

Related

Related guides

• SupabaseStripeStripe webhooks in Next.js and Supabase apps: the questions, answeredGuide
• StripeDo I need a Stripe webhook if I use Stripe Checkout?Guide
• StripeWhy does Stripe say "No signatures found matching the expected signature for payload"?Guide

Sources

Official docs behind this checklist

• Stripe changelog, Endive (2026-09-30)
• Stripe changelog, Remove payment_method_types from Checkout Sessions
• Stripe changelog, Remove payment_method_types from Payment Intents and Setup Intents
• Stripe changelog, Remove paymentMethodTypes from Elements
• Stripe support, Fix the payment_method_types error
• Stripe, Manage payment methods when you upgrade
• Stripe, Dynamic payment methods
• Stripe, API versions
• stripe-node, CHANGELOG (23.0.0)

FAQ

FAQ for builders before launch