Stripe Connectとは：アカウント種別・3つの支払い方式と資金フローの実装手順

Stripe Connectは、マーケットプレイスやSaaSのように「買い手・出品者・プラットフォーム」の三者で代金を分ける事業のための、Stripeのマルチパーティ決済の仕組みです。実装で最初に決めるのは、出品者を表す連結アカウントの構成と、代金をどう流すかの支払い方式の2つです。この記事では、Standard・Express・Customの違いと2026年時点の推奨、ダイレクト・デスティネーション・送金別方式の資金フロー、日本向けの料金とJCB審査、手数料差し引きと返金のコードまでを、公式ドキュメントをもとに解説します。

まとめ｜Stripe Connectで先に決める連結アカウントの構成と支払い方式

1件の注文に出品者が1人のマーケットプレイスなら、Express相当の連結アカウントとデスティネーション支払いの組み合わせから始めるのが定石です。本人確認はStripeのホスト型画面に任せ、プラットフォームはapplication_fee_amountで手数料を差し引くだけで済みます。

Standard・Express・Customというアカウントタイプは、公式ドキュメントでレガシー扱いになりました。新規の実装ではコントローラープロパティかAccounts v2で同じ構成を組みます。作成後に変えられない設定があるため、ここは最初に固めます。

1つの注文を複数の出品者で分ける、出品者が決まる前に代金を受け取る、といった要件があるときだけ支払いと送金別方式を選びます。返金や送金の差し戻しを自前で管理する分、実装量は増えます。

Stripe Connectの役割と連結アカウント・プラットフォームの関係

Connectでは、運営会社のStripeアカウントを「プラットフォーム」、出品者や加盟店ごとに作るアカウントを「連結アカウント」と呼びます。

マーケットプレイスとSaaSで変わるConnectの登場人物と代金の流れ

買い手が支払った代金は、いったんプラットフォームか連結アカウントのどちらかの残高に入り、そこから手数料が分けられます。Connectの支払いの仕組みを説明する公式ページは、作成する支払いのタイプによって、資金の分配方法、利用明細に表示される名義、返金とチャージバックの引き落とし先が決まると説明しています。

公式の例では、出店者が自分の店として売るShopifyのようなSaaS型はダイレクト支払い、プラットフォームの名前で売るAirbnbやLyftのような型はデスティネーション支払いに当てはまります。以降の選択をほぼ決める判断軸は、自社の事業がどちらの型に近いかです。出品者の募集や企業確認まで含めたサイト全体の設計はビジネスマッチングサイトの4つの型と企業確認で整理しています。

日本のプラットフォームで払うConnect料金：月200円と入金ごとの手数料

Stripeの日本向けConnect料金ページには2つのプランがあります。連結アカウントへの決済手数料をStripeが直接請求するプランでは、プラットフォームへの追加手数料はかかりません。プラットフォームが料金体系を管理するプランでは、有効なアカウント1件ごとに月200円、入金ごとに0.25%＋250円がかかります。

有効なアカウントとは、その月に銀行口座への入金があったアカウントを指します。出品者100社が月1回ずつ10万円を受け取る場合、月200円×100社で2万円、入金手数料500円×100回で5万円、合わせて月7万円です。この金額はカード決済手数料（同ページの記載で3.6%）とは別にかかるため、プラットフォーム手数料率を決める前に試算しておきます。

Standard・Express・Customの違いと2026年時点の推奨構成

連結アカウントの構成は、不正利用やマイナス残高の責任を誰が負うか、出品者がどの管理画面を使うかで決まります。

3つのアカウントタイプを責任範囲・管理画面・工数の3軸で比較

連結アカウントのタイプを説明する公式ページの比較表を、判断に効く行に絞ると次のとおりです。

同ページは、連結アカウントを作成した後はタイプを変更できないと明記しています。Customは出品者に見えない分、本人確認の情報や管理画面、問い合わせ対応をすべて自社で持つことになるため、専任の開発体制が無い会社には勧めません。

Stripe Expressを選ぶ条件とExpressダッシュボードで出品者ができること

Expressは、出品者の登録と本人確認をStripeのホスト型画面が受け持ち、出品者には機能を絞ったExpressダッシュボードが提供される構成です。出品者はそこで個人情報の更新や入金の確認を行い、プラットフォームが許可すれば返金や不審請求への対応もできます。

選ぶ条件は、デスティネーション支払いか送金別方式を使いたいこと、そして出品者とのやり取りの大半を自社サービス上で済ませたいことの2つです。対象国の一覧にはJP（日本）が含まれており、国内の出品者だけを相手にする国内マーケットプレイスなら、まずExpress相当で設計して困る場面はほとんどありません。不正利用と返金の負担はプラットフォーム側に来る点だけは、利用規約と出品者審査で手当てします。

アカウントタイプはレガシー扱い：コントローラープロパティとAccounts v2

2026年10月時点の公式ページでは、Standard・Express・Customの説明が「すでに旧タイプを使っているプラットフォーム向け」と位置づけられています。代わりに勧められているのが、責任分担を項目ごとに指定するコントローラープロパティと、新しいAccounts v2 APIです。

コントローラープロパティへの移行ガイドによると、Expressは「マイナス残高の責任がプラットフォーム、手数料の支払いがプラットフォーム、要件の収集がStripe、管理画面がExpress」という4つの値の組み合わせに相当します。Accounts v2の公式解説では、1つのアカウントに決済を受けるmerchant、請求されるcustomer、送金を受けるrecipientの構成を足していく形になりました。

ただし、v2の公式例はAPIバージョンに2026-09-30.previewを指定しており、OAuthでの接続や入金設定の管理などはv1でしか扱えません。入金スケジュールを自社で制御するマーケットプレイスでは、当面はv1のAccounts APIにコントローラープロパティを付ける方法が無難です。

ダイレクト・デスティネーション・送金別方式の資金フローを選ぶ手順

アカウント構成の次は、代金をどのアカウントで受けて、どう分けるかを決めます。

3つの支払い方式を手数料・返金・不審請求の引き落とし先で比較

支払い方式の公式解説をもとに、運用で差が出る項目を並べました。

見落としやすいのは、デスティネーション支払いと送金別方式では返金と不審請求がまずプラットフォームの残高から引かれる点です。出品者から回収するには、送金の差し戻しを自分で実行します。

1取引1出品者のマーケットプレイスはデスティネーション支払いから始める

スキルシェアや予約サービスのように、1件の注文の受取人が1人に決まるならデスティネーション支払いで足ります。支払いの作成時にtransfer_data[destination]へ連結アカウントのIDを入れるだけで、決済と出品者への送金が1回のAPI呼び出しで完結します。

公式ページは、ダイレクト支払いを旧来のExpressとCustomで使うことを推奨していません。Express相当の構成でダイレクト支払いを選びたくなったら、事業の型を見直すほうが先です。

1つの注文を複数の出品者へ分配するときに送金別方式を選ぶ条件

支払いと送金別方式の公式ガイドは、この方式を「ビジネスで必要な場合にのみ」使うよう勧めています。該当するのは、1つの注文を店舗と配達員で分ける場合、決済の時点で担当者が決まっていない場合、決済より先に出品者へ払う場合などです。

対応地域にはJPが含まれています。一方で海外への送金は、アメリカ・カナダ・イギリス・EEA・スイスの残高からしか行えず、それ以外はプラットフォームと連結アカウントが同じ地域にある必要があります。日本のプラットフォームが海外の出品者へ払う計画があるなら、この制約を要件定義の段階で確かめておきましょう。

Express相当の連結アカウント作成とオンボーディングを試す手順

ここからはサンドボックスで手を動かす手順です。APIキーはsk_test_で始まるテスト用を使います。

controllerパラメータでExpress相当の日本の連結アカウントを作る

移行ガイドのExpress相当の例に、国と必要なケイパビリティを足したリクエストです。transfersは送金を受け取るため、card_paymentsは出品者名義の決済（on_behalf_of）に備えるために申請します。

curl https://api.stripe.com/v1/accounts \
  -u "sk_test_xxxxxxxx:" \
  -d country=JP \
  -d "controller[stripe_dashboard][type]=express" \
  -d "controller[fees][payer]=application" \
  -d "controller[losses][payments]=application" \
  -d "capabilities[card_payments][requested]=true" \
  -d "capabilities[transfers][requested]=true"

応答のid（acct_で始まる値）を、自社の出品者テーブルに保存します。移行ガイドによると、作成後にcontroller.stripe_dashboard.typeは変更できず、管理画面の種類を変えるには新しいアカウントを作り直す必要があります。

Account Linksで本人確認フォームへ誘導しreturn_urlで状態を確かめる

出品者に本人確認情報を入力してもらうには、Account Links APIの公式リファレンスにあるaccount_onboardingタイプのリンクを発行し、そのURLへリダイレクトします。

curl https://api.stripe.com/v1/account_links \
  -u "sk_test_xxxxxxxx:" \
  -d account=acct_xxxxxxxx \
  --data-urlencode "refresh_url=https://example.com/connect/reauth" \
  --data-urlencode "return_url=https://example.com/connect/return" \
  -d type=account_onboarding

このURLは1回限りで、リファレンスの応答例では作成から300秒後に期限が切れます。期限切れや再訪問のときはrefresh_urlに戻されるため、そこで必要なのは、同じ条件のリンクを作り直す処理です。return_urlに戻ってきたことは入力完了を意味しないので、アカウントを取得してcharges_enabledとpayouts_enabledを確かめてから出品を許可します。

日本の出品者で止まりやすいJCB審査とカナ項目の入力チェック

JCB決済とConnectに関するStripeのサポート記事によると、日本の連結アカウントではcard_paymentsを申請するとjcb_paymentsも自動で申請され、JCBがすべてのアカウントを審査します。結果はcapability.updatedイベントで、承認ならactive、却下ならinactiveとして届きます。

もう一つの落とし穴がカナ項目です。会社名や代表者氏名のカナ欄はかな・ドット・スペース・ハイフンしか受け付けず、住所のカナ欄だけ英数字も使えます。Expressのホスト型画面ではエラーが表示されますが、情報を自社フォームで集める構成では、全角英字や記号を送る前に自社側で弾く必要があります。

デスティネーション支払いで手数料を差し引き返金で送金を戻すコード

決済と返金の処理は、サーバー側でStripe公式のNode.jsライブラリを使って書きます。

Node.jsで手数料額と送金先を指定して出品者への決済を作る

次の例は、application_fee_amountで手数料額、transfer_dataで送金先を指定し、1万円の注文から手数料1,000円を差し引き、残りを出品者へ送るPaymentIntentを作ります。日本円は小数点以下のない通貨なので、1万円はamount: 10000です。

const Stripe = require('stripe');
const stripe = new Stripe(process.env.STRIPE_SECRET_KEY);

// 1万円の注文から手数料1,000円を差し引き、残りを出品者の連結アカウントへ送る
async function createOrderPayment(orderId, sellerAccountId) {
  return stripe.paymentIntents.create(
    {
      amount: 10000,
      currency: 'jpy',
      automatic_payment_methods: { enabled: true },
      application_fee_amount: 1000,
      transfer_data: { destination: sellerAccountId },
      metadata: { order_id: orderId },
    },
    { idempotencyKey: `order-${orderId}` }
  );
}

// 全額返金：出品者への送金とプラットフォーム手数料も合わせて戻す
async function refundOrder(chargeId) {
  return stripe.refunds.create({
    charge: chargeId,
    reverse_transfer: true,
    refund_application_fee: true,
  });
}

デスティネーション支払いの公式ガイドの資金フローに当てはめると、1万円はいったん全額が出品者の保留残高に入り、1,000円がプラットフォームへ移ります。その後でStripe手数料がプラットフォームの残高から引かれるので、カード手数料3.6%なら360円が引かれ、プラットフォームに残るのは640円です。手数料率を決めるときは、この差額が赤字にならないかを確かめます。

返金時に出品者への送金とプラットフォーム手数料を戻すかの判断基準

公式ガイドによると、reverse_transferを付けずに返金すると、出品者は送金された代金を持ったままで、返金の原資はプラットフォームの残高から出ます。出品者都合のキャンセルでこの状態になると、プラットフォームが丸ごと負担することになります。

手数料も返すかどうかを決める基準は、事業として定めた返金方針です。全額返金で手数料も返すなら上のコードのとおり両方を付け、手数料は受け取ったままにするならrefund_application_feeを外します。出品者の残高が足りないと、送金の差し戻しを伴う返金は保留にならずエラーで返るため、エラー時に返金を再試行するか運用で処理するかの分岐をあらかじめ書いておきます。

送金別方式ではsource_transactionで残高不足の送金失敗を防ぐ

送金別方式では、決済とは別に/v1/transfersで出品者ごとに送金を作ります。そのまま送るとプラットフォームの利用可能残高を超えた時点で失敗し、自動では再試行されません。公式ガイドは、元の決済のIDをsource_transactionに指定する方法を示しています。

# 1万円の決済から店舗へ7,000円、配達員へ2,000円を送る（残る1,000円が手数料）
curl https://api.stripe.com/v1/transfers \
  -u "sk_test_xxxxxxxx:" \
  -d amount=7000 \
  -d currency=jpy \
  -d source_transaction=ch_xxxxxxxx \
  -d destination=acct_store

curl https://api.stripe.com/v1/transfers \
  -u "sk_test_xxxxxxxx:" \
  -d amount=2000 \
  -d currency=jpy \
  -d source_transaction=ch_xxxxxxxx \
  -d destination=acct_courier

source_transactionは送金の作成時にしか指定できず、後から付け足せません。銀行振込のような非同期の決済手段では、charge.succeededを受けてから送金を作るのが公式の推奨です。返金しても送金は自動では戻らないため、差し戻しの処理まで書いて初めて送金別方式の実装は完了します。イベントの受け取り側は決済Webhookの署名検証と冪等な注文確定の作りがそのまま使えます。

Stripe Connectを採用する条件と資金決済法・外部委託の判断基準

最後に、Connectを使うかどうかと、どこまで自社で作るかの判断です。

Connectを見送るべき場面：出品者が数社で自社がすべて請求する事業

自社が売り手としてすべての代金を受け取り、仕入れ先には請求書払いで月1回支払うだけなら、Connectは要りません。通常のStripe決済と会計上の支払処理で足ります。出品者が数社しかないのに連結アカウントの審査・カナ項目・入金手数料を抱えると、管理の手間が手数料収入を上回ります。

逆に、出品者が数十社を超え、出品者ごとの入金と返金を自動で回したいなら採用します。Stripeの製品ごとの守備範囲はStripeの機能一覧と日本での提供可否で比べられます。

資金決済法の線引きと収納代行の論点を実装前に自社の法務と確かめる

Connectを使えば決済処理はStripeが担いますが、自社の事業が資金決済法上どう扱われるかの判断まで代わってくれるわけではありません。代金を長く預かってから出品者に払う、取引成立に関与しないまま代金だけを受け取る、といった設計は、法的な整理を先に済ませるべき論点です。

代金の預かり方と為替取引の線引きはエスクローの仕組みと資金決済法の線引き、資金移動業などの区分は資金決済法の前払式支払手段と資金移動業の区分で解説しています。最終判断は弁護士など専門家に確認してください。なお、送金前の資金を保護された状態に保つ「資金分離」は、公式ガイドでプライベートプレビューの扱いです。

自社で作る範囲と決済開発の経験がある外部に任せる範囲の分け方

Express相当の構成とデスティネーション支払いで、1注文1出品者を扱うだけなら、本記事のコード量で内製できます。最低限の動作に必要なのは、オンボーディング、決済作成、返金、Webhook受信の4つです。テストはStripeテストカードの使い方の番号で拒否や3Dセキュアの分岐まで通しておきます。

送金別方式による多者分配、出品者ごとの入金スケジュール、返金と送金差し戻しの照合、会計システムへの連携まで重なると、状態の組み合わせが一気に増えます。設計経験のある外部に入ってもらうほうが、本番での照合漏れより安く済む場面です。一創では決済・サブスクリプションシステムの開発として、Stripe Connectを使ったマーケットプレイス決済の設計と実装を支援しています。

Stripe Connectのよくある質問｜料金・Express・海外送金・入金

Stripe Connectの導入時によく出る質問をまとめました。

Stripe Connectの手数料は誰が負担しますか？

誰が手数料を負担するかは、支払い方式と料金プランによって異なる仕組みです。デスティネーション支払いと送金別方式では、Stripeの決済手数料はプラットフォームの残高から引かれます。ダイレクト支払いでは、連結アカウントとプラットフォームのどちらから引くかを選べる仕組みです。これとは別に、プラットフォームが料金体系を管理するプランでは、日本向けの場合、有効なアカウントごとに月200円と、入金ごとに0.25%＋250円がかかります。

StripeのExpressとStandardは後から切り替えられますか？

切り替えられません。公式ドキュメントは、連結アカウントを作成した後はタイプを変更できないとしており、コントローラープロパティで作った場合も管理画面の種類は変更できません。構成を変えるには新しい連結アカウントを作り、出品者にもう一度オンボーディングしてもらう必要があります。最初の設計で、出品者に管理画面を渡すかどうかを決めておきましょう。

Connectで出品者への入金タイミングを自社で決められますか？

決められます。公式の比較表では、Standard・Express・Customのいずれでもプラットフォームが入金タイミングを指定できます（Standardはプラットフォーム管理の設定を使います）。ただし、Accounts v2 APIでは入金設定を管理できないため、入金スケジュールを制御する処理はv1のAccounts APIで書きます。

日本のプラットフォームから海外の出品者へ送金できますか？

送金別方式とデスティネーション支払いでの国をまたぐ送金は、アメリカ・カナダ・イギリス・EEA・スイスの残高からに限られ、それ以外はプラットフォームと連結アカウントが同じ地域にある必要があります。on_behalf_ofで出品者を決済の名義にする方法や、Global Payoutsを使う方法もあるため、対象国が決まった段階で公式ドキュメントの条件を確かめてください。

Stripe Connectの動作はテスト環境で確認できますか？

テスト環境での動作確認は可能です。サンドボックスとテスト用APIキーで連結アカウントを作り、Account Linksでオンボーディングを通し、テストカードで決済から送金・返金までを再現できます。デスティネーション支払いの公式ガイドにも4242 4242 4242 4242や残高不足の4000 0000 0000 9995などのテストカードが掲載されているので、動作確認に使ってください。Webhookはstripe listenでローカルへ転送して確かめます。

関連記事

• Stripeとは？決済プラットフォームの仕組み・手数料・実装パターンを開発視点で解説：Connectを含むStripe全体の位置づけと実装パターン3種。
• エスクローとは？仕組みと資金決済法の線引き・実装方式の判断を解説：代金を預かる設計で確かめる法的論点。
• 資金決済法とは？前払式支払手段と資金移動業の区分をポイント・チャージ設計で解説：資金移動業などの区分と登録の要否。
• 決済Webhookとは？仕組み・主要イベントと署名検証・冪等な注文確定の実装を開発視点で解説：capability.updatedや送金イベントを受ける側の実装。
• Stripeテストカード一覧と使い方：3Dセキュア・決済拒否・不審請求をテストする手順：Connectの決済と返金をサンドボックスで再現する番号。