課金を自動化しようと決めたものの、いざ作り始めると手が止まってしまう。そんなことはありませんか？
- 「支払いの処理、利用権の管理、通知……全部が1つのコードに絡まっていく」
- 「どこで何を記録すればいいのか、決められない」
- 「あとから機能を足したら、既存の部分が壊れそうで怖い」
こうした悩みの多くは、仕組みを役割ごとの「箱」に分けて、箱どうしの境界を決めることで解消できます。
今回は、課金の仕組みを5つの箱に分ける考え方と、そのあいだを流れる「知らせ」の扱い方を紹介します。
- 課金の仕組みを分ける5つの箱と、それぞれの役割
- 箱どうしの境界を決める3つのルール
- 支払いから利用開始までの流れ
- 利用状態をシンプルに保つコツと、よくある落とし穴
課金の仕組みを5つの箱に分ける
まずは、仕組みの中にどんな役割があるかを分けてみます。
| 箱 | 役割 | 持つもの | 持たないもの |
|---|---|---|---|
| 決済 | 支払いの受付と実行 | カード情報など支払いに必要な情報 | アプリの利用状態 |
| 受付 | 決済からの知らせを受け取る | 受け取った知らせの記録 | 重い処理、判断のロジック |
| 台帳 | 契約と利用状態の「正しい記録」 | 誰が、どのプランで、いつまで使えるか | カード情報 |
| 提供 | アプリの機能を使わせる | 機能そのもの | 支払いの詳細 |
| 通知 | 利用者や自分に知らせる | 送った履歴 | 判断のロジック |
ここで大事なのは、「持たないもの」を決めることです。たとえば提供の箱が支払いの詳細を知らなければ、決済の仕組みを変えてもアプリ側は影響を受けません。
境界を決める3つのルール
ルール1：支払い情報は自分で持たない
カード番号などの支払い情報は、決済サービスの中だけにある状態にします。自分の仕組みが扱うのは、「誰が、どのプランで、払ったかどうか」という結果だけで十分です。
ルール2：利用できるかは「台帳」だけを見て決める
提供の箱は、決済サービスに直接問い合わせるのではなく、台帳の記録を見て利用できるかを判断します。判断の根拠が1か所にまとまるので、食い違いが起きたときも原因を追いやすくなります。
ルール3：受付は「受け取って記録する」だけ
受付の箱で複雑な処理をしようとすると、処理中の失敗で知らせそのものを取りこぼしやすくなります。まずは確実に受け取って記録し、台帳の更新はそのあとという順番にしておくと、失敗してもやり直せます。
「受け付けはすぐ、処理はあとで」という考え方は、n8nのトリガー設計でも紹介した「組み合わせ型」と同じです。
n8nのトリガー設計｜Webhookで始める「起きたら動く」自動化
支払いから利用開始までの流れ
5つの箱をつなぐと、支払いから利用開始までは次のような流れになります。
- 利用者が、決済サービスの画面で支払う
- 決済サービスから、受付に「支払い完了」の知らせが届く
- 受付は、知らせが本物かどうかを確かめてから記録する
- 台帳は、「この知らせは処理済みか」を確認してから、利用状態を更新する
- 提供は、台帳を見て機能を使えるようにする
- 通知は、利用者に「使えるようになりました」を伝える
ポイントは3と4です。「本物かどうか確かめる」「二重に処理しない」の2つがあるだけで、仕組みの信頼性は大きく上がります。多くの決済サービスには、知らせが本物かどうかを検証するための仕組みが用意されているので、公式ドキュメントを確認しておきましょう。
利用状態は少なく、わかりやすく持つ
台帳に記録する利用状態は、できるだけ少なくします。たとえば、次のような形です。
| 状態 | 意味 | 使えるか |
|---|---|---|
| 有効 | 支払いが確認できている | 使える |
| 支払い待ち | 更新の支払いがまだ確認できていない | 使える（猶予期間を設ける場合） |
| 停止 | 支払いが確認できず、利用を止めている | 使えない |
| 解約 | 利用者が解約した | 期間終了まで使えるかは方針で決める |
状態を増やすほど、「この状態からあの状態には移れるのか」という組み合わせが爆発的に増えます。まずは最小限で始めて、必要になったら足すのが安全です。
よくある落とし穴
| 落とし穴 | 起きること | 対策 |
|---|---|---|
| 提供の箱が決済サービスに直接問い合わせる | 決済側が遅いと、アプリも遅くなる | 台帳を見るようにする |
| 知らせを受けたらすぐに全部処理する | 途中で失敗すると、知らせごと失われる | 受け取りと処理を分ける |
| 同じ知らせを何度も処理する | 利用期間が余分に延びる | 処理済みの記録を持つ |
| 状態を細かく分けすぎる | 分岐が増えて、テストしきれなくなる | 最小限の状態から始める |
設計を確認するチェックリスト
まとめ
今回は、課金の仕組みを役割ごとの箱に分けて設計する考え方を紹介しました。
- 決済・受付・台帳・提供・通知の5つに分ける
- 支払い情報は持たず、利用の判断は台帳だけで行う
- 受付は「確かめて記録する」だけ、状態は最小限に
次の一歩は、今作っている（または作りたい）仕組みの部品を書き出して、5つの箱のどれに当たるか振り分けてみることです。どの箱にも入らない部品や、複数の箱にまたがる部品があれば、そこが見直しポイントです。
「そもそもなぜ課金を自動化するのか」という前提は、シリーズの1本目にまとめています。
※2026年10月追記：シリーズの続きと、自動化の道具の使い分けをまとめた記事を公開しました。