Stripe Connectとは？マッチングサイトに必要なケースと通常のStripeとの違い
Stripe Connectは、出品者、店舗、講師、専門家など、複数のサービス提供者が参加するマッチングサイトやマーケットプレイス向けの決済サービスです。
通常のStripe Paymentsが、主に自社の商品やサービスの代金を受け取るために使われるのに対し、Stripe Connectでは、提供者の登録、本人確認、運営手数料の徴収、売上の移動、銀行口座への入金まで管理できます。
ただし、マッチングサイトだからといって、必ずStripe Connectが必要になるわけではありません。
第一の判断基準は、登録された提供者へ売上を支払うかどうかです。
さらに、誰が販売主体になるのか、誰の名義で決済するのか、返金・チャージバック・マイナス残高を誰が負担するのかを整理して、導入方式を決めます。
本記事では、通常のStripeとの違い、Connectが必要なケース、3つの決済方式、料金、仮払いとの関係、実装時に必要な機能まで解説します。
Stripe Connectとは
Stripe Connectとは、プラットフォームやマーケットプレイスにおける、複数当事者間の決済と資金移動を管理するサービスです。
購入者、商品やサービスの提供者、サイト運営会社という三者が関わる決済に利用されます。
購入者から代金を受け取り、運営手数料を差し引き、残額をサービス提供者へ移動・入金する仕組みを構築できます。
Connectでできること
Stripe Connectには、主に次の機能があります。
- サービス提供者のアカウント登録
- 本人・法人確認に必要な情報の収集
- 購入者からの決済受付
- 運営手数料の徴収
- 提供者への資金移動・入金管理
このほか、返金、不審請求、入金失敗、アカウント制限なども管理対象になります。
Stripeが提供する登録画面や埋め込みコンポーネントを利用する方法と、自社サービスの画面として構築する方法があります。
連結アカウントとは
Connectでは、プラットフォームへ参加する提供者を「連結アカウント」としてStripeへ登録します。
対象になるのは、たとえば次のような利用者です。
- フリマサイトの出品者
- 予約サイトへ登録する店舗
- スキルシェアの講師
- 業務委託サイトの受注者
- マーケットプレイスの出店者
連結アカウントには、本人・法人情報、銀行口座、確認状況、利用可能な決済機能などが紐付きます。
登録情報が不足している場合は、決済や入金が制限されるため、サイト側でも現在の状態を表示する必要があります。
通常のStripeとStripe Connectの違い
自社だけが売上を受け取る場合は通常のStripe Payments、登録された提供者へ売上を支払う場合はStripe Connectを検討します。
| 比較項目 | 通常のStripe | Stripe Connect |
|---|---|---|
| 主な用途 | 自社の商品・サービスの決済 | プラットフォーム・マーケットプレイス決済 |
| 売上を受け取る相手 | 運営会社 | 運営会社とサービス提供者 |
| 提供者の登録 | 原則不要 | 連結アカウントとして登録 |
| 本人・法人確認 | 運営会社が対象 | 登録された提供者も対象 |
| 運営手数料 | 自社売上として受け取る | 取引金額から徴収できる |
| 提供者への入金 | 別の方法で対応 | Connect内で管理できる |
| 開発・運用負担 | 比較的少ない | 提供者管理があるため大きい |
通常のStripeが向いているケース
運営会社だけが料金を受け取るサービスです。
- 月額会員費
- 求人・案件の掲載料
- 問い合わせ料金
- 広告掲載料
- 自社コンテンツの販売
サービス提供者への売上支払いがなければ、Connectを導入せずに対応できることがあります。
Connectが向いているケース
購入者から受け取った代金の全部または一部を、登録された提供者へ支払うサービスです。
- 出品者へ売上を支払うフリマサイト
- 店舗へ予約代金を支払う予約サイト
- 講師へ報酬を支払うスキルシェア
- 受注者へ業務報酬を支払うサイト
- 一つの代金を複数者へ分配するサービス
提供者への売上支払いがないサービスへConnectを入れると、本人確認や入金管理の運用だけが増えることがあります。
Stripe Connectで使われる決済用語の違い
Stripe Connectでは、購入者の決済、提供者への資金移動、銀行口座への入金を別々の処理として扱います。
| 用語 | 意味 |
|---|---|
| Payment・Charge | 購入者から商品・サービスの代金を受け取る処理 |
| Transfer | プラットフォームから連結アカウントへ資金を移す処理 |
| Payout | Stripe残高から提供者の銀行口座などへ入金する処理 |
| Refund | 購入者へ決済代金の全部または一部を返す処理 |
| Transfer reversal | 連結アカウントへ移した資金をプラットフォームへ戻す処理 |
購入者が支払った時点では、提供者の銀行口座へ入金されたとは限りません。決済、連結アカウントへの資金移動、銀行口座への入金は別々に管理されます。
たとえば、購入者へRefundを実行しても、提供者へTransfer済みの資金まで自動的に戻るとは限りません。
その場合は、Transfer reversalを行い、サイト内の提供者売上も取り消す必要があります。
Stripe Connectが必要なケース・不要なケース
提供者別の売上管理、手数料徴収、入金がある場合はConnectの必要性が高く、運営会社だけが料金を受け取る場合は必要性が低くなります。
| サービスの条件 | Connectの必要性 |
|---|---|
| 運営会社が月額料金だけを受け取る | 低い |
| 求人・案件の掲載料だけを受け取る | 低い |
| 問い合わせ後は当事者同士で支払う | 低い |
| 取引代金から運営手数料を差し引く | 高い |
| 提供者へ売上を支払う | 高い |
| 一つの代金を複数者へ分配する | 高い |
必要性が高いサービス
- フリマ・CtoC
- スキルシェア
- 予約マッチング
- 複数店舗型マーケットプレイス
- 業務委託・クラウドソーシング
ただし、提供者への支払いがあるという理由だけで方式を決めてはいけません。
誰が購入者と契約するのか、誰が販売主体なのか、返金やチャージバックを誰が負担するのかも整理します。
必要性が低いサービス
- 月額会員制のコミュニティ
- 求人・案件の掲載課金サイト
- 問い合わせ課金型のBtoBサイト
- 広告枠を販売するサイト
- 成約後は当事者間で決済するサイト
Stripe Connectで選べる3つの決済方式
主な方式は、Direct charges、Destination charges、Separate charges and transfersの3つです。
最初に違いを比較すると、次のようになります。
| 決済方式 | 決済を作る場所 | 主な提供者数 | 返金・不審請求の主な負担 |
|---|---|---|---|
| Direct charges | 提供者の連結アカウント | 原則1者 | 提供者側を中心に処理 |
| Destination charges | プラットフォーム | 1者 | プラットフォーム側を中心に処理 |
| Separate charges and transfers | プラットフォーム | 複数者へ分配可能 | プラットフォーム側を中心に処理 |
Direct charges｜提供者側で決済する
Direct chargesでは、提供者の連結アカウント上で決済を作成します。
購入者 → 提供者の連結アカウント → 運営手数料をプラットフォームへ移動
一つの取引に一人の提供者が関わり、購入者と提供者が直接取引する性質のサービスに向いています。
主な特徴は次のとおりです。
- 決済は提供者側の残高に記録される
- プラットフォームはアプリケーション手数料を受け取れる
- 返金は原則として提供者側の残高へ影響する
- 提供者ごとの決済情報を確認する必要がある
独立した店舗や事業者が、自分の顧客から代金を受け取るSaaS型サービスなどに適しています。
Destination charges｜1人の提供者へ移す
Destination chargesでは、プラットフォーム側で決済を作成し、その一部を指定した提供者へ移します。
購入者 → プラットフォーム → 運営手数料と提供者売上に分ける
購入者がプラットフォームと取引し、実際のサービスを登録店舗や個人提供者が行う場合に使われます。
主な特徴は次のとおりです。
- 決済はプラットフォーム側へ記録される
- 一つの取引につき一つの提供者を指定する
- 決済後に提供者の残高へ資金が移る
- 返金やチャージバックはプラットフォーム残高へ影響する
購入者への返金後、提供者へ移した資金を戻す場合は、Transfer reversalも処理します。
Separate charges and transfers｜複数者へ分配する
Separate charges and transfersでは、購入者の決済と、提供者への資金移動を分けて管理します。
購入者 → プラットフォーム → 提供者A・提供者B・運営会社へ分配
次のようなサービスに向いています。
- 一つの代金を複数者へ分配する
- 決済時点では提供者が決まっていない
- 提供者ごとに異なる時期に資金を移す
- 複数店舗の商品を一つのカートで購入する
柔軟性が高い一方、プラットフォーム残高、返金、Transfer reversalの管理が複雑になります。
複数者への分配が不要なら、Separate charges and transfersを安易に選ばない方が実装を抑えられます。
Standard・Express・Customの違い
Standard、Express、Customは、提供者が使用する画面と、プラットフォームが管理する責任範囲が異なります。
| 項目 | Standard | Express | Custom |
|---|---|---|---|
| 開発負担 | 低い | 中程度 | 高い |
| 提供者用画面 | 通常のStripe Dashboard | Express Dashboard | 原則として自社で用意 |
| UIの自由度 | 低い | 中程度 | 高い |
| 運営側の管理範囲 | 小さい | 中程度 | 大きい |
Standard｜提供者が通常のStripeを使用する
Standardでは、提供者がStripeと直接関係を持ち、通常のStripe Dashboardを利用します。
プラットフォームの開発負担を抑えやすい一方、提供者にはStripeの画面やブランドが表示されます。
すでに事業を行っている店舗や事業者を連結するサービスに向いています。
Express｜導入負担と管理のバランスを取る
Expressでは、Stripeが本人確認や登録画面を提供し、提供者には簡易的なExpress Dashboardが用意されます。
Standardよりプラットフォーム側で管理しやすく、Customより開発負担を抑えられる構成です。
一般的なマッチングサイトやマーケットプレイスでは、有力な候補になります。
Custom｜提供者向け画面を自社で作る
Customでは、提供者向けの体験を自社サービス内へ組み込めます。
ただし、提供者がStripe Dashboardを利用しないため、登録、本人確認、売上、入金、サポートなどを自社で用意する範囲が広がります。
画面を独自化できる一方、開発・運用責任も大きくなります。
現在は3つの名称だけで構成を決めない
現在のStripeでは、従来のStandard・Express・Customだけでなく、次の責任範囲を個別に設定する考え方が用意されています。
- 決済手数料を誰が負担するか
- マイナス残高を誰が負担するか
- 本人確認情報を誰が収集するか
- 提供者へどのダッシュボードを提供するか
- プラットフォームがどこまで機能を提供するか
Accounts v1ではcontroller properties、Accounts v2ではresponsibilitiesやdashboardなどの設定を使用します。
古い3タイプの比較表だけで決めず、手数料・損失・本人確認の責任まで確認する必要があります。
Accounts v2の連結アカウント構成に関する公式ドキュメント
Stripe Connectの導入で必要になる機能
Connectを導入する場合、決済画面だけでなく、提供者登録、本人確認状況、売上、返金、入金、エラーを管理する機能が必要です。
提供者登録・本人確認機能
提供者がConnect登録を開始し、現在の進行状況を確認できるようにします。
- Stripe連携を開始する
- 登録・本人確認画面へ移動する
- 不足している情報を表示する
- 決済・入金の利用可否を表示する
- 再提出・再登録へ案内する
登録画面からサイトへ戻ってきただけでは、本人確認や入金設定の完了を意味しません。
当社では、登録画面から戻ったかだけで完了とは判断しません。本人確認の不足情報、決済可否、入金可否、アカウント制限、requirementsなどを取得し、管理画面から確認できる状態にします。
Accounts v1を使用する構成では、`charges_enabled`、`payouts_enabled`、`requirements`などを確認します。
Accounts v2では、利用するconfigurationやresponsibilitiesに対応した状態を確認します。
売上・手数料・入金管理
提供者側には、次の情報を表示します。
- 取引金額
- 運営手数料
- 提供者売上
- 返金・売上取消
- 入金予定・入金結果
購入者の決済済み、提供者の売上確定、銀行口座への入金済みは分けて管理します。
管理者向けの監視機能
管理画面では、正常な取引だけでなく、対応が必要な状態を抽出します。
- 本人確認の不足・期限超過
- 決済・返金の失敗
- 入金の失敗
- 連結アカウントの制限
- Webhookの受信・処理失敗
問題のある取引をStripe Dashboardだけで探すのではなく、サイト内の会員・注文・予約と紐付けて確認できる設計にします。
Stripe Connectは仮払い・エスクローに使えるのか
Stripe Connectでは提供者への入金時期を調整できますが、Stripeが法律上のエスクローサービスを提供するわけではありません。
Stripe公式も、Stripeはエスクローサービスやエスクロー口座を提供していないと説明しています。
取引完了後に入金する流れ
一般的には、次の流れをサイト内で管理します。
- 購入者が決済する
- 提供者が商品・サービスを提供する
- 購入者が受取・完了を確認する
- 提供者への入金処理を進める
この処理には、Stripe側の入金設定だけでなく、サイト内の取引ステータスが必要です。
手動入金でも無期限には保持できない
提供者のStripe残高に資金を無期限で保持することはできません。
2026年6月23日時点のStripe公式ドキュメントでは、手動入金を利用する場合、タイは10日、アメリカは2年、それ以外の国は90日以内に入金する必要があるとされています。
日本は「その他の国」に該当するため、原則として90日以内の入金が必要です。
キャンセル・紛争時のルールも必要
仮払い型のサービスでは、次の内容を決めます。
- どの操作をもって取引完了とするか
- 何日後に自動完了するか
- 一部返金を認めるか
- 紛争時に誰が証拠を確認するか
- 提供者売上をいつ確定するか
「Connectを使えばエスクローになる」「自由な期間だけ資金を預かれる」とは断定できません。
契約関係や資金の流れについては、Stripeと法律の専門家へ確認する必要があります。
Stripe Connectの料金と導入費用
Stripe Connectの費用は、Stripeへ支払う料金と、自社システムへ組み込む開発・保守費用に分かれます。
Stripeが料金体系を管理する場合
Stripeが連結アカウントの決済料金を設定し、直接徴収する料金モデルでは、プラットフォームに追加のアカウント手数料や入金ごとのConnect手数料が発生しない構成があります。
利用可能な料金モデルは、アカウント構成や契約内容によって異なります。
プラットフォームが料金体系を管理する場合
2026年6月23日時点の日本向け公式料金では、プラットフォーム側がユーザーに適用する料金体系を管理する場合、次の料金が掲載されています。
| 料金項目 | 金額 |
|---|---|
| 有効なアカウント | 1件につき月額200円 |
| 入金手数料 | 入金額の0.25％＋1回250円 |
有効なアカウントとは、その月に銀行口座またはデビットカードへの入金が行われたアカウントです。
このほか、通常の決済処理手数料がかかります。
料金は変更される可能性があるため、導入時には公式ページを確認してください。
システム側で発生する費用
Stripeの利用料だけで、Connectの導入が完了するわけではありません。
主に次の開発が必要です。
- 提供者登録・本人確認状況の連携
- 決済・手数料・資金移動の実装
- 返金・Transfer reversalの実装
- 売上・入金・エラー管理画面
- Webhookと再処理機能
提供者数、決済方式、返金ルール、管理画面の範囲によって開発費は変わります。
Stripe Connectを導入する流れ
Connectは、販売主体と資金フローを決め、Stripeへ確認してから実装・テストします。
流れ1｜販売主体と負担者を決める
最初に、次の内容を整理します。
- 購入者は誰と契約するのか
- 誰の名義で決済を受けるのか
- 運営手数料をどの時点で差し引くのか
- 返金・チャージバックを誰が負担するのか
- 提供者へいつ入金するのか
この内容によって、決済方式やアカウント構成が変わります。
流れ2｜開発前にStripeへ確認する
サービス内容、販売商品、料金体系、資金の流れ、返金条件を整理してStripeへ確認します。
サイト完成後に利用できないと判明すると、決済方式や規約を変更しなければなりません。
流れ3｜画面・API・Webhookを実装する
- 連結アカウントの作成・登録
- 本人確認・利用可否の取得
- 決済・手数料・Transferの作成
- 返金・Transfer reversal
- Webhookと管理画面への反映
Stripe上の状態を毎回直接表示するだけでなく、自社システムにも取引・売上の状態を保存します。
流れ4｜異常系までテストする
正常な決済だけでは不十分です。
- 本人確認が未完了
- 決済・返金が失敗する
- Webhookが重複して届く
- 入金に失敗する
- 連結アカウントが制限される
同じWebhookが複数回届いても、売上や返金が二重に処理されないように実装します。
Stripe Connect導入でよくある失敗
Connectでは、返金、オンボーディング完了判定、Webhook・入金エラーの設計不足が運用トラブルにつながります。
返金とTransfer reversalを同じ処理だと考える
購入者へのRefundと、提供者へ移した資金を戻すTransfer reversalは別の処理です。
返金だけを行うと、プラットフォームが返金額を負担したまま、提供者の売上が残ることがあります。
サイト内でも、返金額、提供者売上、運営手数料を同時に更新します。
登録画面から戻っただけで完了にする
提供者がStripeの画面からサイトへ戻っただけでは、本人確認や入金設定が完了したとは限りません。
不足情報、決済可否、入金可否、アカウント制限を確認し、利用できる機能を制御します。
エラーを管理画面へ表示しない
Webhook、返金、入金に失敗しても、利用者から連絡が来るまで気づけないサイトがあります。
管理画面には、次のような状態を表示します。
- 処理に失敗した取引
- 再処理が必要なWebhook
- 本人確認の不足情報
- 入金に失敗した提供者
- 制限中の連結アカウント
正常に支払えることだけでなく、失敗した処理を運営者が見つけて直せることが重要です。
Stripe Connectに関するよくある質問
個人のサービス提供者にも入金できますか？
個人を連結アカウントとして登録する構成はあります。
ただし、利用国、事業内容、本人確認情報、必要な機能によって条件が変わります。想定する提供者の属性を整理し、Stripeへ確認してください。
複数の提供者へ売上を分配できますか？
Separate charges and transfersを使うことで、一つの決済から複数の連結アカウントへ資金を移動できます。
ただし、返金、チャージバック、残高不足の管理が複雑になるため、複数分配が必要なサービスに限定して利用します。
月額課金にもStripe Connectは必要ですか？
運営会社が月額料金を受け取るだけなら、通常のStripeで対応できる可能性があります。
月額料金の一部を提供者へ支払う場合や、提供者ごとに契約・入金を管理する場合はConnectを検討します。
Stripe Connectはエスクローですか？
Stripeはエスクローサービスやエスクロー口座を提供していません。
手動入金によって入金時期を調整できますが、日本では原則90日以内の入金が必要です。法的なエスクローに該当するかは、契約と資金の流れを専門家へ確認してください。
まとめ｜提供者への支払いと責任範囲から判断する
Stripe Connectは、複数の提供者が参加するマッチングサイトやマーケットプレイスで、決済、手数料、資金移動、入金を管理するためのサービスです。
導入判断は、次の順番で行います。
- 登録された提供者へ売上を支払うか確認する
- 誰が販売主体・決済名義になるか決める
- 返金・チャージバック・マイナス残高の負担者を決める
- Direct、Destination、Separateから決済方式を選ぶ
- 提供者登録・売上・返金・入金を管理する機能を設計する
通常のStripeとConnectの違いだけでなく、Payment、Transfer、Payout、Refundを分けて管理することが重要です。
また、登録画面から戻っただけで本人確認完了と判断せず、利用可否や不足情報を継続して確認します。
Stripe Connectの導入では、決済画面より先に、資金の流れと責任の所在を決めます。
