メルカリのグローバル展開を支える決済プラットフォームの進化

こんにちは。メルペイ Payment & Customer Platform（PCP）チームの Backend Engineer を務める [@ryuyama](https://me.tychy.jp/) です。この記事は「[Merpay & Mercoin Tech Openness Month 2026](https://engineering.mercari.com/blog/entry/20260528-merpay-mercoin-tech-openness-month-2026/)」の1日目の記事です。 ## はじめに メルカリでは、2025 年 9 月 30 日にグローバル版のメルカリアプリをリリースしました。このアプリは台湾・US をはじめとして、[3 年以内に 100 カ国へ展開することを目指しており](https://engineering.mercari.com/blog/entry/20251007-a09afcd49b/)、メルカリのグローバル展開を加速させるための重要なマイルストーンとなりました。 この記事では、メルカリ グローバルアプリ（以下、グローバルアプリ）のリリースに向けて、Payment Platform がどのような課題に向き合い、どのようにアーキテクチャを進化させてきたのかを紹介します。 ## Payment Platform に課せられたミッション グローバルアプリ対応プロジェクトが立ち上がった際に、Payment Platform に課せられたミッションは、**「3 年以内に 100 カ国展開できる決済・会計システムを作ること」**でした。 そこで、Payment Platform のシステムを大きく「決済」と「会計」のドメインに分け、達成すべきゴールを整理しました。 決済基盤としては、主に以下のような対応が求められました。 - 100 カ国の通貨・決済手段への対応 - 決済画面の多言語対応 - 複数の PSP（決済事業者）との接続 - 為替レートを考慮した金額計算 - 不正利用やチャージバックのリスクへの対応 会計基盤としては、以下のような状態をゴールと置きました。 - 通貨ごと、国・地域ごとの売上、返金、決済手数料を正しく集計できること - PSP（決済事業者）からの入金と、メルカリ側の取引データを照合できること - 在庫変動や税務関連の会計イベントを、外部システムから会計システムへ正しい粒度・タイミングで連携できること - 既存の国内向け会計システムとの整合性を保ちながら、新しい会計基盤へ移行できること また、これらを一度きりのゴールとして実装するのではなく、グローバル展開のコストとスピードを強く意識する必要がありました。例えば、通貨や決済手段の追加をできるだけ迅速に行い、展開国を早く増やせること。不正対策、税務、会計などの各国・地域ごとの最適化を、それぞれ独立して進められることが求められました。 ## Payment Platform の進化 ## 既存の Payment Platform 先ほど掲げたミッションを達成するために、現在のアーキテクチャにある課題洗い出しを行いました。Payment Platform は、日本のメルカリアプリの決済基盤をベースにして誕生し、[メルペイの成長とともに進化してきました](https://engineering.mercari.com/blog/entry/2019-12-21-104948/)。 決済のレイヤーでは、Payment Service というマイクロサービスが存在します。Payment Service では、メルカリで商品を購入し、取引が完了するとお金が移動するという一連の取引を表現した Escrow というリソースや、お金の動きに注目した Charge、さらに 3D セキュアの普及や高度化する決済手段への対応のために [Source](https://engineering.mercari.com/blog/entry/20230613-source-payment/) というリソースが開発されてきました。 会計のレイヤーでは、Balance Service（残高サービス）や Accounting Service（会計サービス）といったサービスが存在します。Balance Service はお客さまの残高や加盟店の売上残高の管理を、Accounting Service は会計イベントの保存と経理向けのレポーティングを責務としています。 ![image](https://storage.googleapis.com/prd-engineering-asset/2026/05/701084ad-blog_0601_1.png) これらはいずれも、これまでのメルカリグループ全体の成長を支えてきた重要なサービスです。 一方で、グローバル対応に向けて、特に「展開コスト」と「展開スピード」という観点において、いくつかの課題がありました。 ## グローバル展開に向けた課題 ## PSP や決済手段の追加に Payment Service が必要 1 つ目の課題は、Payment Service において、PSP（決済事業者）との接続ロジックと Source リソースが密結合していたことです。 グローバル展開では、国や地域によって利用される決済手段が異なります。また、接続すべき PSP も国や地域ごとに変わる可能性があります。 そのため、新しい PSP や決済手段を追加するたびに Payment Service のロジックへ変更が入る状態では、展開国が増えるほど開発・運用コストが増大してしまいます。 また、Source が特定の決済手段と密結合していたため、新しい決済手段を追加する際には、新しいリソース定義や既存リソースへの影響を慎重に検討する必要がありました。 国内向けの決済基盤としては十分に機能していた設計でも、100 カ国展開を前提にすると、決済手段や PSP の追加をより小さな変更範囲で実現できる構成が必要でした。 ## 残高と会計イベントの整合性がアーキテクチャで保証できていない 2 つ目の課題は、残高管理と会計イベントの整合性です。 既存の構成では、Balance Service が残高を管理し、Accounting Service が会計イベントを保存していました。しかし、両者の整合性は会計レイヤー自体で保証されているわけではなく、Payment Service 側のサービス間トランザクション管理に依存していました。 グローバル展開では、通貨ごと、国・地域ごと、PSP ごとの売上、返金、決済手数料を正しく集計できることが求められます。また、PSP からの入金とメルカリ側の取引データを照合できることや、在庫変動・税務関連の会計イベントを外部システムから会計システムへ正しい粒度・タイミングで連携できることも必要になります。 そのため、単に決済処理の結果を保存するだけではなく、後続の照合やレポーティング、既存の国内向け会計システムとの整合性を見据えた会計基盤が必要でした。 この課題は、グローバル対応が始まる以前から、メルカリのグローバルなマーケットプレイスの実現というビジョンに向けての課題だと認識されていました。これらの課題は次世代の会計システムであるBalance V2やBookkeeperとして、[メルコイン](https://engineering.mercari.com/blog/entry/20230614-distributed-transaction/)やメルカリ ハロの立ち上げに合わせて導入され、実運用の中で磨き上げられていました。一方で、メルカリのマーケットプレイスに関連する領域では既存システムからの移行コストが高く、導入の機会を待っている状況でした。 ## 現在のアーキテクチャ Payment Platformでは、グローバル対応に合わせて2つの大きな意思決定を行いました。 1つ目は、PSP（決済事業者）と接続するための処理をPayment ServiceからPSPとの接続を責務とするPayment Provider Serviceに切り出し、PSPとの接続ロジックや決済手段に関するロジックを決済リソース管理から分離することです。 2つ目は、会計システムにBalance V2とBookkeeperを利用し、Payment Serviceのトランザクション管理による整合性の管理から、残高と会計イベントが整合したモデルで扱われるアーキテクチャへ移行することです。 ![image](https://storage.googleapis.com/prd-engineering-asset/2026/05/e4ea5470-blog_0601_2.png) ## Payment Serviceが決済リソースのライフサイクル管理に集中する 新しいアーキテクチャでは、Payment Serviceの責務をより明確にしました。 Payment Serviceは注文や取引に紐づく決済リソースのライフサイクル管理に集中し、決済の作成、オーソリ、キャプチャ、キャンセルなどといった状態遷移を管理します。 一方で、どのPSPのAPIをどのように呼び出すか、各決済手段にどのようなパラメータが必要でPSPから返ってくるレスポンスやWebhookをどのように処理するかといった詳細はPayment Provider Serviceに切り出しました。 これにより、Payment Serviceは特定のPSPや決済手段に強く依存せず、より安定した決済リソース管理の責務に集中できるようになりました。 ## Balance V2 / Bookkeeperで残高と会計イベントの一貫性を担保する 会計基盤には、[Balance V2](https://engineering.mercari.com/en/blog/entry/20241113-designing-a-zero-downtime-migration-solution-with-strong-data-consistency-part-i/)とBookkeeperを利用しました。 Balance V2 と Bookkeeper では、残高の変動と会計イベントを一貫したモデルとして扱います。これにより、残高更新と会計イベントの記録が別々のデータとして管理されるのではなく、複式簿記のように、「現在の残高（ストック）」と「残高が変化した理由（フロー）」を対応づけて保存されるようになりました。 このアーキテクチャにより、Payment Service 側で残高と会計イベント間の整合性を保つ複雑なサービス間トランザクション管理を担う必要が減り、Payment Service は決済リソースの管理により集中できるようになりました。 ## 終わりに 今回のプロジェクトでは、グローバル展開に必要な決済・会計基盤の土台を作ることができました。 記事執筆時点では台湾・US へのローンチが完了し、クレジットカード決済・Apple Pay・Google Pay などの決済手段にも対応しています。 また、Payment Platform で実現した抽象化を利用して、カートを使ったまとめ買い機能などの新しい購入体験も日本国内に先立ってグローバルアプリで提供することができました。 一方で、今後取り組むべき課題もまだ残っています。 例えば、日本のメルカリで日本円で売られている商品を海外通貨で販売する時の為替変換の仕組みは、現時点ではグローバルアプリ専用の実装に近く、社内の Payment Platform を利用しているチームにとって十分になめらかな体験になっているとは言えません。また、グローバルアプリ内でのポイントや残高の利用サポートも、今後進めていく必要があります。 そして、より長期的には、今回整備した基盤を日本国内のメルカリにも適用するプロジェクトも進行しています。今回整備したグローバル向けの基盤や設計を国内向けの基盤にも還元することで、Payment Platform 全体をより柔軟で拡張しやすい基盤へ進化させていきたいと考えています。 次の記事は mattsuu さんです。引き続きお楽しみください。

背景や根拠まで確認しますか？

関連記事

調べる

選ぶ

サイト