ECサイトや予約サイトの決済に Stripe を組み込み、サーバー側を Node.js で書いているなら、依存関係の更新で stripe のメジャーバージョンが上がるPRが届くことがあります。2026年10月1日に npm へ公開された stripe 23.0.0 は、番号が1つ上がっただけに見えて、決済のリクエストの中身と Webhook の検証の挙動が変わります。
変更履歴には「⚠️」の付いた破壊的変更が多数並んでいます。そのうち決済の画面とWebhookの受け口に直接関係するものを、22.6.2 と 23.0.0 を手元で動かした結果とあわせて整理します。テスト用のローカルサーバーにリクエストを送らせる方法で確かめており、Stripe の本番・サンドボックスの環境には接続していません。
SDKを上げると、送るAPIバージョンも変わる
変更履歴の 23.0.0 の冒頭には「This release changes the pinned API version to 2026-09-30.endive」とあります。README の設定項目の表でも、apiVersion を設定しなければ「stripe-node will use the latest version at the time of release」と説明されています。
送信先をローカルのサーバーに向けて、実際のヘッダーを記録しました。
stripe 22.6.2 sent Stripe-Version: 2026-08-26.dahlia
stripe 23.0.0 sent Stripe-Version: 2026-09-30.endive
stripe 23.0.0（apiVersion: '2026-08-26.dahlia' を指定） sent Stripe-Version: 2026-08-26.dahliaapiVersion を指定していないコードは、パッケージを上げた時点で Stripe に送るAPIバージョンが変わります。指定しておけば、SDKを上げても以前のバージョンで送れます。ただし README は「our types only reflect the latest API version」としており、TypeScript の型は新しいバージョンに合わせて変わります。古いバージョンのまま使うと、型と実際の応答がずれる箇所が出る点に注意が必要です。
Checkoutの決済手段の指定が型とAPIから消えた
23.0.0 の生成コードの変更には「Remove support for payment_method_types on Checkout.SessionCreateParams, PaymentIntentConfirmParams, PaymentIntentCreateParams, …」とあり、代わりに「Add support for allowed_payment_method_types on Checkout.SessionCreateParams and Checkout.Session」が加わっています。
Checkout のセッションを payment_method_types: ['card'] で作るコードを、両方の版で型チェックしました。
# stripe 23.0.0
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'?
error TS2561: ... but 'payment_method_types' does not exist in type 'PaymentIntentCreateParams'.
# stripe 22.6.2
（エラーなし。逆に allowed_payment_method_types は存在しないとエラー）TypeScript ならビルドで止まるので気づけます。注意が要るのは JavaScript のまま書いている場合です。23.0.0 でも、コードに書いた payment_method_types はそのままリクエストの本文に入って送られました（payment_method_types[0]=card）。SDK は止めないので、結果は Stripe 側の扱いで決まります。
Stripe の API 変更履歴（2026-09-30.endive の破壊的変更）によると、このAPIバージョンでは Checkout Session の作成時に payment_method_types を渡すと400 エラーが返ります。Payment Intents（作成・更新・確定）と Setup Intents（作成・更新）でも同じで、エラーコードは payment_method_types_no_longer_supported と書かれています。つまり apiVersion を指定していない JavaScript のコードは、SDK を上げた時点で決済画面を作れなくなります。代わりに、ダッシュボードで決済手段を管理する動的な決済手段か、allowed_payment_method_types を使います。変更履歴は、allowed_payment_method_types は通貨や金額に合わない決済手段をエラーにせず除外する、と説明しています。編集部は Stripe の API に接続しておらず、400 エラーは変更履歴の記載によるもので、実際の応答は確かめていません。更新の前に、サンドボックスで Checkout の作成から決済完了まで通すことを勧めます。
allowed_payment_method_types の型には、paypay も含まれていました。PayPay への対応（paypay_payments の capability、payment_method_details.paypay など）も 23.0.0 で加わった項目です。Stripe の API 変更履歴では、日本に拠点のある対象アカウント向けの1回払いのオンライン決済として案内されており、定期支払い・サブスクリプションには対応していません。
Webhookの署名検証で変わる2つの挙動
決済の完了を Webhook で受けて注文を確定している場合は、こちらの方が影響が大きいかもしれません。変更履歴は次のように書いています。
stripe.webhooks.signature.verifyHeader()andverifyHeaderAsync()previously skipped timestamp tolerance verification when thetoleranceargument was omitted. They now default toWebhook.DEFAULT_TOLERANCEPassing 0 to stripe.webhooks.constructEvent now properly skips timestamp tolerance verification. Previously, passing 0 would perform verification with the default tolerance Webhook.DEFAULT_TOLERANCE.
SDKの generateTestHeaderString で、署名の時刻を「今」「10分前」「1時間前」にしたヘッダーを作り、3通りの呼び出し方で検証しました（DEFAULT_TOLERANCE はどちらの版も300秒）。
読み取れることは2つです。
signature.verifyHeader()を直接呼んでいるコードは、23.0.0 から古い署名を拒否するようになります。受信が遅れたイベントを後から検証する処理があれば、エラーになる可能性がありますconstructEvent(..., 0)と書いているコードは、23.0.0 から時刻の確認をしなくなります。22.6.2 までは 0 を渡しても300秒の確認が働いていたため、「0は既定値」のつもりで書いたコードは、気づかないうちに古い署名（再送された署名）を受け入れる状態に変わります
署名そのものの検証は引き続き行われますが、時刻の確認は、盗まれた正規のリクエストを後から送り直される攻撃への備えです。リポジトリの中を次のように検索し、0 を渡している箇所があれば、引数を外すか秒数を明示します。
grep -rnE "constructEvent(Async)?\(|verifyHeader(Async)?\(" --include=*.js --include=*.ts --include=*.mjs --include=*.cjs src/ server/ api/ 2>/dev/nullそのほかに確かめる変更
- Node.js 18 のサポート終了: 変更履歴に「Node.js 20 is now the minimum supported version」。package.json の
enginesも>=18から>=20に変わりました。サーバーレスの実行環境で Node.js のバージョンを固定している場合は先に上げます。Node.js の版ごとの保守期限はNode.js 24は10月20日に保守期へで整理しています - エラーの種類の変更: 応答の本文が途中で切れた場合は
StripeAPIErrorではなくStripeConnectionErrorになります。エラーの種類で再試行を分けている処理は見直します - 型の書き出しの削除:
ErrorTypeが書き出されなくなり、Stripe.errorsを使うよう案内されています - 特定商取引法の表示URL: 型に
Account.business_profileのspecified_commercial_transactions_act_urlが加わりました（Connect でアカウントを作るプラットフォーム向け）。日本向けの項目で、23.0.0 では型チェックが通り、22.6.2 では存在しないとエラーになりました
更新の進め方
以下は編集部の提案です。
- API バージョンを先に固定する。 22.x のまま
apiVersion: '2026-08-26.dahlia'を明示しておくと、SDKの更新とAPIバージョンの更新を別々に進められます - SDK を 23.0.0 に上げ、型エラーと Webhook の呼び出しを直す。
payment_method_typesの置き換え、constructEventの第4引数、verifyHeaderの直接呼び出しを確認します - サンドボックスで決済を一通り通す。 カード決済、利用している決済手段、返金、Webhook の受信と注文の確定まで確かめます
- 最後に API バージョンを上げる。 ダッシュボードの Webhook の送信設定のバージョンもあわせて確認します
チャージバックへの備えなど、決済の運用面はフレンドリーフラウドとチャージバックへの備え、npm の依存部品の版を確かめる手順はsharpのAVIF脆弱性 — Astro・Next.jsで0.35.4以上か確かめるでも扱っています。
確認した範囲
2026年10月11日に、stripe/stripe-node の CHANGELOG.md（23.0.0、2026-09-30）、npm に公開された stripe 23.0.0 の README・package.json、registry.npmjs.org の公開日時を確認しました（資料調査）。あわせて Linux 上の Node.js 22.22.0 で stripe 22.6.2 と 23.0.0 を入れ、送信先をローカルのHTTPサーバーに向けて
Stripe-Versionヘッダーと本文を記録し、TypeScript 5 で型チェックを行い、generateTestHeaderStringで作った署名で Webhook の検証を比べました（実機検証）。2026年10月16日には、Stripe の API 変更履歴（2026-09-30.endive）のpayment_method_typesの削除と PayPay の追加の項目も確認しました。Stripe の API（本番・サンドボックス）には接続しておらず、400 エラーなどの実際の応答は確認していません。
決済まわりのライブラリ更新や Webhook の受け口の点検は、開発・AI・自動化のご相談からお問い合わせください。
参考資料
- stripe/stripe-node — CHANGELOG.md（23.0.0 - 2026-09-30）
- stripe/stripe-node — README.md（API バージョンと TypeScript の型、Webhook の署名）
- npm registry — stripe（公開日時）
- Stripe Docs — Removes the payment method types parameter from Checkout Sessions（2026-09-30.endive）
- Stripe Docs — Removes the payment method types parameter from Payment Intents and Setup Intents（2026-09-30.endive）
