判断の出発点
まず、顧客が何を利用でき、その権利がいつ変わるかを決めます。Stripeの説明でも、支払い、請求書、購読は関連しながら別の状態を持ちます。自社アプリには明示的な利用権限の方針が必要です。
具体例で考える
架空の月額チームプランで、期間途中に上位プランへ変更したものの支払いに追加操作が必要になり、管理者が再読込したとします。旧プランを継続するかを決め、未確認の変更を完了と表示せず保留を伝えます。
決済の状態と利用権を並べる
購読状態、アプリが与える権利、顧客への表示を状態図にします。更新時の解約なら期限まで使え、最初の支払失敗なら登録未完了かもしれません。遷移ごとに正式なイベントやサーバー照会を結び付け、変更要求者と保存済みデータをどう扱うか記します。提供元のイベントを実装する前に、約束を確認できる形にします。
中断したプラン変更を試す
提供元の試験機能で変更を始め、ブラウザを閉じ、通知を繰り返し、処理を遅らせます。購読が二つできたり成功ページだけで権利が増えたりしないか確認します。再開できる状態と調査用の参照番号を示し、決済認証情報は出しません。古い通知は正式な現在状態と比較して扱い、一時的に両システムが違うときの照合責任を決めます。
顧客が理解できる解約にする
将来の請求停止、機能の利用停止、作業の出力、データ削除を分けます。解約で直ちに記録が消えるかを推測させず、招待メンバーと待機処理への影響も決めます。不可逆操作には実際の方針と適切な確認を示します。開発に参加していない人に試用終了、変更、支払失敗、解約、再開をテストしてもらいます。一回の課金成功で見えない製品判断が分かります。
選択肢とその負担
即時、更新時、支払確認後の適用など、約束と提供元の仕様に応じて選びます。試用終了、集金失敗、解約、再開は別々に定義します。決済画面を外部へ任せても利用権のルールは残ります。
見落としやすい点
決済からブラウザが戻っただけで権限を付けないことです。サーバーで確定した状態を確認し、通知の再送を安全に扱います。請求とチーム所属も別の関係として保持します。
依頼前に確認すること
解約後に保存済みの仕事はどうなるか。誰がプランを変更するか。保留中の支払いを支援担当がどう説明するか。決済画面を描く前にSaaS設計で決めます。