Merpay & Mercoin Tech Fest 2023 は、事業との関わりから技術への興味を深め、プロダクトやサービスを支えるエンジニアリングを知ることができるお祭りで、2023年8月22日（火）からの3日間、開催しました。セッションでは、事業を支える組織・技術・課題などへの試行錯誤やアプローチを紹介していきました。
この記事は、「メルペイ加盟店売上精算の仕組み」の書き起こしです。
@shiv3：本セッションでは、「メルペイ加盟店売上精算の仕組み」についてお話しします。
最初に自己紹介です。Shibazakiと申します。社内ではSlackネームである@shiv3と呼ばれています。現在、メルペイでソフトウェアエンジニアをしており、2021年9月に入社し、加盟店精算領域の開発を担当しています。現在はそこのチームでテックリードをしています。
アジェンダは、この通りです。主に加盟店精算についての概要と、加盟店精算の仕組みについてお話しします。
加盟店精算は、コード決済・ネット決済のメルペイ加盟店さまが、お客さまから決済を受けたときに、それを月1回および月2回の頻度で入金するために金額を集計して、入金日に合わせて事前に入金指示を行います。
加盟店精算における精算は、クリアリングとセトルメントの二つのステップで行われます。クリアリングは、加盟店さまの未精算の売上や手数料など、過不足なく正確に計算し、最終売上を確定させる処理になります。
セトルメントは、確定した売り上げを加盟店さまに実際に振り込み、もし返金などで、当月中の売上金の赤残が発生する場合、その金額を確定させて、加盟店さまへ請求するというフローです。
メルペイではお客さまには個人と加盟店さまの2種類があり、それぞれのお財布・決済アカウントを管理しています。ここでは加盟店精算で用いる加盟店さまのお財布・決済アカウントのみを紹介します。
まず内部のアカウントとしては、決済をするたびに売上がたまる未精算売上口座および、精算のプロセスが完了した後で確定された売上が入る精算済み売上口座があります。また、売り上げが債権として精算される場合は、精算済み債権口座に入ります。
マイクロサービス全体での精算処理がこのようなフローで行われます。加盟店精算のリクエストが決済サービスに来ると、決済処理を担当するサービスが決済処理を行い、精算サービスは決済サービスからそのイベントを受け取り、イベントをもとにリアルタイムで手数料を発生させ、その後月1回・2回で最終的な売上を確定する精算サイクルです。
次に各ステップを詳しく見ていきます。
精算サービスは、決済イベントを受け取るとリアルタイムで決済サービスにメルペイの決済手数料をリクエストします。
その後、精算サービスは、手数料の決済時イベントも決済サービスから受け取り、清算対象にします。ここで、手数料自体の決済に対しては、再度手数料をかけることしないようにしています。加えて精算サービスは、どの決済に対して手数料を発行を行うか、もしくは各加盟店のためにどういう加盟店やどういう決済に手数料をどうかけるかという設定も管理しています。
次に、決済イベントのデータをもとに、精算用のデータを作成・保存するステップに移ります。
加盟店精算用のデータは、加盟店さまから、および加盟店さまへを対象に、お金の動きをToとFromで管理しています。お客さまから加盟店さまに決済として売上があった場合は、Toの方に加盟店さまのIDを設定し、決済手数料では、Toの方にメルペイ、Fromの方に加盟店さまのIDを設定してします。返金および手数料の返金に関しては、その逆のフローです。
次に、保存した精算用のデータが正しく保存されているかを、他のマイクロサービスと突合を行うリコンサイルという処理を行います。先ほどのステップで保存した取引データを1件ずつ会計帳簿サービスのデータと突合し、突合済みのデータとして更新します。
その後にリコンサイルの取引データを対象に、日時の集計を行います。ここでは、リコンサイルの結果を基に、Xという加盟店が10月3日の売り上げとして300円になったという日次精算のデータを保存しています。
また、集計時に入金集約というパターンが存在します。複数の加盟店の売り上げを一つの振り込み先に集約させるフローで、集計元の加盟店さまの売り上げは、入金先の加盟店さまに対しての一時精算データとして集計します。ここでは子パートナーa・b・cの100円ずつの精算を、親パートナーAの精算金額として保存しています。
その後、月1回・2回の精算サイクルで入金額の集計を行います。ここでは、月1回の精算サイクルで集計する場合を紹介します。
10月1日から10月31日までの日次精算の1ヶ月分のデータを合計し、10月分の売上データとして保存します。ここではSalesSummariesという名前のデータとして保存しています。その後、データを用いて入金額の集計を行います。ここではPayoutsというテーブルに集金額を入れています。
ここで前回の入金が失敗した場合や、繰越設定があった場合は、入金額に前回の分を合算します。
精算サイクルごとに精算データを作成した後は、売上金のクリアリングを行います。未精算売上口座から精算済み売上口座にお金を動かす際、加盟店売上金クリアリングリクエストを決済サービスにリクエストし、精算済みの口座にお金の移動を行います。
ここでは、未精算売上口座にあった5000円を、精算済み売上口座に加算しました。
返金などで当月中の精算サイクル締め期間の売り上げがマイナスになった場合は、赤残と呼んでいます。
精算済み売上金口座にクリアリングを行いましたが、赤残が発生した場合は清算済み債権口座にお金を動かすためのリクエストを発行します。例えば売上金がマイナス2000円になってしまった場合、その2000円は精算済み債権口座に移動させます。
クリアリングのステップの最後に、債権口座と売上口座の相殺処理を行います。ここでは債権口座に2000円、売上金口座に5000円ある場合、それを相殺して精算済み口座に3000円が入る状態にします。
最後に、加盟店さまの入金日に合わせて、売上金のセトルメントと振り込みを行います。クリアリング時に作成した入金金額のデータをもとに、入金日に合わせて決済サービスを通じて、銀行接続サービスから振込リクエストを行います。
入金結果を銀行接続サービスが入金日の後に入金結果を取得し、精算サービスはデータを決済サービス経由で受け取り、入金状態を更新します。ここでは12000円振り込んだので、その金額の結果をPayoutsに保存しています。
最後に、課題についてです。
課題は二つあり、一つ目は加盟店の手数料発行と精算処理が密結合していることです。精算データの作成処理の手数料の発行処理とほぼ同じタイミングで行っている都合上、精算処理のドメインとしては、手数料発行は異なりますが、それぞれの処理が密結合しています。これは、データの作成部分や処理のフローを分離することで対応しようと思っています。
二つ目はリコンサイル時に会計帳簿に依存しており、会計帳簿サービスと決済処理サービス間のリコンサイルに不整合や遅れが発生した場合に、精算に影響が出る可能性があることです。
こちらについてはリコンサイルのためにProcessing Tracingというサービスの導入を進めており、それによって会計帳簿サービスへの依存を減らす方針で進めています。
以上で、今回のセッションを終わりにしたいと思います。ご清聴ありがとうございました。
