本件のお客様は、対面でサービスを提供する施術者と、それを利用する方をつなぐマッチングサービスを提供される事業者様です。
本案件では、利用者による施術者の検索・予約リクエストから、施術者側の受諾、オンライン決済、施術後の売上の送金、相互レビューまでを、ひとつのサービス内で完結できるマッチングプラットフォームを新規開発しました。決済代行サービスとAPIで連携し、利用者からの集金と施術者への支払いを、システム上で自動的に処理できるようにしています。
本記事では、開発前の課題、提案したアプローチ、実装した主な機能、そして開発で苦労した点を整理してご紹介します。
今回のポイントは、利用者・施術者・運営者という立場の異なる三者が同じサービスを使うなかで、それぞれに必要な情報と操作だけを見せ、予約から決済・送金までのお金の流れを、人手を介さずに自動で回せる仕組みを実現したことです。
開発前の課題
このサービスには、施術者を探して予約したい「利用者」、対応できる日時やメニューを提示して依頼を受けたい「施術者」、そして両者の間で発生するお金とトラブルを安全に管理したい「運営者」という、立場の異なる三者が関わります。三者それぞれで求めるものがまったく異なるため、同じサービスの中に、立場ごとの画面と操作を用意する必要がありました。
また、施術という性質上、実際に会う前の本人確認や、当日の連絡手段、そして「予約したのに来ない」「約束と違った」といったトラブルへの備えが欠かせません。お金を先に受け取り、施術が終わってから提供者へ支払うという流れを、手作業の集金・振込で回すのは現実的ではありませんでした。
加えて、施術者ごとに対応できるエリアや提供メニュー、稼働できる時間帯が細かく異なります。利用者が「近くで・希望の日時に・受けたいメニューを対応してくれる人」を探せるようにするには、これらの条件を掛け合わせて絞り込める仕組みが必要でした。
ご提案・開発アプローチ
まず、利用者・施術者・運営者それぞれに独立したログインとダッシュボードを用意し、同じサービスでありながら、立場ごとに見える画面と権限をはっきり分ける設計としました。互いの操作が混ざらないよう、それぞれのログイン状態を独立して管理しています。
お金の流れは、決済代行サービスとの連携を軸に組み立てました。予約が確定した時点で利用者から先に決済し、施術が完了したあとに手数料を差し引いて施術者へ送金する、という流れをシステム側で自動的に処理します。キャンセル時の返金も、条件に応じて自動で行えるようにしています。
本人確認にはSMS認証を、当日の連絡やお知らせにはメッセージアプリ連携を組み合わせ、会う前の安心と、会うまでの連絡のしやすさを両立させました。予約は「利用者からのリクエスト → 施術者の受諾」という二段階とし、施術者が内容を確認したうえで引き受けられる導線としています。
実装した主な機能
- 利用者・施術者・運営者それぞれの登録・ログイン・管理画面
- SMS認証による本人確認登録
- エリア・メニュー・日時での施術者検索、お気に入り登録
- 予約リクエストの作成と、施術者による受諾・辞退
- 施術者ごとのスケジュール・対応エリア・提供メニュー管理
- オンライン決済・キャンセル時の返金処理
- 施術完了後の売上集計と、施術者への自動送金・再送金
- 利用者と施術者のチャット（予約前の相談・予約後のやり取り）
- 施術後の相互レビュー
- ブロック・ブラックリストによる利用制限
- メッセージアプリ連携（ログイン・お知らせ配信）
- 各種通知メールの自動配信
開発で苦労した点
立場の異なる三者を、ひとつのサービスに同居させる
今回の開発でもっとも設計に神経を使ったのが、利用者・施術者・運営者という三者のログインと権限の切り分けです。同じサービスの中で三者が同時にログインすることもあり、片方の操作がもう片方に影響してはいけません。
たとえば、ある立場でログアウトしたつもりが、別の立場のログイン状態まで一緒に切れてしまう、といった事故が起こり得ます。そこでそれぞれのログイン状態を完全に独立して管理し、操作が互いに干渉しない構造としました。どの立場で操作しているのかを常に意識しながら、画面・権限・通知の出し分けを一つずつ積み上げています。
「お金を預かって、後から渡す」流れを安全に回す
先に利用者から決済し、施術後に施術者へ送金するという流れは、途中で失敗すると「お客様からはお金をもらったのに、施術者へ渡せていない」という事態を招きかねません。外部の決済サービスと連携する以上、通信の失敗や一時的な不調は避けられないからです。
そのため、決済サービスからの通知を受け取って状態を確実に記録し、送金が失敗した場合には自動で再送金を試みる仕組みを用意しました。お金に関わる処理は、失敗することを前提に、あとから追跡・やり直しができる形にしておくことを重視しています。
会う前の安心をどう担保するか
実際に人と人が会うサービスであるため、本人確認とトラブル対応の設計は特に慎重に進めました。登録時にはSMSで本人確認を行い、いたずらや重複登録を防いでいます。
それでも合わない相手は出てくるため、利用者・施術者の双方から相手をブロックできる機能や、運営者が問題のある利用者を制限できる仕組みも用意しました。マッチングサービスは「つなぐ」機能だけでなく、「安全につなげない相手を止める」機能まで含めて初めて成立するというのが実感です。
まとめ
施術者と利用者をつなぐマッチングプラットフォームの開発事例では、立場の異なる三者を安全に同居させ、予約から決済・送金までのお金の流れを自動で回す仕組みを整えたことがポイントです。
複数の立場が関わるサービスや、外部の決済サービスと連携してお金を扱う開発では、正常に進む場合だけを考えていては動きません。失敗したときにどう追跡し、どうやり直すかまで含めて設計することを重視しました。
同様に、マッチングサービスや予約・決済を伴うプラットフォームの開発をご検討の際は、お気軽にご相談ください。
