マッチングサイトの決済機能とは？課金方法・売上分配・導入方法を解説

マッチングサイトに決済機能を導入する場合、クレジットカードで支払えるようにするだけでは十分ではありません。

運営会社が月額料金を受け取るサイトと、購入者から支払われた代金をサービス提供者へ渡すサイトでは、必要な決済システムが大きく異なります。

そのため、決済会社や決済手段を選ぶ前に、次の内容を整理する必要があります。

• 誰が料金を支払うのか
• 誰が売上を受け取るのか
• 運営会社はどの時点で手数料を受け取るのか
• キャンセル時に誰が返金を負担するのか

最初に決めるべきなのは決済会社ではなく、サービス内における資金の流れです。

本記事では、マッチングサイトで使われる課金方法、必要な決済機能、売上分配や仮払いの仕組み、決済代行会社の選び方まで分かりやすく解説します。

マッチングサイトの決済機能とは

マッチングサイトの決済機能とは、利用者から料金を受け取り、必要に応じて運営手数料を差し引き、商品やサービスの提供者へ売上を支払うための仕組みです。

ただし、すべてのマッチングサイトで売上分配が必要になるわけではありません。運営会社だけが料金を受け取るのか、登録ユーザーにも売上を支払うのかによって、必要な機能が変わります。

①一般的なECサイトとの違い

一般的なECサイトでは、サイトを運営する会社が商品を販売し、その会社が代金を受け取ります。

一方、マッチングサイトでは、次の三者が決済に関わることがあります。

• 商品やサービスを購入する利用者
• 商品やサービスを提供するユーザー
• マッチングの場を提供する運営会社

運営会社が販売者ではなく、第三者同士の取引を仲介する場合、提供者ごとの売上管理や入金処理も必要になります。

サービス提供者へ売上を支払うかどうかで、必要な決済システムは変わります。

②「決済手段」と「課金方法」は異なる

マッチングサイトの決済を考える際は、決済手段と課金方法を分けて整理することが重要です。

決済手段とは、利用者が料金を支払う方法です。

• クレジットカード
• 銀行振込
• コンビニ決済
• 口座振替
• QRコード・ウォレット決済
• 請求書払い

一方、課金方法とは、運営会社がどのタイミングで収益を得るかを表します。

• 月額課金
• 掲載課金
• 問い合わせ課金
• 都度課金
• 成約手数料
• ポイント課金

「カード決済を導入する」というだけでは、誰から、何の料金を、いつ受け取るのかまでは決まりません。

③決済機能が必要になりやすいサイト

サイト内で予約、購入、契約などを完結させる場合は、決済機能が必要になりやすくなります。

• 有料会員プランを提供する
• 求人や案件の掲載料を受け取る
• 予約時にサービス料金を受け取る
• 成約金額から運営手数料を差し引く
• 提供者へ売上を支払う

反対に、決済機能がなくても運営できるケース

サイトの役割を「相手を見つけて問い合わせるところまで」に限定し、契約や支払いを当事者間で行う場合、サイト内決済を導入しない選択肢もあります。

ただし、サイト外で取引されると、運営会社が成約状況を把握しにくくなります。成約手数料型で収益化したい場合は、サイト内で取引を完結させる仕組みも検討する必要があります。

マッチングサイトで使われる主な課金方法

マッチングサイトの主な課金方法は、月額課金、掲載・問い合わせ課金、都度課金、成約手数料の4つです。

どの方法が適しているかは、サービスの種類だけでなく、どの時点で利用者が価値を感じるかによって変わります。

月額課金｜利用権限に対して料金を受け取る

月額課金は、一定期間サービスを利用できる権利に対して料金を受け取る方法です。

次のようなサービスに向いています。

• 法人向けビジネスマッチング
• 有料コミュニティ
• 会員限定の求人・案件サイト
• 有料コンテンツの閲覧サービス
• 検索・問い合わせ回数を拡張するプラン

システムには、自動更新、プラン変更、解約、支払い失敗時の再請求などの機能が必要です。

月額課金は継続収益を得やすい一方で、無料会員との機能差や、継続して利用する理由を明確にしなければなりません。

掲載・問い合わせ課金｜行動単位で収益化する

掲載課金は、求人、案件、店舗、商品などをサイトへ掲載する際に料金を受け取る方法です。

問い合わせ課金では、問い合わせの送信、受信、連絡先の開示などを課金対象にします。

成約金額を把握しにくいBtoBマッチングサイトや、比較・資料請求サービスでも採用しやすい方法です。

ただし、問い合わせ課金では、次のような運用ルールが必要になります。

• 重複問い合わせをどう扱うか
• 不正な問い合わせを課金対象にするか
• 返信がなかった場合に返金するか
• 問い合わせの有効条件をどう定めるか

都度課金・成約手数料｜取引時に課金する

都度課金は、予約、相談、レッスン、コンテンツ購入など、利用のたびに料金を受け取る方法です。

成約手数料型では、取引金額の一定割合または固定金額を運営会社の手数料として差し引きます。

たとえば、1万円の取引に対して運営手数料を10％に設定した場合、運営会社が1,000円、提供者が9,000円を受け取る設計が考えられます。

成約手数料型では、決済だけでなく取引完了と売上確定の仕組みが必要です。

仮払い型｜取引完了後に売上を確定する

仮払い型では、購入者が先に支払いを行い、商品到着やサービス完了などの条件を満たした後に、提供者側の売上を確定します。

業務委託、制作、スキルシェア、レンタルなど、支払いからサービス完了までに時間がある取引に向いています。

ただし、「購入者が支払った代金を一時的に保持すること」と、法律上のエスクローサービスを提供することは必ずしも同じではありません。契約関係や資金の流れによって法的な評価が変わるため、決済会社や法律の専門家への確認が必要です。

マッチングサイトにおける4つの資金フロー

マッチングサイトの資金フローは、運営会社だけが料金を受け取る方式と、提供者へ売上を支払う方式に大別できます。

ケース1｜運営会社が利用料金を受け取る

月額料金、掲載料、問い合わせ料などを運営会社が受け取る方式です。

提供者への売上分配がないため、比較的シンプルな決済設計で対応できます。

BtoBマッチング、求人掲載、会員制コミュニティなどで採用しやすい方式です。

ケース2｜購入者が提供者へ直接支払う

サイトでは相手を探すところまで行い、支払いは当事者間で直接行う方式です。

システム内の決済構築を抑えやすい一方、運営会社が取引金額や成約状況を把握しにくくなります。

そのため、成約手数料ではなく、掲載料や月額料金で収益化するサービスに向いています。

ケース3｜手数料を差し引いて分配する

購入者が支払った代金から運営手数料を差し引き、残額を提供者へ支払う方式です。

フリマ、予約、スキルシェア、複数店舗型のマーケットプレイスなどで使われます。

売上分配が必要な場合、通常のオンライン決済だけでは対応できないことがあります。

ケース4｜取引完了後に提供者へ入金する

購入者が先に支払い、サービス完了や検収の後に提供者への入金を進める方式です。

この方式では、取引完了の条件、確認期限、キャンセル、紛争、返金などを事前に設計しなければなりません。

単に入金日を遅らせるだけではなく、完了しなかった場合にどのような処理を行うかまで決める必要があります。

マッチングサイトに必要な決済機能

最低限必要なのは、支払い、決済履歴、キャンセル・返金、管理者確認の4機能です。

提供者へ売上を支払う場合は、さらに売上管理や入金状況の確認が必要になります。

利用者側｜支払いと履歴を確認する機能

購入者や有料会員が使用する主な機能は次のとおりです。

• 決済方法の登録
• 購入・申込画面
• 支払金額の確認
• 決済履歴
• 領収書・利用明細
• 継続課金の解約
• 決済方法の変更

決済画面では、商品代金、手数料、割引、税額などを分かりやすく表示することが重要です。

提供者側｜売上と入金状況を管理する機能

商品やサービスの提供者には、売上金額だけでなく、手数料を差し引いた後の受取予定額を表示する必要があります。

• 売上金額
• 運営手数料
• 返金・キャンセル額
• 受取予定額
• 入金予定日
• 入金履歴
• 出金状況

システム内で売上残高を表示する場合は、「決済済み」「取引中」「売上確定」「入金済み」など、状態を分けて管理します。

重要ポイント｜キャンセル・返金を先に決める

決済機能では、正常に支払われた場合だけでなく、取引が中止された場合も考える必要があります。

• 全額返金
• 一部返金
• キャンセル料の徴収
• 運営手数料の返還
• 提供者売上の取り消し
• クーポンやポイントの返還

決済は成功時より、キャンセルや返金が発生したときに設計の差が出ます。

購入者へ返金しても、すでに提供者へ計上した売上を取り消していなければ、運営会社が二重に負担する可能性があります。

管理者側｜決済と取引を一つの画面で確認する

管理画面では、決済会社側の決済IDだけでなく、サイト内の注文・予約・案件と紐付けて確認できるようにします。

• 決済一覧
• 取引ステータス
• 利用者・提供者情報
• 手数料・提供者売上
• 返金状況
• 入金失敗
• エラー内容
• CSV出力

決済会社の管理画面と自社システムの管理画面を行き来しなくても、問題のある取引を把握できる設計が理想です。

通常決済とプラットフォーム型決済の違い

運営会社だけが売上を受け取る場合は通常のオンライン決済、複数の提供者へ売上を支払う場合はプラットフォーム型決済を検討します。

通常のオンライン決済が向いているケース

通常のオンライン決済は、自社が販売者となり、自社の商品やサービスの料金を受け取る場合に向いています。

• 月額会員費
• 掲載料
• 問い合わせ料金
• 自社コンテンツの販売
• 自社開催イベントの参加料

提供者への入金や複数者への売上分配がなければ、複雑なプラットフォーム決済が不要な場合もあります。

プラットフォーム型決済が向いているケース

プラットフォーム型決済は、サイトへ参加する店舗、出品者、講師、専門家などへ売上を支払う場合に使われます。

• 提供者ごとに売上を管理する
• 取引代金から運営手数料を差し引く
• 提供者へ入金する
• 一つの支払いを複数者へ分配する
• 提供者の本人確認を行う

Stripe Connectとは

Stripe Connectは、複数の当事者が関わるプラットフォームやマーケットプレイス向けに、アカウント登録、本人確認、手数料徴収、売上の振り分け、提供者への入金などを提供するサービスです。

判断基準｜Stripe Connectは必要か

提供者への入金がなければ、Stripe Connectは必須ではありません。

マッチングサイトの決済代行会社を選ぶポイント

決済代行会社は、決済手数料だけでなく、事業への対応可否、売上分配、入金方法、返金機能で比較します。

判断ポイント1｜サービス内容に対応しているか

決済会社によって、取り扱える業種、商品、サービスが異なります。

サイトを開発した後に決済審査を行い、希望する決済会社が使えないと判明すると、仕様変更が必要になる可能性があります。

次の資料をできるだけ早い段階で用意しておきましょう。

• サービスの概要
• 商品・サービスの内容
• 料金体系
• 資金の流れ
• 利用規約
• キャンセル・返金条件
• 特定商取引法に基づく表記

判断ポイント2｜必要な課金方式に対応しているか

月額課金に対応していても、売上分配や提供者への入金に対応しているとは限りません。

• 継続課金
• 都度決済
• 一部返金
• 売上分配
• 提供者への入金
• 複数者への分配
• 本人確認
• 海外提供者への対応

判断ポイント3｜料金と入金条件が合っているか

比較する費用には、決済手数料だけでなく、次のようなものがあります。

• 初期費用
• 月額費用
• 決済手数料
• アカウント管理費
• 入金手数料
• 振込手数料
• 返金時の費用

入金サイクルが月1回なのか、週次なのかによって、運転資金への影響も変わります。

判断ポイント4｜開発と運用がしやすいか

APIが提供されていても、自社に必要な処理を実装できるとは限りません。

• APIの対応範囲
• Webhookの種類
• テスト環境
• 管理画面
• エラー確認
• サポート体制
• 仕様変更時の案内

決済代行会社は、料金・機能・審査・運用の4点で比較します。

マッチングサイトの決済導入にかかる費用

決済導入の費用は、決済会社へ支払う費用と、システムへ実装するための開発費に分けられます。

費用1｜決済会社へ支払う料金

決済会社によって、初期費用、月額費用、決済手数料、入金費用などが設定されています。

料金が安く見えても、提供者数や入金回数が増えることで費用が上がる場合があります。

次の数値から月間・年間コストを試算しましょう。

• 月間決済金額
• 月間決済件数
• 提供者数
• 提供者への入金回数
• 返金件数
• 海外取引の有無

費用2｜システムへ組み込む開発費

通常のカード決済では、決済画面、決済完了処理、決済履歴、管理画面などを実装します。

プラットフォーム型決済では、さらに次の機能が必要になることがあります。

• 提供者の決済アカウント登録
• 本人確認状況の取得
• 運営手数料の計算
• 提供者売上の管理
• 入金状況の同期
• 返金・送金取消
• Webhookエラー管理

費用3｜金額が上がりやすい決済機能

• 売上分配
• 仮払い型の取引
• 複数者への分配
• 一部返金
• 出金申請
• ポイントとの併用
• 会計システムとの連携

売上分配や仮払いを伴う決済は、通常のカード決済より開発範囲が広くなります。

決済部分だけで見積もるのではなく、取引管理、通知、管理画面まで含めて必要な範囲を確認しましょう。

マッチングサイトに決済機能を導入する流れ

決済機能は、決済会社を選ぶところからではなく、収益モデルと資金フローの整理から始めます。

流れ1｜収益モデルと資金の流れを決める

まず、誰が、誰に、何の料金を支払うのかを整理します。

• 月額料金か
• 掲載料か
• 取引代金か
• 運営手数料はいくらか
• 提供者へ売上を支払うか

図にして整理すると、必要な決済機能を判断しやすくなります。

流れ2｜取引完了と返金ルールを決める

成約手数料型や仮払い型では、どの時点で取引完了とするのかを決めます。

• 購入者が完了ボタンを押した時点
• 提供者が納品した時点
• 予約日時を過ぎた時点
• 一定期間異議がなかった時点
• 管理者が承認した時点

同時に、キャンセル期限、返金額、キャンセル料、運営手数料の扱いも決定します。

流れ3｜開発前に決済会社へ確認する

サービス内容と資金フローが決まったら、開発前に決済会社へ相談します。

サイト完成後ではなく、開発前に決済会社へ事業内容を確認することが重要です。

審査結果によって決済方法や画面構成が変わる可能性があるため、開発を先行させすぎないようにします。

流れ4｜実装・テスト・本番審査を行う

実装後は、正常な決済だけでなく、エラーや返金も確認します。

• 決済成功
• 決済失敗
• 重複決済
• 全額返金
• 一部返金
• 月額課金の更新
• 解約
• Webhookの再送
• 入金失敗

テスト環境で問題がなくても、本番設定やWebhookの接続先が誤っていることがあります。公開前に本番環境でも少額の実決済を行い、管理画面やメール通知まで確認します。

マッチングサイトの決済でよくある失敗

決済機能では、支払いが成功するかだけでなく、審査・返金・入金・管理画面まで含めて設計する必要があります。

失敗例1｜決済審査を開発後に始める

希望する決済会社を利用できなかった場合、決済画面や資金フローの作り直しが発生します。

決済審査に必要な規約や料金体系も含め、開発前に準備することが重要です。

失敗例2｜返金時の処理を決めていない

購入者へ返金しても、提供者に計上した売上や運営手数料が自動的に元へ戻るとは限りません。

返金と売上取消を別々に管理するシステムでは、片方だけ処理されるミスが起こりやすくなります。

失敗例3｜提供者への入金をすべて手作業にする

取引数が少ないうちは、表計算ソフトで売上を集計して振り込む方法でも対応できます。

しかし、提供者や取引が増えると、金額の集計、振込先の確認、返金反映などの負担が大きくなります。

将来的に自動化する可能性がある場合は、初期段階から取引と売上データを分けて保存しておきましょう。

失敗例4｜決済会社の管理画面だけで運用する

決済会社の管理画面には、サイト内の案件名、予約内容、取引経緯などが十分に表示されないことがあります。

決済データとサイト内の取引データを必ず紐付けて管理します。

決済ID、取引ID、購入者、提供者、金額、ステータスを自社管理画面で確認できる設計が必要です。

サイトの種類別に適した決済設計

同じマッチングサイトでも、収益モデルと提供者への入金有無によって適した決済設計は異なります。

サイトの種類だけでなく、契約から取引完了までの流れを見て決済方法を選びます。

マッチングサイトの決済に関するよくある質問

マッチングサイトに決済機能は必須ですか？

必須ではありません。

問い合わせ後に利用者同士で直接契約・支払いを行うサイトであれば、サイト内決済を設けない方法もあります。ただし、成約手数料を徴収する場合や、サイト内で取引を完結させる場合は決済機能が必要です。

通常のStripeとStripe Connectは何が違いますか？

通常のStripeは、主に運営会社自身が料金を受け取る決済に向いています。

Stripe Connectは、複数の提供者が参加するプラットフォームにおいて、提供者登録、手数料徴収、売上の振り分け、提供者への入金などを管理するためのサービスです。

仮払いとエスクローは同じですか？

同じとは限りません。

サービス内で提供者への売上確定を遅らせる設計と、法的な意味でエスクローサービスを提供することは別の問題です。契約関係や資金の保持方法を確認し、決済会社や法律の専門家へ相談する必要があります。

決済機能はサイト公開後に追加できますか？

追加できますが、取引データや会員権限、管理画面の作り直しが必要になる場合があります。

将来的に成約手数料や売上分配を導入する可能性がある場合は、初期設計の段階で開発会社へ伝えておくことをおすすめします。

まとめ｜決済機能は資金の流れから設計する

マッチングサイトの決済では、クレジットカードや銀行振込といった支払方法だけを決めても、十分な設計にはなりません。

重要なのは、次の点です。

• 誰が料金を支払うのか
• 誰が売上を受け取るのか
• 運営手数料をいつ差し引くのか
• どの時点で取引完了とするのか
• キャンセル時にどのように返金するのか

決済会社を選ぶ前に、誰から料金を受け取り、誰へ売上を支払うかを決めましょう。

提供者への入金がない場合は通常のオンライン決済で対応できることがあります。一方、提供者ごとの売上管理や入金がある場合は、Stripe Connectなどのプラットフォーム型決済を検討する必要があります。