Fincs

運営アドミン / 契約・支払い管理

運営アドミン / 契約・支払い管理

本ページは 2 段構成。上段が biz/CS 向け（ユーザー提示可）、下段（## 🔧 実装詳細 以降）が dev 向け。biz/CS がユーザーへ提示・転用してよいのは上段のみ。

概要

運営アドミン向けの契約・支払い管理機能群。CS 対応・障害復旧・例外処理として、契約状態の調整や支払いに関わる代行操作をまとめて扱う。

主な対象操作:

  • 無料受講者登録: テストユーザー（社内検証用ユーザー）に対する無料契約の付与・解除
  • 契約の強制論理削除: CS 案件で誤契約を取り消したい場合などの代理操作
  • クーリングオフ処理: 契約解除日付の即日設定 + 内部的な返金扱いフラグの設定（決済プロバイダへの返金実行は別経路）
  • 入会日変更: テスト用途や障害復旧で契約開始日を任意の日付に変更
  • 強制退会: 任意の終了日を指定して受講者を退会扱いにする
  • 銀行振込の入金確認完了: 振込待ちの状態を入金済に切り替えて契約成立とする
  • 銀行振込ユーザー検索: 振込人名義 / 振込コードでフィルタして該当受講者を検索
  • 返金実行: 決済プロバイダ側の返金実行は 助言会社系の別ロール が担当。本機能では行えない

主な利用想定は、銀行振込の入金確認・反映（営業日対応）、不適切契約の取り消し、テストユーザー向けの無料契約付与、クーリングオフ申請への対応、入会日付の不具合修正など。

クーリングオフと返金実行の分離: 運営アドミンがクーリングオフ操作を実行すると、契約終了日と内部の返金扱いフラグは設定されるが、決済プロバイダ側への返金実行は自動では走らない。返金実行は助言会社系の別ロールでのみ実行可能で、CS 対応では「クーリングオフ操作」と「返金実行」の 2 ステップを別担当で行う運用となる。

支払い失敗の代理再試行は不可: 自動決済が失敗した場合の再試行は、受講者本人による画面操作のみで実行可能。運営アドミンが代理で受講者の決済を再試行する経路は提供していない。

テストユーザー限定の機能: 無料受講者登録機能は、内部的にテストユーザーフラグが立っているユーザー（社内検証用）に対してのみ利用可能。一般受講者へは無料契約付与不可。

📝 レビュー観点:

  • 目的: 契約・支払いに関する CS 対応・障害復旧・例外処理
  • 誰が使うか: 運営アドミン（返金は助言会社系）
  • どこで使うか: 運営アドミン汎用ツール経由
  • 隣接機能との関係: 料金プラン管理（../plan-management/price.md）、ユーザー管理（./user.md）、月次決済バッチ
  • CS 問い合わせで頻発する論点: 「銀行振込の入金確認完了が反映されない」「決済失敗の手動再試行」「クーリングオフでの返金挙動」「無料受講者登録の条件（テストユーザー限定）」
  • [本機能特有] クーリングオフは内部的な返金フラグのみ: 実際の決済プロバイダ返金は別経路
  • [本機能特有] 銀行振込キャンセルの運営経路は無し: 自動バッチで未入金期限超を処理
  • [本機能特有] 決済失敗の運営代理再試行は不可: 受講者本人操作のみ
  • [本機能特有] 返金は別ロール（助言会社系）の経路: 運営アドミンとロールが分かれる

利用シナリオ

シナリオ 1: 銀行振込の入金確認完了

受講者が銀行振込で入会申請を行った後、運営側で入金確認が取れたタイミングで運営アドミンが「入金確認完了」操作を実行。これにより該当の銀行振込が「入金済」状態に切り替わり、契約成立 + 入会完了メールが送信される。

シナリオ 2: 不要なテスト契約の解除

社内検証で付与したテストユーザー向けの無料契約を、検証完了後に運営アドミンが解除。テストユーザー条件を満たすユーザーに対してのみ操作可能で、一般受講者の契約には影響しない。

シナリオ 3: クーリングオフ申請への対応

受講者からのクーリングオフ申請に対して、まず運営アドミンが「クーリングオフ操作」を実行（契約終了日を当日に設定 + 内部の返金扱いフラグを ON）。その後、助言会社系ロール担当者が決済プロバイダ側の返金実行を別途実施する 2 ステップフロー。

シナリオ 4: 強制退会（任意終了日指定）

規約違反や運営判断で受講者を退会扱いにする場合、運営アドミンが強制退会操作を実行。任意の終了日を指定可能（指定しない場合は当日）。退会後は自動更新フラグが OFF になり、次回更新は発生しない。

シナリオ 5: 入会日変更（テスト用 / 障害復旧）

テスト用途や障害復旧の一環で、受講者の契約開始日を任意の日付に変更。新規契約条件のテスト確認や、過去の不具合で開始日が誤って記録されたケースの修正に利用。

シナリオ 6: 銀行振込ユーザーの検索

「振込連絡が届いたが、どの受講者か特定できない」ケースで、振込人名義（口座名義）または振込コードを使って該当受講者を検索。

よくある失敗ケース

  • テストユーザー条件違反: 無料受講者登録機能でテストユーザー以外を指定するとエラー
  • 既に契約中の受講者へ無料契約付与: 重複契約として弾かれる
  • 対象契約が不在: クーリングオフ・契約論理削除・強制退会で、該当する有効契約がないとエラー
  • 既に返金済の支払いに対する重複返金: 返金済フラグ立ち済みの履歴に対する再返金は弾かれる
  • 支払い失敗の運営代理再試行: 機能として提供していないため不可（受講者本人での再試行を案内）
  • 銀行振込の運営手動キャンセル: 機能として提供していない（自動バッチで未入金期限超を処理）
  • クーリングオフ後の決済プロバイダ返金漏れ: クーリングオフ操作のみで返金実行が走らないため、別途返金実行を漏れなく実施することが必要

権限別仕様

権限定義は ../user-roles.md 参照。用語は ../terminology.md。

横断軸

操作 運営アドミン 助言会社系 受講者 講師
無料受講者登録（テストユーザー限定） ○ × × ×
無料受講者登録解除 ○ × × ×
契約論理削除 ○ × × ×
クーリングオフ（フラグ更新のみ） ○ × × ×
入会日変更 ○ × × ×
銀行振込ユーザー検索 ○ × × ×
銀行振込の入金確認完了 ○ × × ×
強制退会 ○ × × ×
返金実行（決済プロバイダ呼出） × ○ × ×

📝 レビュー観点:

  • 返金は助言会社系の権限: 運営アドミンとはロールが分かれている。本ページのスコープに含めるか別 PSD（助言会社系）に切り出すか確認

機能詳細（ふるまい）

無料受講者登録（テストユーザー限定）

  • テストユーザーフラグが立っているユーザーへのみ、指定講座の無料契約を付与
  • 既に有効契約があるユーザーへは登録不可（重複契約エラー）
  • 入会完了メールは送信しない（テスト用途のため）

無料受講者登録解除

  • テストユーザーに付与した無料契約を解除（論理削除）
  • テストユーザー以外のユーザーには利用不可

契約の論理削除

  • 指定受講者の指定プラン契約を強制的に論理削除
  • 通常ユーザーの契約に対しても実行可能（CS 対応で誤契約を取り消すケース）
  • 支払履歴の返金扱いは自動では行われないため、必要に応じて別途返金実行

クーリングオフ

  • 契約終了日を当日に設定 + 内部的な返金扱いフラグを ON
  • 決済プロバイダへの返金実行は別経路（助言会社系ロール） で実施
  • 運営アドミンによる本操作だけでは、受講者の決済自体は取り消されない点に注意

入会日変更

  • 契約開始日を任意の日付に変更
  • テスト用途・障害復旧での利用を想定（一般 CS 対応では原則使用しない）

銀行振込ユーザー検索

  • 振込人名義（口座名義）または振込コード（6 桁の数字）で該当する受講者を検索
  • 入金確認時の本人特定に利用

銀行振込の入金確認完了

  • 銀行振込待ちの状態を「入金済」に切替して契約成立
  • 切替時に重複契約・受講者数上限のチェックを実施
  • 切替成功時に入会完了メールを自動送信
  • 旧経路（廃止済み）を使用した場合はエラーで弾かれる

強制退会

  • 指定受講者の指定講座の契約を退会扱いにする
  • 終了日（end_date）は任意指定可能。未指定の場合は当日扱い
  • 自動更新フラグを OFF にし、次回更新を発生させない

決済失敗の手動再試行（提供していない機能）

  • 自動決済の失敗に対する運営代理での再試行は 提供していない
  • 受講者本人が画面から再決済を行う運用となる
  • 「自動決済失敗時のみ手動契約更新可」の特殊条件もあるが、いずれも受講者本人操作前提

📝 レビュー観点:

  • 入力 → 処理 → 出力: 経路入力 → 即時実行
  • エッジケース: 既契約者への再付与、テストユーザー条件違反、銀行振込の二重確認
  • エラー表示: user.not.test.user、contract.already.contract、contract.not.exist.contract、refund.already.refunded
  • [本機能特有] 銀行振込の旧経路は廃止: 古い bank_transfer_contract/{user_id}/... は弾かれる

admin 操作

本ページ全体が運営アドミン操作の集約。

該当なし / 実装されていない

  • 銀行振込の運営からの手動キャンセル: 自動バッチのみ、運営からの手動キャンセル経路無し
  • 決済失敗の運営代理再試行: 未実装（受講者本人操作のみ）
  • クーリングオフ時の決済プロバイダ返金の自動呼出: 未実装（フラグ更新のみ、別経路で返金実行）
  • bank_transfer.transfer_status の cancelled 値: enum に未定義（自動キャンセルバッチでの扱いを要確認）

📝 レビュー観点:

  • クーリングオフと返金実行を 1 経路に統合する必要性
  • 決済失敗時の運営代理経路の必要性

品質 / 約束事項

  • 応答性: 即時反映
  • 信頼性: トランザクション境界に依存。入金確認完了・強制退会等は単一トランザクション
  • 制限値:
    • 振込コード: 6 桁数字
    • 無料受講者登録: テストユーザー限定
  • データ保持: 論理削除（契約）、内部的な返金状態フラグで管理（dev 下段に詳細）

📝 レビュー観点:

  • [本機能特有] クーリングオフの内部状態と決済プロバイダ状態の整合

変更履歴（リリースノート候補）

v2.29.2: 2026-05-04（PSD 初版）

  • [PSD 追加] 本ドキュメント初版作成。v2.29.2 時点の実装を起こし。機能追加・変更は含まない

📝 レビュー観点:

  • 過去の主要変更（銀行振込フロー導入 / 旧経路廃止 / クーリングオフ追加 等）

関連ドキュメント

このページの内容を AI に質問しますか？
関連 spec を自動抽出して ChatGPT / Claude などに渡せます。
AI Prompt で開く →