マッチングサイトの取引フローとは？ステータス・決済・完了条件の設計方法
マッチングサイトでは、相手が見つかっただけで取引が完了するわけではありません。
問い合わせ後には、条件調整、申込、承認、決済、商品やサービスの提供、完了確認などの工程があります。
この流れを決めずに開発すると、利用者は次に何をすればよいか分からず、運営者も取引が止まっている場所を把握できません。
マッチングサイトの取引フローは、誰が次に操作し、どの条件を満たすと次の状態へ進むかで設計します。
本記事では、マッチングサイトの基本的な取引フローと、取引開始、決済、完了条件、ステータス、キャンセルなどの設定方法を分かりやすく解説します。
最初に結論｜マッチングサイトの基本的な取引フロー
マッチングサイトの基本的な取引フローは、掲載・検索、問い合わせ・条件調整、申込・承認、決済・提供、確認・完了、評価の順に進みます。
ただし、すべてのサイトに同じ工程が必要なわけではありません。
BtoBマッチングでは問い合わせや商談まで、フリマやスキルシェアでは決済、納品、売上確定までをサイト内で管理することがあります。
| 取引段階 | 購入者・依頼者 | 提供者・受注者 | 運営者 |
|---|---|---|---|
| 掲載・検索 | 案件や商品を検索する | 商品・サービスを掲載する | 掲載内容を審査する |
| 問い合わせ・条件調整 | 希望条件を伝える | 内容・金額・日程を回答する | 必要に応じて内容を確認する |
| 申込・承認 | 正式な条件で申し込む | 申込みを承認・拒否する | 不正な申込みを確認する |
| 決済・提供 | 代金を支払う | 発送・作業・サービス提供を行う | 決済と進行状況を確認する |
| 確認・完了 | 受取確認・検収を行う | 修正や再対応を行う | 紛争や期限超過へ対応する |
| 売上確定・評価 | 取引相手を評価する | 売上を確認し、相手を評価する | 手数料・売上・入金を管理する |
正常に進む取引だけでなく、承認拒否、決済失敗、修正依頼、期限超過などの分岐も設定します。
| 現在の状態 | 利用者の操作・発生事象 | 次の状態 |
|---|---|---|
| 承認待ち | 提供者が承認する | 決済待ち |
| 提供者が拒否する | 不成立 | |
| 承認期限を過ぎる | 自動終了 | |
| 決済待ち | 決済に成功する | 取引中 |
| 決済に失敗する | 再決済待ち | |
| 支払期限を過ぎる | キャンセル | |
| 確認待ち | 購入者が承認する | 完了・売上確定 |
| 購入者が修正を依頼する | 取引中へ戻る | |
| 購入者が異議を申し立てる | 紛争中 | |
| 確認期限を過ぎる | 自動完了 |
正常に完了する流れだけでなく、拒否、決済失敗、未返信、修正依頼、キャンセル、紛争、期限超過から次にどの状態へ進むかを決めます。
マッチング成立・取引開始・取引完了の違い
マッチング成立、取引開始、決済完了、取引完了、売上確定は、それぞれ異なる状態です。
これらを一つの状態として扱うと、取引がどこまで進んでいるか判断できなくなります。
| 状態 | 意味 |
|---|---|
| マッチング成立 | 条件に合う相手が見つかり、問い合わせや申込みができる状態 |
| 取引開始 | 申込承認、予約確定、決済完了など、サービスで定めた開始条件を満たした状態 |
| 決済完了 | 購入者や依頼者からの支払いが完了した状態 |
| 取引完了 | 発送、納品、検収、サービス提供などが終了した状態 |
| 売上確定 | 提供者が受け取る売上金額が確定した状態 |
取引開始の条件は、サービスによって異なります。
一般的には、申込内容を相手が承認し、取引する当事者、金額、内容、日程などの条件が確定した時点を基準にします。
商品販売では決済完了時、予約サイトでは予約確定時、審査制のサービスでは管理者承認時を取引開始とする設計もあります。
問い合わせを送っただけでは取引開始にしない
問い合わせは、相手へ最初の連絡を送った状態です。
この時点では、金額、日程、納期、提供内容が決まっていないことがあります。
問い合わせ、条件調整、正式申込、取引開始を分けることで、実際の取引件数や成約率を正確に管理できます。
決済完了と取引完了を分ける
購入者が支払いを終えても、商品発送やサービス提供が終わっていなければ、取引は完了していません。
提供者への売上支払いがあるサイトでは、決済完了後すぐに売上を確定せず、受取確認や検収後に売上を確定する方法もあります。
支払いが終わったことと、取引が無事に終了したことは同じではありません。
システム上の「取引開始」と法律上の契約成立時点が一致するとは限りません。申込み、承認、決済のどの時点で契約が成立するかは、利用規約と申込画面・確認画面の表示でも明確にします。
マッチングサイトの取引設定で決める5項目
取引設定では、開始条件、承認方法、決済時期、完了条件、キャンセル・期限超過時の処理を決めます。
この5項目を決めることで、必要な画面、ボタン、通知、管理機能を整理できます。
1．取引を開始する条件
何をもって正式な取引開始とするかを決めます。
- 相手が申込内容を承認した時
- 予約が確定した時
- 見積もりを発注者が承認した時
- 購入者が決済を完了した時
- 管理者が審査を承認した時
取引開始前の問い合わせやメッセージは、条件調整中として管理します。
2．相手の承認を必要とするか
申込後すぐに取引を開始するのか、提供者の承認を挟むのかを決めます。
在庫や提供条件が確定している商品販売では、承認なしで購入へ進む設計が向いています。
日時、作業内容、金額などを調整する予約、業務委託、スキルシェアでは、提供者の承認を挟む方が安全です。
提供者が条件を変更した場合は、変更後の金額、納期、提供内容を申込者が再確認できるようにします。
3．決済するタイミング
決済時期は、商品の種類や、キャンセル・金額変更の発生しやすさに合わせて決めます。
| 決済時期 | 向いている取引 |
|---|---|
| 申込時に決済 | 商品購入、即時予約、デジタルコンテンツ |
| 相手の承認後に決済 | 予約、見積もり、業務委託 |
| サービス提供後に決済 | 利用時間や数量によって金額が変わる取引 |
| サイト外で決済 | 問い合わせや商談までを仲介するBtoBサイト |
4．取引を完了する条件
取引完了の条件は、取引内容によって変わります。
- 購入者が受取確認を行った時
- 発注者が納品物を検収した時
- 予約日時が終了した時
- 双方が完了を承認した時
- 一定期間、異議申立てがなかった時
利用者が完了操作を忘れる可能性がある場合は、自動完了を設定します。
たとえば、納品から7日以内に確認されなかった場合、期限の2日前に通知し、異議申立てがなければ自動完了する流れです。
5．キャンセル・未返信・期限超過を処理する
正常に進む取引だけでなく、途中で止まった場合の処理を決めます。
- 誰がキャンセルを申請できるか
- いつまでキャンセルできるか
- 相手の同意を必要とするか
- キャンセル料を徴収するか
- 未返信や期限超過で自動終了するか
決済後のキャンセルでは、購入者への返金だけでなく、提供者売上と運営手数料の取消も必要です。
当事者だけで解決できない場合は、取引を「紛争中」に変更し、管理者がメッセージ履歴、提供内容、決済状況を確認します。
取引ステータスと状態遷移の設定例
取引ステータスは、現在の状態だけでなく、実行できる操作と次へ進む条件まで決めます。
次に操作する人や、利用できるボタンが変わらない状態は、無理に分ける必要はありません。
| ステータス | 操作する人 | 実行できる操作 | 次へ進む条件 |
|---|---|---|---|
| 問い合わせ中 | 問い合わせを受けた相手 | 返信・辞退 | 返信すると条件調整中 |
| 条件調整中 | 双方 | メッセージ・見積もり・申込 | 正式申込で承認待ち |
| 承認待ち | 提供者・受注者 | 承認・拒否・条件変更 | 承認すると決済待ち |
| 決済待ち | 購入者・依頼者 | 支払い・申込取消 | 決済成功で取引中 |
| 取引中 | 提供者・受注者 | 発送・作業・納品・提供完了 | 提供完了で確認待ち |
| 確認待ち | 購入者・依頼者 | 承認・修正依頼・異議申立て | 承認すると完了 |
| 完了 | 双方 | 評価・レビュー | 売上確定・評価完了 |
| キャンセル | 利用者・管理者 | 返金確認・理由確認 | 返金処理後に終了 |
| 紛争中 | 管理者 | 調査・返金・取引再開・強制終了 | 管理者判断で状態を変更 |
ステータスは工程を細かく見せるためではなく、利用者が次の操作を判断できるように設定します。
状態が変わったら対象者へ通知する
取引ステータスを変更するときは、誰へ、何を、どの方法で通知するかも決めます。
| 状態の変化 | 通知先 | 通知内容 |
|---|---|---|
| 申込 → 承認待ち | 提供者 | 新しい申込みが届いたことを通知 |
| 承認 → 決済待ち | 購入者 | 申込承認と支払い期限を通知 |
| 納品 → 確認待ち | 購入者 | 納品内容の確認を依頼 |
| 完了期限の2日前 | 購入者 | 自動完了予定日を通知 |
| 紛争中へ変更 | 双方・管理者 | 取引停止と今後の対応を通知 |
重要な通知は、サイト内通知だけでなくメールでも送ります。
承認待ち、決済待ち、確認待ちなど、利用者の操作を待っている状態では、期限前に再通知する設計も有効です。
サイトの種類別に見る取引フロー
マッチングサイトの取引フローは、商談、予約、発送、納品など、取引が完了する条件に合わせて変えます。
| サイトの種類 | 主な取引フロー |
|---|---|
| BtoBマッチング | 案件掲載 → 問い合わせ → 商談 → 見積もり → 発注 |
| 求人・人材 | 求人掲載 → 応募 → 選考 → 内定 → 採用 |
| 予約マッチング | 検索 → 予約申込 → 承認・決済 → サービス提供 → 完了 |
| フリマ・CtoC | 出品 → 購入・決済 → 発送 → 受取確認 → 売上確定 |
| スキルシェア | 相談 → 見積もり → 購入 → 作業 → 納品 → 検収 |
| レンタル | 予約 → 決済 → 貸出 → 返却 → 状態確認 → 完了 |
BtoBでは、問い合わせ後に金額や業務範囲を調整するため、見積もりや発注承認が重要です。
フリマでは受取確認、スキルシェアでは納品物の検収、予約サイトでは予約日時の終了が取引完了の基準になります。
マッチングサイトの取引フローでよくある失敗
主な失敗は、取引開始と完了の条件が曖昧なこと、次の操作が分からないこと、例外時の遷移がないことです。
問い合わせと取引開始を同じ状態にする
問い合わせ時点で取引開始にすると、相手から返信がない相談や、条件が合わず終了した問い合わせも取引件数に含まれます。
問い合わせ、条件調整、正式申込、取引開始を分けて管理します。
次に必要な操作を表示しない
「進行中」「対応中」だけでは、購入者と提供者のどちらが操作するのか分かりません。
ステータスと一緒に、次のような案内を表示します。
- 提供者の承認をお待ちください
- 支払い期限までに決済してください
- 商品を発送してください
- 納品内容を確認してください
正常系だけを作り、例外時の遷移を決めない
取引では、承認拒否、決済失敗、未返信、修正依頼、キャンセル、紛争が発生します。
それぞれの状態から、再決済、取引中への差し戻し、返金、強制終了など、次に進む状態を決めておく必要があります。
マッチングサイトの取引フローに関するよくある質問
取引ステータスはいくつ必要ですか？
一般的には、問い合わせ中、条件調整中、承認待ち、決済待ち、取引中、確認待ち、完了、キャンセルの8種類前後で整理できます。
紛争対応が必要なサイトでは「紛争中」を追加します。
次に操作する人や実行できる機能が変わらない状態は、増やさない方が管理しやすくなります。
決済はどのタイミングで行うべきですか？
商品販売や即時予約では申込時、見積もりや提供者の承認が必要な取引では承認後の決済が向いています。
利用時間や数量で金額が変わる場合は、サービス提供後に金額を確定して決済する方法もあります。
取引の自動完了は必要ですか？
購入者や依頼者が完了操作を忘れる可能性があるサイトでは、自動完了を設定します。
自動完了前には、完了予定日を通知し、修正依頼や異議申立てができる期間を設けます。
公開後に取引フローを変更できますか？
変更できますが、進行中の取引へ新しいルールを適用すると、状態や期限が合わなくなる可能性があります。
変更前に開始した取引は旧フロー、変更後に開始した取引は新フローとして分けて管理する方法が安全です。
まとめ｜取引フローは状態と次の操作をセットで設計する
マッチングサイトの取引フローでは、正常に進む順番だけでなく、途中で取引が止まった場合の分岐も必要です。
設計時には、次の内容を決めます。
- 何をもって正式な取引開始とするか
- 現在の状態で誰が何を操作できるか
- 決済、提供、確認をどの順番で行うか
- 何をもって取引完了・売上確定とするか
- 拒否、決済失敗、キャンセル、紛争をどう処理するか
ステータスが変わったときは、次に操作する利用者へ通知し、期限までに対応がなければ再通知や自動終了を行います。
現在の状態、実行できる操作、次へ進む条件をセットで決めることが、分かりやすく運用しやすい取引フローにつながります。
