マーケットプレイスの支払い・手数料・ベンダー精算：収益レイヤーの設計方法

このガイドは、マルチベンダーマーケットプレイスのCTO、プロダクトオーナー、財務責任者を対象としています。マーケットプレイスプラットフォームアーキテクチャガイドより一段深い内容で、そちらではベンダー、カタログ、注文の中に決済が位置づけられていますが、ここではチェックアウト後の資金のみを扱います。カスタムプラットフォームが正当化される場面については、カスタムECプラットフォームガイドをご参照ください。

このガイドの内容

• 3つのレイヤーとは：プロバイダー、台帳、支払いエンジン
• 手数料モデルと各モデルの適用場面
• ベンダー台帳
• 精算タイミングとリリースルール
• 返金、チャージバック、マイナス残高
• 支払い運用と失敗への対応
• 税務と報告義務
• 照合
• 構築・購入・設定：選択肢と選定基準
• マーケットプレイス精算におけるAI
• どのような納品実績があり、何がないか
• このガイドの限界
• よくあるご質問
• 次のステップ

3つのレイヤーとは：プロバイダー、台帳、支払いエンジン

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

• 決済プロバイダーは購入者に課金し、規制された資金を保管し、ベンダーを審査してその銀行口座に送金します。Stripe ConnectやAdyen for Platformsのようなマーケットプレイス向け製品は、セラーのオンボーディング、支払いの分割、支払い処理を管理します。
• 台帳は各金額が誰に帰属するかの理由を記録します：注文明細、手数料、費用、割引、返金、積立金、調整項目です。ベンダー明細書、財務レポート、サポート対応の根拠となります。
• 支払いエンジンは残高をいつ解放するかを決定し、プロバイダーに移動を依頼し、その結果を記録します。

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

手数料モデルと各モデルの適用場面

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

ベンダー台帳

資金の移動を会計士のように扱ってください。Martin Fowlerの会計パターンに適切な説明があります：残高はエントリーから生まれ、誤りは新しい調整エントリーや逆転エントリーで修正し、古いエントリーを編集することは決してありません。マーケットプレイスでは次のことを意味します：

• イベントごとに1エントリー。注文明細の支払い、手数料の請求、プロバイダー手数料の配分、返金の発行、チャージバックの受領、積立金の保留、積立金の解放、支払いの送信、支払いの返却。
• 複式記入。各エントリーは2つの勘定科目間で金額を移動します（例：購入者資金をベンダー保留へ、またはベンダー保留をプラットフォーム手数料へ）。これにより合計は常にゼロになります。
• 3つの状態でベンダーごとに残高管理。保留中（獲得済みだが配送・返品ウィンドウ内）、利用可能（次回実行で支払い可能）、積立済み（返金・紛争に対して保留）。Stripeは連結アカウントの保留中残高と利用可能残高を同じ用語で説明しています。
• 出典へのリンク。すべてのエントリーに、発生元の注文、明細、返金または紛争を記録し、プロバイダーの取引参照番号も保持します。

このような台帳があれば、支払いの理由、控除の理由、未払い残高を数分で回答できます。

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

返金と紛争は資金移動後に発生するため、ローンチ前にルールが必要です。

• ベンダー明細ごとの返金。返金はその明細のベンダー分と、ポリシーに応じてその手数料を逆算します。カート内の他のベンダーには影響しません。
• チャージバック。プロバイダーは課金が行われたアカウントから紛争額を回収します。ベンダーへの支払いが既に完了している場合、プラットフォームはベンダー残高で補填できるまでその差額を負担します。
• マイナス残高は正常です。ベンダーに金額、理由、日付を表示し、将来の収益から自動的に相殺し、残高が解消されない場合のみエスカレーションします。Stripeは、マイナス残高の連結アカウントはプラスに戻るまで支払いを受けられず、プラットフォーム自身の残高が責任を負うアカウントをカバーするために積み立てられる場合があると説明しています。
• 損失の負担者を決定する。各プロバイダーの設定で、ベンダーのマイナス残高をプロバイダーまたはプラットフォームのどちらが負担するかを決め、その決定を踏まえて手数料を設定します。

支払い運用と失敗への対応

不測の事態も想定して支払いを設計してください：

• 銀行口座情報の変更。支払い先の変更はリスクイベントとして扱ってください：確認し、次の支払いを一時保留し、変更者と変更内容を記録します。
• 返却された支払い。拒否された銀行振込は金額をベンダーの利用可能残高に戻し、ベンダーが情報を修正するタスクを生成します。
• 通貨。各換算で注文通貨、精算通貨、使用レートを記録し、明細書が銀行に届いた金額と一致するようにします。
• 明細書。各ベンダーに支払いごとのダウンロード可能な明細書を提供してください：支払い済み金額に加算される注文、手数料、費用、返金、積立金、調整項目を記載します。

税務と報告義務

セラーの収入を処理するプラットフォームは、複数の地域で報告義務を負います。EUでは、DAC7によりプラットフォーム運営者はセラー情報を収集・確認し税務当局に報告することが義務付けられています。米国では、第三者決済機関として機能するマーケットプレイスはIRSの報告基準を超えた場合にForm 1099-Kを提出します。オンボーディング時にセラーデータを取得し（確認シーケンスについてはAIセラーオンボーディングガイドをご参照ください）、台帳にセラーごと・年度ごとの支払い合計を保持することで、レポートはクエリ一つで生成できます。現行の基準値については税務顧問にご確認ください。

照合

毎日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のインサイトもご参照ください。

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