Skip to main content

​
継続収益を自動化。

顧客がサブスクリプションを開始したら、請求サイクル、更新リカバリー、ライフサイクル管理は私たちが処理します。あなたは製品に集中してください。

​
仕組み

更新の課金が失敗すると、サブスクリプションは past_due に移行します。Waffo 自身はリトライをスケジュールしません。決済チャネルが課金を1 回リトライし、通常は翌日に行われます。リトライが成功すればサブスクリプションは active に戻り（subscription.recovered）、失敗すれば即時にキャンセルされ（subscription.canceled）、顧客は再度申し込む必要があります。独立した猶予期間のタイマーはありません。顧客には更新前にリマインダーメール（週次は 1 日前、月次・四半期は 3 日前、年次は 7 日前。トライアル終了は 1 日前）が届き、課金が成功するごとに領収書が送られます。

​
サブスクリプションプランの構造

Waffo Pancake では、個別に購入可能なサブスクリプションオプションはそれぞれ独立したサブスクリプション商品です。 最も一般的な区別は請求サイクルです。例：
  • 月次
  • 年次
月次と年次の両方の請求を提供する場合、通常は2つのサブスクリプション商品を作成します。

​
サブスクリプションステータス

​
請求サイクル

​
トライアル期間

登録のハードルを下げましょう。購入を決める前に顧客にお試しいただけます — 無料でも、少額の課金付きでも設定できます。

​
トライアルの設定

サブスクリプション商品を作成する際、ダッシュボードでトライアルトグルを有効にし、日数を設定してください。

​
プラットフォームレベルのトライアル保護

Waffo Pancake は Merchant of Record（記録商）として、トライアルの不正利用を自動的に防止します： 2つのレイヤーの相互作用：
  • 加盟店のリクエストがプラットフォーム最大値以下の場合 → 加盟店のリクエスト値が使用されます
  • 加盟店のリクエストがプラットフォーム最大値を超える場合 → プラットフォーム最大値にフォールバックします
  • 加盟店が指定しない場合 → プラットフォーム最大値がそのまま使用されます

​
有料トライアル

トライアルは無料である必要はありません。トライアル期間中に費用を完全に免除する代わりに、少額の割引金額を請求できます — いわゆる「$1 トライアル」のパターンです。この金額は任意で、通貨ごとに設定でき、常に通常価格より低くなります。トライアル終了後は、自動的に通常価格での請求に切り替わります。
有料トライアルは無料トライアルよりも低意向の登録をフィルタリングしやすい一方、一定のコンバージョン摩擦が生じます。象徴的な少額（例：$1）を請求するだけで、真剣な購入者を遠ざけることなく支払い方法の有効性を確認できます。

API でトライアル価格を設定する

リクエストフォーマットとルールについては trialAmount フィールドのリファレンスを参照してください。

​
購入者 ID とトライアル保護

トライアル適格性は buyerIdentity で追跡されます — 認証済みチェックアウトで提供する安定した識別子です。プラットフォームはこれを使用して、セッション間での重複トライアル取得を検出します。
buyerIdentity なし（匿名チェックアウト）の場合、トライアル適格性チェックは完全にスキップされます。購入者はメールアドレスを変更するだけで無制限にトライアルを取得できます。
7〜14日間のトライアルが最も効果的です。短すぎると評価する時間が足りず、長すぎると忘れられてしまいます。

​
更新リカバリー

更新の課金が失敗すると、サブスクリプションは past_due に移行し、subscription.past_due が届きます。リカバリーの猶予は短く、決済チャネルが決めます。チャネルは通常翌日に 1 回だけ再課金します。
  • リトライ成功 —— サブスクリプションは active に戻り、subscription.recovered と subscription.payment_succeeded が届きます。
  • リトライ失敗 —— サブスクリプションは即時にキャンセルされ、subscription.canceled が届きます。顧客は再度申し込む必要があり、3 回目の試行や猶予期間のタイマーはありません。
past_due の当日はアクセスを維持し、2 回目の失敗でサブスクリプションが終了するため、リトライ前に支払い方法の更新を顧客へ促してください。
past_due は単に「支払いが失敗してサービスが停止した」ではなく、「更新にリカバリーが必要」と捉えてください。

​
サブスクリプション管理

​
キャンセル

キャンセルは常に現在の請求期間の終了時に有効になります。キャンセルがリクエストされると、サブスクリプションは canceling の中間ステータスに移行します。顧客は現在の請求期間が終了するまでアクセスを維持し、その時点でステータスは canceled に移行します。
レスポンスには currentPeriodEnd が含まれるため、アクセスがいつ期限切れになるかを把握できます。返されるステータスは canceling（期間がすでに終了している場合は canceled）です。
即時キャンセルのオプションはありません。顧客は常に支払い済み期間の終了までアクセスを維持します。canceling → canceled の移行は、現在の請求期間の満了時に自動的に行われます。

​
サブスクリプションの再開

サブスクリプションがまだ canceling の場合、顧客は現在の期間が終了する前に再開できます。 再開後：
  • サブスクリプションは active に戻ります
  • アクセスは中断なく継続します
  • 以降の更新は元の請求サイクルで継続します
再開は、キャンセルされたものの現在の期間の終了にまだ達していないサブスクリプションに適用されます。これは実質的にキャンセルの取り消しであり、新規購入ではありません。

​
プラン変更

プラン変更は、顧客にキャンセルと再購入をさせることなく別のプランへ移行させる仕組みです。実装上は1 件のキャンセルと 1 件の新規サブスクリプションとしてモデル化されており、古い注文が終了し、新しい注文が作成されます。サブスクリプションのプランをその場で書き換えることはありません。 顧客は必ずホスト型の変更確認ページで確定します。変更前後のプランが並べて表示され、日割り差額が項目ごとに明示され、適用日も記載されます。

​
変更方向がデフォルトの適用タイミングを決める

即時変更では、現プランの未使用分が新プランの請求額から控除されます。この控除額は送信時点で実際の残日数から再計算されます —— リンク発行時に表示された金額は見積もりであり、確約ではありません。
最後の 24 時間は非対称です。 即時変更は次回請求まで最低 24 時間必要ですが、翌期変更は期間終了まで 1 時間あれば足ります。そのため最後の 1 日の間、アップグレードは 400（Immediate plan change requires at least 24 hours before the next charge）で失敗します。changeTiming: "next_period" を明示的に指定した場合を除きます —— 黙ってフォールバックしません。ダウングレードは元々翌期がデフォルトなので、引き続き利用できます。

​
誰が開始できるか

2 つの経路があり、それぞれ従うルールが異なります。
selfServicePlanChange は商品グループのルールで、未設定は無効として扱われます。無効の間、ポータルからのプラン変更は 403 で拒否されます —— 加盟店が発行する変更は影響を受けません。プランを自分で切り替えられると顧客に案内する前に、有効化してください。
ダッシュボードの画面からプラン変更を開始する機能は、まだ利用できません。サブスクリプションページに導線は表示されますが、近日公開 と記載されています。API は今すぐご利用いただけます。

​
顧客のセルフサービス

セルフサービスはカスタマーポータルで行われ、あなた側の実装作業は必要ありません。顧客がサインインし、サブスクリプションを開き、同一グループ内の別プランを選んで確定します。 有効にする方法：対象プランを 1 つの商品グループにまとめ、selfServicePlanChange を有効にします。
セルフサービスの入口はポータルだけではありません。customer セッショントークンを使えば同じことを自社の画面でも提供できます —— SDK の customer.createPlanChangeSession() です。顧客自身の資格情報で発行されるため、まったく同じ 3 つの条件（本人のサブスクリプション・同一商品グループ・selfServicePlanChange が有効）で制御されます。あなたの API Key で発行する場合は別の経路で、3 つの条件はいずれも適用されず、任意のプランへ変更できます —— 詳細は下記のとおりです。

​
API による加盟店起点の変更

1

変更リンクを発行

checkout/create-session を呼び出し、originOrderId に移行させたいサブスクリプションを指定します。これでエンドポイントがプラン変更モードに切り替わり、変更確認ページ向けの checkoutUrl が返ります。
2

送付はあなたが実施

メール、アプリ内メッセージなど、既存の到達手段をお使いください。プラットフォームがこのリンクを送信することはありません。
3

顧客が確認

顧客が変更前後の比較を確認して確定します。あなたのシステムは Webhook で結果を知ります。
任意パラメータ リンク発行時にチェックされる条件 —— 顧客がページを目にする前に失敗します。
未確定の変更が新しい変更を妨げることはありません。顧客がリンクを開いたまま支払わなかった場合は、もう一度発行するだけです。

​
システム側で想定すべきこと

ライフサイクルは 3 つの Webhook イベントでカバーされます。 即時変更はオーソリ直後に切り替え時刻に到達するため、先行する scheduled なしで plan_changed に直行します。
権限判定ロジックの落とし穴が 2 つあります：
  1. 対象となる 2 つの注文について、subscription.activated と subscription.canceled は送信されません。これは意図的で、「キャンセル時に権限を剥奪する」処理がプラン変更で誤作動しないようにするためです。
  2. 確定から切り替え時刻までの間、元のサブスクリプションは canceling にとどまりますが、権限は有効なままです —— 支払い済みの期間はまだ継続中だからです。canceling はアクセス権ありとして扱ってください。顧客自身による期末キャンセルと同じ扱いです。
予定された変更が保留中の間、新しいサブスクリプションにはまだ請求期間がありません（currentPeriod は null）—— 最初の期間は切り替え時刻に決済チャネルによって確定します。
失敗した場合、新しい注文は終了し、元のサブスクリプションはそのまま継続します。元のサブスクリプションを既に canceling にしていた予定済みの変更では、active に戻ります。その後、改めて変更を発行できます。
通貨をまたぐ変更はサポートされません。トライアル期間中のサブスクリプションはプラン変更できません。

​
メトリクス

​
MRR（月次経常収益）

​
主要メトリクス

​
Webhooks

サブスクリプションのライフサイクルイベントを Webhook で受信できます。設定 —> Webhooks で Webhook エンドポイントを設定してください。
具体的な Webhook イベント名は変更される可能性があるため、ここでは記載していません。利用可能なイベントの最新リストについては、ダッシュボードの Webhook 設定をご参照ください。
Webhook ペイロードは Waffo Pancake の標準的な規約に従います：
  • ID は UUID v4 形式
  • 金額は表示形式の文字列
  • タイムスタンプは ISO 8601 UTC
  • 請求頻度は billingPeriod フィールドを使用（例：monthly、yearly）

​
カスタマーポータル

顧客がセルフサービスでサブスクリプションを管理：
  • 詳細を確認
  • 支払い方法を更新
  • プランを変更
  • キャンセル
  • サブスクリプションの再開
  • 請求書をダウンロード

カスタマーポータル

セルフサービスのサブスクリプション管理。

​
ベストプラクティス

更新請求の失敗が即時キャンセルを意味する必要はありません。顧客にサブスクリプションを回復する時間を与えましょう。
トライアル終了前、請求前に通知。顧客を驚かせない。