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

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

月額料金やサブスク料金を運営会社が受け取るサイトと、購入代金から手数料を差し引いて提供者へ支払うサイトでは、必要な仕組みが異なります。

決済会社を選ぶ前に、誰から料金を受け取り、誰へ売上を支払うのかを整理することが重要です。

本記事では、月額課金（サブスク）をはじめとする主な課金方法、4つの資金フロー、必要な決済機能、売上分配、セキュリティ、決済代行会社の選び方を解説します。

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

マッチングサイトの決済機能とは、利用者から料金を受け取り、必要に応じて運営手数料を差し引き、提供者の売上や入金まで管理する仕組みです。

すべてのマッチングサイトに、同じ決済機能が必要なわけではありません。

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

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

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

• 商品やサービスを購入する利用者
• 商品やサービスを提供するユーザー
• 取引の場を提供する運営会社

運営会社以外の提供者へ売上を支払う場合は、提供者別の売上、運営手数料、返金、銀行口座への入金も管理しなければなりません。

決済手段・課金方法・資金フローは別に考える

マッチングサイトの決済では、次の3つを分けて整理します。

「カード決済を導入する」と決めても、誰が売上を受け取るかまでは決まりません。

サイト内決済が必要かを判断する

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

一方、サイトの役割を問い合わせや相手探しまでに限定し、契約と支払いを当事者間で行う方法もあります。

ただし、サイト外で支払われると、運営会社は成約金額を把握しにくくなります。

成約手数料を自動で徴収するには、取引と決済をサイト内で紐付ける必要があります。

マッチングサイトの主な課金方法

主な収益化方法には、月額課金（サブスク）、掲載・問い合わせ課金、都度課金、成約手数料があります。

成約手数料型では、取引完了後に提供者の売上を確定する仮払い方式を組み合わせることもあります。

月額課金（サブスク）｜利用権限に対して課金する

月額課金は、サブスクとも呼ばれ、一定期間サービスを利用できる権利に対して継続的に料金を受け取る方法です。

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

サブスク型のシステムには、自動更新、プラン変更、解約、支払い失敗後の再決済、会員権限の変更が必要です。

また、解約手続き後すぐに利用できなくするのか、契約終了日まで有料機能を利用できるのかも決めます。

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

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

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

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

問い合わせ課金では、次のルールを決めます。

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

都度課金｜購入や予約のたびに課金する

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

運営会社が自社の商品やサービスを提供する場合は、通常のオンライン決済で対応しやすくなります。

登録された店舗、講師、出品者などがサービスを提供する場合は、提供者への売上支払いも検討します。

成約手数料｜取引金額の一部を受け取る

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

たとえば1万円の取引で手数料を10％に設定した場合、運営会社の収益は1,000円、提供者の売上は9,000円です。

必要になるのは決済機能だけではありません。

• 取引金額と手数料の計算
• 提供者別の売上管理
• 取引完了と売上確定
• キャンセル・返金
• 提供者への入金

仮払いは課金方法ではなく、決済後に提供者の売上を確定するまでの処理方法です。

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

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

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

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

提供者への売上分配がないため、通常のカード決済や継続課金で対応しやすい構成です。

BtoBマッチング、求人掲載、会員制コミュニティなどに向いています。

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

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

決済システムを簡素化できますが、運営会社は成約金額や支払い状況を把握しにくくなります。

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

ケース3｜手数料を差し引いて提供者へ支払う

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

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

提供者登録、本人確認、手数料計算、売上管理、入金状況の確認が必要です。

ケース4｜取引完了後に売上を確定する

購入者が先に支払い、商品到着、サービス完了、納品・検収などの条件を満たした後に提供者の売上を確定します。

この方式では、次のルールを事前に決めます。

• 何をもって取引完了とするか
• 何日後に自動完了するか
• 異議・紛争が発生した場合の処理
• キャンセル料と返金額
• 提供者売上を取り消す条件

提供者別の売上管理や入金がある場合は、通常決済ではなくプラットフォーム向けの決済サービスを検討します。

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

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

提供者へ売上を支払うサイトでは、提供者側の売上・入金管理も追加します。

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

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

• 購入・申込・プラン選択
• 支払金額と内訳の確認
• 決済方法の登録・変更
• 決済履歴・利用明細
• 継続課金・サブスクの変更と解約

決済前には、商品代金、運営手数料、割引、税額、合計金額を分かりやすく表示します。

提供者側｜売上と入金状況を確認する

提供者には、取引金額だけでなく、手数料を差し引いた後の受取予定額を表示します。

• 取引金額・運営手数料
• 売上確定前・確定済み金額
• 返金・キャンセルによる取消額
• 受取予定額・入金予定日
• 入金済み・入金失敗の履歴

「決済済み」「取引中」「売上確定」「入金済み」は別の状態として管理します。

キャンセル・返金の処理を先に決める

決済機能は、正常に支払われた場合より、取引が中止された場合に設計の差が出ます。

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

購入者への返金だけを行い、提供者売上を取り消さなければ、運営会社が損失を負担する可能性があります。

返金、提供者売上の取消、運営手数料の再計算は一つの業務として設計します。

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

管理画面では、決済会社側の決済IDと、サイト内の注文、予約、案件を紐付けます。

• 購入者・提供者・対象取引
• 決済・取引ステータス
• 運営手数料・提供者売上
• 返金・入金失敗・エラー内容
• 期間指定・CSV出力

決済会社の管理画面を開かなくても、どの取引に問題があるか確認できる状態が必要です。

決済機能に必要なセキュリティ・不正利用対策

決済機能では、カード番号を自社で保持しない構成、EMV 3-Dセキュア、不正ログイン対策、Webhookの検証が必要です。

決済会社を導入しても、自社サイト側のセキュリティ対策が不要になるわけではありません。

カード情報を自社システムへ保存しない

カード番号やセキュリティコードを、自社のデータベースへ直接保存する構成は避けます。

一般的には、決済会社が提供する次の仕組みを利用します。

• 決済会社が提供する決済ページ
• 埋め込み型のカード入力フォーム
• カード情報をトークンへ変換するSDK
• 保存済み決済方法を示す顧客ID・カードID

カード情報を決済会社へ直接送信し、自社サーバーではトークンや決済IDだけを扱う構成にします。

ただし、この構成にしただけで、PCI DSSを含むすべての確認が不要になるわけではありません。採用する決済画面とシステム構成に応じて、決済会社へ対応範囲を確認します。

PCI DSSに関する公式情報

EMV 3-Dセキュアと不正ログイン対策を行う

EMV 3-Dセキュアは、カード発行会社による本人認証を決済へ追加する仕組みです。

経済産業省が2025年3月に公表したクレジットカード・セキュリティガイドライン6.0版では、EC加盟店にEMV 3-Dセキュア、脆弱性対策、適切な不正ログイン対策が求められています。

経済産業省のクレジットカード・セキュリティガイドライン

決済認証だけでなく、会員アカウントの乗っ取りも防ぐ必要があります。

• ログイン失敗回数の制限
• 不審な端末・アクセスの検知
• メールアドレス変更時の通知
• 高額決済や決済方法変更時の再認証
• 不正利用・チャージバックの監視

Webhookの署名と重複受信を検証する

Webhookは、決済成功、返金、入金失敗などを決済会社から自社システムへ通知する仕組みです。

受信した内容をそのまま信用せず、決済会社が送信した通知であることを署名によって検証します。

また、同じWebhookが複数回届くことを前提にします。

• 署名を検証する
• イベントIDの処理履歴を保存する
• 処理済みイベントを重複実行しない
• 失敗したイベントを再処理できるようにする
• エラーを管理画面へ表示する

二重決済を防ぐ

決済ボタンの連続クリックや通信エラー後の再送によって、同じ注文へ複数回請求されることがあります。

対策として、注文ごとに一意のIDを設定し、同じ注文に対する決済処理を重複実行しないようにします。

決済サービスが冪等性キーを提供している場合は、同じ処理の再送でも決済が一度だけ作成されるように実装します。

決済成功だけでなく、重複、通信失敗、不正な通知を前提に設計することが重要です。

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

決済代行会社は、料金だけでなく、事業への対応可否、課金方式、売上分配、入金、セキュリティで比較します。

目的別の候補例は次のとおりです。

対応機能は、契約内容、業種、事業モデル、審査結果によって変わります。サービス名だけで決めず、自社の商材と資金フローを伝えて利用可否を確認します。

事業内容と商材に対応しているか

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

開発前に、次の資料を用意して相談します。

• サービス概要・取扱商材
• 利用者と提供者の属性
• 料金体系・資金フロー
• キャンセル・返金条件
• 利用規約・特定商取引法に基づく表記

サイト完成後に利用できないと判明すると、決済方法や画面の作り直しが必要になります。

必要な課金・売上分配に対応しているか

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

• 都度決済・継続課金・サブスク
• 全額返金・一部返金
• 提供者別の売上管理
• 複数者への分配
• 本人確認・銀行口座への入金

提供者へ売上を支払う場合は、一般的なカード決済ではなく、プラットフォーム向け機能の有無を確認します。

Stripe Connect公式ページ
PAY.JP Platform公式ページ

料金と入金条件を比較する

決済会社の費用は、決済手数料だけではありません。

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

月間決済額、件数、提供者数、入金回数を基に、月間・年間の費用を試算します。

決済手段・API・サポートを確認する

カード以外にも、コンビニ決済、口座振替、銀行振込、キャリア決済、QRコード決済などが必要な場合は、複数の決済手段を扱う決済代行会社を候補にします。

APIの機能だけでなく、次の項目も確認します。

• Webhookとテスト環境
• エラー・不正利用の管理画面
• 仕様変更時の案内
• 障害発生時のサポート
• 審査・導入に必要な期間

UnivaPay公式ページ

決済会社は、料金・機能・審査・運用の4点をまとめて比較します。

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

決済導入の費用は、決済会社へ支払う利用料と、自社システムへ組み込む開発費に分けられます。

決済会社へ支払う費用

主な費用は次のとおりです。

• 初期費用・月額費用
• 決済金額に対する手数料
• 提供者アカウントの管理費
• 提供者への入金・振込費用
• 返金・チャージバック関連費用

提供者数や入金回数が多いサイトでは、決済手数料以外の費用も大きくなります。

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

通常のカード決済やサブスク決済では、決済画面、決済結果、利用履歴、継続課金管理、管理画面などを実装します。

提供者への売上支払いがある場合は、さらに次の開発が必要です。

• 提供者の決済アカウント登録
• 本人確認・利用可否の取得
• 運営手数料・提供者売上の計算
• 返金・売上取消・入金管理
• Webhook・エラーの監視

費用が上がりやすい決済機能

次の機能は、通常のカード決済より開発範囲が広くなります。

• 複数プランのサブスク・日割り計算
• 仮払い・取引完了後の売上確定
• 複数の提供者への売上分配
• 一部返金・キャンセル料
• 有償ポイント・会計システム連携

決済画面だけでなく、取引管理、通知、管理画面まで含めて見積もる必要があります。

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

決済導入は、収益モデルと資金フローを決め、決済会社へ確認してから実装・テストします。

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

最初に、次の内容を整理します。

• 誰が何の料金を支払うのか
• 月額・サブスクか、都度課金か
• 運営会社だけが受け取るのか
• 提供者へ売上を支払うのか
• 誰が販売主体になるのか

資金の流れを図にすると、通常決済とプラットフォーム型決済のどちらが必要か判断しやすくなります。

流れ2｜完了・キャンセル・返金条件を決める

都度課金や成約手数料型では、取引が完了する条件を決めます。

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

サブスク型では、解約受付日、契約終了日、プラン変更の反映時期、支払い失敗時の利用停止条件を決めます。

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

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

確認する内容は、商材、契約主体、料金体系、提供者の属性、売上分配、返金条件です。

サイト完成後ではなく、決済設計が固まった段階で審査・利用可否を確認します。

流れ4｜正常系と異常系をテストする

実装後は、決済成功だけでなく、次の状態もテストします。

• 決済失敗・認証失敗
• 決済ボタンの連続操作
• 全額返金・一部返金
• サブスク更新の失敗・解約
• Webhookの重複・再送・処理失敗

提供者への入金がある場合は、本人確認不足、入金失敗、口座変更、アカウント制限も確認します。

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

主な失敗は、決済審査の後回し、返金と売上取消の不整合、エラーを発見できない管理画面です。

決済審査を開発後に始める

希望する決済会社を利用できなかった場合、決済画面、資金フロー、利用規約を作り直すことになります。

サービス内容、料金、販売主体、返金条件を整理し、開発前に利用可否を確認します。

返金と提供者売上の取消を分けて考えない

購入者への返金と、提供者へ計上した売上の取消は別の処理になることがあります。

返金だけが成功すると、購入者へ代金を返した後も提供者売上が残り、運営会社が損失を負担します。

返金結果を受けて、提供者売上、運営手数料、クーポン、ポイントまで一貫して更新します。

決済エラーを管理画面へ表示しない

決済会社の管理画面だけで運用すると、サイト内のどの注文や予約に問題があるか分かりにくくなります。

管理画面には、次の状態を表示します。

• 決済・返金に失敗した取引
• 重複または未処理のWebhook
• サブスク更新に失敗した会員
• 提供者への入金失敗
• 本人確認・アカウント制限

正常に決済できることだけでなく、失敗した処理を運営者が見つけて直せることが重要です。

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

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

サイトの名称だけで決めず、契約から取引完了までの流れを基に設計します。

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

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

必須ではありません。
問い合わせ後に利用者同士で直接契約・支払いを行う場合は、サイト内決済を設けない方法もあります。

成約手数料を自動で徴収する場合や、サイト内で予約・購入まで完結させる場合は決済機能が必要です。

サブスク型のマッチングサイトに必要な決済機能は何ですか？

サブスク型では、自動更新、プラン変更、解約、支払い失敗後の再決済、会員権限の切り替えが必要です。

解約を受け付けた時点で利用を停止するのか、契約終了日まで有料機能を利用できるのかも決めます。
無料期間を設ける場合は、無料期間の終了日、初回決済日、無料期間中に解約した場合の処理も必要です。

通常決済とプラットフォーム型決済の違いは何ですか？

通常決済は、主に運営会社自身が料金を受け取る方式です。

プラットフォーム型決済は、登録された店舗、出品者、講師などの売上を管理し、手数料を差し引いて提供者へ入金するために使います。

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

同じとは限りません。
取引完了まで提供者の売上確定を遅らせるシステムと、法律上のエスクローサービスは別の問題です。

資金の保持方法、契約関係、入金までの期間を整理し、決済会社と法律の専門家へ確認してください。

カード情報を自社で保存しなくてもセキュリティ対策は必要ですか？

必要です。
EMV 3-Dセキュア、不正ログイン対策、脆弱性対策、Webhookの署名検証、二重決済防止など、自社サイト側で行う対策があります。

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

追加できますが、取引データ、会員権限、利用規約、管理画面の変更が必要になる場合があります。
将来的にサブスク、成約手数料、売上分配を導入する可能性があるなら、初期設計の段階で開発会社へ伝えておきましょう。

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

マッチングサイトの決済では、クレジットカードや銀行振込などの支払方法を選ぶだけでは不十分です。
最初に整理するのは、次の内容です。

• 誰が何の料金を支払うのか
• 月額・サブスクか、都度課金か
• 運営会社と提供者のどちらが売上を受け取るのか
• どの時点で取引と売上を確定するのか
• キャンセル時に何を返金・取消するのか

運営会社だけが月額料金、サブスク料金、掲載料を受け取る場合は、通常のオンライン決済で対応しやすくなります。

提供者別の売上管理や入金がある場合は、Stripe ConnectやPAY.JP Platformなどのプラットフォーム向け決済を検討します。

決済会社を決めた後は、カード情報を自社で保持しない構成、本人認証、不正ログイン対策、Webhook検証、二重決済防止まで設計します。

決済機能は、支払い画面ではなく、課金・サブスク・取引・返金・売上・セキュリティを一つの流れとして構築します。