サブスクで稼ぐなら、 決済は“機能”じゃなく “インフラ”で選べ

サブスクで稼ぐなら、 決済は“機能”じゃなく “インフラ ”で選べ サービスをつくるなら稼ぎたい。決済について話そう。 Hidetaka Okamoto

自己紹介 Hidetaka Okamoto (岡本秀高 ) ● Stripe -> CircleCI Senior Field Engineer ● https://wp-kyoto.net / https://hidetaka.dev ● AWS Community Builder ( Serverless | 3年目 ) 2

決済サービス、 何で選びました？ 手数料 API ドキュメント Developer Advocateとして会話して、出てくることが多いのはこの３つ 社内的な アレコレ

多くの人が想像する「決済導入」 実際に起きること APIを呼ぶ ↓ 支払いが通る ↓ 完了！ →

多くの人が想像する「決済導入」 実際に起きること APIを呼ぶ ↓ 支払いが通る 請求書の発行・送付 → ↓ 完了！ 決済を「入れる」のは一瞬。その後の運用が本番。 未払いの検知・リトライ 顧客からの問い合わせ対応 プラン変更・解約処理 経理への数字共有 マーケ施策のたびに改修

この視点の転換は、すでに業界で起きている Revenue Operations 営業・マーケ・ CSがバラバラに動くのをやめて、 収益プロセス全体を一つのチームとして設計する考え方。 Revenue & Finance Automation Stripeが提唱。決済だけでなく、請求・税・レポート・照合まで キャッシュフローの全工程を自動化する考え方。 共通点： 決済の「外側」まで含めて設計しないと、稼ぎが運用コストに溶ける

20〜40% SaaSの解約のうち、決済失敗が原因の割合 顧客は使い続けたかったのに、カードが通らず静かに離脱する 月額1万円 × 100人 = 月商100万円のサービスなら 毎年 約1ヶ月分の成長が決済失敗で帳消しになる

これは仮定の話ではない $3.8B Stripeの自動リカバリーが 2022年に回収した売上額。 仕組みがなければ （約5,700億円） この全額が静かに消えていた。 決済失敗のリカバリーだけで、これだけの差がつく。 他の運用も含めれば、決済サービスの選択が利益構造を左右する。

サブスクを入れると何が起きるか 回収の運用 管理の運用 カード期限切れ、残高不足、 決済失敗のリトライ・通知 請求書、領収書、按分計算、 インボイス制度対応 顧客対応の運用 施策実行の運用 解約、カード変更、 領収書再発行の問い合わせ 新プラン追加、トライアル変更 のたびにエンジニアが動く これらを人がやるか、インフラが吸収するかで利益構造が変わる

決済サービスを選ぶとは、 この依存関係を どこまで断ち切れるかを選ぶこと エンジニアのリソースが運用に溶ければ機能開発が止まる 施策のリードタイムが開発キャパに縛られる

Stripeはこれをどう吸収するか 各機能を「どの運用を、誰から解放するか」で見る Invoicing Dashboard Customer Portal Workflows

Invoicing 管理の運用を経理から解放する 請求書・領収書の自動発行 按分計算、税計算を自動処理 インボイス制度対応 適格請求書の要件を Stripe側で吸収 経理の手作業ゼロへ 毎月の発行・送付・管理が自動化される

Dashboard 数字の可視化を開発チームから解放する MRR・チャーン率・未払い状況 リアルタイムで可視化 経営・CS・マーケが自分で見れる 「あのデータ出して」でエンジニアが動かない 意思決定の速度が変わる 数字を取るためのリードタイムがゼロに

Customer Portal 顧客対応をサポートから解放する プラン変更・支払い方法更新・解約 顧客が自己完結 サポート問い合わせが減る 「解約したい」「カード変えたい」が来ない この機能を自前で開発する必要もない コード数行で顧客向けポータルが立つ

Workflows イベント駆動の運用を開発チームから解放する 支払い失敗 →リトライ +通知 ノーコードでダッシュボード上に構築 高額請求 →社内承認ルート 条件分岐付きのフローをビジュアルで設計 Webhookハンドラを書かなくていい 運用サイドが自分でフローを組んで改善を回せる

開発チーム以外が 自走できる基盤かどうか 経理が請求を回す CSが顧客状況を見る マーケが施策を試す 運用がリカバリーを 自動化する 全部エンジニアを介さずに。 決済APIの美しさでも手数料の安さでもなく、 ops機能の幅が利益構造を決める

Engineering that maximizes SaaS revenue 技術選定は収益構造の設計である