orderId は session token がバインドされている customer に属している必要があります。ある customer 用に mint されたトークンは、別の customer のサブスクリプションをキャンセルできません。キャンセル動作
保留中のプラン変更サブスクリプションをキャンセルすると、その変更は無効になります。新サブスクリプションは直接
canceled となり、PSP キャンセルが即時送信されるため、予定の切替時刻に有効化も課金も発生しません。元のサブスクリプションは生効状態に戻りません —— canceling のまま一方向に canceled へ進み、サブスクリプションの再開は 400 を返します。支払いを継続するには新規注文が必要です。past_due のサブスクリプションのキャンセルは期間終了時ではなく即時に有効となり、「キャンセル予定・X 日まで利用可能」のメールも送信されません（課金期間は既に終了しているため）。このキャンセルは取り消せません：サブスクリプションの再開は「キャンセル要求時点で未払いの請求があった」サブスクリプションに対して 400 を返します。リクエストボディ
理由が保存されるのは購入者側の認証情報による呼び出しで、かつキャンセルが実際に成功した場合のみです。1 回のキャンセル操作につき 1 行なので、キャンセル → 再開 → 再キャンセルでは 2 行残ります。理由の書き込みは副経路であり、失敗してもキャンセル自体は成功しレスポンスは変わりません。キャンセルが失敗した場合（400 / 500 / 502）は何も保存されません。マーチャントは保存された理由を GraphQL 経由で参照します。
cancelReason を省略した場合の挙動は、呼び出しに使った認証情報によって異なります：
2 つのチャネルは意図的にこのセンチネル値を共有しません。「一度も尋ねていない」と「尋ねたが回答を拒んだ」を同一の値にまとめると、マーチャントは
not_provided の割合を解釈できなくなります。自作の連携でも理由の選択肢を提示し、スキップを分母に含めたい場合は、cancelReason を明示的に送信してください（値域は開放されており、例えば not_provided を使えます）。
リクエスト例
成功レスポンス (200)
レスポンスフィールド
エラー
リトライポリシー：4xx は一切リトライしない — リクエストを修正してから再送信。5xx は指数バックオフでリトライ（5s 開始、最大 3 回）。