結論
Stripe を「カード決済API」だけで捉えると、後工程で 課金・分配・リスク・オフライン の要件が出たときに手戻りが起きやすいです。
まずは プロダクト群をレイヤーで分けて地図化 し、詳細は領域ごとの記事へ渡すのが安全です。
主要機能マップ（一覧資料）
| レイヤー | 代表プロダクト・概念 | ざっくり役割 | 詳細記事 |
|---|---|---|---|
| 決済UI | Stripe Checkout、Payment Element | hosted UI と埋め込みUIの二系統 | Checkout と Payment Element の比較 |
| 決済コア | PaymentIntent、Customer、PaymentMethod、SetupIntent | 支払い状態・顧客・支払手段の管理 | PaymentIntent の状態遷移 |
| イベント連携 | Webhook | 非同期の決済確定・更新の受け口 | Webhook の失敗パターン |
| 定期課金・請求 | Billing、Subscription、Invoice、Customer Portal | プラン課金と請求書ライフサイクル | Billing とサブスクリプション |
| プラットフォーム | Connect | 出品者・加盟店への送金とオンボーディング | Connect とプラットフォーム決済 |
| リスク | Radar、Dispute | 不正スコアとチャージバック対応 | Radar と Dispute の要点 |
| 対面 | Terminal | 実店舗のカードターミナル連携 | Terminal と対面決済 |
| 低コード・請求周辺 | Payment Links、請求書、Tax | リンク決済・税計算・インボイスの入口 | Payment Links と請求まわり |
このテーマで判断すべき軸
- 誰が売り手か（自社のみか、マルチベンダーか）→ Connect の要否
- 課金モデル（単発・従量・座席・複合）→ Billing / Invoice の深さ
- チャネル（Webのみか店舗もか）→ Terminal の要否
- リスク許容（手動レビュー・ルール運用）→ Radar / Dispute オペ設計
実装の基本フロー
- 決済手段の入口（Checkout か Payment Element）を決める
- PaymentIntent と内部注文IDを常にペアで扱う
- 確定通知は Webhook を正とし、画面戻りは補助にする
- 定期課金が絡むなら Subscription と Invoice の状態を注文と分離して追う
失敗しやすい点
- 一覧のどれか1つだけ導入して「あとから Connect が必要」と設計が崩れる
- UIとAPIの責務を混同し、hosted と埋め込みを途中で乗り換える
- 用語が多いまま議論が進み、仕様書と実装の語彙がズレる → 用語集一覧 で揃える
運用で見る指標
- Webhook 処理の成功率・再送率・遅延
- Dispute 率と証拠提出のリードタイム
- サブスクの更新失敗（カード期限・残高）と回収フロー
次に読む記事
よくある質問
最初にどの領域から読むのがよいですか？
オンライン決済が主目的なら Checkout / Payment Element と PaymentIntent、定期課金なら Billing、多店舗・出品者がいるなら Connect が中心になります。
用語の意味だけ知りたい場合は？
[用語集一覧](/glossary/) から個別記事に飛べます。