サブスク実装は意外と考えることが多いという話

はじめに

表記について
本記事では、サブスクリプション（定期購入・定期課金）のことを、「サブスク」と省略して記載しています。

「Webサービスにサブスク機能をつけたいんだよね」と言われたとき、最初に何を思い浮かべますか？

「ユーザーにプランを紐づけて、毎月1回請求するだけでしょ？」といった、割とシンプルなイメージだと思います。

ただ、実際に手を動かしてみると、想像以上に検討すべきことが多くあります。

この記事では、私が実際にサブスク実装を進める中で直面した課題やポイントを整理し、Stripe や PAY.JP の機能がどう役立つかを紹介します。

開発者はもちろん、複雑なサブスクの仕様策定に悩む企画担当の方にも、きっと参考にしていただけるはずです。

1. トライアルの分岐

無料トライアルはユーザー獲得に効果的ですが、実装を考え始めると途端に分岐が増えます。
※トライアルをなしにするのも一つの判断ですが、無料トライアルがあるサービスの方が一般的な気はしてます (主観です)

▼検討すべきこと

カード登録は任意か必須か

• 任意の場合
  カード情報なしで開始できますが、トライアル終了後にどうやって有料プランへ誘導するかが重要になります。UI上の導線や、どのタイミングで案内を出すかなどを丁寧に設計する必要があります。

• 必須の場合
  トライアル終了と同時に自動的に課金が始まります。トライアル中に「カード未登録なら機能制限」というような仕組みは不要ですが、その分、初回登録時のハードルは上がります。

▼決済SaaSの関連する機能

Stripe / PAY.JP ともに以下のようなパラメータで簡単に制御できます。

• trial_end（トライアル終了日時）

また、「カード情報なしでサブスクリプション枠だけ作っておく」という運用にも対応しています。

2. 課金タイミングの検討

「月額課金」と一言で言っても、実装上は「いつ」「いくら」課金するかをきちんと定義する必要があります。特にカレンダーの不規則性が厄介です。

▼検討すべきこと

毎月1日課金の場合

1月25日に加入したユーザーの初月分をどう扱うかは、サービスごとに違います。

• 日割りで請求する
• 初月無料とする
• 初月から満額請求する (あまり見ない)

どれを採用するかは、ビジネス側とのすり合わせが必要です。

加入日ベースの場合

1月31日に加入したユーザーの翌月の請求日はどうなるのか、という問題があります。

2月には31日が存在しないため、「28日（うるう年は29日）にするのか」「月末に合わせるのか」など、取り扱いを明確にしておく必要があります。

▼決済SaaSの関連する機能

両サービスとも、課金基準日の固定や日割りの制御が下記のパラメータを使用することで実現できます。

機能	Stripe	PAY.JP
課金基準日の固定	billing_cycle_anchor	billing_day
日割りの制御	proration_behavior	prorate

また、「存在しない日（2月30日など）」の扱いについても、両サービスとも自前での日付計算は不要です。月末などが存在しない場合、自動的にその月の末日などに調整するロジックを備えています。

• Stripe
  • 起点日に最も近い「その月の最終日」になります。
    • 例) 1/31開始 → 2/28請求 ( うるう年の場合は2/29 ) → 3/31請求
• PAY.JP
  • 翌月に同日がない場合、「最も近い日」に移動します。
    • 例) 1/31開始 → 2/28請求 → 3/28請求
      • 日付が前にずれる

3. プラン変更の分岐

ユーザーがプランを変更する際の挙動も、想像より多くの仕様を決める必要があります。

▼検討すべきこと

アップグレード（下位 → 上位）

通常は「即時適用」ですが、料金の扱いをどうするかがポイントです。

• 残り期間分の差額を即時決済する
• 次回請求に合算する
• 日割りするかどうか

ここが曖昧だと、後々ユーザーからの問い合わせにつながります。

ダウングレード（上位 → 下位）

返金対応が発生すると手間が増えるため、「次回更新時に下位へ変更する」という運用を採用するサービスが多い印象です。

▼決済SaaSの関連する機能

Stripe

proration_behavior パラメータで、日割りの挙動を細かく制御できます。

• create_prorations: 差額を次回請求に追加（またはクレジット化）。
• always_invoice: 差額を即時決済。
• none: 日割り計算なし。

プラン変更の予約（次回更新時に適用）には Subscription Schedules 機能を使います。「3ヶ月後にさらに別のプランへ」といった複雑なスケジュールも組めますが、実装工数はやや高くなります。

参考: 比例配分

PAY.JP

prorate パラメータ（ true / false ）で、日割りの有無をシンプルに指定できます。true にすれば、差額の即時請求や返金計算が自動で行われます。

プラン変更の予約は next_cycle_plan パラメータを指定するだけです。「次回更新時から新プラン」という要件も、複雑なバッチ処理なしでAPIのみで完結します。

参考: 定期課金を更新

4. 決済失敗の分岐

クレジットカードの期限切れや限度額超過で更新時の決済が失敗することは頻繁に起こります。この処理次第で継続率が大きく変わります。

▼検討すべきこと

即時に利用停止にするか

カード更新忘れなど一時的な理由もあるため、いきなり利用停止にするとユーザー体験を損ねる可能性があります。

猶予期間を設けるか

決済が失敗していても、一定期間は利用を許可する仕組みです。
ただし「グレース中」「リトライ中」などのステータス管理が必要になります。

リトライ回数や最終的なステータス

何回再決済を試みるのか、最終的に「解約扱いにするのか」「未払いとしてアカウントを保持するのか」を決めておく必要があります。

▼決済SaaSの関連する機能

Stripe

決済失敗後のリカバリーフローを、非常に細かく自動化できるのが最大の特徴です。 機能が豊富な分、管理画面での設定項目は多岐にわたるため、「どこまでをStripeに任せ、どこから独自実装するか」の設計判断が重要になります。

• Smart Retries 機能あり
  • 一部のステータスを除き、機械学習を用いて、「最も成功率が高いタイミング」を判断し自動で再決済を行う。
• 自動メール通知あり
  • 決済失敗時にユーザーへ案内メールを送信したり、カード更新用のリンクを自動で案内可能。
• ステータスの自動遷移あり
  • active(課金有効) → past_due(延滞) → unpaid(未払い) → canceled(解約) といったサブスクリプションの状態遷移を、設定したルールに基づいてStripeが自動処理。

PayJP

PAY.JPの課金失敗リトライは、定期課金の場合、管理画面またはAPIから「再開」ボタンを押すことで、即時決済を試みることができます。

自動リトライ機能は限定的であるため、失敗時のハンドリングは加盟店(開発)側で実装する必要があります（※加盟店側へメールや Slack 通知機能は利用可能）。
その反面、Stripe に比べて機能や管理画面が非常にシンプルであるため、設定に迷うことなくスムーズに運用を開始できるのが強みです。

共通

どちらのサービスもWebhook (決済の成功や失敗やステータス変更などを通知する仕組み) が用意されているので、加盟店側はそれを受け取った際に、どこまでの独自実装をするかを使用するサービスによって判断していく必要があります。

参考: Webhook エンドポイントで Stripe イベントを受信する - Stripe / Webhook - PAY.JP

終わりに

ここまで見てきたように、サブスク実装は「APIを呼べば終わり」というものではありません。
プラン変更やトライアル、課金日の扱い、決済失敗時の対応など、仕様として詰めるべき点が多岐にわたります。

ありがたいことに、 Stripe や PAY.JP には、こうした複雑なケースに対応するオプションが豊富に用意されています。

「日割りするかどうか」「プラン変更の扱い」「決済失敗後の猶予期間」など、実装の前に一度ドキュメントを眺めてみると、意外と簡単に解決できるオプションが見つかるはずです。

これからサブスク実装に取り組む方の参考になれば幸いです。

各サービスの仕様やAPIパラメータはアップデートされる可能性があるため、実際の開発・実装にあたっては、必ず各社の公式ドキュメントにて最新情報を確認してください。