月額で使ってもらうサービス（サブスクリプション、以下サブスク）を作るとき、後回しにされがちなのが課金と退会です。画面や機能に比べて目立たないうえ、決済の道具を入れれば済むと思われがちです。けれども実際には、請求のしかた、料金の段階、人数の上限、プランの変更、解約と記録の扱いなど、決めることが多くあります。この記事では、当社の仕事管理サービス「Chattus」の課金と退会を、決済の道具Stripeで作ったときの記録を、つまずいた所と決めたことに分けて紹介します。料金そのものの話はしません。
サブスクの課金は「お金を受け取る」より「状態をそろえる」仕事
一度きりの買い物なら、決済が終われば取引も終わります。サブスクは違います。毎月の請求、支払いの確認、プランの変更、人数の増減、解約と、お客様の状態が時間とともに変わり、そのたびに決済の側とサービスの側の情報をそろえ続ける必要があります。
そのため、課金を作るときに考えることは、大きく次の3つに分けられます。
- どう払ってもらうか：カードか、請求書と振込か。
- どの情報をどこに置くか：金額や契約の状態を、決済の道具とサービスのどちらで持つか。
- 状態が変わるときにどう動くか：支払いの知らせ、プランの変更、解約で、何がいつ変わるか。
以下、当社の記録をこの順に紹介します。
🛠 この記事のようなプロダクト開発の課題は、ご相談ください。何をつくるかの整理から、開発、反応を見た手直しまで一緒に進めます（相談は無料）。
Invoice
請求書を毎月メールで送り、振込とカードの両方で払えるようにした
当社では「Chattus」の課金と退会を、決済の道具Stripeで作りました。請求書を毎月メールで送り、銀行振込とカードの両方で払えるようにしています。振込は自動で消し込みます（入金と請求を自動で突き合わせます）。
Stripeの公式ドキュメントでは、請求書を作るときに支払い方法の扱いとして「請求書を送る（send_invoice）」を指定し、支払い期限までの日数を決める例が示されています。また、請求書を送ると、Stripeはその時点で請求書を確定し、多くの国や地域では確定済みの請求書は法的な文書とみなされ、一部の項目は変更できなくなる、と説明されています[1]。
銀行振込については、Stripeが振込先として仮想の口座番号を示し、その番号を使って自動で消し込む仕組みだと説明されています。振り込む側には仮想の口座番号だけが示され、受け取る事業者の実際の口座情報は見えません。サブスクで銀行振込を使う場合は「請求書を送る」方法だけが使えること、振込では顧客が多すぎる・少なすぎる金額を送ることがあり、その差は顧客の残高として扱われること、消し込まれないまま75日を超えた入金は自動で返金が試みられることも書かれています[2]。振込を受け付けるなら、こうした「金額が合わないとき」の流れも、作る前に確かめておきたい点です。
Where
金額はStripeに置き、サービスの側は段階の名前と人数の上限だけを持つ
当社では、金額はStripeの側に置き、サービス（アプリ）の側は料金の段階の名前と、使える人数の上限だけを持つ形にしました。
| 情報 | 置いた場所 | 一般的に、ここに置くと起きやすいこと |
|---|---|---|
| 金額 | Stripe | サービスの側にも持つと、片方だけ値段を変えて食い違うことがある |
| 料金の段階の名前 | サービス（アプリ） | 画面の表示や、使える機能の切り分けに使える |
| 使える人数の上限 | サービス（アプリ） | 人数を増やす操作のたびに、その場で確かめられる |
同じ情報を2か所に持つと、どちらが正しいかを決める手間が生まれます。金額のように決済の道具が本来持っている情報は、そちらに任せ、サービスの側は自分の画面と動きに必要なものだけを持つ、という分け方です。
Limit
人数が増える経路には、すべて上限の確かめを置いた
当社では、人数が増える経路にはすべて上限の確かめを置きました。ただ、見落としていた経路が1つあり、2回目のレビューで見つかりました。
人数が増える経路は、「メンバーを追加する」ボタンだけとは限りません。一般には、招待のリンクから入ってくる、一度外した人を戻す、まとめて取り込む、管理者が別の画面から足す、といった道がありえます。上限をどこか1か所で確かめるだけでは、ほかの道から上限を超えてしまいます。人数が増える道を先に全部書き出し、そのすべてに確かめを置いたかを点検しておくと、抜けを見つけやすくなります。
Accounts
Stripeのアカウントは事業ごとに分けた
当社では、Stripeのアカウントを事業ごとに分けました。別の事業のお客様に請求が飛ぶ事故を防ぐためです。
複数の事業やサービスを持つ会社では、決済の道具を1つのアカウントにまとめたくなります。管理は楽になりますが、顧客や請求の一覧が混ざり、取り違えたときの影響が大きくなります。どの単位でアカウントを分けるかは、課金を作り始める前に決めておきたい点です。
課金や退会のような、目立たないけれど間違えられない所まで含めて開発します。決済の道具をどう組み込むか、決める段階からご相談ください。
無料で相談するWebhook
つまずいた所：決済の知らせの重複を見分けられていなかった
Stripeは、支払いが済んだ、請求書が確定した、といった出来事を、サービスの側へ知らせとして送ります（Webhook）。当社では、この決済の知らせが重複していないかの判定に、毎回変わる値を使っていたため、判定が働いていませんでした。変わらない値で判定するように直しました。
Stripeの公式ドキュメントは、知らせを受け取る側は同じ出来事を複数回受け取ることがあるとして、処理した出来事のID（識別番号）を記録し、記録済みのものは処理しないようにする方法を示しています。また、出来事の作成時刻は秒単位のため、別々の出来事が同じ時刻を持つことがあり、順番や処理済みかどうかの判断に使わず、出来事のIDで重複を見分けるよう書かれています[3]。
重複の判定が働かないと、同じ支払いを2回数える、同じ知らせのメールを2回送る、といったことが起こりえます。知らせは「1回だけ届く」とは限らない、という前提で作っておく必要があります。
Downgrade
「次の更新日にプランを下げる」日付は、Stripeの返事から読む
当社では、「次の更新日にプランを下げる」ときは、効力が出る日を自分で計算せず、Stripeに書き込んだときの返事から読むようにしています。
Stripeでは、時間をおいて起きるサブスクの変更を「サブスクリプションスケジュール」で決められ、段階（フェーズ）ごとに何をいつ変えるかを指定します。将来の日付からの開始や、アップグレード・ダウングレードもこの仕組みで扱えると説明されています[4]。解約についても、今の請求期間の終わりに解約する設定（cancel_at_period_end）や、日付を指定して解約する方法などがあり、解約の日付を指定すると、その日に合わせて今の期間の終わりの日付も更新されると書かれています[5]。
月の長さ、うるう年、時刻帯、請求の周期の設定など、更新日の計算に関わる条件は意外に多くあります。同じ計算を自分でもう一度書くと、Stripeの側と1日ずれる、といったことが起こりえます。日付は決済の道具が決めたものを読んで使う形にしておけば、サービスの側と実際の請求が食い違いにくくなります。
Records
解約で記録まで消える経路があり、記録を残すほうを選んだ
当社では、片付けのために解約すると、受け取った請求書の記録まで消える経路がありました。記録を残すほうを選びました。
一般に、決済の道具の中の情報は、消すと元に戻せないものがあります。たとえばStripeのAPIの説明書では、顧客を削除する操作は完全な削除で元に戻せず、その顧客の有効なサブスクもすぐに解約される、と書かれています[6]。
請求や取引の記録は、税の面でも残しておく必要があります。国税庁の説明では、注文書・契約書・領収書・見積書などに書かれる取引の情報を、電子メールやウェブサイトを通じてやりとりする取引は「電子取引」に当たり、その記録は一定の要件のもとで保存しなければならない、とされています[7]。退会や解約の処理を作るときは、「何を止めるか」と「何を残すか」を分けて決めておくと、片付けのつもりで大事な記録を消す事故を防ぎやすくなります。
Test Cases
公開前に試しておきたい「普段は起きない場面」
課金の不具合は、毎月の普通の支払いでは起きにくく、たまにしか起きない場面で表に出ます。一般的に、公開の前に次のような場面を一つずつ試しておくと、上で紹介したようなつまずきに気づきやすくなります。
- 同じ知らせが2回届いたとき：支払い済みの数え方や、お客様へのメールが二重にならないか。
- 振込の金額が請求と合わないとき：多すぎる・少なすぎる入金が、どう表示され、だれが気づくか。
- 人数の上限ちょうどで、さらに1人増やそうとしたとき：どの経路から増やしても止まるか。
- 月末や年末をまたいでプランを変えたとき：効力が出る日が、決済の道具の返事と画面で一致しているか。
- 解約したあとに、過去の請求書を見ようとしたとき：記録が残っていて、取り出せるか。
Stripeには本番とは別に試すための環境があり、本物のお金を動かさずにこうした場面を作れます。課金は、間違えるとお客様との信頼に直接関わる所です。画面の見た目よりも先に、こうした場面の動きを確かめておくことをおすすめします。
Checklist
課金と退会を作る前に決めておく6つのこと
- 払い方：カードだけか、請求書と振込も受けるか。振込の金額が合わないときの扱いはどうするか。
- 情報の置き場所：金額はどこに置き、サービスの側は何だけを持つか。
- 上限の確かめ：人数などが増える経路を全部書き出し、そのすべてで上限を確かめているか。
- アカウントの単位：決済の道具のアカウントを、事業ごとに分けるか。
- 知らせの重複：同じ知らせが2回届いても、1回分だけ処理されるか。
- 止めるものと残すもの：プラン変更や解約の日付を自分で計算していないか。解約で請求の記録が消えないか。
Sources
参考にした資料
FAQ
Stripeでサブスクの課金を作るときによくある質問
Stripeで請求書払い（銀行振込）は受けられますか？
Stripeの公式ドキュメントでは、仮想の口座番号を使った銀行振込と自動の消し込みが説明されています。サブスクで使う場合は「請求書を送る」方法になります。当社の「Chattus」でも、請求書を毎月メールで送り、振込とカードの両方で払えるようにしています。
金額はサービスの側にも持っておいたほうがよいですか？
当社では、金額はStripeの側に置き、サービスの側は料金の段階の名前と人数の上限だけを持つ形にしました。同じ情報を2か所に持つと、食い違ったときにどちらが正しいかを決める手間が生まれます。
決済の知らせ（Webhook）で気をつけることは何ですか？
同じ知らせが複数回届くことがある点です。Stripeは、処理した出来事のIDを記録して重複を見分ける方法を示しています。当社でも、毎回変わる値で判定していて重複を見分けられていなかったことがあり、変わらない値で判定するように直しました。
解約したお客様のデータは消してよいですか？
請求や取引の記録は、税の面でも保存が求められることがあります。当社では、解約で請求書の記録まで消える経路を見つけ、記録を残すほうを選びました。何を止め、何を残すかを分けて決めておくことをおすすめします。
サブスクの課金と退会は、決済の道具を入れれば終わる仕事ではありません。払い方、情報の置き場所、上限の確かめ、アカウントの分け方、知らせの重複、変更や解約の日付と記録の扱いを、作る前に一つずつ決めておくことで、間違えにくい仕組みになります。当社では、決済の道具などの外部サービスとの連携を含むプロダクトの開発から、その後の運用保守や改善まで、続けてご相談いただけます。
