Stripeサブスク解約の基本理解
まずは「Stripeのサブスクを解約する」と言ったときに、何が起きるのかを全体像として押さえておきましょう。
Stripeでは、月額課金や年額課金などの継続課金は「Subscription（サブスクリプション）」オブジェクトとして管理されており、このSubscriptionが有効かどうかで、ユーザーがサービスを使えるかどうかを判断するのが一般的です。
解約とは、このSubscriptionを「いつまで有効にするか／いつ無効にするか」をStripeに伝える操作だとイメージすると分かりやすくなります。
運営者として大事なのは、「解約ボタンを押した瞬間に使えなくなるのか」「請求期間の最後まで使えるのか」「その間のstatus（状態）は何になるのか」をきちんと理解しておくことです。
これを知らないまま実装すると、ユーザーが「解約したのに請求された」「もう使えないのは困る」といった不満につながりやすくなります。
Stripeには、即時解約と次回請求で解約を行うためのフラグやオプションが用意されているので、それぞれの挙動を整理していきましょう。
自動更新サイクルの仕組み
Stripeのサブスクは、基本的に「請求期間（billing cycle）」が一定間隔で繰り返される仕組みです。
例えば月額プランであれば、契約開始日から1カ月ごとに請求が自動生成され、顧客が解約しない限りは自動更新され続けます。
この自動更新のスケジュールは、Subscriptionに紐づくプラン（price）や、trial（無料期間）、billing_cycle_anchorなどの設定で決まります。
ポイントは、Stripe側は「次の請求日」を常に意識して動いている、ということです。
次回請求日の直前になると請求書が発行され、支払いが成功すればそのまま次の期間に突入します。
解約操作とは、この自動更新サイクルに対して「この日以降は更新しないで」と指示を出すイメージです。
そのため、いつのタイミングで解約操作をするかによって、最後の請求日や有効期限が変わってきます。
２種類の解約：即時解約と解約予約（次回請求で停止）
Stripeでサブスクを止めるときの考え方は、大きく2パターンあります。
ひとつは即時解約（今すぐ停止）で、解約した瞬間にSubscriptionを無効にしてしまう方法。
もうひとつは解約予約（次回請求分から停止）で、今の請求期間の終わりまでは利用を許可し、それ以降は自動更新しないようにする方法です。
Webサービスの多くは、ユーザー体験の観点から後者（次回請求で停止）を採用することが多いです。
StripeのAPIやダッシュボードでは、この2種類の解約を切り分けるためのオプションが用意されています。
即時解約の場合は「今すぐキャンセル」、次回請求で停止する場合は「現在の期間の終了時にキャンセル」などの文言で表示され、
内部的にはcancel_at_period_endというフラグで制御されます。
運営者はサービスのポリシー（返金の有無、日割りの有無）に合わせて、どちらのパターンをデフォルトとするか決めておく必要があります。
cancel_at_period_end の動作
Stripeで「今の請求期間の終了時に解約する」を実現するときに登場するのが、Subscriptionオブジェクトのcancel_at_period_endというフラグです。
この値がtrueの場合、「現在の期間が終わったタイミングでサブスクをキャンセルする」という予約状態になります。
ダッシュボードから解約した場合も、どちらの挙動を選んだかによって、このフラグの値が変わります。
cancel_at_period_endを理解しておくと、「ユーザーは解約したつもりだが、期間の終わりまでは使える」という状態を、アプリ側で正しく表現できるようになります。
例えば、マイページ上では「○月○日までは利用可能です」と表示しつつ、内部的には「更新予約なし」の状態として扱う、といったUI設計ができるようになります。
ここからは、true/falseそれぞれの意味と、有効期限までの扱いを詳しく見ていきましょう。
true/false の意味
cancel_at_period_endがfalse（デフォルト）の場合、Subscriptionは通常の自動更新モードです。
次回請求日が来るたびに請求が行われ、顧客が解約しない限りstatusはactiveのまま維持されます。
この状態で「即時解約」を選ぶと、そのタイミングでSubscriptionはキャンセルされ、statusもcanceledなどの非アクティブな状態に変わり、以降の請求は行われません。
一方、cancel_at_period_endをtrueに設定して解約予約した場合は、「今はactiveだけれど、次の請求は発生させない」という予約状態になります。
このときSubscriptionのstatus自体は、請求期間が終わるまではactiveのままです。
current_period_endを見れば、「いつキャンセルされる予定か」「今の期間はいつまでか」が分かるようになっています。
アプリ側では、この値を使って「解約予約済み」のフラグを持たせることが多いです。
また、cancel_at_period_endをtrueに設定した場合でも、次回請求日前であれば、falseに設定することができ、この場合は解約予約も解除されます。
status が変化するタイミング
StripeのSubscriptionは、契約のライフサイクルに応じて status（状態） が自動的に変化します。
解約処理を正しく扱うためには、この状態遷移を理解しておくことが重要です。
なぜなら、ユーザーの利用権限の切り替えや、社内システム側でのアクセス停止・通知処理などは、このstatus変化をトリガーに実行されることが多いためです。
Subscriptionのstatusには incomplete、incomplete_expired、trialing、active、past_due、canceled、unpaid、paused（比較的新しい状態） などがありますが、解約運用で特に関係するのは active → canceled の流れです。
cancel_at_period_endをtrueにした場合や、即時解約した場合などで変化のタイミングが異なるため、ここで整理しておきましょう。
active から canceled へ
まず、cancel_at_period_endをtrueにした場合、Subscriptionは「今は有効だが、次回更新はしない」という予約状態になります。
このときstatusはactiveのままですが、内部的には「終了予定日」がセットされ、期間終了の直前に自動でcanceled状態に移行します。
この瞬間、Webhook（customer.subscription.deleted）が送信されるため、運営側はこのイベントをキャッチしてユーザーの利用権限を停止する、メール通知を送る、プラン変更処理を行うなどの後続処理を行います。
実践的には、アプリ側の停止処理はWebhookに合わせるのが最も安全です。
prorate（按分）と請求書の扱い
即時解約を行った場合、その月の残り期間に対して「日割り（prorate）」を返金するかどうかを選ぶことができます。
prorateは「どれだけ利用したかに応じて差額を計算する」仕組みで、Stripeのprice設定や請求ロジックに応じて動作が変わります。
日割りを適用する場合、差額はクレジットとして顧客に付与され、次回請求時に自動調整されます。
一方、次回請求で停止（cancel_at_period_end=true）の場合は、今の期間が満了するため返金は発生しません。
この辺りは組み込むときに揉めるところでもあります。
たとえば、ユーザーがサブスク契約している状態から、サブスクのみ解約するなら次回の請求で停止すればいいのですが、
ユーザーアカウント自体を削除した場合の挙動と按分をどうするか十分に詰めて利用規約にも明記しておく必要があります。
即時解約の挙動
Stripeには「即時解約」という操作があり、その名の通り、ボタンを押した瞬間にSubscriptionを無効化する方法です。
cancel_at_period_endをfalseのまま解約するとこの即時解約扱いとなり、statusもすぐにcanceledへ遷移します。
期間途中でも利用できなくなるため、学習サービス・コミュニティ・ツール利用権といった「即時停止が問題になりやすい」サービスを運営している場合は注意が必要です。
また、即時解約では、残り期間に対して返金を行うかどうかを選択できます。
これはStripeのダッシュボードやAPIで「prorate（按分計算）」のオンオフを切り替えることで制御でき、返金した場合は顧客残高にクレジットとして付与されます。
ただし、日割り計算の仕様は変わる可能性があるため、実際の運用前にテスト環境で動作確認しておくと安心です。
返金の考え方
即時解約時の返金は、サービスのポリシーによって異なります。
SaaSでは一般に「即時解約＝返金なし」とするケースが多いですが、ユーザー満足度の観点から日割り返金を採用する事例もあります。
Stripeでは、残り期間分の金額を正確に計算して返金できるため、柔軟なポリシーを設定することが可能です。
運営側としては、カスタマーサポート工数と顧客体験のバランスを考え、統一的なルールを決めておくとトラブルが減ります。
また、「返金した場合はどう会計処理すべきか？」といった疑問もよくあります。
この点は事業規模や会計ルールにより扱いが変わるため、必要があれば税理士など専門家への確認が確実です。
Stripeの返金ログはダッシュボードから確認できるため、管理面で迷うことは少ないでしょう。
あくまで私の意見ではありますが、利用規約に明記してある前提で、即時解約の残り期間の利用料について返金しないという選択は全然ありです。
先程のサブスク利用期間中のアカウント削除においても、利用規約に明記してある前提で即時解約を行い返金は不要としても良いと考えています。（実際そのように運用しているケースもあります）
というのも按分は会計的に複雑になるため、思い切って妥協しても良いのではないかと思います。
プランのアップグレード（ダウングレード）時にも按分が関わってきますが、こちらでも一度解約をして、再び契約するというスタイルにすることでスマートになります。
ユーザー体験を優先するなら未使用期間分を按分して、アップグレードすることも可能です。
Webhook で補足すべきイベント
即時解約を実装する際に重要なのは、「解約した瞬間に実行すべき処理」と「Stripe側でキャンセル処理が確定したときの処理」を正しく切り分けることです。
基本的には、以下のWebhookイベントを補足しておくと安心です。
- customer.subscription.deleted：Subscriptionがキャンセルされたときに送信されるメインイベント
- invoice.payment_refunded：返金が発生したときに送られるイベント（即時解約＋日割り返金時）
- customer.subscription.updated：状態変更があった場合の総合的な更新イベント
特にcustomer.subscription.deletedは、アプリ側の利用停止処理のトリガーとして最も信頼できます。
運営側で任意のタイミングで実行するロジックではなく「Stripeが確定処理したタイミング」に合わせることで、ズレや取り違えを防げます。
Webhookイベントは突然仕様が変わることは少ないものの、重要な箇所なので定期的に公式ドキュメントをチェックすると安心です。
よくある質問（FAQ）とトラブル事例
ここでは、Stripeサブスク解約で運営者からよく寄せられる質問や、実際に起きやすいトラブルをまとめて紹介します。特に、cancel_at_period_end の誤解や Webhook 未設定に起因する問題はよく発生します。事前に理解しておくことで、ユーザー対応の工数を減らし、安定した運用が実現できます。
Q：解約したのに status が active のままなのはなぜ？
A：解約には２種類あり、即時解約と解約予約があります。
cancel_at_period_end=true の場合、解約予約となり期間の終了までstatusはactiveです。
UI側でも、即時解約と解約予約を使い分け、ユーザーの意思とシステム側の変数に行き違いが無いようにしましょう。
current_period_end を確認し、UI 上で「解約予約中」と表示するのが安全です。
Q：即時解約したのに返金されないのは？
A：prorate（按分）が無効の場合、返金は行われません。返金ポリシーに従って、必要なら手動返金するケースもあります。
Q：解約後に請求書が届くことはある？
A：cancel_at_period_end=true の場合は原則なし。
ただしタイミングによっては invoice が発行済みの場合もあるため、必ず最新の invoice ステータスを確認するようにしましょう。
もしそういったトラブルが発生した場合には、手動で対応してください。
Q：Webhook を設定していないとどうなる？
A：Subscription がキャンセルされてもアプリ側で利用停止処理が行われず、「解約後もサブスクが使える」状態が発生します。
必ず customer.subscription.deleted イベントをリッスンし、サブスクのキャンセルを自社システムに反映させてください。
Q：trial（無料期間）中に解約した場合の扱いは？
A：trial_end を過ぎるまでは請求が発生しません。解約しても trial 中は利用できるため、UI 表示に注意が必要です。
まとめ
Stripe のサブスク解約は、基本的なロジックを理解してしまえば難しくありませんが、「期間の終わりまで使える」「即時に止まる」「status とフラグの意味が異なる」など、知っておくべき細かなポイントがあります。これらを押さえたうえで、自社サービスに合った解約運用を設計していくと、トラブルの少ない運営につながります。
コメント