判断の出発点

設計例を考えます。月額サービスの開発でカード登録と初回決済まで確認しました。しかし翌月の決済が失敗すると、疑問が生じます。今すぐ利用を止めるべきか、三日待ってもよいか。その間に解約を申し込んだ顧客へ再度決済を試みてもよいでしょうか。

定期決済APIを接続しただけでは、サブスクリプションサービスは完成しません。 決済手段を登録して代金を受け取る機能に加え、誰に、どの期間のいくらを請求し、どの機能をいつまで提供するかを結ぶ必要があります。ただし、その責任を分けることと、大規模な独立した課金プラットフォームを導入することは別の判断です。

Toss Paymentsの自動決済ガイドは、APIを使ってサブスクリプションサービスを自ら構築し、決済周期に合わせて承認要求を自らスケジュールするよう案内しています。ビリングキーの発行と、そのキーで金額を決済する段階も区別しています。[1] 開発範囲を決める際は「定期決済連携」という一行より、その後に残る責任を先に確認します。

決済手段から利用権限まで六つに分けます

以下は構築範囲を定める内部概念図です。特定供給者のAPI構造や、必ず作るべき六つのDBテーブルを意味しません。

顧客 ── 登録 ── 決済手段の参照（例：ビリングキー）
 │                              │
 └─ 締結 ── サブスクリプション契約 │ 決済に使用
                │               ▼
        プラン・版・期間 → 請求 → 決済試行・取引
                │          │     成功 / 失敗 / 取消
                └────┬─────┘
                     ▼
             猶予・変更・終了方針の適用
                     ▼
             利用権限：機能・範囲・失効時点
内部概念答えるべき問いほかの概念との区別
顧客誰が契約し、誰が費用を負担するかログインユーザーと費用を負担する会社が異なる場合があります。
決済手段何で決済できるか決済手段の登録自体は、今回請求の入金完了ではありません。
契約・プランどの条件をどの期間に適用するかプラン名以外に価格・適用時点・変更履歴を区別します。
請求どの利用期間についていくら受け取るべきか決済が失敗しても請求額と根拠は残ります。
決済試行・取引実際の決済要求と結果は何か同じ請求への再試行と次回の請求は異なります。
利用権限今どの機能を使えるか決済結果に加え、猶予・無料体験・終了方針を反映します。

本稿の「請求」は、受け取る金額と対象期間を管理する技術的な概念です。それ自体を税務上の請求書や特定の会計処理と同一視しません。表も唯一の正解となるスキーマではなく、抜けた業務を探す設計表です。

供給者の名称をこの内部モデルにそのまま当てはめると混乱しやすくなります。Toss PaymentsのcustomerKey、billingKey、paymentKeyは、それぞれ顧客識別に使う値、自動決済に使うキー、決済識別子です。ビリングキー発行はBillingオブジェクト、自動決済承認の成功はPaymentオブジェクトを返します。これらのキーだけでアプリケーションの契約や利用権限が生まれるわけではありません。[2]

一方、Stripe BillingはCustomer、Product、Price、Subscription、Invoiceなどを提供し、契約に基づく請求と代金回収を結び付けます。Subscriptionのactiveは、全請求書の決済完了を意味しません。[3] 一般構造を先に定め、選んだ製品のオブジェクトがどの責任を持つか対応付ける順序が適切です。

サービスの仕組み

契約条件から請求・再試行まで — プランと契約条件を分け、請求計算と失敗理由別の再試行を購読ライフサイクルに組み込みます。

サブスクリプションには成功と失敗以上の変化があります

次の表は、サブスクリプション機能の受け入れで区別する状態変化です。最後の列は供給者の既定動作ではなく、サービスが定める方針です。

事象別に記録する変化先に決める方針
初回決済成功初回請求の入金結果と初回利用期間決済確認後いつ権限を開くか
次回請求到来新回次の期間・金額と決済結果基準タイムゾーン、月末処理、請求担当ジョブは何か
決済失敗その試行の失敗理由と未入金状態初回失敗と更新失敗を同じ方法で扱うか
再試行既存請求への追加決済試行どの理由をいつまで再試行するか
猶予期間未入金でも許可する利用範囲・期限全機能を維持するか、一部だけ許可するか
一時停止請求・回収・利用の何が止まるか再開日と停止中に発生した請求をどう扱うか
解約予約将来の終了時点と次回更新停止決済済み期間の利用はいつ終わるか
即時解約契約終了・権限終了・残る請求の処理返金や最終使用量請求が別途必要か
プラン変更新条件の適用時点と追加・減額請求即時か次回からか、日割り計算が必要か
返金既存決済の金額調整と処理結果契約も終了するか、特定期間・項目だけ調整するか

特に、契約の解約、決済取消・返金、利用権限終了を一つの操作として扱わないことが重要です。Stripeも即時解約と期間末解約を区別し、返金の有無と方法を別に扱います。[4] 解約申請だけを理由に既存決済記録を削除したり権限を即時停止したりすると、選択した方針を説明できません。

「一時停止」も名称だけでは不十分です。Stripeのpause_collectionは代金回収の一時停止で、契約状態を変えず、請求書が生成され続ける場合があります。サービス利用自体の停止とは区別します。[5] 企画書に「停止ボタン」とだけ書くのでなく、何を止め、何を続けるかを記述します。

APIを選ぶ前に決める三つのこと

決済失敗後、いつまで利用を認めるか

更新決済が失敗したら即時制限することも、一定期間猶予することもできます。決済会社のエラーコードが代わりに決める問題ではありません。

設計例として、無料体験のない月額サービスが「初回失敗では権限を開かず、更新失敗は72時間猶予」と決めたとします。失敗記録だけでなく、猶予終了時刻、その間の許可機能、期限後の制限処理、決済回復後の権限復元が必要です。72時間はこの例の選択であり、推奨標準や法定期間ではありません。

再試行も失敗理由で異なります。Toss Paymentsは、カード・口座の再発行や期限切れ時に新情報でビリングキーを再発行するよう案内しています。[1] Stripe Smart Retriesも、一部の強い拒否理由では新決済手段なしに実際の再決済を行いません。[6] 全失敗に同じ間隔で承認要求を繰り返す方針は避けます。

解約申請日と利用終了日を同じにするか

期間末解約を選ぶ設計では、今日申請を受けても、既に許可した利用期間を維持しつつ次回請求を防ぎます。即時解約に対応するなら、契約終了、権限回収、返金検討をそれぞれ処理します。

また、次回を更新しない判断と、既に発生した未入金請求をどう扱うかは別です。 解約予約で過去請求の再試行もすべて止めるか、確定済み請求だけを処理するか決めなければ、担当者ごとに動作が異なります。これは状態設計の問いであり、特定の解約・返金方針が法的に許されるという判断ではありません。実際の商品と契約について別途検討が必要です。

プラン変更をいつ反映するか

すべてを次回請求周期から適用すれば、中途期間の差額計算を減らせます。月途中に上位機能をすぐ開くなら、追加料金、適用時点、追加決済失敗時の権限処理も決めます。

日割り計算と返金も同義ではありません。Stripeの日割りでは、減額が発生しても自動返金されるわけではなく、追加額も設定によっては即時請求されません。未払い請求がある状態でのプラン変更では、まだ払っていない金額を基にクレジットが計算される場合も説明されています。[7] 計算機能の有無より、どの金額をいつ実際に受け取り、返すかが先です。

PG・課金ツール・アプリケーション・運用担当者の責任

サブスクリプションシステム全体を自社構築する必要はありません。ただし外部ツールを使っても、誰が何を扱うかを残します。以下はToss Payments自動決済APIとStripe Billingの文書で確認した境界に基づく分担案であり、全PG共通の機能表ではありません。[1][2][3][6][8]

担当任せられる仕事サービス側が引き続き決定・接続する仕事
PG・決済API契約した決済手段の登録・承認・照会・取消、提供される状態通知プラン方針、請求時点、失敗後の利用許可
商用課金ツール（任意）対応範囲内の契約・請求書・プラン変更・再試行管理商品規則設定、既存システム接続、非対応の例外
アプリケーション顧客・契約の紐付け、商品機能と利用期間管理、外部結果の反映実際の要求への権限制御適用、不整合状態の復旧
事業・運用担当者料金・猶予・変更・終了方針の承認、顧客案内、例外処理担当者・承認範囲・処理履歴の維持、方針変更の検証

商用ツールが利用権限情報を提供しても、アプリケーションのアクセス制御まで完成させるわけではありません。Stripe Entitlementsの文書も、商品に紐付く機能情報をイベントやAPIで確認し、サービス側で権限を付与・回収する流れを説明しています。[8]

自動化の実行責任は重複させない方が安全です。自社スケジューラーと商用ツールのどちらが請求し、失敗した請求をどちらが再実行するか、一つずつ決めます。手動処理でも根拠取引と変更理由を残す設計にします。

「再試行」も区別します。Webhook再送は結果通知を送り直すことで、決済再試行は代金を受け取る要求を再実行することです。 Toss PaymentsのWebhook送信失敗時の再処理とStripeの決済再試行は別の責任を扱います。[9][6] Webhookを受けたという事実だけで未入金請求の再決済を起動してはいけません。

導入可能性も開発とは別です。Toss Paymentsの自動決済は、公式案内上リスク審査と追加契約が必要です。[1] 本稿の課金ツールが特定の韓国国内PGに直結し、全事業者が同条件で使えるという意味ではありません。実際の契約主体、対応決済手段・通貨、連携方法を確認します。

二つのサービスでは最小構築範囲が異なります

以下は実際の顧客事例ではなく設計例です。顧客数や売上ではなく、選んだ課金規則によって必要機能がどう変わるかを比較します。

判断項目A：単一プランのコンテンツ会員サービスB：席数・使用量課金の業務SaaS
基本条件月前払い、単一プラン、使用量課金・クーポンなし会社単位契約、複数プラン、席数・使用量による金額、販促
変更方針価格変更は次回から適用席数・プラン別の適用時点と差額方針が必要
請求根拠契約版、利用期間、固定額契約版、席数変更履歴、使用量集計期間・締め基準、割引根拠
失敗処理理由別案内、許可した再試行、猶予満了、権限復元請求項目確認、決済手段変更、組織別許可範囲、例外承認
最小実装候補既存アプリ内の契約・請求モジュール、決済API、スケジューラー、権限検査、運用照会画面使用量収集・検証、請求計算・プレビュー、変更履歴、権限接続、運用確認機能
ツール選定上記範囲を維持・検証できれば専用課金基盤なしで開始可能商用ツールと自社実装を比較する理由が大きい。非対応規則と連携費用も確認

Aには複雑な販促エンジンや使用量集計システムは不要で、既存アプリに小さなモジュールとして実装できます。ただし、請求漏れの発見方法、決済手段の再登録経路、解約後の次回更新防止まで省略できる意味ではありません。返金が少なければ運用者承認後の処理を選べますが、金額・取引・権限の変更履歴は残します。

Bでは「使用量」の定義だけでも範囲が広がります。どのイベントをいつまで集計し、遅れて届く使用量をどの請求に反映し、締め後の修正を誰が承認するか決めます。商用ツールを使うのは反復機能を任せるためであり、事業方針を省略するためではありません。

自社構築が適するのは、規則が限定され、チームが請求処理と例外を運用できる場合です。外部支援を検討する条件は計算自体より、方針・実装・検証・運用の担当が分かれ、責任が抜ける場合です。どちらを選んでも、導入に含む機能と自社に残す仕事を同じ表で比較します。

サービスの仕組み

注文から承認・返金まで状態を接続 — 決済手段を注文フローにつなぎ、応答遅延、再試行、取消し、返金の例外を検証します。

受け入れ時は決済成功画面の先を確認します

以下は上記設計に追加する受け入れシナリオの例です。実測結果ではなく、合意した方針を検証するための期待結果です。

受け入れシナリオ確認すべき結果
ビリングキー発行は成功し初回決済は失敗無料体験など別根拠のない有料権限は開かず、失敗理由と次の行動を確認できます。
PGでは成功したが内部反映に失敗決済済み取引を確認し、請求・権限反映を復旧する経路があります。復旧が新規決済や二重の利用期間付与を起こしてはいけません。
更新失敗後に猶予が満了、または決済が回復選んだ方針どおりに制限・復元します。決済状態だけ変わり権限が残らないか確認します。
期間末解約を予約次回更新は止め、約束した既存利用期間は維持します。発生済み請求も合意した方針に従います。
プラン変更の追加決済が失敗新機能をすぐ開くか変更を保留するか、定めた結果と一致します。請求条件と実権限が別プランに残ってはいけません。
一時停止・再開または返金を処理何が停止・再開され、どの決済を調整し、契約・権限にどう影響したか説明できます。

小さなサービスなら複雑な運用コンソールでなく、限定的な照会・処理画面から始めても構いません。ただし担当者は、なぜこの顧客を請求対象とし、なぜ今サービスを使えるのかの根拠を確認できる必要があります。失敗再処理の具体的実装や部分返金計算を別設計にしても、担当者と受け入れ条件を省いてはいけません。

決済情報を直接保存する範囲も減らします

カード自動決済は供給者の決済画面を使い、サービス側では決済手段の参照と必要な取引識別子を管理する方向から検討します。Toss Paymentsも決済画面経由のビリングキー発行を提供します。[1] ビリングキーとAPI認証情報を一般顧客IDと同じに扱わず、アクセス権とログ露出を制限します。

定期決済に再利用するためでも、カードのCVV・CVCを承認後に保存する実装は避けます。PCI SSCは、暗号化や顧客同意にかかわらず承認後のセキュリティコード保存を禁止すると説明しています。[10] 外部委託してもPCI DSS関連責任がすべてなくなるわけではないため、実際の連携構造に適用される範囲を確認します。[11]

定期決済の完成基準は翌月も説明できることです

単純な月額サービスは小さな課金モジュールで十分な場合があります。複数プラン・席数・使用量・割引が絡むと商用ツールが適する場合があります。出発点は機能数ではなく、自社サービスのプラン・請求・決済・利用権限を一致させるために必要な責任です。

最小構築範囲を決めた後、規則ごとの適用時点と期待結果をサブスクリプション課金規則・検証シナリオ設計書で具体化します。方針を記録する様式と、構築範囲を決める作業は役割が異なります。

プラン・請求・権限・失敗処理のどこを外部に任せるか検討しているなら、IXCの定期決済・ビリングサービスの提供範囲も併せて確認できます。