ADR-007: 決済基盤に Stripe を採用
- ステータス: Accepted
- 日付: 2026-03-09
- 決定者: アーキテクトチーム
コンテキスト
TASHIKAはB2B SaaSとして月額サブスクリプション請求を行う。決済基盤の選定にあたり、以下の要件がある:
- サブスクリプション請求: 月次バッチで請求を生成し、クレジットカードに自動課金する
- 従量課金との組み合わせ: 基本料金＋アクティブ従業員数による従量料金＋オプション料金を1つの請求にまとめる
- Webhook による入金通知: 支払い成功・失敗をリアルタイムにシステムへ連携する
- カード情報の非保持: PCI DSS 準拠のため、カード情報はシステム内に保存せずトークン化する
- インボイス制度対応: 適格請求書（登録番号、税率ごとの消費税額等）を発行できること
日本の B2B SaaS 決済の現状
日本のB2B SaaSでは以下の決済手段が一般的:
- クレジットカード決済: SaaS の標準的な決済手段。即時課金・自動更新が可能
- 請求書払い（銀行振込）: 日本のB2Bでは依然として需要が高い。特に中小の税理士事務所や会計事務所では「クレジットカードNG、請求書払いのみ」のケースがある
- 掛け払いサービス: NP掛け払い、Paid、マネーフォワード ケッサイ等。請求書発行・入金管理・督促・未回収リスクを代行する。B2B SaaSでは決済サービス＋掛け払いサービスの併用パターンが増えている
MVP ではクレジットカード決済のみをサポートし、請求書払い（銀行振込）は顧客層の需要を見て将来対応を判断する。
決定
決済基盤に Stripe を採用する。
- Stripe Billing: サブスクリプション・従量課金の請求管理
- Stripe.net SDK: バックエンド連携
- Stripe Webhook: 入金通知・支払い失敗通知
- Stripe Elements / Checkout: フロントエンドのカード情報入力（PCI DSS SAQ-A 準拠）
理由
- サブスクリプション＋従量課金の組み合わせ: Stripe Billing が従量課金（metered billing）をネイティブサポートしており、基本料金＋従業員数ベースの従量料金を1つのサブスクリプションで管理できる
- .NET SDK の品質: 公式 .NET SDK が提供されており、ASP.NET Core との統合が容易
- Webhook の信頼性: 署名検証、リトライ、イベント順序保証が組み込まれている
- インボイス制度対応: Stripe の請求書機能が日本のインボイス制度（適格請求書）に対応済み
- 開発者体験: ドキュメント・テストモード・CLI ツールが充実しており、開発効率が高い
- 将来の拡張性: 請求書払い対応時に Stripe Invoicing + 掛け払いサービスとの併用が可能
却下した代替案
| 代替案 | 却下理由 |
|---|---|
| PAY.JP | 国産で日本語サポートが手厚いが、サブスクリプション＋従量課金の組み合わせ機能が Stripe より弱い。Webhook の柔軟性も劣る |
| GMOペイメントゲートウェイ | 銀行振込・コンビニ払い等の決済手段が豊富だが、API設計が旧世代で開発コストが高い。大企業向けの契約形態 |
| Square | 対面決済に強いがB2B SaaSのサブスクリプション請求には機能不足 |
トレードオフ・リスク
- 決済手数料: Stripe の手数料は 3.6%。PAY.JP（3.0%〜）やGMO（2.8%〜）と比較するとやや高い。ただし開発コストの削減で相殺できると判断
- 請求書払い未対応（MVP時点）: 銀行振込を要求する顧客を取りこぼすリスクがある。顧客獲得状況を見て掛け払いサービスとの併用を検討する
- Stripe への依存: 決済基盤を Stripe に依存する。ただし、ユースケース設計は「外部決済サービス」として抽象化しており、移行は可能
カード情報の非保持方針
TASHIKAのサーバーはカード情報を一切受け取らない。利用者は Stripe が提供する UI を通じて直接 Stripe と支払い情報をやり取りする。TASHIKAが保持するのは Stripe の顧客ID（Customer ID）のみ。
Stripe は以下の2つの UI 統合方式を提供しており、具体的な画面設計時にUX要件や実装コストを考慮して選定する:
Stripe Checkout（リダイレクト型）
Stripe がホストする決済ページにリダイレクトし、完了後に TASHIKA に戻る方式。PayPal と同様のフロー。
- TASHIKA 側のフロントエンド実装が最小限で済む
- Stripe 側で入力バリデーション・3Dセキュア・多通貨対応等を自動処理
- UIのカスタマイズ性は限定的（ロゴ・カラー程度）
Stripe Elements（埋め込み型）
TASHIKA の画面内に Stripe の UI コンポーネント（カード番号入力欄等）を埋め込む方式。カード情報はブラウザから Stripe のサーバーに直接送信される。
- TASHIKA の画面内で完結するため、UX の一貫性が高い
- UIのカスタマイズ性が高い（フォントやスタイルを自社デザインに合わせられる）
- フロントエンド側の実装コストは Checkout より高い
Stripe Customer Portal（利用者向け管理画面）
Stripe がホストするポータル画面。利用者が支払い方法の変更・請求書の確認等を TASHIKA を介さずに直接行える。UC-953（支払い方法を変更する）の実装候補。
共通
いずれの方式でも PCI DSS SAQ-A 準拠となり、TASHIKAに対する PCI DSS の監査負担は最小化される。
結果
docs/design/tech-stack.mdのバックエンドライブラリに Stripe .NET SDK を記載- ユースケース（UC-951〜956）では「外部決済サービス」として抽象化し、Stripe 固有の実装詳細には依存しない
- カード情報は TASHIKA のサーバーを経由しない。利用者と Stripe の直接のやり取りで完結する