結論
Stripe Connect は 複数の売り手が関与する決済 を、Stripe 上の「接続アカウント」として表現するためのプロダクトです。
単一事業者の Checkout / Payment Element だけでは足りない 分配・レポート・本人確認 を扱うレイヤーと捉えると説明がしやすくなります。
このテーマで判断すべき軸
- マネーフロー（顧客→プラットフォーム→出品者、直収かスプリットか）
- 誰が返金・争議の一次窓口か（CS と規約の書き分け）
- 本人確認（KYC）を誰が案内するか
- レポート粒度（出品者別売上、手数料、税）
最初に決めるべきアカウントモデル
Stripe Connect の mental model として、いまも Standard Express Custom は重要です。
| タイプ | 向いているケース | 注意点 |
|---|---|---|
| Standard | Stripe ダッシュボードを売り手に持たせたい | 既存 Stripe 利用者との接続に向くが制御は限定的 |
| Express | オンボーディングは簡素化したいが、ある程度プラットフォームで主導したい | 実務では一番バランスが良いことが多い |
| Custom | UI も要件収集もすべて自前で握りたい | 実装責務と運用責務が最も重い |
Stripe 公式でも、アカウント作成後に type は変更できません。
また最近は controller properties の考え方が強くなっていますが、初期設計では依然として「誰がダッシュボードを持ち、誰が要件収集責務を持つか」で整理するのが分かりやすいです。
実装の基本フロー
- プラットフォームの Stripe アカウントと、接続アカウントの関係をデータモデルに持つ
- 決済作成時に どの接続アカウントに紐づくか を必ず決める（曖昧なまま進めない）
- Webhook で送金・更新・本人確認状態を取り込み、社内の「出品者ステータス」と同期する
- 返金・Dispute 時のルールを、利用規約と実装の両方で先に固定する
Webhook で特に注意する点
Connect では Webhook が 1 系統ではありません。
- 自分のプラットフォームアカウント用 Webhook
- 接続アカウントのイベントを受ける Connect Webhook
接続アカウント由来のイベントにはトップレベルの account が付きます。
これを保存しないと、どの出品者の問題か後で追えません。
失敗しやすい点
- 「とりあえず Standard」で始め、後から送金サイクルや手数料モデルが合わず作り直す
- 接続アカウント ID と自社のユーザーIDの同期を疎かにし、手動補正が常態化する
- PaymentIntent 単体の設計だけ見て、Connect 特有のイベントや制約を読み落とす
- Connected account の
account.updatedを見ず、要件不足や payout 停止に気づけない
運用で見る指標
- オンボーディング完了率と滞留理由
- 送金失敗・返金・チャージバックの接続アカウント別分布
- サポート問い合わせのタイプ（本人確認・振込・レシート等）
次に読む記事
関連用語: Connect、Webhook、Customer。一覧は 用語集 です。
よくある質問
Standard と Express の違いは何ですか？
オンボーディング体験とダッシュボードの見え方、プラットフォーム側の運用負荷が異なります。要件に合わせて公式ドキュメントで最新の差分を確認してください。
Webhook はプラットフォームだけで足りますか？
連携イベントの取り方は設計次第ですが、接続アカウント側のイベントも横断して見る必要が出るケースがあります。