予約プラットフォーム、マーケットプレイス、加盟店を抱えるサービス。「客から集めた金を、手数料を引いて店に配る」構造を作るとき、Stripe Connect を使います。
実装より先に決めるべきことがあります。資金がどう流れ、誰がいくら取り、いつ着金するか。 ここを曖昧なまま実装すると、後から変更できません。
設計の観点を整理します。
結論：実装前に決める5つ
- アカウント種別（Standard / Express / Custom）
- 資金フロー（Direct / Destination / Separate）
- 手数料構造（誰がStripe手数料を負担するか）
- 入金サイクル（加盟店にいつ払うか）
- 返金・キャンセル時の資金の戻り方
このうち1と2は後から変えられません。最初に決めてください。
1. アカウント種別
加盟店にどこまで管理させるかで3種類あります。
Standard
加盟店が自分でStripeアカウントを持ちます。加盟店はStripeダッシュボードにログインでき、自分で返金も入出金設定もできます。
- 実装が最も軽い
- 加盟店の本人確認はStripeが行う（こちらの責任が小さい）
- ただし加盟店側にStripeアカウント開設の手間がかかる
Express
Stripeが用意する簡易ダッシュボードを加盟店が使います。オンボーディングもStripeのホスト画面を使えます。
- 実装と責任のバランスが良い
- マーケットプレイスで最も選ばれる
Custom
加盟店にStripeの存在を見せず、すべて自社UIで完結させます。
- 体験は最も良い
- 本人確認・不正対応の責任を自社が負う
- 実装量が大きい
迷ったらExpressです。 Customは責任の重さに見合う理由がある場合だけ選んでください。
2. 資金フロー
金がどこを通るかで3種類あります。
Direct charges（直接課金）
客の支払いが加盟店のアカウントに直接入り、そこからプラットフォーム手数料を引きます。
客 → 加盟店アカウント
└→ application_fee → プラットフォーム
- Stripe手数料は加盟店負担
- 決済の当事者は加盟店。返金責任も加盟店
- 明細の表示名は加盟店の名前
Destination charges（宛先指定課金）
客の支払いがプラットフォームのアカウントに入り、そこから加盟店へ送金します。
客 → プラットフォームアカウント
└→ transfer → 加盟店
- Stripe手数料はプラットフォーム負担
- 決済の当事者はプラットフォーム
- 明細の表示名はプラットフォームの名前
Separate charges and transfers（分離）
課金と送金を完全に分けます。1回の決済を複数の加盟店に分配する場合に使います。
- 最も柔軟
- 最も複雑
選び方
客から見て「誰から買ったか」で決めます。プラットフォームのブランドで売るなら Destination、加盟店のブランドで売るなら Direct です。
3. 手数料構造
ここを曖昧にすると、後で必ず揉めます。合計何%を、誰が負担するかを数字で決めてください。
例として、合計5%の構造を分解します。
決済額 10,000円
Stripe決済手数料 3.6% = 360円
プラットフォーム手数料 1.4% = 140円
─────────────────────────────
合計 5.0% = 500円
加盟店の受取 9,500円
決めるべきは以下です。
Stripe手数料を誰が負担するか
Destination charges では既定でプラットフォーム負担です。加盟店に負担させたい場合、application_fee_amount にStripe手数料相当を上乗せします。この計算を間違えると、プラットフォームが赤字になります。
プラットフォーム手数料をどう表示するか
加盟店への明細に「決済手数料3.6% + プラットフォーム利用料1.4%」と内訳を出すか、「手数料5%」とまとめるか。内訳を出すほうが問い合わせが減ります。
端数処理
application_fee_amount は整数（円）で指定します。切り捨てか切り上げかを決め、全経路で統一してください。返金時の計算がずれる原因になります。
4. 入金サイクル
加盟店にいつ払うか。
- Stripeの既定は自動入金（国・アカウントにより数日後）
- 手動入金にして、プラットフォームが送金タイミングを制御することもできる
予約サービスでは注意が必要です。 予約時に決済し、サービス提供は1か月後という場合、提供前に加盟店へ入金すると、キャンセル時に回収できません。
対策は2つです。
- 提供完了後に送金する（
transferを遅延させる） - 入金を保留し、キャンセル期限を過ぎてから送る
どちらにせよ、まだ提供されていない役務の金をいつ動かすかを決めておく必要があります。
5. 返金・キャンセル
最も設計漏れが多い箇所です。
全額返金
客に全額戻す場合、すでに加盟店に送金済みなら、その分を戻す必要があります。reverse_transfer を使います。プラットフォーム手数料も返すかどうかを決めてください。
部分返金
金額を按分するか、プラットフォーム手数料は返さないか。規約に明記してください。
キャンセルポリシー
- 何日前までなら全額返金か
- それ以降は何%か
- 加盟店都合のキャンセルはどうするか
これは技術ではなく事業ルールですが、決めないと実装できません。
実装前に書くべきドキュメント
コードを書く前に、以下を1枚にまとめてください。
1. 資金フロー図
客 → どこ → どこ → 加盟店
各段階で誰がいくら取るか
2. 手数料の計算式（具体的な金額例つき）
決済額 10,000円のとき、各者がいくら受け取るか
3. 状態遷移
予約 → 決済 → 提供 → 送金
各段階でキャンセルされたらどうなるか
4. 特商法・規約に書く文言
手数料、返金条件、提供時期
この4つが埋まらないうちは実装に入らないでください。 埋まっていない項目は、必ず後で仕様変更になります。
よくある落とし穴
テスト環境で加盟店アカウントが作れない
Connect のテストは、テスト用の連結アカウントを作る必要があります。本番と同じフローを踏めるか、早い段階で確認してください。
加盟店の本人確認が完了していないと送金できない
Express/Custom では、加盟店が本人確認を終えるまで payouts_enabled が false です。オンボーディングの完了率を監視する仕組みが要ります。
手数料の二重取り
application_fee_amount を設定したうえで、別途 transfer の金額を減らすと、二重に引かれます。テストで実額を必ず検算してください。
返金時にプラットフォーム手数料が戻らない
既定では application_fee は返金されません。返すなら refund_application_fee: true を明示します。
まとめ
Stripe Connect は、実装より設計に時間をかけるべき領域です。
アカウント種別と資金フローは後から変えられません。手数料と返金のルールは、決めていないと実装できません。
図と計算例を1枚書いてから、コードを書いてください。
マルチベンダー決済を検討している方へ
Stripe Connect の資金フロー設計、手数料構造の設計、実装を承っています。設計ドキュメントのみのご相談も可能です。
販売実績58件・評価5.0・出品者ランク プラチナ（2026-09時点）