Merpay & Mercoin Tech Fest 2023 は、事業との関わりから技術への興味を深め、プロダクトやサービスを支えるエンジニアリングを知ることができるお祭りで、2023年8月22日（火）からの3日間、開催しました。セッションでは、事業を支える組織・技術・課題などへの試行錯誤やアプローチを紹介していきました。
この記事は、「メルコイン決済基盤の実践話」の書き起こしです。
@foghost：皆さん、こんにちは。これからのセッションは、2023年3月にリリースされたメルカリアプリでのビットコインの取引の裏側にある、「メルコインの決済基盤の実践話」を紹介します。
まず、簡単に自己紹介します。私はJunwei Liangと申します。社内では、@foghstとも呼ばれています。
2016年11月にメルカリに入社し、メルペイの立ち上げ時期から決済基盤の開発に関わってきました。現在はEngineering HeadとしてValue Circulation Platformチームでメルカリグループ全体の各事業を支えるためのビジネス基盤の開発・運用をしています。
私たちのチームでは、「プロダクトチームにとってベストチョイスとなる基盤をプロダクトとして提供する」ことをビジョンとして掲げています。
具体的には、本日紹介する決済基盤や加盟店管理、KYC、カスタマーサポートなどの基盤をプロダクトチーム向けに提供しています。
そして本日のセッションの内容は、このようになります。最初に軽く全体の概要を紹介し、三つのドメインについてそれぞれ話します。
こちらは、決済基盤の概要です。ご覧のように、中は独立した二つの決済基盤にわかれています。右側は、メルペイの決済基盤です。メルカリのフリマアプリやメルカリShops、メルペイの各種決済手段に対応するための決済機能を提供しています。左側は、メルコインの暗号資産取引サービス向けの決済基盤です。
なぜ二つにわかれているかというと、メルコインの暗号資産取引の事業には、最初はセキュリティとITリスク観点での要件から、システムのインフラから開発運用を全部既存のシステムと切り離すという判断があったからです。
そのため、既存の決済基盤から機能を提供できなくなり、メルコイン専用の決済基盤を再構築しました。メルコインの決済基盤は、赤色の決済処理・台帳管理・帳簿管理という三つのドメインで構成されています。
私たちが提供している決済基盤における決済の定義は、「さまざまな決済取引において参加者たちのお財布を操作して、価値の移転・交換を行う」こととしています。
メルコインにおいては「暗号資産取引においてお客さまの取引口座、暗号資産口座などの財布を操作して、価値の移転・交換を行う」ことを決済と言います。
中でも最も基本となるのが、お客さまが持っている口座や口座の中で管理される価値の変動などの管理です。これを私たちは「台帳管理」というドメインで整理しています。
メルコインのお客さまが持っている口座の種別はこのようになっています。まずメルコインのお客さまは、基本メルペイを利用しているお客さまなので、メルペイ側の口座としてはメルカリのポイント口座またはメルペイの資金の口座を持っている状態です。
メルコインのサービスを利用し始めると、メルコインの法定通貨を扱う取引口座として暗号通貨ビットコイン（以下、BTC）を扱う暗号資産口座が作られます。ちなみにここのBTC口座は、あくまでもシステムの中の口座の話で、ブロックチェーン上のウォレットではないです。
これらの口座を操作するときに、価値の変動を記帳します。方法は二種類あります。
一つは、単式です。例えば、お客さまがメルコインでメルカリのポイント1000円と、メルコインの取引口座の残高1000円を利用してBTCを2000円分を購入するというユースケースがあげられます。
この場合、決済処理のところからそれぞれメルカリのポイントを引いて、または台帳サービスから1000円を引いて、最後にまとめて2000円のBTC付与を台帳サービスに記帳します。
この記帳方法では、取引におけるお金の移動については、移動元の口座と移動先の口座でそれぞれ単独で操作・記帳しています。
また、単独のため、ある口座のお金がどこから入った・出たなどの追跡はできないようになっています。先ほどの例では、2000円分の内訳は追跡できません。
もう一つの記帳方法は、私たちは複式と読んでいます。台帳に連携する際に、移動先と移動元をセットで操作・記帳します。
例えば、取引口座の1000円を引いて、コインBTC1000円を付与した場合、先ほどと違って、1000円の取引口座の残高消費と1000円のBTC口座の付与は一つの記帳処理として台帳に連携され、台帳で二つの口座を同時に操作・記帳することになります。
取引におけるお金の動きについては、移動先・移動元の口座は必ずセットで操作され、台帳に記帳されます。お金の出入りについて、移動先・移動元を追跡できます。
メルコインの台帳サービスでは、複式記帳を採用しています。例えば先ほどの例で言うと、取引口座の1000円を引いてBTC1000円分を購入した場合は、上流から台帳に記帳のリクエストを投げ、台帳システムのTransaction Layerでインプットを受け取り、そこで指定された口座を扱ってそして該当する金額分の価値の交換処理を行います。
価値の交換によって口座の内容が変動するのですが、変動ログなどを保存するため、口座の裏側にログやスナップショットなどの細かいデータが作られています。
複式記帳法については、一つ課題があります。
メルコインの台帳システムで管理してない口座を操作する時に、メルカリポイントだとメルペイの決済基盤で管理されてますので、メルコインの台帳システムでは、口座としては置いていません。
複式記帳する際に口座がないので、本当は実現できないのですが、記帳の実態がない内部口座を設けて今処理してます。
例えばメルカリポイントであればメルカリポイントの預かり金口座を、メルペイの残高であれば、メルペイの残高の預り口座を用意しています。そして、メルコイン自身でお客さまにBTCを付与するキャンペーンがあるときは、費用負担の口座も作っています。
また、複式を採用すると、口座の種別が2倍になる可能性もあるので、口座を増やすときに、随時開発が必要になる、生産性が低い仕組みになってしまいます。
そこで私たちが行ったのが、Configurable Value Accountの仕組みの導入です。基本全ての口座のデフォルトの動きが一緒なんですけど、それぞれの口座の特性によって特殊な動きが発生するときに、それを属性として定義・コントロールします。
すると、新しい口座が作られるときに既存の口座で提供している動きであれば、Configを書けば、あんまり実装コストをかけずに、機能を提供できます。
次に、決済処理について説明します。お客さまが持っている、内部もしくは外部の口座を操作して価値交換を行うところを決済処理と定義しています。
そしてシステムを跨いでも決済処理をするので、複数のサービスを跨いだ際の整合性担保も、重要な役割です。
機能としては、このように、メルコインでは価値交換という形で決済のスキームを抽象化して、提供しています。メルペイでは決済の取引に参加しているお客さまの種別や口座種別、サポートするアクションによって、決済APIを分けて対応しました。
メルコインでは、もう一段階抽象度を上げて、相手同士で持っている口座が価値交換という形で決済処理できるよう機能を提供しています。
メルコインでの取引は基本、お客さま自身が持っている口座間になるので、相手はお客さまです。そしてお客さまが持っている各種口座からお客さまのある口座に価値を交換してあげることを、この価値交換APIを通して実行できます。
サポートする処理としては、上流側で即時で確定したい場合は、即時確定モードを使ったり、条件をクリアした後に確定処理をしたいというニーズであれば、仮処理してから確定sよりを行う2 Phaseの処理もできるように機能設計しています。
BTC購入のユースケースを例に説明します。お客さまに提示している価格などの条件を使って、実際の取引の約定処理をするのが上流の暗号資産取引を担当するサービスです。約定処理の中で決済処理を担当するサービスにお客さまが持っている取引口座やメルカリポイント口座を表記させるという依頼を、APIを通して依頼を投げてきます。
上流側で約定を確定したタイミングで、ここで定義している確定処理を呼べば、取引口座やメルカリポイント口座から押さえた残高を確定し、最終的にお客さまの暗号資産口座にBTCを付与します。
続いて、BTC売却を例にお話しします。先ほどとは逆に、お客さまが持っているBTC口座からBTCを消費し、上流側の取引が約定確定したら、確定処理を行って、最終的にBTCが消費され、お客さまの取引口座に該当する金額分の売上残高が付与されます。
もう一つのトピックとしては、複数のサービスをまたいで決済処理を行うので、分散型のトランザクションをハンドリングする必要があります。これについては既存のメルペイでも同じ課題がありました。メルコインでは、この課題について新しい取り組みをしてきました。
参考記事
マイクロサービスにおける決済トランザクション管理
メルコイン決済基盤における分散トランザクション管理
メルコインの決済サービスの開発と一緒に、社内の他のチームでも汎用的に使えるワークフローのSDKを開発しました。SDKを使えば、通常のプログラミングと同じ体験でワークフローの関数を定義すれば、ワークフローのロジックを組み立てることができます。
そして、一つの決済処理を複数のActivityに分解して、ロールバックが必要なエラーが発生したら、右側の補償処理をActivityとして定義すれば、自動的に実行し、最終的に決済処理の結果整合性を担保する仕組みです。こちらの詳細について別のセッションでチームメンバー（@susho）から詳しく紹介してくれます。
参考記事：メルコイン決済マイクロサービスのトランザクション管理を支える技術
もう一つのトピックは、メルコインではマイクロサービスを跨いだ整合性担保をProcessing Tracerという仕組みを使って担保しています。
この仕組みを使うと、各マイクロサービスで今まで独自でバッチなど実装している処理が全部共通の仕組みでイベントベースで処理されます。
また、突合する結果もProcessing Tracerに報告が求められるので、報告のレポート
がProcessing Tracerにシングルソースとして集められます。
そうすると、例えば会計帳簿のところで仕分けする時に、後で手戻りがないように、一つの処理の会計データに対してその処理の突合が終わっているかどうか確認した上で処理できます。
最後に帳簿管理のドメインについても説明します。具体的には、会計および法定帳簿の管理の話です。
帳簿と台帳との定義の違いは、独自で定義している部分もありますが、一応どちらも取引におけるお金の変動・流れを記録するためのものです。
台帳と私たちが呼んでいるのが、プロダクトサイド向けにお客さまが持っている口座の価値の増減や移動の管理を行っているものです。それ以外の目的で、お金の移動・流れを記録するものを帳簿と定義してます。
具体的には、会計処理するための帳簿が会計帳簿、法定要件を守るための帳簿を法定帳簿と定義しています。
最初に、会計帳簿連携の話をします。メルペイでは、社内に共通の会計サービスがあるので、会計要件が発生するときに、各マイクロサービスから必要に応じて必要な会計イベントを定義して、会計サービスに連携しています。
またメルペイの台帳サービスは単式記帳を採用しているので、片側しか取れてないので会計連携にするためにデータが不足しています。
既存のメルペイの手法にはこれらの課題を感じています。
一つは、各マイクロサービスについて必要に応じて会計連携すると、システムや会計のドメイン知識が必要なので、特に決済基盤で一番コアな決済サービスでは、たくさん決済種別があって、決済種別によって予定会計連携のデータ群の整形が間違っています。すると、会計や運用のコストが高くなります。
また、メルペイの台帳システムは単式記帳を採用しているので、台帳のLayerから会計の連携を全て行うことは現状不可能です。
台帳と会計帳簿はどちらも上流側の決済取引によって発生したお金の動きなので、そこのリコンサイル観点でも細かく実施したいですが、まだ台帳と会計帳簿の連携は今バラバラで、特に記録する時間が各マイクロサービスを処理時刻になってずれることもあるので、正確にはリコンサイルができない状態にはなっています。
それを考慮した上で、メルコインの会計帳簿の連携の仕組みははこのようになっています。
複式記帳を採用した台帳サービスをメルコインは作っているので、取引で発生しているお金の移動元と移動先が台帳サービスの中でも取れている状態です。それを使って、会計仕訳に必要なデータを連携できるようになります。
帳簿サービスは、会計帳簿を行っているところです。会計帳簿という新しい会計のイベントを集めて仕分け処理を行い、会計に欲しい仕分け帳簿などのデータを作るコンポーネントも開発しました。
メルコインが採用している会計連携の仕組みの特徴としては、台帳のサービスのレイヤーのみ会計データの連携をするので、それ以外のマイクロサービスが会計連携の責務は考えなくても良く、開発運用コストは軽くなります。
基本確定された台帳データを使って会計帳簿にデータを連携するので、台帳と会計帳簿のリコンサイルの仕組みも簡単に作れます。
最後に、法定帳簿についても軽く紹介します。法定帳簿は、暗号資産交換業における法定要件を満たすための帳簿データの集計と管理が求められるものです。
「顧客・自己注文伝票」「顧客・自己感情元帳」「分別管理表」などの法定帳簿を集計する必要があります。これらの帳簿を作成するために、同じく帳簿のドメインとして、帳簿サービスの中で、法定帳簿を管理する機能を作っています。
データソースとしては、上流側の暗号資産取引サービスから必要な取引のドメインイベントを集めたり、台帳サービスから提供しているAPIを使って、お客さまが持っている各種口座の変動データを参照しながら、この辺が必要になる法定帳簿の集計を日次で行っています。
最後に、まとめです。本日は、メルコインの決済基盤について紹介しました。
ハイライトとして、複式の記帳手法を採用した新しいの台帳サービスの開発、そしてより汎用的に利用できる価値交換の決済機能を提供する決済サービスの開発、整合性を担保をするために、ワークフローのSDKやProcessing Tracerの新しい仕組みの取り組みも行いました。
最後に、会計および法定帳簿の管理をするための帳簿サービスの開発も、プロダクトサイドで行いました。
これからのチャレンジとしては、メルコインで、実践した経験を生かして、メルペイ側の決済基盤もこれから進化させていきます。また組織横断で、台帳帳簿の決済については共通化できそうなドメインコンポーネントも見えているので、共通化できるシステム設計にもこれから挑戦していきたいです。
以上で本日のセッションを終わりにします。ご清聴ありがとうございました。
