― 課金を繋ぐのは半日で終わる。難しいのは、その後に起きることの設計。
§ 01 / 「決済が通る」はスタート地点
Stripe を使えば、カード決済を通すこと自体は短時間で実装できます。プロジェクトが伸びるのは、そこから先です。
- 月の途中でプランを上げたら、いくら請求するのか
- カードの期限が切れて決済が失敗したら、いつサービスを止めるのか
- 解約されたら、データはいつまで残すのか
これらは技術ではなく事業ルールです。決めるのは開発会社ではなく、事業側です。ここが決まっていないと、実装は必ず止まります。
§ 02 / 先に決める 6 つの論点
| 論点 | 決めること |
|---|---|
| プラン変更 | アップグレードは即時か次回更新か。日割りするか |
| ダウングレード | 即時反映か、次回更新まで現プランを維持か |
| 無料期間 | 何日か。カード登録を先に求めるか |
| 決済失敗 | 何回リトライするか。何日目で機能を止めるか |
| 解約 | 即時停止か期末まで利用可か。返金の有無 |
| 請求書 | 適格請求書（インボイス）の発行が要るか |
決済失敗の扱いは特に重要です。カード期限切れは一定割合で必ず起きます。「失敗したら即停止」にすると、優良顧客をうっかり失います。3 回リトライして、その間はメールで通知し、7 日目に制限、というような段階設計が実務的です。
§ 03 / 日割りは、やらない選択もある
Stripe は日割り計算に対応していますが、日割りしないと決めるのも有力な選択です。
- 日割りあり … 顧客にとって公平。ただし請求書が複雑になり、問い合わせが増える
- 日割りなし … 「変更は次回更新から」で統一。説明も実装もシンプル
BtoB で単価が高い場合は日割り、月額数千円のサービスなら日割りなし、という判断が多いです。公平さと運用コストのトレードオフとして決めてください。
§ 04 / 自社で持つデータと、Stripe に持たせるデータ
境界を曖昧にすると、後で整合が取れなくなります。
- Stripe に持たせる … カード情報、請求履歴、サブスクの状態
- 自社で持つ … 顧客とプランの紐付け、利用権限、サービス内のデータ
カード情報を自社で持たないことがセキュリティ上の最大の利点なので、そこは絶対に自前化しない。一方で「このユーザーが今どのプランか」は自社側にも持っておかないと、Stripe への問い合わせが常時発生して重くなります。
§ 05 / テストで必ず通す 5 ケース
リリース前に、最低限このシナリオを通します。
- 新規登録 → 初回課金 → 翌月の自動更新
- プランのアップグレード / ダウングレード
- 決済失敗 → リトライ → 復帰
- 解約 → 期末で権限が落ちる
- 解約後の再登録
⑤ の再登録が抜けがちです。一度解約した顧客が戻ってきたときに、古いデータと衝突してエラーになるケースは頻出します。
§ 06 / A.I.M の考え方
A.I.M は Shopify / Stripe での構築実績があります。決済まわりは、実装より先に事業ルールを一緒に決めるところから入ります。プラン設計・失敗時の扱い・解約フローを整理したうえで開発すれば、後から作り直す事態を避けられます。初期費用を抑えたい場合は、月額固定のサブスク型で開発・運用費を分割する契約形態もご用意しています。
関連サービス: システム受託開発 / HP・LP・EC制作 / お問い合わせ