マーケットプレイスの支払い・手数料・出品者精算：マネーレイヤーの設計方法

このガイドは、マルチベンダーマーケットプレイスのCTO、プロダクトオーナー、財務責任者を対象としています。マーケットプレイスのプラットフォームアーキテクチャガイドよりも一段深い内容で、そちらでは出品者・カタログ・注文の中の決済を扱っていますが、ここではチェックアウト後の資金のみを取り上げます。カスタムプラットフォームが必要かどうかの判断は、カスタムECプラットフォームガイドから始めてください。

このガイドの内容

• 3つの層：プロバイダー・台帳・ペイアウトエンジン
• 手数料モデルと適用場面
• 出品者台帳
• 精算タイミングとリリースルール
• 返金・チャージバック・マイナス残高
• ペイアウト運用と失敗への対処
• 税務と報告義務
• 照合
• 構築・購入・設定：選択肢と選定基準
• マーケットプレイス精算におけるAI
• 存在する納品実績と存在しないもの
• このガイドの限界
• よくある質問
• 次のステップ

3つの層：プロバイダー・台帳・ペイアウトエンジン

精算の問題のほとんどは、3つの役割を混同することから生じます。

• 決済プロバイダーは購入者への請求、規制された資金の保管、出品者の審査、および銀行口座への送金を担います。Stripe ConnectやAdyen for Platformsなどのマーケットプレイス向け製品は、出品者のオンボーディング、支払い分割、ペイアウト管理を提供します。
• 台帳は、各金額が誰に帰属するかの理由を記録します。注文明細、手数料、費用、割引、返金、準備金、調整が対象です。出品者明細、財務レポート、サポート回答の根拠となります。
• ペイアウトエンジンは残高をいつリリースするかを判断し、プロバイダーに送金を依頼し、結果を記録します。

プロバイダーの残高が示すのは「今日動かせる金額」であり、「出品者が予定より少ない金額を受け取った理由」や「返金が先月の手数料にどう影響したか」は示しません。それは台帳の仕事であり、スプレッドシートの仕事ではありません。

手数料モデルと適用場面

どのモデルであれ、手数料ルールはコードではなくデータとして記述してください。出品者・カテゴリー・日付をキーとするレートテーブルを用意し、変更のたびに有効開始日を設定します。各注文明細に使用したレートを保存してください。3カ月後の返金では、現在のレートではなく当時請求した手数料を取り消す必要があるためです。

出品者台帳

資金の動きを会計士のように扱います。Martin Fowlerの会計パターンでは、残高はエントリーから生まれ、誤りは古いエントリーを編集するのではなく、新しい調整・取消エントリーで修正するとされています。マーケットプレイスでは次を意味します：

• イベントごとに1エントリー。注文明細の支払い、手数料の請求、プロバイダー手数料の配賦、返金の発行、チャージバックの受領、準備金の保留、準備金の解放、ペイアウトの送信、ペイアウトの返戻。
• 複式記帳。各エントリーは、購入者資金から出品者未確定へ、または出品者未確定からプラットフォーム手数料へのように、2つの口座間で金額を移動させます。合計は常にゼロになります。
• 出品者ごとに3つの状態の残高。未確定（獲得済みだが配送・返品期間内）、利用可能（次回実行時に支払い可能）、準備金（返金・紛争に備えて保留中）。StripeもConnectedアカウントの未確定・利用可能残高を同じ用語で説明しています。
• ソースへのリンク。各エントリーには元となる注文、明細、返金、紛争、およびプロバイダーのトランザクション参照が付きます。

このような台帳があれば、ペイアウトの理由、控除の理由、まだ未払いの金額を数分で答えられます。

返金・チャージバック・マイナス残高

返金や紛争は資金移動後に発生するため、ローンチ前にルールを定める必要があります。

• 出品者明細ごとの返金。返金はその明細の出品者取り分を取り消し、ポリシーに応じて手数料も取り消します。カート内の他の出品者には影響しません。
• チャージバック。プロバイダーは請求が行われたアカウントから異議申立額を回収します。出品者がすでに支払いを受けていた場合、出品者残高で賄えるまでプラットフォームが差額を負担します。
• マイナス残高は正常です。金額、理由、日付を出品者に表示し、将来の収益から自動的に相殺し、長期化した場合のみエスカレーションします。Stripeでは、マイナス残高のConnectedアカウントはプラスになるまでペイアウトを受け取れず、プラットフォームの残高が責任を負うアカウントの補填に充てられる場合があると説明しています。
• 損失の負担を決定する。各プロバイダーの設定で、出品者のマイナス残高についてプロバイダーとプラットフォームのどちらが責任を負うかを決め、その判断を踏まえて手数料を設定します。

ペイアウト運用と失敗への対処

例外ケースも考慮してペイアウトを設計します：

• 銀行口座情報の変更。ペイアウト先の変更はリスクイベントとして扱います。確認を行い、次回のペイアウトを一時的に保留し、誰が何を変更したかを記録します。
• 返戻ペイアウト。拒否された銀行振込は出品者の利用可能残高に戻り、出品者が情報を修正するためのタスクが生成されます。
• 通貨。注文通貨、精算通貨、各換算に使用したレートを記録し、明細と実際に銀行に届いた金額を一致させます。
• 明細書。各ペイアウトごとに出品者がダウンロードできる明細書を提供します。注文、手数料、費用、返金、準備金、調整を合算するとペイアウト額と一致する内容にします。

税務と報告義務

出品者の収入を処理するプラットフォームは、複数の地域で報告義務を負います。EUではDAC7により、デジタルプラットフォーム運営者は出品者に関する情報を収集・確認し、税務当局に報告することが義務付けられています。米国では、第三者決済機関として機能するオンラインマーケットプレイスは、IRSの報告基準を超える出品者についてForm 1099-Kを提出します。オンボーディング時に出品者データを取得し、台帳に出品者ごと・年ごとのペイアウト合計を保存しておけば、レポートはクエリで生成できます。現行の基準については税務アドバイザーに確認してください。

照合

毎日3つのビューを照合します。台帳、プロバイダーの残高トランザクション、銀行です。各ペイアウトを台帳エントリーおよび銀行入金と照合し、差異をフラグし、未照合項目に担当者が割り当てられた状態でのみ日次クローズを行います。要約エントリーを財務システムに転記します。ERP・CRM・EC統合アーキテクチャガイドでその連携を解説しています。ローンチ前のテストでは、複数出品者を含むカート、部分返金、ペイアウト後のチャージバック、返戻ペイアウト、通貨換算を含むシナリオを検証し、最終的に台帳残高がゼロになることを確認してください。

構築・購入・設定：選択肢と選定基準

決定には4つの基準があります。手数料・準備金ルールの独自性、精算する通貨・国の数、紛争による損失の負担者、財務が毎月必要とするレポートの量です。Netbase JSCはWooCommerce、Magento 2、Laravel、ヘッドレスコマースでコマースプラットフォームを納品しており、カスタム開発ではクライアントが作成されたIPを所有します。Netbase JSCのプロジェクトのほとんどはディスカバリー後の請負契約で納品されます。フルビルドの商用オファーはECマーケットプレイスソリューションで、EC開発サービスを通じて提供されます。

ソフトウェアエージェントが注文を行う場合も、自動化された返金にはトレース可能なエントリーが必要です。エージェンティックコマース対応ガイドをご覧ください。

存在する納品実績と存在しないもの

• RB Marketplace。西アフリカおよびディアスポラ向けのLaravelマルチベンダーマーケットプレイスで、出品者は収益・手数料控除・ペイアウトリクエストを確認でき、管理者が手数料とペイアウトを管理します（RB Marketplace実績）。
• EUファッションテックマーケットプレイス。Netbase JSCは匿名のEUクライアント向けにマルチベンダーマーケットプレイスを構築し、Stripe Connectで支払い分割と出品者ペイアウトを処理しています（EUマーケットプレイス事例）。
• クラシックマーケットプレイス以外のマルチベンダーモジュール。ドバイのロイヤルティ・リワード会社向けに、Netbase JSCはマルチベンダーモジュール、フルフィルメントルーティング、ポイント＋現金チェックアウトを備えたリワードショッププラットフォームを納品しました（ロイヤルティリワードショップ実績）。

存在しないもの。カスタム精算エンジン、準備金ポリシー、税務報告の構築について公開されたNetbase JSCの実績はなく、ペイアウト・照合・紛争に関する数値も公開されていません。上記の台帳・リリース・照合の実践は、納品経験と引用されたプロバイダードキュメントに基づくものであり、測定された成果ではありません。

このガイドの限界

• 決済・税務・消費者ルールは国によって異なります。引用されている情報源は設計上考慮すべき義務の例示であり、網羅的なリストではありません。法務・税務アドバイザーに相談してください。
• StripeとAdyenはプラットフォーム決済サービスの例として挙げており、他のプロバイダーよりも推奨するものではありません。

よくある質問

決済プロバイダーが残高を表示している場合、独自の台帳は必要ですか？最もシンプルなマーケットプレイス以外では必要です。プロバイダーが示すのは動かせる金額であり、台帳は注文明細ごとにその理由を説明し、出品者明細・財務・サポートに情報を提供します。

出品者へのペイアウトはいつ行うべきですか？取引が確定するイベント、つまり配送・返品期間終了・サービス完了の後です。利用可能残高のみから、固定カレンダーに従って支払います。

出品者への支払い後にチャージバックが発生した場合、誰が負担しますか？プロバイダーは請求が行われたアカウントから回収します。その後出品者残高を引き落とすかどうかは契約条件で決まります。差額はそれが解消されるまでプラットフォームが負担します。

次のステップ

手数料モデル、決済地域、ペイアウトカレンダーをご共有いただければ、台帳と精算フローの概要をお伝えするためのソリューションレビューを予約します。Netbase JSCの小売・EC分野での実績もご覧いただけます。また、Netbase JSCのインサイトもご参照ください。

関連サービスとソリューション