マッチングプラットフォームの決済設計で最初に決めるべきなのは、「利用者が払った代金を、誰が、いつまで、どういう立場で持っているのか」です。代金をいったん運営が預かり、取引の完了を確認してから手数料を差し引いて提供者に支払う方式は、一般にエスクロー型と呼ばれ、利用者と提供者の双方に安心感を与えます。一方で、他人のお金を預かって別の人に渡す行為は、資金決済に関する法規制の論点に触れる可能性があり、方式によっては登録や許可が必要になったり、満たすべき条件が生じたりします。決済の流れは、システムの設計だけでなく、法務の確認と決済代行サービスの選定を並行して進めるテーマです。
この記事は、マッチングサービスやマーケットプレイス型の事業を立ち上げようとしている事業責任者、決済機能の設計を任された開発担当者やプロダクト担当者に向けて書いています。マッチングにおける決済の基本的な流れ、代金の預かり方の選択肢、手数料の取り方、提供者への支払い（出金）の設計、キャンセルと返金の扱い、そして法規制の論点を、設計の順番に沿って説明します。
読み終えたときに、自社のサービスにどの決済の方式が合いそうか、設計にあたって何を決め、誰に何を確認すべきかを整理できることを目指しています。なお、法規制に関する記述は一般的な論点の整理であり、個別のサービスへの適用については、弁護士などの専門家や監督官庁の窓口で最新の情報を確認してください。
マッチング決済の基本：三者の間でお金が動く
一般的なネットショップの決済では、お金は利用者からお店へと一方向に流れます。マッチングプラットフォームでは、利用者、提供者、運営の三者が関わり、次のような流れが発生します。
- 支払い：利用者が代金を支払う
- 保持：代金が、取引の完了まで誰かの手元にとどまる
- 手数料の差し引き：運営が自社の取り分を差し引く
- 出金：提供者に残りの金額が支払われる
- 返金：キャンセルやトラブルのときに、利用者にお金が戻る
この五つの段階それぞれで、「誰がお金を持っているのか」「どのタイミングで移るのか」を決めるのが、マッチングの決済設計です。
代金の預かり方の選択肢
代金をどう扱うかには、大きく三つの考え方があります。
| 方式 | お金の流れ | 利点 | 注意点 |
|---|---|---|---|
| 直接取引型 | 利用者が提供者に直接支払い、運営は手数料を別途提供者に請求する | 運営がお金を預からないため、仕組みが単純 | 手数料の回収が遅れる・漏れる。利用者の安心感が弱い |
| 運営が預かる型（エスクロー型） | 運営が代金を受け取って保持し、完了後に手数料を差し引いて提供者に支払う | 利用者・提供者の双方に安心感。手数料を確実に回収できる | 資金決済に関する法規制の確認が必要。資金管理の負担 |
| 決済代行の仕組みを使う型 | 決済代行サービスのプラットフォーム向け機能を使い、代金の保持と分配を決済代行側で行う | 法規制や資金管理の負担の一部を仕組みに委ねられる | サービスごとに対応範囲・条件・手数料が異なる。提供者の本人確認が求められることが多い |
直接取引型
利用者と提供者が直接お金をやり取りし、運営は成立件数などに応じて提供者に手数料を請求する方式です。運営がお金を預からないので、仕組みは単純です。一方で、手数料の請求と回収に手間がかかり、取引がサービスの外で行われると成立を把握できなくなります。利用者にとっても、提供者が約束どおりサービスを提供してくれるかの不安が残ります。
運営が預かる型（エスクロー型）
運営が利用者から代金を受け取り、取引の完了を確認してから、手数料を差し引いて提供者に支払う方式です。利用者は「サービスを受けられなければお金が戻る」、提供者は「代金の支払いが確実」という安心感を得られ、運営は手数料を確実に回収できます。
ただし、運営が他人のお金を預かって別の人に渡す形になるため、資金決済に関する法規制との関係を整理する必要があります。どのような契約の形をとるか、代金をどのような立場で受け取るかによって、論点が変わります。
決済代行の仕組みを使う型
決済代行（PSP）の事業者の中には、マーケットプレイスやプラットフォーム向けに、代金の受け取り、手数料の差し引き、提供者への分配をまとめて扱える機能を提供しているところがあります。Stripeのような海外発の決済サービスや、国内の決済代行事業者が、こうした機能を用意している例があります。
この方式では、お金の保持と分配を決済代行の仕組みの中で行うため、運営が自社の口座で他人のお金を預かる場面を減らせる可能性があります。ただし、対応している取引の形、提供者側に求められる本人確認や審査、手数料、出金の頻度などはサービスごとに異なり、変わることもあります。自社の取引の形に合うかを、導入前に確認する必要があります。
手数料の取り方の設計
マッチングプラットフォームの収益の取り方には、いくつかの形があります。
- 成立手数料：取引ごとに、代金の一定割合や定額を手数料として受け取る
- 利用者側の手数料：利用者が支払う代金に、サービス利用料を上乗せする
- 掲載料・月額料金：提供者から、掲載や利用の対価として定額を受け取る
- オプション料金：上位表示や追加機能の対価を受け取る
これらは組み合わせることもできます。どの形が合うかは、取引の頻度と金額、提供者と利用者のどちらが価値を感じているか、競合するサービスの状況によって変わります。手数料率の決め方そのものについては、マーケットプレイスの手数料設計で詳しく扱っています。
決済の設計で決めておくこと
手数料の形を決めたら、決済の仕組みとして次の点を決めます。
- 手数料は、代金から差し引くのか、別途請求するのか
- 手数料の計算の基準（代金の総額か、税抜きの額か、送料などを含むか）
- 端数の扱い（切り捨て、切り上げ、四捨五入）
- 決済代行に支払う決済手数料を、運営と提供者のどちらが負担するか
- 手数料率を変更したとき、変更前の取引にどう適用するか
- 手数料に関する請求書や領収書の発行方法
手数料に関わる消費税の扱いや、請求書の記載事項は、税制の変更の影響を受けます。会計や税務の専門家に確認しながら決めてください。
出金（提供者への支払い）の設計
提供者への支払いは、提供者にとっての満足度に直結します。設計では次の点を決めます。
- 支払いの条件：取引の完了をどう確定させるか。利用者の完了確認、一定期間の経過、運営の確認など
- 支払いのタイミング：取引ごとに支払うのか、月末締めでまとめて支払うのか、提供者が申請したときに支払うのか
- 振込手数料の負担：振込にかかる手数料を運営と提供者のどちらが持つか。最低出金額を設けるか
- 支払い先の情報の管理：口座情報の登録・変更の手続きと、なりすましによる変更を防ぐ確認
- 支払いの記録と明細：提供者が、いつのどの取引の分がいくら支払われたかを確認できる明細
取引の完了をどう確定させるか
エスクロー型では、取引の完了をもって提供者への支払いが確定するため、完了の判定が重要になります。利用者が「受け取った」「サービスを受けた」と操作したら完了とする方法が分かりやすいですが、利用者が操作を忘れると支払いが進みません。そのため、一定期間が経過したら自動的に完了とみなし、その間に利用者から異議があれば支払いを止める、といった仕組みを組み合わせるのが一般的な考え方です。
不正な取引への備え
決済が絡むマッチングサービスでは、盗まれたカード情報を使った支払いや、利用者と提供者が共謀して架空の取引を作り、売上を引き出そうとする不正が起こりえます。こうした不正に備えるため、提供者への支払いを一定期間保留できる仕組み、登録して間もない提供者の初回の支払いを運営が確認してから行う仕組み、短期間に同じ相手との高額な取引が続いた場合に運営に知らせる仕組みなどを検討します。
カード決済に後から異議が申し立てられ、売上が取り消されることもあります。そのときに、すでに提供者へ支払ってしまった代金をどう扱うのかも、利用規約と運用のルールで決めておきます。不正対策の機能は、決済代行の仕組みに用意されているものも多いので、何を決済代行に任せ、何を自社で作るかを整理します。
キャンセル・返金・トラブル時の扱い
決済の設計で見落とされやすいのが、取引が予定どおりに進まなかったときのお金の扱いです。次のような場面ごとに、お金の流れを決めておきます。
- 取引の成立前に利用者が取り消した場合
- 取引の成立後、実施前に利用者または提供者がキャンセルした場合
- 提供されたサービスや商品に問題があり、利用者から異議があった場合
- 提供者と連絡が取れなくなった場合
それぞれについて、返金の範囲（全額か一部か）、キャンセル料の有無、手数料の扱い（運営の手数料も返すのか）、返金の方法とタイミングを決め、利用規約に明記します。キャンセル料や事前決済の考え方は、予約システムのキャンセル料・事前決済の実装方法と運用ルールも参考になります。
決済のタイミングと返金の関係
クレジットカード決済では、支払いの時点で売上を確定させる方法と、まず与信の枠だけを確保して後から売上を確定させる方法があります。後者を使えば、成立前の取り消しでは売上を確定させずに枠を解放するだけで済み、返金の手続きが不要になる場合があります。ただし、枠を確保しておける期間には制限があることが多く、決済代行やカード会社の条件によって異なるため、取引の成立から完了までの期間と合わせて確認します。
資金決済に関する法規制の論点
マッチングプラットフォームの決済では、次のような論点が生じることがあります。いずれも一般的な論点の整理であり、自社のサービスに当てはまるかどうかは、契約の形や取引の実態によって判断が分かれます。
- 他人のお金を預かって移す行為：運営が利用者から代金を受け取り、提供者に渡す形が、資金決済に関する法律で規制される為替取引に当たるかどうか。一般的には、運営が提供者に代わって代金を受け取る「収納代行」として整理できるかどうかなどが論点になる
- ポイントや残高の発行：利用者が事前に入金して残高として使う仕組みや、提供者の売上を残高として保持し別の支払いに使える仕組みは、前払式支払手段などの規制に関わる可能性がある
- 取引の形と契約の当事者：運営が売り手として取引に入るのか、場を提供するだけなのかによって、責任の範囲や必要な表示が変わる
- 表示や広告の規制：手数料やキャンセル料の表示、特定商取引に関する表示など
こうした論点は、サービスの設計を少し変えるだけで結論が変わることがあります。設計の初期段階から、資金決済や消費者取引に詳しい弁護士に相談し、必要に応じて監督官庁の窓口でも確認することをおすすめします。決済代行の仕組みを使う型を選ぶ場合も、その仕組みの中で自社がどのような立場になるのかを、決済代行事業者と専門家の両方に確認します。
決済設計の進め方
ここまでの内容を、設計の手順にまとめます。
- 取引の流れを書き出す：成立から完了、キャンセル、異議までの流れと、それぞれの時点で誰が何をするかを書き出します。
- お金の流れを重ねる：書き出した流れの各時点で、誰がお金を持っているかを書き込みます。
- 方式の候補を選ぶ：直接取引型、預かる型、決済代行の仕組みを使う型から候補を選びます。
- 法務の確認を始める：候補の方式について、専門家に法規制の論点を相談します。
- 決済代行を比較する：対応している取引の形、提供者の本人確認、手数料、出金の頻度、管理画面や開発のしやすさで比較します。
- 手数料と出金のルールを決める：計算の基準、端数、負担者、支払いのタイミングを決めます。
- キャンセルと返金のルールを決める：場面ごとの返金の範囲と方法を決め、利用規約に反映します。
- 管理画面と記録を設計する：取引ごとの代金、手数料、支払い額、返金額を確認できる画面と、会計処理に使える記録を設計します。
立ち上げ初期に決済の実装を最小限にする方法は、MVPでの決済導入も参考にしてください。
決済設計のチェックリスト
- 取引の各時点で、誰がお金を持っているかを図にした
- 代金の預かり方の方式を決め、その理由を説明できる
- 選んだ方式について、専門家に法規制の論点を確認した
- 決済代行の対応範囲・条件・手数料を、最新の情報で確認した
- 手数料の計算基準・端数・負担者を決めた
- 取引の完了の判定方法と、自動で完了とみなす条件を決めた
- 提供者への支払いのタイミング・最低額・振込手数料の負担を決めた
- 支払い先の口座情報の変更時に、本人確認の手続きがある
- キャンセル・異議・連絡不通の場面ごとに返金のルールを決めた
- 手数料・キャンセル料・返金のルールを利用規約に明記した
- 取引ごとの金額の記録を、会計処理に使える形で残す設計にした
よくある失敗とその避け方
法規制の確認を後回しにする
システムを作り終えてから法規制の論点に気づくと、お金の流れを作り直す必要が生じ、大きな手戻りになります。方式の候補を選んだ段階で専門家に相談します。
返金の流れを設計していない
正常に取引が完了する流れだけを作り込み、キャンセルや異議のときの処理を後回しにすると、公開後に運営が手作業で返金や調整をすることになり、記録も不正確になります。
手数料率の変更を想定していない
手数料率を取引のデータに保存せず、計算のたびに現在の率を使う設計にすると、率を変更したときに過去の取引の金額が変わって見えてしまいます。取引の時点の率と金額を保存します。
提供者への支払いを手作業で続ける
立ち上げ期は手作業の振込で回せても、取引が増えると作業の負担と間違いが増えます。手作業で始める場合も、支払い額を計算した一覧を管理画面から出力できるようにしておき、件数が増えたら自動化に移れる準備をしておきます。
具体的な場面で考える：スキル提供のマッチング
架空の一般例として、デザインや翻訳などのスキルを持つ個人と、仕事を依頼したい企業を結びつけるサービスを考えます。
依頼の成立時に企業が代金を支払い、納品と検収を経て、手数料を差し引いた額を個人に支払う流れを想定しました。企業にとっては納品されなければ支払わずに済む安心感、個人にとっては納品すれば確実に支払われる安心感が重要なため、預かる型の考え方を採用する方針としました。
自社で代金を預かる方式は法規制の確認と資金管理の負担が大きいため、プラットフォーム向けの機能を持つ決済代行サービスを候補にし、専門家と決済代行事業者の双方に、自社の立場と論点を確認しました。手数料は成立時の代金から差し引き、決済手数料は運営が負担、個人への支払いは月末締めの翌月払いとしました。企業が検収の操作をしない場合は、納品から一定期間が経過した時点で自動的に検収済みとし、その間に異議があれば運営が仲裁する流れにしました。
よくある質問
Q. エスクロー型の決済は小さな事業者でも導入できますか？
自社で代金を預かる仕組みを一から作るのは、法規制の確認と資金管理の負担が大きくなります。プラットフォーム向けの機能を持つ決済代行サービスを使えば、小さな事業者でも比較的導入しやすくなります。ただし、対応範囲や条件はサービスごとに異なるため、自社の取引の形に合うかを確認してください。
Q. 立ち上げ期は請求書払いで始めてもよいですか？
企業間の取引や、取引の件数が少ない立ち上げ期であれば、請求書払いで始めて、件数が増えてからオンライン決済を導入する方法もあります。その場合も、お金の流れと手数料の方針は最初に決めておき、後から決済の仕組みに移しやすいデータの持ち方にしておきます。
Q. 提供者に本人確認を求める必要はありますか？
決済代行の仕組みを使う場合、提供者への支払いのために、提供者の本人確認や事業者情報の登録が求められることが多くあります。また、不正な取引やなりすましを防ぐ観点からも、支払いを受ける側の確認は重要です。本人確認の設計はマッチングサービスの本人確認・審査・通報機能をどう設計するかで説明しています。
Q. 決済まわりの開発費用は何で決まりますか？
選ぶ方式、決済代行の仕組みがどこまでを担ってくれるか、キャンセルや異議の処理をどこまで自動化するか、管理画面と記録をどこまで作るかで変わります。お金の流れが複雑になるほど、テストの範囲も広がります。見積もりを比較するときは、返金や異議の処理が範囲に含まれているかを確認してください。
Otsumuに相談できること
取引の件数がまだ少なく、請求書払いや決済代行が用意している標準的な決済ページで足りる段階であれば、この記事のチェックリストでお金の流れとルールを整理し、社内で運用を始めることは十分可能です。まずは取引の流れの各時点で誰がお金を持つのかを図にし、専門家への相談の準備をするところから始めてみてください。
一方で、代金の預かり、手数料の差し引き、提供者への分配、キャンセルや異議の処理までをシステムとして組み込みたい場合は、決済代行の仕組みの選定、取引の状態とお金の記録の設計、管理画面の開発など、設計と開発の経験が品質を左右します。お金の流れの方針そのものを事業の設計から見直したい場合も、外部の視点が役立つことがあります。
Otsumuでは、取引とお金の流れの整理から、決済代行の仕組みを使った決済機能の設計・開発、管理画面や記録の仕組みづくりまでを一貫して支援しています。法規制の判断は専門家と連携していただく前提で、その結論をシステムに落とし込む部分を担います。詳しくはマッチングサービス開発のページをご覧ください。
自社の取引の形にどの方式が合いそうか、まずは状況を伺いながら一緒に整理することもできます。30分の無料相談からお気軽にご連絡ください。
この記事について
Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。
執筆：Otsumu株式会社 ／ 編集日 2026.10.01