Admin GraphQL API / 2026-04 RC

サブスクの課金試行から
「未払い注文」を作れるようになった

subscriptionBillingAttemptCreate に新フィールド paymentProcessingPolicy が追加。有効な支払い方法が無くても、注文を「未払い」のまま作成できる選択肢が増えた。

このページの構成
  1. そもそも何が変わるのか(30秒で理解)
  2. paymentProcessingPolicy の 2 つの値
  3. 仕組み図解 : 課金試行から注文ができるまで
  4. 2 つの挙動の比較
  5. 前提・注意(バージョンと記載範囲)
  6. 技術者が押さえるべき5つのポイント
  7. 業務に活かせる3つのユースケース
  8. 提案で使える1行サマリ

1そもそも何が変わるのか

サブスクの定期課金(billing attempt = 契約に基づいて顧客に請求するアクション)を作るときに、
支払い方法が無効でも「未払い注文」を作成できる新しいオプションが追加された。
挙動を切り替えるのが新フィールド paymentProcessingPolicy

これまで : 有効な支払い方法が必須

課金試行で注文を成立させるには、契約に有効な支払い方法がある前提。無ければ注文は作れなかった。

UNPAID

これから : 未払いのまま注文化も可

paymentProcessingPolicySKIP_PAYMENT_AND_CREATE_UNPAID_ORDER を指定すると、有効な支払い方法が無くても未払い注文を作成する。

2paymentProcessingPolicy の 2 つの値

既定 / 省略時

FAIL_UNLESS_VALID_PAYMENT_METHOD

フィールドを指定しない場合も、この値を指定した場合も挙動は同じ。有効な支払い方法が無いと注文の作成に失敗する(=従来通りの挙動)。

新オプション

SKIP_PAYMENT_AND_CREATE_UNPAID_ORDER

サブスク契約に有効な支払い方法が無くても、システムが未払い注文を作成する。決済処理をスキップして注文だけ先に立てるイメージ。

フィールドを渡さない=従来挙動。つまり既存の subscriptionBillingAttemptCreate 呼び出しは何もしなければ今まで通り動く(後方互換)。

3仕組み図解 : 課金試行から注文ができるまで

サブスク契約 subscription contract subscriptionBilling AttemptCreate + paymentProcessingPolicy 支払い方法 は有効? 有効 → 通常の注文を作成 (決済処理が走る) 無効でも → 未払い注文 SKIP_PAYMENT_AND_ CREATE_UNPAID_ORDER 指定時
従来挙動(既定 / FAIL_UNLESS_VALID_PAYMENT_METHOD)では、支払い方法が無効なら注文は成功しない。未払い注文を作りたいときだけ SKIP_PAYMENT_AND_CREATE_UNPAID_ORDER を明示する。

42 つの挙動の比較

項目FAIL_UNLESS_VALID_PAYMENT_METHOD(既定・省略時)SKIP_PAYMENT_AND_CREATE_UNPAID_ORDER
有効な支払い方法が必要か 必須 無いと注文作成に失敗 不要 無くても注文を作成
作られる注文 通常の注文(決済処理あり) 未払い注文(決済をスキップ)
フィールド省略時の扱い これと同じ
後方互換 従来どおり 明示指定が必要な新挙動

5前提・注意(バージョンと記載範囲)

2026-04 RC

API 2026-04 のリリース候補版

この機能は 2026-04 release candidate で利用可能になったもの。正式版での提供時期や仕様確定については記事に記載なし

実装詳細はドキュメント参照

具体的な実装手順は「サブスク契約の構築(building a subscription contract)」のドキュメントを参照、と案内されている。API スキーマの細部やエラー挙動はそちらで確認する。

対象は Admin GraphQL APIsubscriptionBillingAttemptCreate ミューテーション。未払い注文の後続フロー(請求書発行・入金消込・督促など)の具体は記事に記載なし。

6技術者が押さえるべき5つのポイント

FIELD

1. 追加点は入力フィールド 1 つ

subscriptionBillingAttemptCreatepaymentProcessingPolicy を渡すだけ。既存の課金試行フローに 1 フィールド足す差分で済む。

2. 省略すれば従来挙動(後方互換)

未指定時は FAIL_UNLESS_VALID_PAYMENT_METHOD と同じ。既存コードは触らなければ挙動が変わらない。

UNPAID

3. 未払い注文は「決済スキップ」

SKIP_PAYMENT_AND_CREATE_UNPAID_ORDER は決済処理を行わずに注文を作る。入金の回収は注文作成後の別フローで担保する設計が前提。

4. 分岐は支払い方法の有効性で決まる

挙動は「契約に有効な支払い方法があるか」に依存。未払い注文化を狙うフローでは、契約側の支払い方法状態を意識した実装になる。

RC

5. 2026-04 RC なので本番投入前に固定&検証

リリース候補版で利用可能になった機能。本番採用時は API バージョンを 2026-04 に固定し、未払い注文の生成・後続処理をサンドボックスで検証してから載せる。実装の詳細は「building a subscription contract」ドキュメントに従う。

7業務に活かせる3つのユースケース

UNPAID
USE CASE 1

B2B サブスクの「請求書払い(後払い)」運用

課題
法人向け定期購入で、毎回カード決済ではなく請求書・銀行振込で後から回収したい。従来は有効な支払い方法が無いと注文を作れず、サブスクの自動課金に乗せられなかった。
打ち手
課金タイミングで SKIP_PAYMENT_AND_CREATE_UNPAID_ORDER を指定し、未払い注文として注文を作成。請求・入金は別途オフラインで処理。
効果
カード以外の支払い条件の取引先もサブスクの定期サイクルに乗せられ、注文起票が自動化できる。
技術メモ
subscriptionBillingAttemptCreate 実行時にポリシーを切り替えるだけ。入金消込は注文作成後の自社/外部フローで担保する。
retry
USE CASE 2

決済失敗時の「注文だけ先に立てる」ダニング設計

課題
カード期限切れなどで課金が通らないと、これまでは注文自体が成立せず、契約と注文の対応が崩れて督促・再課金の管理が煩雑だった。
打ち手
支払い方法が無効な周期では未払い注文を作成しておき、支払い方法の更新後に回収・消込する運用に切り替える。
効果
サイクルごとの注文が漏れなく台帳化され、未回収の可視化と督促フローが組みやすくなる。
技術メモ
既定(フィールド省略)では失敗する挙動なので、ダニング対象のみ明示的に SKIP_PAYMENT_AND_CREATE_UNPAID_ORDER を渡す分岐を実装する。
注文 外部
USE CASE 3

外部決済・自社課金システムと連携する定期注文の起票

課題
決済は外部システム/自社の与信フローで行い、Shopify 側には注文の事実だけ作りたいが、有効な支払い方法を Shopify に持たせないと注文化できなかった。
打ち手
課金試行で未払い注文を作成し、決済自体は外部側で処理。Shopify は注文・契約の正本として使う。
効果
決済レイヤーと注文管理レイヤーを分離でき、既存の与信/決済資産を活かしたまま Shopify サブスクに乗せられる。
技術メモ
実装は「building a subscription contract」ドキュメントに従う。未払い注文の後続(決済反映の同期)は別途設計が必要。

8提案で使える1行サマリ

「サブスクの課金試行に paymentProcessingPolicy が追加。
SKIP_PAYMENT_AND_CREATE_UNPAID_ORDER を指定すれば、有効な支払い方法が無くても『未払い注文』を作れる。
省略時は従来どおり(有効な支払い方法が必須)=後方互換。後払い・ダニング・外部決済連携の起票に効く(2026-04 RC)。」