認証と サブスク決済

認証と サブスク決済 nishinomiya.dev 2025/09/21

請求モデルに合致した データ連携を設計しよう 「技術負債が原因で、やりたい請求モデルが作れない」を回避する

岡本 秀高 @hidetaka_dev ● 元 Stripe の DevRel ● US や東京の Stripe カンファレンス参戦 ● Stripe Apps アプリ開発者 ● テスト用 Stripe MCP サーバー開発 https://clerk.com/b2b-saas

• https://clerk.com/b2b-saas

決済は、後回しされる必須機能 ● ● ● ● 基本機能とは 直接関係ない なくても コア機能自体は動かせる 「リソース最適化」で 組み込みを後回しにする 「いざとなれば、 別で請求書を出せばいい」 プランごとの 権限設定どうする？ 契約情報はどこから？ 追加のDBが・・・ プラン変更・・・！？

実装はしなくとも 決済を見据えた設計を心がける 決済がなくても、アプリは動く。 ただしお金を産まないなら「会社の商品」ではない

ありがちなハマりどころ・考慮漏れ 契約主体の考慮漏れ 権限管理の考慮漏れ ユーザーごと契約でリリース プランベースで権限管理 しかし「法人契約が必要」と 見込み客から言われた。 ある日大口顧客から、 個別のカスタム契約相談が 決済では、顧客の商習慣や契約体系に応じた データモデルや設計が必要となる

「担当者退職したので、 契約者と決済内容を このアカウントに移して」

B to B の取引・契約は 開発者にとって複雑すぎる

B to Bで押さえておきたい要件 ユーザーと契約の分離 権限を独立管理 ● 組織 / Organization ● Feature Flag ● ユーザーDBとは ● プランと権限を 別のテーブルで管理 ● サブスクや決済は 組織に対して紐づける 別で管理 ● 個別の権限付与に対応

Clerk Organization ● IDaaS prebuilt Org feature ● ユーザーと別に 組織管理機能を提供 ● IDaaSに統合されていることで、 DB設計の複雑さを回避 https://clerk.com/b2b-saas

• https://clerk.com/b2b-saas

Stigg.io ● 決済 & Entitlement SaaS ● 契約やプランに対する 権限の管理に特化 ● APIやダッシュボードも提供 ● Stripeなどとも連携可能 https://www.stigg.io/

• https://www.stigg.io/

BtoB SaaS は、商習慣も重要なドメイン ● 契約主体が個人か組織（法人）かは必ずチェック ● 契約主体に合わせて ユーザー DB と決済データなどの連携を設計すべし ● マーケティングや営業戦略を踏まえると、 プランと権限も別で管理することを推奨

価格は変わる。 絶対に AWS ですら、 Kiro ( AI エディタ )の価格を 二転三転させている

Stripe Subscription Schedule API などで 価格改定に備える https://docs.stripe.com/api/subscription_schedules/create

• https://docs.stripe.com/api/subscription_schedules/create

B to C なら もっとシンプルにできる？

B to C でも、組織概念はたまに必要 ● ● 例: 契約主体が家族になるケース ○ 知育アプリやサービス ○ 見守りサービス ○ 回線契約や施設利用など 「ユーザーはどんな契約をするだろうか？」を 企画調査フェーズでかならず行うこと

まとめ: ログインの先にある複雑さ ● ログインユーザーと契約者 / 主体が 常に同一人物とは限らない ● ユーザーとプランだけでなく、 権限と組織についても設計を行おう ● そもそもの設計・調査フェーズで 「どう契約して、使われるか」も考慮しよう