API バージョン 2026-07 から、Stripe・Authorize.net・Braintree の入力で支払い方法の識別子フィールドが必須になる。スキーマ上は任意だったが、実際の決済処理には元々必要だった項目。スキーマを実態に合わせる変更。
customerPaymentMethodRemoteCreate ミューテーションを
Stripe / Authorize.net / Braintree の入力で使うとき、支払い方法の識別子フィールドが必須になる。識別子を渡さなくても スキーマ検証は通った。しかしその支払い方法は決済処理に使えず、機能しない状態で作成されていた。
識別子が無いとミューテーションが 検証段階で弾かれる。「機能しない支払い方法が黙って作られる」状況を、最初から防げる。
必須化されるのは、ゲートウェイごとに次の3フィールド。自分が連携しているゲートウェイの行だけ確認すればよい。
| ゲートウェイ | 入力タイプ（Input） | 必須になるフィールド |
|---|---|---|
| Stripe | RemoteStripePaymentMethodInput |
paymentMethodId 必須 |
| Authorize.net | RemoteAuthorizeNetCustomerPaymentProfileInput |
customerPaymentProfileId 必須 |
| Braintree | RemoteBraintreePaymentMethodInput |
paymentMethodToken 必須 |
paymentMethodIdcustomerPaymentProfileIdpaymentMethodToken「スキーマでは任意」だが「実行時には必須」というズレが、これまで存在していた。今回の変更はそのズレを解消する。
現状 customerPaymentMethodRemoteCreate 呼び出し時に該当の識別子フィールドを渡しているなら、変更は不要。そのまま 2026-07 に上げてよい。
2026-07 を採用する前に、自分のゲートウェイに対応する識別子を入力に含めるよう連携を更新する。更新せずに 2026-07 へ上げると、ミューテーションが弾かれる。
customerPaymentMethodRemoteCreate を Stripe / Authorize.net / Braintree のリモート入力で使っている連携のみ。それ以外の作成経路への影響や、過去に識別子なしで作成済みの支払い方法の扱いについては、本記事に 記載なし。必須化が効くのは 2026-07 以降を指定したリクエスト。それより前のバージョンを使っている間は従来どおり（スキーマ上は任意）。アップグレードのタイミングが分岐点。
Stripe の paymentMethodId、Authorize.net の customerPaymentProfileId、Braintree の paymentMethodToken。自分が使うゲートウェイの値だけ確認すればよい。
スキーマ定義上 optional だったフィールドが non-null（required）に変わる。コード生成や型チェックを使っている場合、生成物の更新で コンパイル段階で抜け漏れを検出できる。
識別子を渡していない連携が 2026-07 に上がると、ミューテーションが弾かれる。バージョン採用前にテスト環境で必須フィールドが入っているか確認するのが安全。
これまでは識別子なしでも作成自体は成功し、決済処理の段になって初めて使えないと分かる遅延した失敗だった。必須化により、作成リクエストの時点で失敗するため、ユーザーがチェックアウトで詰まる前に問題に気づける。データ品質と障害の早期発見の両面でメリットがある。
customerPaymentMethodRemoteCreate の呼び出し箇所を洗い出し、Stripe/Authorize.net/Braintree それぞれで識別子を渡しているかを点検項目に追加。テスト環境を 2026-07 に上げて検証する。paymentMethodId / customerPaymentProfileId / paymentMethodToken）。grep で呼び出しを機械的に拾える。customerPaymentMethodRemoteCreate の支払い方法識別子が必須に。