サブスクリプション課金ルール・検証仕様書

サブスクリプションは同じ金額を定期的に請求するだけではありません。料金表が変わっても旧条件の顧客が残ることがあり、決済が失敗しても契約や利用権限が直ちに終了するとは限りません。料金表、個別契約、請求書、決済試行、利用権限を分けると、変更する対象を確認できます。現在の契約バージョンと次に適用するバージョンを記録します。

記入例は架空のB2B月額ポリシーv1です。Basicを月額120,000ウォン、Proを180,000ウォンとし、計算では税額を除きます。請求期間はAsia/Seoul基準の毎月1日00:00から翌月1日00:00直前までです。終了時刻は次の期間に属します。上位プランへの変更は追加決済の承認結果を事前に確認し、予約日の午前0時から適用します。下位プランへの変更は翌請求期間から適用し、当月差額を調整しないポリシーを仮定します。

金額と条件は例の業務ルールです。実際の税務・証憑・返金・契約条件は担当部門が確定します。実装では契約した決済手段と処理仕様も確認します。Toss Paymentsの自動決済連携文書は、ビリングの契約と加盟店側のスケジュール実装を説明しています。カード登録やビリングキーの発行で商品プランと解約条件まで自動的に定まるわけではありません。

プラン変更には申請時刻、金額の算定時刻、適用予定時刻、決済結果の確認時刻があります。これを一つの日付で上書きすると、支払いを確認する前に利用権限が変わることがあります。変更申請IDと算定バージョンを付け、金額・期間・適用条件を一緒に確定します。未払いの期間で変更や調整を受けるかも別ルールにします。

架空の記入例では2026年9月は30日です。9月16日00:00にBasicからProへ変更すると、10月1日00:00まで残り15日です。月額差60,000ウォンに15/30を掛けると追加請求は30,000ウォンになります。UP-0916に入力と金額を記録します。予定時刻前に追加決済の承認結果を確認できた場合だけ、その時刻にProへ移します。確認できなければ変更を保留し、既存条件を維持します。

このポリシーでは実際の暦月の日数を使い、1ウォン未満は最終計算で一度だけ切り捨てます。料金や日付がなければ算定保留、適用日が期間外なら入力エラーにします。確認が遅れて予定時刻を過ぎた場合は適用日と金額を再確定します。後から承認された決済があれば、新たな請求の前に状態を確認します。Stripeの日割り計算文書も未払い請求と調整を区別しています。この例の式を全PGの共通ルールや製品の初期設定として使いません。

更新と失敗処理は異なる対象の状態を動かします。契約が継続し、請求書が未払い、決済試行が失敗でも、猶予ポリシーで利用を続ける場合があります。一つの「契約状態」だけでは何が未収で、どの処理を再試行すべきか分かりません。対象ごとに現在状態と変更を認める確定イベントを定めます。

記入例では契約S-01に10月請求書INV-1001を発行します。10月1日の初回決済が失敗したら請求は未払い、契約は継続、利用は猶予と記録します。10月2日の再試行が承認されたと確認できれば、同じ請求書を支払済みにして通常利用へ戻します。同じ成功イベントが二度届いても請求と利用権限は一度だけ反映します。9月請求に関する遅延した成功通知は、10月の支払い証拠にはなりません。

契約ID、期間ID、請求書ID、決済試行ID、外部取引IDを区別します。成功イベントを反映する前に対象請求、金額、通貨を照合します。イベントの受信記録と業務処理の完了記録も分けます。Toss PaymentsのWebhook文書でイベントと配信仕様を確認し、実際の連携規格に合わせます。認証・重複・状態の不整合に関する基本準備は決済連携着手点検表につなぎます。

承認応答がないことと、決済失敗が確定したことは異なります。承認されたのに応答だけ失われた場合があるため、別の決済試行を作る前に元取引を照会します。カードが期限切れなら繰り返し請求するより支払手段の変更が先になることもあります。確認できた一時的失敗は契約と決済手段が認める条件で再試行します。エラーコードの意味を確認して次の行動へ対応付けます。

架空の更新ポリシーでは、10月1日に確定した一時的失敗に対して10月2日と4日の09:00を再試行機会とします。毎回、同じ請求がまだ未払いかを確認します。10月5日00:00まで未払いなら運用担当の確認後に利用を制限し、契約は継続します。この日時と猶予期間は架空ポリシーの選択であり、共通のPG再試行回数や顧客の権利を定めるものではありません。

承認未確認や状態が衝突する取引は、そのまま再試行予定に入れません。照会と運用確認へ回し、重複請求や誤った利用制限を保留します。顧客への案内も未払い確定、処理確認中、支払手段の変更が必要な状態を区別します。連絡チャネルと同意条件は実際のサービス運用に合わせます。決済運用の参照・診断・承認・実行権限を分け、最終状態を確認する担当を定めます。

期間末の解約予約では、現在の利用終了時点と次の請求停止を記録します。期間途中の終了では、いつ利用を止め、いくら調整するかの追加判断が必要な場合があります。受付、内部審査、金額承認、決済会社の処理、照合完了は別の状態です。受付だけで返金済みとせず、結果不明の取消を繰り返しません。

別途承認した中途精算の記入例では、Pro利用を9月21日00:00に終了すると合意します。架空契約の担当者が未使用10日分について180,000×10/30の60,000ウォン調整を承認します。先の月額120,000ウォンと変更請求30,000ウォンで支払済み額は150,000ウォンです。調整完了後の残額は90,000ウォンで、次の期間の請求は作成しません。ADJ-0921で適用時点と承認の証拠を結びます。

60,000ウォンは架空契約で承認した例示額であり、法定返金額ではありません。実行時は元取引ごとの返金可能残高と手段別の規格を確認して配分します。請求調整と実際の取消・支払結果が一致することも確認します。元取引、調整、取消イベント、精算反映を精算照合ルール・運用様式につなぎ、財務と運用が同じ取引を追跡できるようにします。

検証表には承認済みルールID、試験入力、期待する金額と状態、実行結果、証拠を記録します。UP-0916で事前に決済を確認できた場合は30,000ウォンと予約日の切替、未確認なら変更保留を期待します。更新成功イベントを重複受信しても一請求に一度だけ反映します。前期間の成功で当期未払いが消えてはいけません。期間末解約では次の請求が作成されないことを確認します。

日付境界、月の日数、金額欠落、差額0、適用期間外も試験し、算式と状態を別々に検証します。ローカル計算の確認は実際の決済承認や返金完了の証拠ではありません。連携したテスト環境では照会・再配信・承認の衝突・取消結果を確認します。本番開始前には契約した手段とキー、スケジュール、顧客案内、参照・返金権限を別途確認します。未実施項目には担当と確認予定を残します。

IXCの定期決済・ビリングはプラン・契約・請求・再試行・解約をつなぐ構築を提供します。PG連携・決済システム構築と合わせて、承認したポリシーのデータモデルと連携範囲を定めます。現在条件、変更例、未払い・解約の未確定事項から、開発・検証・運用引き継ぎの分担を協議できます。共有用の仕様書には秘密キーや実顧客の決済情報を記載しません。