こんにちは、Merpay の Payment Core チームで EM をしている komatsu です。普段はメルカリグループ全体の決済基盤や銀行接続まわりを担当しています。
この記事は Merpay & Mercoin Advent Calendar 2025 の 19 日目の記事です。
年末ということで、今回は Payment Platform がこの 1 年で取り組んできた 2 つの大きな進化の方向性を振り返ります。1 つは Checkout Solution による統合決済体験の提供、もう 1 つは 2B (法人向け) 決済への展開です。
背景: 決済ニーズの多様化
メルカリグループでは、C2C マーケットプレイスを起点としながらも、さまざまなプロダクトが展開されています。メルカリShops やメルカリNFT、さらには直近リリースしたメルカリ グローバルアプリなど、2C の提供先が広がると同時に、スキマバイトアプリであるメルカリ ハロや広告事業であるメルカリAds、外部事業者がメルカリの商品をオファー経由で購入・再販する C2B (Consumer-to-Business) パートナーシップなど、2B の決済スキームも登場し、多様化しています。
Payment Platform は、こうした多様な決済ニーズに応えるため、これまでマイクロサービスアーキテクチャによる決済基盤を構築し、gRPC API を通じて各プロダクトに決済機能を提供してきました。
この 1 年では、さらに 2 つの軸で大きな進化を遂げています。
Checkout Solution – UI を含む統合決済ソリューションへ
背景: gRPC API を超えた、統合ソリューションという選択肢
従来、Payment Platform は gRPC API を通じて決済のバックエンド機能を提供していました。各プロダクトチームは、この API を利用して独自に決済フローや UI を実装していました。
この方式は柔軟性が高い一方で、いくつかの課題もありました。
- 開発負荷の重複: 新しい決済手段を追加する際、各プロダクトが個別に UI や決済フローを実装する必要がある
- UX の分断: プロダクトごとに決済体験が異なり、統一された UX を提供しにくい
- ローンチ速度: 新規プロダクトが決済機能を実装する際、フロントエンドからバックエンドまで一から構築する必要がある
これらの課題を解決するため、gRPC API に加えて、UI を含む統合決済ソリューションという新しい選択肢を提供し始めました。これが Checkout Solution です。
Checkout Solution のアーキテクチャ
Checkout Solution は、決済のフロントエンド (UI) とバックエンド (API) を一体として提供する統合ソリューションです。
上図のように、プロダクトは Checkout Solution の UI を組み込むだけで、決済手段の選択から決済完了までの体験を提供できます。バックエンドでは Payment Service をはじめとする既存の決済基盤と連携し、各決済手段の処理を実行します。
詳しいアーキテクチャについては、以下の記事をご覧ください。
プロダクトチームは Checkout Solution を組み込むだけで、決済フローや UI を一から実装する必要がなくなりました。新しい決済手段の追加も、Payment Platform 側で対応すれば全プロダクトで使えます。
従来のプロダクトは引き続き gRPC API を使いながら、新しいプロダクトは Checkout Solution で迅速な開発とリリースを実現しています。
展開の歩み
メルカリNFT での初導入
Checkout Solution は、まずメルカリNFT で初めて導入されました。新しいプロダクトのローンチにあたり、MVP として決済機能を素早く統合できることが実証されました。ユースケースごとの設定の切り替えや、プロダクト固有のコンポーネントの描画も含め、基礎となる機能が実現できました。
メルカリ グローバルアプリへの拡大
その後、先日公開されたメルカリ グローバルアプリでも Checkout Solution のサポートが始まりました。
グローバルアプリでは、日本のお客さま向けに提供しているメルペイの残高やポイント、メルペイのあと払いといった決済手段ではなく、海外のお客さま向けのクレジットカード決済機能を新たに開発しました。Cross Border (XB; 越境販売) 事業に必要な決済機能も、Checkout Solution を通して提供することでスピーディーに立ち上げることができました。
こうして、異なるプロダクト間で統一された決済体験を提供できるようになりました。
また、このタイミングは Payment Platform にとって初めての日本円以外の決済ユースケースでした。
日本円前提だったシステムの多通貨対応も行い、決済やその裏にある会計や帳簿も含めて今後のグロースに耐えうる基盤に進化を遂げました。
多通貨対応の詳細は近日公開予定の Guest post from FT payment platform — Engineering for Multi-Currency and Multi-Provider Payments をお楽しみに。
メルカリモバイルへの導入、サブスクリプション対応: Mandate の導入
グローバルアプリとは別の新しい導入先として、既存のメルカリモバイルの決済方法登録画面の置き換えも行いました。
これまでとは異なり、サブスクリプション型の決済スキーム対応のため、お客さま不在時に自動課金を行うための決済手段選択モードを追加し、Mandate (継続的な課金への同意) という概念を導入しました。これにより、タイミングに依らないより自由な決済スキームの構築が可能となりました。Mandate の詳細設計については以下の記事をご覧ください。
2C から 2B へも拡張可能なアーキテクチャ
また、Payment Platform には以前から、メルカリShops やメルペイ加盟店向けの 2B 精算の仕組みがありました。とはいえ、これらは法人が決済すると言うより、お客さまの決済によって資金が移動する先、というユースケースにとどめていました。そこにメルカリ ハロやメルカリAds が登場し、法人自身が決済を行うケース^1も出てきたことで、2B 決済のニーズがさらに多様化してきています。
Checkout Solution は現在 2C をメインに展開していますが、将来的にはこうした 2B 向けの決済でも活用できるアーキテクチャになっています。
Payment Platform があらゆる決済の裏側に加えて、カスタマイズ可能な UI も提供することで、新しい決済手段を追加するたびに各プロダクトが個別に開発する必要がなくなり、統一した UX をお客さまや加盟店に届けられます。
2B 決済への展開
2C 決済と 2B 決済の違い
Checkout Solution でも 2B プロダクトのサポートを視野に入れているように、メルカリ ハロやメルカリAds をはじめとして、メルカリグループでは 2B の決済ニーズも増えています。
2B の決済体験を考えるうえで重要なのは、2C との違いを理解することです。
特に 2C と 2B では、アカウントや決済の座組が大きく異なります。
2C: シンプルな構造
- 1 人 = 1 アカウント
- 与信、請求、決済の単位が基本的に一致
2B: 複雑な構造
- 法人の下に支社・店舗・部署が存在し、木構造での管理が必要
- 与信、請求、決済の単位が異なる場合がある (例: 与信は店舗別、請求は支社単位)
- 座組が複雑で、柔軟な対応が求められる
- インボイス制度など 2B 固有の要件が存在
2B 決済のユースケース
メルカリグループでは、すでにいくつかの 2B 決済のユースケースが存在しています。
メルカリ ハロ
「メルカリ ハロ」では事業者掛け払いというスキームを提供していました。メルカリが事業者の代わりにクルーに仕事完了時に給料を支払い、月末締め翌月払いで事業者から給与および手数料を回収する仕組みです。
詳しくは以下の記事をご覧ください。
メルカリAds
メルカリAds では、パートナー企業の広告をメルカリアプリに掲載し、月末締め翌月払いを請求書経由で行う仕組みを提供しています。
C2B 決済
C2B パートナーシップでは、外部事業者がメルカリの商品をオファー経由で購入・再販するビジネスモデルを提供しています (大黒屋とのパートナーシップ事例)。
メルカリ出品者が販売しても売れ残った商品に対して、パートナー企業から買取リクエストが送信されます。出品者が承諾すると、メルカリが出品者から商品を購入し、その後パートナー企業に販売する C2B モデルです。
パートナー企業からメルカリへの決済は、与信に基づくオファーで与信枠内で行われ、月末締め翌月払いで請求されます。現在、パートナー数が限定的であることから与信枠の管理は Finance チームがスプレッドシートを中心に手動で行っています。
2B 決済基盤に求められる要素
2B の決済基盤、特に事業者請求払い (掛け払い) のような与信を伴う決済では、以下の要素が不可欠となります。
上図のように、決済から入金、会計処理まで一連のフローを支える必要があります。
- 決済および債権の管理: 決済実行と売掛金の計上
- 与信管理: 事業者ごとの与信枠の設定と残高管理、木構造での柔軟な管理
- 請求書の発行・送付・消込: 適格請求書の自動発行と送付、入金管理と売掛金の消し込み (入金消込)、事業者ごとに異なる管理単位への対応
- 入金の受け取り: 入金管理
- 精算処理: 月次での精算と会計処理
- 督促: 未払いに対する督促処理
これまでの取り組み
Payment Platform では、これらの要素を段階的に構築してきました。
外部サービスの活用
メルカリ ハロやメルカリAds のローンチ時には、外部企業が提供する掛け払いサービスを採用しました。ローンチの速度や与信管理の容易性・貸倒リスクを加味した結果、与信審査や貸倒リスクを外部に委譲し、スピーディーにビジネスを立ち上げることにフォーカスしました。Payment Platform としては、これまでの決済 API のインターフェースを保ったまま法人の与信を利用した決済手段である Invoice Payment を Payment Service に導入しました。
一部内製化と手動運用の組み合わせ
メルカリAds では一部の企業に対して、外部サービスを使わない内製掛け払いソリューションを提供しました。決済時に Debt Service で債権を計上し、月次で Settlement Service を通じて精算する仕組みです。利用先を限定していたため、請求書の発行や消込は手動運用で対応しました。このタイミングでは、中長期の内製化や掛け払いプロバイダの多様化を見越して、外部サービスの掛け払いを利用する場合と内製掛け払いを利用する場合を抽象化した概念として Invoice Payment API を提供しました。
この取り組みにより、既存の Payment Service と Debt Service を活用した 2B 決済の基礎が築かれました。
Invoice Service のローンチ
2025 年には、2B に対する請求書の発行・管理・送付などを行う Invoice Service システムをローンチしました。これはメルカリAds やその他 2B プロダクトで内製掛け払いに移行していく際に必要となるだけでなく、メルカリ – メルペイ間の精算など、他のビジネスでも利用するための基盤として構築されました。
ここまでで実現できたこと
これまでの取り組みにより、事業者請求払いに必要な要素のうち、以下がシステムとして整いました。
- ✅ 決済トランザクションの管理 (Payment Service)
- ✅ 債権の管理 (Debt Service)
- ✅ 請求書の発行・送付・消込 (Invoice Service)
- ✅ 精算処理 (Settlement Service)
- ✅ バーチャル口座 (Virtual Account) による入金管理 (Bank Service)
- ❌ 与信管理 ← まだシステム化されていない
- ❌ 督促 ← まだユースケースがない
重要なのは、これらの多くがこれまでのメルカリのプロダクトのために構築した既存マイクロサービスを活用できている点です。汎用性の高い設計が、新しい決済スキームへの迅速な対応を支えています。
これから: 与信管理の内製化
前述の通り、現在 C2B の与信枠は Finance チームがスプレッドシートで手動管理しています。パートナー数が限定的な間はこの運用で対応できていますが、規模拡大に向けてシステム化が必要です。
手動管理では与信残高の即時更新が困難で、ヒューマンエラーのリスクや運用負荷が増大します。また C2B、メルカリAds など複数プロダクトで独自に与信管理を行うと、メンテナンスコストが増大し一貫性も保ちにくくなります。同じ法人が複数プロダクトを利用する場合、与信枠の重複管理や過剰付与のリスクもあります。
与信管理サービスのシステム化
これらの課題を解決するため、統一的な与信管理基盤をシステム化する計画があります。与信管理サービスとして、リアルタイムの与信残高照会・更新、複数事業で再利用可能な汎用設計、法人・支社・店舗といった木構造での柔軟な管理、既存決済基盤との一貫した会計処理を提供していく予定です。
与信管理が内製化されると、以下のように Payment Platform のマイクロサービス群が連携して 2B 決済を支えることになります。
この図から見えるのは、既存マイクロサービスと新規サービスを組み合わせて全体のソリューションを構築している点です。
これまでに構築してきた Payment Service、Debt Service、Settlement Service、Bank Service といった共通サービスは、それぞれが明確なドメイン責務を持つため、新しいユースケースでもそのまま活用できます。2B 特有の与信管理や請求書発行だけを新しいサービスとして追加し、請求書送付には Payment Platform 外の Notification Service を活用します。
各サービスは API を通じて疎結合に連携し、Payment Service が決済のオーケストレーションを担うことで、全体として 2B 決済ソリューションを実現しています。このアーキテクチャにより、新しい決済スキームにも柔軟に対応できる拡張性を持っています。
Payment Platform が目指す姿
Payment Platform は、メルカリグループにおける既存サービスのグロース・新規サービスのローンチを簡単に・早く・効率的にできるようにすることを目指しています。
- スピード: 新規プロダクトが決済機能を素早く統合できる
Checkout Solution のような統合ソリューションを提供することで、プロダクトチームは決済フローや UI を一から実装する必要がありません。 - 効率: 各プロダクトの開発負荷を削減
新しい決済手段を追加する際、Payment Platform 側で対応すれば、すべてのプロダクトで使えるようになります。各プロダクトが個別に実装する必要がなくなり、開発効率が向上します。 - 一貫性: 統一された UI/UX の提供
UI を含む統合ソリューションを提供することで、異なるプロダクト間でも統一された決済体験を届けられます。 - 拡張性: 2C から 2B まで、あらゆる決済シーンをカバー
2B の決済ニーズをキャッチしながら機能を育て、汎用的なソリューションにすることで、メルカリグループの多様な決済ニーズに応えていきます。
まとめ
この 1 年、Payment Platform は 2 つの大きな軸で進化してきました。
1 つ目は Checkout Solution による統合決済体験の実現です。gRPC API に加えて、UI を含む統合ソリューションという新しい選択肢を提供することで、プロダクトチームの開発負荷を削減し、統一された UX を提供できるようになりました。また、多通貨対応も合わせて行い、今後のグローバルなプロダクト展開に耐えうる決済基盤の仕組みも加わりました。
2 つ目は 2B 決済への展開という新たな挑戦です。2B 決済は始まったばかりの領域ですが、既存の 2C で培った強固なマイクロサービス群を活用しながら、段階的に基盤を構築しています。与信管理サービスによる与信管理の内製化により、2B 決済基盤が完成に近づいていきます。
Payment Platform は、これまで多様な決済ニーズに応えてきた実績を基盤に、今後もメルカリグループの成長を決済で支えていきます。
明日の記事は kobaryo さんです。引き続きお楽しみください。
関連記事
