API 2026-04 リリース候補（RC）から、契約作成ミューテーションの paymentMethodId が必須でなくなった。支払い方法が無い／失効していても契約データを移行できる。
paymentMethodId）が必須だった。paymentMethodId が必須項目。カードが失効・欠落している契約は API では作成できず、移行が止まっていた。
paymentMethodId は任意に。支払い方法が欠落・失効していても契約を作成でき、移行を完了させられる。
今回 paymentMethodId が必須でなくなったのは、以下の 2 つの契約作成ミューテーション。
subscriptionContractCreateサブスクリプション契約を作成する標準のミューテーション。支払い方法 ID の指定が任意になった。
subscriptionContractAtomicCreate契約とライン等をまとめて一括（アトミック）に作成するミューテーション。こちらも支払い方法 ID が任意に。
| 項目 | 従来 | API 2026-04（RC） |
|---|---|---|
paymentMethodId |
必須 指定しないと契約を作れない | 任意 省略しても契約を作成できる |
| 支払い方法が失効/不在の契約 | 作成不可 | 作成可能 |
| 移行ユースケース | 有効なカードが揃わないと移行が止まる | そのまま契約データを移行できる |
| 対象ミューテーション | — | subscriptionContractCreate / subscriptionContractAtomicCreate |
| 適用バージョン | — | API 2026-04 リリース候補（RC） |
この挙動はリリース候補（release candidate）版で提供。リクエストで 2026-04 を指定する必要がある。正式 GA 時期・以前バージョンへの反映は記載なし。
支払い方法が無い契約で次回課金がどう扱われるか、いつ支払い方法を求められるかは本記事に記述なし。実運用前に docs と挙動検証が必要。
paymentMethodId が required から optional になった、という入力スキーマ上の変更。新しいフィールドや別ミューテーションが増えたわけではない。
記事が明示する用途は、支払い方法が欠落・失効した契約のマイグレーション。新規の通常契約フローを変えるための機能ではない。
subscriptionContractCreate と subscriptionContractAtomicCreate の両方。アトミック作成を使う一括移行スクリプトでも効く。
2026-04 はリリース候補。本番採用前に仕様変更リスクを織り込み、リクエストの API バージョン指定を 2026-04 に固定する。
支払い方法なしで作った契約に、いつ・どうやって支払い方法を紐づけ直すか、その間の課金挙動はどうなるかは本記事に記載なし。再アタッチ手順・課金再開フローは docs（サブスクリプション契約の構築方法）と実機検証で詰めること。
subscriptionContractAtomicCreate を使い、paymentMethodId を省略して契約データだけ先に移行。