コラム / 決済・金融システム /
Stripe Connect で SaaS マーケットプレイスを作る実務 ─ Standard / Express / Custom の選び分けと、KYC・送金保留・Application Fee 設計
「決済 SDK」ではなく「金融プラットフォーム」として設計する3つの実装判断
📖 約10分 / 公開日: 2026/06/03
「うちのサービス、Stripe Connect を使ったほうがいいですか」と相談を受けることが増えています。マーケットプレイス型、SaaS のサブアカウント分離型、フランチャイズ本部→加盟店型、いずれの形態でも答えは「だいたい使ったほうがいい」になります。問題はどのアカウントタイプを選ぶか、本人確認と送金設計をどう作るか。ここで詰まる現場が多い。
まず Standard / Express / Custom の3タイプを整理します。
Standard は受け取り側の事業者が自分で Stripe アカウントを作るタイプ。ダッシュボードも Stripe 純正の画面をそのまま使う。実装コスト最小。本人確認、税務情報、送金口座登録すべて Stripe が引き受けてくれる。プラットフォーム側が触れるのは「決済の振り分け」と「手数料の徴収」だけです。日本の中小事業者が多いマーケットプレイスなら、最初の数十社まではこれで十分回ります。
Express は中間。Stripe の本人確認フローを Stripe ホスト型で借りつつ、ダッシュボードはプラットフォーム側で UI を作る前提。ライドシェアやウーバーイーツ型のギグワーカー向けに設計されています。Standard より導入工数は増えますが、ユーザ体験を作り込めるメリットがある。本人確認の主体は Stripe のまま。
Custom は全部を自分で作る。アカウント開設の本人確認 UI、書類アップロード、税務情報入力、送金口座登録、すべてプラットフォーム側で実装する。決済 SDK ではなく完全な金融サービスを内製する覚悟がいる。実装工数は Standard の 5〜10倍。Custom が必要になるのは「マーケットプレイス事業者が法的に金融サービス提供者として扱われる前提で、UX も完全管理したい」という極めて限られたケース。中小規模で Custom を選ぶ理由はほぼない。
選び分けの実務基準を数字で示します。受け取り側の月間取引件数が 1,000 件未満、プラットフォーム側のエンジニア工数が月 20 時間未満なら Standard 一択。月間 5,000 件以上、UX への投資余力があるなら Express。年間 GMV が 50 億超え、コンプライアンス組織が社内にあるなら Custom も視野に入る。この3つの境界を見誤ると、後から作り直しになります。
KYC（本人確認）で詰まるポイントを具体的に書きます。
日本の場合、Stripe Connect の本人確認は「個人」と「法人」で求められる書類が違います。個人は運転免許証 or マイナンバーカード or パスポート + 住所証明。法人は登記簿謄本 or 履歴事項全部証明書 + 代表者の本人確認書類 + 実質的支配者（UBO）の確認。実質的支配者の概念を経営者が理解していないケースが多く、申請が差し戻されて 1〜2 週間止まる。実装上は、本人確認状況を Stripe API の account.requirements.currently_due で監視し、未完了項目があれば該当アカウントを「決済受付停止」状態にする運用が必須です。これを怠ると、後で大量の保留金が発生して送金できない事故が起きます。
送金（Payout）と保留期間の設計はもっと厄介です。
Stripe の標準動作は、決済成立から「日本円なら4営業日後」に自動送金。この期間に返金リクエストやチャージバックが来た場合、Stripe の手数料負担はプラットフォーム側に来ます。これを甘く見て、プラットフォーム手数料を「決済額の 5%」に固定していた事業者が、悪意ある購入者の連続チャージバックで月数百万円の赤字を出した事例があります。
対策は2つ。
ひとつは Rolling Reserve の導入。Stripe Connect 側で「決済額の 10% を 30日間保留」のような設定を入れる。返金やチャージバックが来てもこの保留分から先に引き当てられます。デメリットは受け取り側事業者のキャッシュフローが圧迫されること。月商 100 万円の事業者なら、常時 30 万円が保留される計算。導入前に説明していないとトラブルになります。
もうひとつは Payout タイミングを「手動」に切り替えて、プラットフォーム側で送金タイミングを制御する方式。週次バッチで一括送金し、その時点で未確定リスクのある取引は除外する。実装は重いが、リスクコントロールは効きます。
手数料設計の典型パターンも整理しておきます。
Stripe の決済手数料は日本のカード決済で 3.6%。これがプラットフォームに請求されます。プラットフォーム側がさらに上乗せ手数料（Application Fee）を取る場合、Stripe API の application_fee_amount パラメータで指定する。「決済額の何%」「決済額 + 固定額」など柔軟に設定可能。
ここで多くのプラットフォームが間違えるのが、消費税の扱いです。Application Fee は「役務提供の対価」なので、原則として消費税課税対象になります。プラットフォーム側が課税事業者なら、内税で受け取って消費税申告に組み込む設計が必要。これを忘れていて、年度末に追加納税が発生する事故をよく見ます。
国内のライバル決済プロバイダとの比較も触れておきます。
GMOペイメントゲートウェイは老舗の安定感がありますが、Connect 相当のマーケットプレイス機能は別契約・別審査・別実装で、立ち上げに 2〜3 ヶ月かかる。Square はシンプルだが、サブアカウント管理は実質ない。PayPay for Developers は急速に機能拡充中ですが、2026年6月時点でも Connect レベルの分割送金機能には到達していません。「マーケットプレイス型を最短で始める」ニーズなら、Stripe Connect が現実解になる場面が多い。
失敗事例も書いておきます。
ある SaaS 事業者は、自社サービスから出店者の Stripe アカウントへ Application Fee 10% で売上を分配する設計を入れました。出店者 200 社まで順調だったところで、ある出店者が大量返金を発生させ、Stripe 側で出店者アカウントの残高がマイナスに転じた。この場合、Stripe はプラットフォーム側に Application Fee の返還を求めます。出店者から回収できない金額は、プラットフォーム側が事実上立て替えることになる。月の Application Fee 収入を超える返金が発生すると、即座にプラットフォームのキャッシュ問題になります。
対策として、Application Fee の一部を 60日間 Hold する内部口座を持ち、その期間中に返金が発生したら Hold 分から相殺する独自の仕組みを後付けで実装することになりました。最初から Rolling Reserve を入れておけば 3ヶ月の工数は不要だった事例です。
結論として、Stripe Connect は強力ですが、決済 SDK ではなく金融プラットフォームを抱える話だと最初から認識する必要があります。Standard で始めて、トラフィックが伸びたら Express へ、KYC や UX の作り込みが必要になったら部分 Custom 化、という段階的な拡張が現実的。最初から Custom を選ぶ判断は、ほぼ間違いなく過剰投資になります。
導入時に決めておくべきは3つ。アカウントタイプ、Rolling Reserve の有無と料率、Application Fee の課税扱いと内税/外税表記。この3つを設計せずに開発に入ると、半年後に必ず作り直すことになります。
補足として、Stripe Connect の Webhook イベントは account.updated、payout.failed、charge.dispute.created の3つを最低でも監視対象に入れる。account.updated は本人確認状況や送金可能性の変化を捕まえる起点。payout.failed は送金口座の登録誤りや銀行側拒否を即座に検知する。charge.dispute.created はチャージバック発生で、Rolling Reserve が機能しているかを実運用で確認するトリガーになります。3つとも放置すると、後から「気づいたら出店者の送金が3ヶ月止まっていた」という事故が起きます。
当方では、Stripe Connect を含むマーケットプレイス決済基盤の設計・実装・運用引き継ぎまで対応しています。既に走り始めたサービスのリスク点検、Application Fee と消費税の整合確認、Rolling Reserve の後付け設計など、限定スコープでの相談も受け付けています。
まず Standard / Express / Custom の3タイプを整理します。
Standard は受け取り側の事業者が自分で Stripe アカウントを作るタイプ。ダッシュボードも Stripe 純正の画面をそのまま使う。実装コスト最小。本人確認、税務情報、送金口座登録すべて Stripe が引き受けてくれる。プラットフォーム側が触れるのは「決済の振り分け」と「手数料の徴収」だけです。日本の中小事業者が多いマーケットプレイスなら、最初の数十社まではこれで十分回ります。
Express は中間。Stripe の本人確認フローを Stripe ホスト型で借りつつ、ダッシュボードはプラットフォーム側で UI を作る前提。ライドシェアやウーバーイーツ型のギグワーカー向けに設計されています。Standard より導入工数は増えますが、ユーザ体験を作り込めるメリットがある。本人確認の主体は Stripe のまま。
Custom は全部を自分で作る。アカウント開設の本人確認 UI、書類アップロード、税務情報入力、送金口座登録、すべてプラットフォーム側で実装する。決済 SDK ではなく完全な金融サービスを内製する覚悟がいる。実装工数は Standard の 5〜10倍。Custom が必要になるのは「マーケットプレイス事業者が法的に金融サービス提供者として扱われる前提で、UX も完全管理したい」という極めて限られたケース。中小規模で Custom を選ぶ理由はほぼない。
選び分けの実務基準を数字で示します。受け取り側の月間取引件数が 1,000 件未満、プラットフォーム側のエンジニア工数が月 20 時間未満なら Standard 一択。月間 5,000 件以上、UX への投資余力があるなら Express。年間 GMV が 50 億超え、コンプライアンス組織が社内にあるなら Custom も視野に入る。この3つの境界を見誤ると、後から作り直しになります。
KYC（本人確認）で詰まるポイントを具体的に書きます。
日本の場合、Stripe Connect の本人確認は「個人」と「法人」で求められる書類が違います。個人は運転免許証 or マイナンバーカード or パスポート + 住所証明。法人は登記簿謄本 or 履歴事項全部証明書 + 代表者の本人確認書類 + 実質的支配者（UBO）の確認。実質的支配者の概念を経営者が理解していないケースが多く、申請が差し戻されて 1〜2 週間止まる。実装上は、本人確認状況を Stripe API の account.requirements.currently_due で監視し、未完了項目があれば該当アカウントを「決済受付停止」状態にする運用が必須です。これを怠ると、後で大量の保留金が発生して送金できない事故が起きます。
送金（Payout）と保留期間の設計はもっと厄介です。
Stripe の標準動作は、決済成立から「日本円なら4営業日後」に自動送金。この期間に返金リクエストやチャージバックが来た場合、Stripe の手数料負担はプラットフォーム側に来ます。これを甘く見て、プラットフォーム手数料を「決済額の 5%」に固定していた事業者が、悪意ある購入者の連続チャージバックで月数百万円の赤字を出した事例があります。
対策は2つ。
ひとつは Rolling Reserve の導入。Stripe Connect 側で「決済額の 10% を 30日間保留」のような設定を入れる。返金やチャージバックが来てもこの保留分から先に引き当てられます。デメリットは受け取り側事業者のキャッシュフローが圧迫されること。月商 100 万円の事業者なら、常時 30 万円が保留される計算。導入前に説明していないとトラブルになります。
もうひとつは Payout タイミングを「手動」に切り替えて、プラットフォーム側で送金タイミングを制御する方式。週次バッチで一括送金し、その時点で未確定リスクのある取引は除外する。実装は重いが、リスクコントロールは効きます。
手数料設計の典型パターンも整理しておきます。
Stripe の決済手数料は日本のカード決済で 3.6%。これがプラットフォームに請求されます。プラットフォーム側がさらに上乗せ手数料（Application Fee）を取る場合、Stripe API の application_fee_amount パラメータで指定する。「決済額の何%」「決済額 + 固定額」など柔軟に設定可能。
ここで多くのプラットフォームが間違えるのが、消費税の扱いです。Application Fee は「役務提供の対価」なので、原則として消費税課税対象になります。プラットフォーム側が課税事業者なら、内税で受け取って消費税申告に組み込む設計が必要。これを忘れていて、年度末に追加納税が発生する事故をよく見ます。
国内のライバル決済プロバイダとの比較も触れておきます。
GMOペイメントゲートウェイは老舗の安定感がありますが、Connect 相当のマーケットプレイス機能は別契約・別審査・別実装で、立ち上げに 2〜3 ヶ月かかる。Square はシンプルだが、サブアカウント管理は実質ない。PayPay for Developers は急速に機能拡充中ですが、2026年6月時点でも Connect レベルの分割送金機能には到達していません。「マーケットプレイス型を最短で始める」ニーズなら、Stripe Connect が現実解になる場面が多い。
失敗事例も書いておきます。
ある SaaS 事業者は、自社サービスから出店者の Stripe アカウントへ Application Fee 10% で売上を分配する設計を入れました。出店者 200 社まで順調だったところで、ある出店者が大量返金を発生させ、Stripe 側で出店者アカウントの残高がマイナスに転じた。この場合、Stripe はプラットフォーム側に Application Fee の返還を求めます。出店者から回収できない金額は、プラットフォーム側が事実上立て替えることになる。月の Application Fee 収入を超える返金が発生すると、即座にプラットフォームのキャッシュ問題になります。
対策として、Application Fee の一部を 60日間 Hold する内部口座を持ち、その期間中に返金が発生したら Hold 分から相殺する独自の仕組みを後付けで実装することになりました。最初から Rolling Reserve を入れておけば 3ヶ月の工数は不要だった事例です。
結論として、Stripe Connect は強力ですが、決済 SDK ではなく金融プラットフォームを抱える話だと最初から認識する必要があります。Standard で始めて、トラフィックが伸びたら Express へ、KYC や UX の作り込みが必要になったら部分 Custom 化、という段階的な拡張が現実的。最初から Custom を選ぶ判断は、ほぼ間違いなく過剰投資になります。
導入時に決めておくべきは3つ。アカウントタイプ、Rolling Reserve の有無と料率、Application Fee の課税扱いと内税/外税表記。この3つを設計せずに開発に入ると、半年後に必ず作り直すことになります。
補足として、Stripe Connect の Webhook イベントは account.updated、payout.failed、charge.dispute.created の3つを最低でも監視対象に入れる。account.updated は本人確認状況や送金可能性の変化を捕まえる起点。payout.failed は送金口座の登録誤りや銀行側拒否を即座に検知する。charge.dispute.created はチャージバック発生で、Rolling Reserve が機能しているかを実運用で確認するトリガーになります。3つとも放置すると、後から「気づいたら出店者の送金が3ヶ月止まっていた」という事故が起きます。
当方では、Stripe Connect を含むマーケットプレイス決済基盤の設計・実装・運用引き継ぎまで対応しています。既に走り始めたサービスのリスク点検、Application Fee と消費税の整合確認、Rolling Reserve の後付け設計など、限定スコープでの相談も受け付けています。