Stripe
Overview
Stripe（ストライプ）は、オンライン決済プラットフォーム。
企業や個人事業主がウェブサービスやアプリケーションに簡単に決済機能を導入できるようにするAPIおよびサービスを提供している。
クレジットカード決済、銀行振込、サブスクリプション（定期課金）、マーケットプレイス支払いなど、幅広い支払い方法をサポートしており、世界中の多くの国と通貨に対応している。
Stripeの主な特徴
- 簡単なAPI設計
REST APIを使ったシンプルな設計で、少ないコードで決済機能を組み込むことができる。
プラン変更や顧客情報の更新などもプログラム上で柔軟に操作可能。 - 多様な支払い方法
クレジットカード、デビットカード、Apple Pay、Google Pay、銀行口座引き落としなど、多くの支払い方法をサポートしている。 - グローバル対応
世界中の135以上の通貨をサポートしており、国際的な取引にも強い。 - サブスクリプション管理
Stripeは「Subscription API」を使って定期課金（サブスクリプション）の管理ができる。
プランのアップグレード、ダウングレード、支払い失敗時の通知やリトライも容易に設定可能。 - セキュリティ対策
PCI DSS（クレジットカードの国際基準）に完全準拠しており、カード情報はすべてStripe側で安全に管理される。
開発者は直接カード情報を扱わず、トークン化されたデータを使うため、セキュリティリスクが低減される。 - 顧客ポータルやダッシュボード
Stripeが提供するダッシュボードを使うことで、取引や売上、支払いのステータスを簡単に確認できる。 また、顧客自身がサブスクリプションを管理する「顧客ポータル」を導入することも可能。
Stripeでできること
- オンライン決済の導入
オンラインショップやWebアプリにカード決済や電子決済を導入できる。 - サブスクリプションの構築
定期課金サービスを提供するためのサブスクリプション（定額課金）の仕組みを簡単に導入できる。
例）月額プランや年額プランの管理 - マーケットプレイス型決済
出品者と購入者がいる「CtoCプラットフォーム」でも、Stripeを使えば売上の分配や手数料管理ができる。 - 支払い処理の自動化
Webhookを使うことで、支払い成功・失敗時に自動的に処理を追加できる。
支払い失敗時の通知や支払い方法の再設定リマインダーなどの処理も可能。
PCI DSSについて
ここに書いてある内容は正確性に欠けている可能性があるので、実際に対応を進める場合は必ず専門家に相談しながら進めてください。 決済機能を提供する上で避けて通れないのがPCI DSSへの対応です。PCI DSSとは、クレジットカード情報を事業者がどのように扱うべきかを定めた情報セキュリティ基準です。クレジットカード情報を自社で保持する場合は300 件を超えるPCI DSSの各セキュリティ制御要件を満たさなければなりませんが、カード情報の処理をStripeなどの外部SaaSに任せる事で事業者に求められるセキュリティ制御要件は22件にまで減ります。そのためにカード情報の「非保持・非通過」を目指します。
Stripe拒否コード
Stripe Billing(サブスクリプション)
Stripe のサブスクリプション（すばらしいblog）
Stripe Subscription 開始パターンごとの作成方法まとめ
サブスクリプションに関連するリソース図
今まで Stripe Subscriptions として出してきた製品が Stripe Billing としてパワーアップし、新しくなった。
| リソース | 概要 |
|---|---|
| 顧客(Customer) | Subscription の購入者。カード番号を保持するのに必須で、Subscription を作るのに必須。 |
| 製品(Products) | 販売するサブスクリプション。名称や料金など設定する。料金の保存場所的なリソース。 |
| 料金(Price) | サブスクリプションの販売価格。Products に対して複数設定可能で請求金額と請求間隔を設定する。Subscription を作るのに必須。 |
| サブスクリプション(Subscription) | 販売するサブスクリプション。状態を持ち支払いに関連して状態遷移する。 |
| 請求書(Invoice) | サブスクリプションに対する請求。顧客にサブスクリプション料金を請求するタイミングで自動的に作られる。明細、税率、支払いの合計金額が記載される。 |
| PaymentIntents | 顧客の支払い処理。請求に対する顧客側から見た記録を保持する。状態を持つ。 |
| 税率(TaxRate) | 請求に加算する税率。Subscription を作成するときに default_tax_rates で指定してやると適用される。 |
| クーポン(Coupons) | 割引クーポン。Subscription を作成するとき coupon に指定すると適用され、割り引かれる。定額または割引率で設定する。割引期間も設定できる。税率を設定している場合、割引後の請求額で税金が計算される |
| Charge と Transaction | Invoice に対して、支払いが発生すると、ワンショットの決済の様に Charge が作成される。Charge の balance_transaction を見ると、その決済手数料がわかる。 |
サブスクリプションの状態
| 状態 | 概要 |
|---|---|
| trialing | Subscription 試用期間。まだ請求してない。 |
| active | Subscription が有効な状態。直近の請求に対する請求が成功している。 |
| incomplete | Subscription 作成時の請求が失敗した状態。 |
| incomplete_expired | 作成時の請求に失敗し、その後 23 時間以内に支払われなかった状態。 |
| past_due | 直近の請求が失敗している状態。リトライを試みている。 |
| canceled | Subscription がキャンセルされた状態。自動的な定期請求が止まる。 |
| unpaid | 直近の請求が失敗し、リトライも成功しなかった状態。請求書は作成されるが、自動的には請求されない。 |
サブスクリプションの更新について
【Stripe】サブスクリプションの支払いタイミングが特定日時においてズレる問題について(月末版)
まず起点の時間を把握しておく必要がある。
Stripeでは毎月・四半期・毎年などのサイクルを指定でき、起点からそのサイクルに則って開始される。
- billing_cycle_anchor
billing_cycle_anchorとは支払い開始の起点となる日時のことです。たとえば、毎月1日に決済したい場合、サブスクリプション作成時にbilling_cycle_anchorに翌月の1日を指定することで、毎月1日払いを実現することが出来ます。特に指定をしなければ、サブスクリプション作成時刻 = billing_cycle_anchorとなります。
サブスクリプションの更新(アップグレード)
ドキュメントの内容を基に deleted: true が必要なケース。
サブスクリプションを更新する際に、現在の料金を新しい料金に置き換えるには以下の方法がある。
- 既存のサブスクリプションアイテムを指定し、そのpriceを新しいprice_idに置き換える
items: [
{
id: '{{SUB_ITEM_ID}}',
price: '{{NEW_PRICE_ID}}',
},
]
これにより、サブスクリプションアイテムの料金が上書きされます。 2. 既存のサブスクリプションアイテムを削除してから、新しい料金を持つアイテムを追加する
items: [
{
id: '{{SUB_ITEM_ID}}',
deleted: true,
},
{
price: '{{NEW_PRICE_ID}}',
},
]
この方法では、削除のフラグdeleted: trueを使って既存の料金を無効化します。
deleted: trueを指定しない場合
- 対象のサブスクリプションアイテム（id）が正しく指定されている場合
- サブスクリプションアイテムが特定され、その価格が新しい価格（price）で上書きされる。
- 特に問題なく更新処理が行われる。
- サブスクリプションアイテム（id）が間違っている場合
- Stripeは指定されたサブスクリプションアイテムが存在しないと判断する。
- その結果、新しい料金（price）が「追加」され、サブスクリプションには複数の料金（既存のもの＋新しいもの）が紐付けられる状態になる。
deleted: trueを指定する場合
既存のサブスクリプションアイテムを明示的に「削除」してから新しい料金を追加するため、以下が保証されます：
- ミスによる新規料金の追加が防げる 間違ったidを指定する可能性がなくなる（削除対象が見つからない場合はエラーになります）
- サブスクリプション内の料金が常に1つに保たれる: 古い料金が削除され、新しい料金へ完全に置き換わる。
よくあるケースと選択
- シンプルなサブスクリプション構成（料金が常に1つだけ）:
- deleted: trueを使って確実に料金を置き換えるべき。
- 複数の料金をサブスクリプションで併用したい:
- deleted: trueを省略して、新しい料金を追加する。
まとめ
- deleted: trueを省略すると:
- 指定したidが正しければ更新される。
- idがミスっている場合は新しい料金が追加され、既存の料金も残る（サブスクリプションに複数の料金が紐付けられる）
- deleted: trueを使うと:
- 常に既存の料金が削除されるため、ミスや重複を防ぎ、サブスクリプション構造がシンプルに保たれる。
安全性を高めたい場合は、deleted: trueを指定するのがおすすめ
サブスクリプションの次回以降の支払い日時を変更する方法
次回以降の支払い日時を変更する方法としてtrial_endを使用します。
trial_endは本来であればトライアル期間を設定するために使用するパラメーターですが、支払い日時を変更する用途でも使用できます。
サブスクリプション継続決済
基本的にイベントは update が発行される。
しかし一度サブスクリプションをキャンセルした後に、再度入り直すとイベントはcreateになる。
Stripe Billing - 定期支払いにおける比例配分の考え方
Stripe document比例配分の仕組み
Stripe Billing - 定期支払いにおける比例配分の考え方
Stripe Billingで、サブスクリプションのプラン・料金変更後の請求金額を事前にプレビューする
Stripe Billingでサブスクリプションを提供している場合、契約期間中のプラン変更で「使った分だけ支払う」決済ができる。
stripeではこれを「比例配分」と呼んでいる
覚えた方がいい単語
- 按分（あんぶん）
- 割合に応じて分けること
- 按分とは
Stripeの按分計算
Stripeのデフォルトでは日割り計算（按分計算）は秒単位で行われる。
これにより、非常に正確な料金計算が可能。
詳細説明
Stripeでは、サブスクリプションの変更やキャンセルが行われた際に、利用期間に基づいて正確に料金を計算するため、秒単位で按分計算を行います。これにより、料金計算の精度が高まり、利用者に対して公平な請求が可能となります。
例
たとえば、月額料金のサブスクリプションが月の途中で変更された場合、変更前後の料金を以下のように秒単位で按分します。
- 月額料金が1000円のサブスクリプション
- 月の半ばで料金を2000円に変更
計算方法
-
月の前半（変更前）
- 1か月を秒単位で計算（30日と仮定して
30 * 24 * 60 * 60 = 2,592,000秒） - 前半の期間の秒数を計算（
15 * 24 * 60 * 60 = 1,296,000秒） - 前半の料金: (
1000円 / 2,592,000秒) * 1,296,000秒 = 500円
- 1か月を秒単位で計算（30日と仮定して
-
月の後半（変更後）:
- 後半の期間の秒数を計算（同じく
1,296,000秒） - 後半の料金: (
2000円 / 2,592,000秒) * 1,296,000秒 = 1000円
- 後半の期間の秒数を計算（同じく
-
合計料金: 500円 + 1000円 = 1500円
このように、非常に細かい時間単位（秒）での按分計算を行うことで、利用者に正確な料金を請求できます。
まとめ
Stripeのデフォルト設定では、按分計算は秒単位で行われます。これにより、自前で日割り計算の実装を行う必要がなくなり、StripeのAPIを利用することで高精度の料金計算が可能になります。自前で実装する場合、同様の精度を持つ計算を行うことは非常に難易度が高いため、Stripeのデフォルト機能を活用するのが望ましいです。
サブスクリプションの更新(ダウングレード)
即時でダウングレードを行うか、または未来で行うかで変わる。
即時ダウングレードの基本的な実装手順
- サブスクリプション情報の取得
既存のサブスクリプションを取得する(顧客の現在のプランや支払い情報を確認するために必要) - フェーズを利用したスケジュール作成or直接プラン変更
StripeのSubscriptionScheduleを使用してフェーズを定義し期間ごとに変更内容をスケジュールする。
もしくは、現在のサブスクリプションに対して直接プランを更新します。 - クレジット処理
ダウングレードの際、クレジット（差額）が発生する場合があります。
通常、Stripeはその金額を「顧客のアカウント残高」に適用し、次回請求時に差し引く。
顧客に即時返金したい場合は、別途refundを発行し、その後アカウント残高を調整する必要がある。
Stripe インボイス
Stripeにおけるインボイスは、顧客に対する請求や決済を管理するためのひとつの手段。
Stripeのインボイスは柔軟性が高く、異なる支払いシナリオやビジネスモデルに応じて設定することが可能。
具体的には、Stripeのインボイスは自動的な決済と手動決済の両方のケースに対応している。
Stripe インボイスの基本
-
自動的な決済 一般的にStripeを使用している多くのサービスでは、サブスクリプションや定期的な支払いがあり、これらは顧客が事前に支払い方法（例：クレジットカード）を登録しており インボイスが発行されると自動的にその登録された支払い方法で料金が決済される。
この場合、インボイスは主に記録として機能し、顧客への支払い詳細の確認や、会計処理のために用いられます。 -
手動での支払い 一部のケースでは、インボイスが発行された後、顧客が指定された支払い期限までに自ら支払いを行う必要がある。
この方式は、通常、B2B（ビジネス間取引）でよく見られる。
ここで、顧客はインボイスに記載された支払い手順にしたがって、オンラインでの支払い、銀行振込、または他の方法で支払いを完了する。
インボイスの送付と決済プロセス
-
インボイスのメール送信
- Stripeでは、インボイスが生成されると、顧客に自動的にメールで送信される。 このメールにはインボイスの詳細と、支払いを行うためのリンク（オンラインで支払いを完了するためのページへのリンク）が含まれている場合がある。
-
自動決済の通知
- 自動決済を行う設定の場合、顧客はメールでインボイスを受け取ると同時に、そのインボイスが登録されたカードで自動的に支払われたことを通知されることが一般的。
考慮すべき点
-
カード情報の更新:
- 顧客のカード情報が有効期限切れになっている場合や、その他の理由で決済が拒否された場合、多くのサービスではカード情報の更新を求める通知が行われます。これは、サービスの中断を避けるために重要です。
-
セキュリティ:
- 支払い情報の取り扱いには、常に高いセキュリティ基準を遵守することが重要です。StripeはPCI DSS準拠を実施しており、セキュリティの観点から信頼性が高いです。
Stripeのインボイス機能は非常に柔軟で、自動的な決済だけでなく、手動での支払いを求める場合にも対応できるため、さまざまなビジネスモデル
拒否コードの見方
まず大元として支払いが失敗する理由は3つある
- カード発行会社による支払い拒否
- ブロックされた支払い
- 無効なAPIコール
クーポン
Stripeにはクーポンとプロモーションコードの機能があります。これらを使うことで、顧客に対して割引や特典を提供できる。
クーポン (Coupon)
- 顧客にクーポンを適用する
- 顧客にクーポンを追加すると、クーポンは、顧客のすべてのサブスクリプション（後から追加するサブスクリプションを含む）に適用されます。顧客のすべての継続支払いを割引しないようにするには、顧客ではなくサブスクリプションにクーポンを追加します。
- クーポンを削除する
- クーポンを削除すると、その後のサブスクリプションや顧客に適用できなくなりますが、そのクーポンをすでに持っているサブスクリプションや顧客から割引が削除されることはありません。
概要
- クーポンは、特定の顧客に対して割引を適用するためのものです。
- クーポンは、サブスクリプションの請求時や、ワンタイムの支払い時に適用できます。
- クーポンは、固定金額の割引や割合の割引を提供できます。
主なフィールド
- id: クーポンの一意識別子
- amount_off: 固定金額の割引額
- percent_off: 割引率
- currency: 金額割引が適用される通貨
- duration: 割引が適用される期間（例：once, repeating, forever）
- duration_in_months: 割引が適用される月数（期間がrepeatingの場合に使用）
- max_redemptions: クーポンの最大利用回数
- times_redeemed: 現在までのクーポン利用回数
- redeem_by: クーポンの有効期限
利用例
Stripe::Coupon.create({
percent_off: 25,
duration: 'repeating',
duration_in_months: 3,
})
プロモーションコード (Promotion Code)
クーポンに作成される顧客表示用のコード
クーポンだけでも割引することは可能ですが、システム側で商品や顧客に対してクーポンを適用する必要があります。物理的なクーポン券のように顧客が任意のタイミングで利用していただくためにはプロモーションコードを作成する。
概要
- プロモーションコードは、クーポンを基にして顧客が特定のコードを入力することで割引を適用できるようにするものです。
- プロモーションコードを使うことで、クーポンをより広範に、簡単に利用できるようにできます。
- プロモーションコードは、クーポンに追加の制約を設定できます（例：特定の顧客のみ利用可能、特定の使用期限など）
- 特定のサブスクリプションや顧客に、プロモーションコードとクーポンの両方を同時に適用することはできません。
- 2つ以上のプロモーションコードを適用することはできません
主なフィールド
- id: プロモーションコードの一意識別子
- code: 顧客が入力するコード
- coupon: 関連付けられたクーポンのID
- active: プロモーションコードが有効かどうか
- restrictions: プロモーションコードに適用される制約（例：特定のカスタマーグループのみ利用可能など）
- expires_at: プロモーションコードの有効期限
- max_redemptions: プロモーションコードの最大利用回数
- times_redeemed: 現在までのプロモーションコード利用回数
利用例
Stripe::PromotionCode.create({
coupon: '25OFF', # 事前に作成されたクーポンのID
code: 'SUMMER2024',
max_redemptions: 100,
expires_at: Time.now.to_i + 86400 * 30 # 30日間有効
})
クーポンとプロモーションコードの違い
-
適用方法:
- クーポン: 直接適用される割引。クーポンIDを特定の支払いに関連付けることで割引が適用される。
- プロモーションコード: 顧客が入力するコードによって割引が適用される。クーポンを基にして作成される。
-
利用シーン:
- クーポン: 特定の顧客や特定のシナリオ（例：リテンションオファー）で使用。
- プロモーションコード: より広範なマーケティングキャンペーンやプロモーションで使用。
結論
Stripeのクーポンとプロモーションコードは、顧客に割引を提供するための柔軟なツールです。クーポンは直接割引を適用するためのものであり、プロモーションコードはそのクーポンを基にした顧客入力型の割引コードです。これらを効果的に利用することで、さまざまなマーケティングキャンペーンや顧客ロイヤルティプログラムを運用できます。
実装関連
Webhookの実装
基本は冪等で実装するべき（Stripeは何度も送信してくる可能性があるため）
エラーレスポンスを返してしまうと、Stripeが何度も試行してしまうのでそこも考慮すべき
RailsでのStripeの実装
顧客情報をstripeに登録し、その際に作られた顧客IDを中心にその他の課金等の処理を実行する というのが実装の方針となる。
それはなぜかと言うと、この顧客ID（cus_xxxxxxxxxxxxxx）を取得してしまえば、その顧客に対して定期課金や登録しているクレジットカードの削除などの処理を行えば良いからです！
Stripe APIを利用するための準備
クーポンについて 顧客にクーポンを適用する 顧客にクーポンを追加すると、クーポンは、顧客のすべてのサブスクリプション (後から追加するサブスクリプションを含む) に適用されます。顧客のすべての継続支払いを割引しないようにするには、顧客ではなくサブスクリプションにクーポンを追加します。 クーポンを削除する クーポンを削除すると、その後のサブスクリプションや顧客に適用できなくなりますが、そのクーポンをすでに持っているサブスクリプションや顧客から割引が削除されることはありません。
プロモーションコードについて クーポンに作成される顧客表示用のコード クーポンだけでも割引することは可能ですが、システム側で商品や顧客に対してクーポンを適用する必要があります。物理的なクーポン券のように顧客が任意のタイミングで利用して頂くためにはプロモーションコードを作成します。
クーポンの割引種類について 固定額割引: 購入金額から一定額を割り引く。 最小金額：1円 最大金額：999,999,999,999円（約9,999億円 ※日本円の場合） 固定額割引の場合、通貨毎に割引額を変えられます。 円では2,000円引き、ドルでは10ドル引き、のような指定が可能（現在は1ドル147円なので、日本円で購入した方がお得になるように見せる事ができます。）
パーセンテージ割引: 購入金額の特定のパーセンテージを割り引く。 最小割引：0.01% 最大割引：100%
チャージバック（不審請求）の申請
不審請求の申請は、さまざまな理由により、口座名義人が銀行に連絡して貴社への支払いに異議を申し立てたときに発生する。
不審請求が申請された場合、そのプロセスはカードネットワークによって若干異なりますが、一般的には標準パターンに従う。
チャージバック（不審請求）の概要
- カード会員が取引に異議を申し立てた状態を指す。Stripe では Dispute として扱われる。
- 期限までに反証資料（提供実績・規約同意・返金済み証跡 等）を提出しないと、自動的にカード会員勝ち（lost） になり、売上が取り消されるか資金が引き落とされる。
例：「信用取引が未処理（Credit Not Processed）」＝返金すべき取引の返金が未処理と主張されたケース。
典型フロー（時系列例）
- 支払い成功 …
invoice.payment_succeededまたはcharge.succeeded - 不審請求（dispute）開始 …
charge.dispute.created - 資金引落（暫定）…
charge.dispute.funds_withdrawn（加盟店口座から当該金額が控除） - 反証審理 … 提出がなければ自動的にカード会員側で解決
- 最終結果 …
charge.dispute.closed（won/lost）。lostのままなら売上は戻らない。wonの場合は下記の返還が入る。 - 資金返還 …
charge.dispute.funds_reinstated（勝訴時）
取得（購読）すべき Stripe イベント
EventLog（全件保存）
charge.dispute.createdcharge.dispute.funds_withdrawncharge.dispute.funds_reinstatedcharge.dispute.closed- 参考：売上系（重複計上しないポリシー前提）
- 請求主:
invoice.payment_succeeded - 都度主:
charge.succeeded/charge.captured
- 請求主:
- 返金系：
refund.created/charge.refunded - 失敗/未収（監査用）：
invoice.payment_failed/payment_intent.payment_failed
EventLog と PaymentHistory の使い分け
- EventLog … 受信した全 webhook を生で保存（監査・再処理・根拠保全）
- PaymentHistory … 金銭が実際に動いた時だけ登録（集計・会計連携）
PaymentHistory へのマッピング指針
| Stripe イベント | 登録 | event_type（例） | amount | 備考 |
|---|---|---|---|---|
invoice.payment_succeeded | 登録 | completed | 正（invoice.total） | サブスク/請求を主にする場合の唯一ソース |
charge.succeeded / charge.captured | 登録 | completed | 正（amount_captured/amount） | 都度決済を主にする場合の唯一ソース |
refund.created or charge.refunded | 登録 | refunded / refunded_partial | 負（返金額） | どちらを主にするか運用統一 |
charge.dispute.funds_withdrawn | 登録 | chargeback_lost（または chargeback_opened） | 負（控除額） | 資金が抜かれた時点で記録 |
charge.dispute.funds_reinstated | 登録 | chargeback_won | 正（返還額） | 勝訴時のみ |
invoice.payment_failed / payment_intent.payment_failed | 登録しない | — | — | 金銭未確定のため |
customer.subscription.* | 登録しない | — | — | 状態遷移は EventLog のみ |
チャージバック手数料は Stripe の手数料明細で別途発生。
PaymentHistoryではadjustment（負）等の種別で別レコードとして計上するか、手数料専用テーブルに切り出す。
運用（推奨）
- 期限アラート：
charge.dispute.created受信時に Slack 通知＋期限（evidence_details[due_by]）まで日次リマインド。 - 自動照合：「信用取引が未処理」理由コードの場合、対象取引の返金有無を自動突合し、返金済みなら証跡（refund id / 日時）をテンプレ化して即提出。
- 可視化 KPI：チャージバック率、理由コード別件数、負け率（lost%）、平均対応日数、ネット損益（売上−返金−CB−手数料）。
実装メモ
- 冪等：EventLog 挿入は
(source, event_id)で UPSERT。PaymentHistory への反映も(event_source, event_id)または(transaction_id, event_type, refund.id)等で UPSERT。 - 主従の決定：**請求主（invoice）**を唯一ソースにするか、**都度主（charge）**を唯一ソースにするかを先に決め、片側のみ計上（もう片側は EventLog 参照のみ）。
- 金額は符号付きで保持（売上=正、返金/CB/手数料=負）。
用語メモ
- 信用取引が未処理（Credit Not Processed）：返金すべき案件に対し返金が未処理と主張されたときのブランド理由コード系。反証がなければ lost になりやすい。
churn（チャーン）分析とは
「churn（チャーン）分析」はサブスクビジネスでよく使う用語で、日本語では「解約率」「離脱率」と訳されます。
サブスクリプションや継続課金サービスにおいて、顧客がどのくらい離脱しているか（課金を続けていないか）を定量的に分析することです。
具体的には次のような指標を測ります： • 解約率（Subscription Churn Rate） 一定期間で解約したサブスク契約数 ÷ 期初の契約数 → 「契約ベースでどれくらい解約されたか」 • 収益チャーン率（Revenue Churn Rate） 一定期間で失われたMRR（月次売上） ÷ 期初のMRR → 「売上ベースでどれくらい解約されたか」
⸻
例 • 月初に 1,000 人がサブスク契約していた • 月末までに 50 人が解約 • → 解約率 = 50 ÷ 1000 = 5%
もしその 50 人が高額プランだった場合、人数では 5% でも売上ベースではもっと大きな割合になる（→ 収益チャーン で見る必要がある）。
なぜ重要か • LTV（顧客生涯価値） の計算に直結 • 新規獲得よりも「離脱防止」が利益に効くことが多い • プランごと・顧客セグメントごとに 解約のパターン を分析すると、改善のヒントになる
決済失敗との関係 • 継続課金型サービスでは、解約の直接原因が「ユーザーの意思」だけとは限らない • クレカ有効期限切れ • 残高不足 • カード会社の拒否 • こうした 継続課金の失敗 → 未回収 → 結果として解約 になるケースも多い
👉 だから「継続課金の失敗イベント（payment_failed）」を拾って分析に組み込むと、 「本当に解約したい人」 vs 「失敗で仕方なく churn した人」を分けられる → 改善施策に役立つ。
まとめ • churn分析 = 顧客や売上がどれくらい離脱したかを追う分析 • 種類は「契約チャーン」と「収益チャーン」 • サブスクでは「決済失敗」も churn の一因 → 分析用にログ/履歴を残すと便利
👉 ここで質問ですが、あなたがやりたい churn 分析は「会計レベルでの売上推移」なのか、それとも「プロダクト改善のためにユーザー行動や決済失敗要因まで掘りたい」のか、どちらに寄せたいですか？