メルペイが事業者向け後払い決済の与信管理マイクロサービス設計を公開

こんにちは。メルペイ Payment & Customer Platform (PCP) チームの Backend Engineer をしている@imamu です。この記事は「[Merpay＆Mercoin Tech Openness Month 2026](https://engineering.mercari.com/blog/entry/20260528-merpay-mercoin-tech-openness-month-2026/)」の 6 日目の記事になります。 ## はじめに 「事業者請求払い」とは、事業者（加盟店やビジネスパートナー）向けの後払い決済の仕組みです。取引が発生した時点ではプラットフォーム側が代金を立替え、後からまとめて請求・回収します。事業者にとっては都度の支払いが不要になり、取引のたびにキャッシュフローを気にせず利用できるという利点があります。 立替えて後から請求する以上、プラットフォーム側には一つの重要な責務が生まれます。**事業者ごとに「いくらまで立替えてよいか」= 与信上限（Credit Limit）を安全に管理すること**です。これが破綻すると、回収できない債権が積み上がり事業全体のリスクになります。 本記事では、事業者請求払いを実現するために与信ドメインを Credit Service として切り出した際の 4 つの設計ポイントを紹介します。 ## 背景：従来の請求払いの課題 事業者請求払いは、取引時に代金を立替え、後からまとめて請求・回収する仕組みです。概念的には、次のようなライフサイクルになります。 ![image](https://storage.googleapis.com/prd-engineering-asset/2026/06/73fe9ff8--2026-06-08-17.35.22-1024x280.png) 従来、この請求払いを実現する手段は主に 3 つありました。 **1. 外部のあと払いサービス**** いくつかのプロダクトは [外部のあと払いサービスを使って与信管理・請求を実現していました](https://engineering.mercari.com/blog/entry/20241221-invoice-payment/) が、プロダクト特性に応じたリスク管理やパートナーに応じた柔軟な請求、入金イベントをトリガーにした精算や会計連携のシステム化が難しい側面があり、システム外での運用が避けられませんでした。 2. 外部の請求代行サービス**** 請求書の発行・送付といった請求業務のみを外部サービスに委ねる方法も取られていました。しかし、与信枠（Credit Line）を自社で管理していないため上限を超過しても取引自体は通ってしまうリスクがありました。 3. クレジットカードによる代理決済**** 一般的な法人カードで利用上限の範囲内で建替え、請求する運用も使われていましたが、取引前に「いまいくらまで使えるか」を自社システムで把握できず、取引が成立した後の決済段階で初めて残高不足エラーが顕在化し、お客さまの体験にも悪影響が出ていました。 ## 目的：なぜ内製の与信管理が必要だったか 前節の 3 つの手段はいずれも、請求払いそのものは実現できていました。しかし、プロダクトごとに運用や要件が異なる状態では、事業者ごとの与信をプロダクト横断で一元管理できない**という共通の課題が残ります。事業者請求払いは複数のプロダクトでの利用が見込まれるため、プラットフォームとしては次の不変条件を常に満たす必要があります。 **プロダクト横断で保有する債権の合計 例えば事業者の与信上限が 100 のとき、プロダクトAの利用 60 とプロダクトBの利用 60 が同時に成立して合計 120 になる、といった状態を許してはなりません。プロダクトごとに与信判断が分散していると、この不変条件は容易に破られてしまいます。 そこで私たちは与信管理をプラットフォーム側で提供し、次の3点を満たすことを目的にしました。 - プロダクト横断で与信・債権を一元管理すること 不変条件「債権合計 - 取引前に安全に通すこと いま使える額を判断し、必要に応じて与信枠を確保したうえで取引を開始できる - 請求・入金・精算プロセスまでシームレスにつなぐこと 取引の状態変化に追従し、後続の請求・入金・精算へ自然につなげる ## 設計：4 つの設計ポイント 設計は次のようなサービス連携のユースケースを想定して組み立てました。 ![image](https://storage.googleapis.com/prd-engineering-asset/2026/06/86be7d72-architecture4points-1024x309.png) まず Payment Service が各プロダクトから決済リクエストを受け付けます。これは Payment Service が決済手段の提供と決済リソースの状態管理を責務としているためです。そして、Credit Service に与信枠の利用を依頼し、Credit Service が債権管理を担う Debt Service に債権を登録します。この債権を集約して Invoice Service が請求書を発行します。この連携を以下の 4 つの観点で設計しました。 ## 1. 与信管理の責務を 1 サービスに凝集する まず決めたのは「与信ドメインをどのサービスが持つか」です。 すでに存在する Payment Service は決済手段の提供と決済リソースの状態管理を責務としています。ここに与信枠の管理や利用可能額の計算といった与信ドメインの知識を持ち込むと、Payment Service が本来のスコープを超えて肥大化してしまいます。そこで、与信に関わる以下の責務を全て Credit Service に凝集しました。 - 与信上限の決定（事業者審査の結果として上限を確定する） - 与信枠の作成・更新（プロダクトごとに任意に切れる枠を管理する） - 利用可能額の計算（いまいくらまで使えるかを算出する） - 与信枠の利用（与信を消費し、債権の登録を依頼する） 審査（枠を決める）と利用（枠を使う）をあえて分離せず一体で持つことにしました。こうすることで、Payment Service は「与信枠を利用する」という一つの操作を呼ぶだけでよくなり、利用可能額のチェック・与信の消費・債権登録という一連の処理がサービス内に閉じます。また、横断的な与信上限（目的の不変条件）をアトミックに守るには、与信の利用を 1 サービスに集約する以外に方法がありません。このように、責務の凝集は明確なドメイン境界と不変条件から導いた設計判断です。 ![image](https://storage.googleapis.com/prd-engineering-asset/2026/06/03b77715-cohesion.png) ## 2. 与信と請求を分離する 次に**与信の単位と請求の単位は同じではない**という前提を設計に組み込みました。 - 与信は「どの枠でいくら使えるか」を、事業者が任意に切った枠（CreditLine）の単位で管理したい - 請求は「どの宛先にまとめて請求書を出すか」を、請求先（InvoiceAccount）の単位で管理したい この2つを密結合にしてしまうと、「請求の単位を変えたいだけ」で与信側まで作り直すことになります。両者は本来別々の関心事なので、疎結合に保つ必要があります。 実現方法は次のとおりです。Credit Service は与信を消費して債権を登録するとき、その債権に**「どの請求先に属するか」「どの与信枠に属するか」という集計のための情報**を持たせて Debt Service に渡します。Debt Service は、債権を**複数の軸で集計・一覧できる仕組み**を備えており、以下のようにそれぞれのサービスが債権の情報を参照することができます。 - Credit Service は「与信枠の軸」で未返済の債権から利用額を計算する - Invoice Service は「請求先の軸」で指定期間の債権から請求書を発行する ![image](https://storage.googleapis.com/prd-engineering-asset/2026/06/aa6ef81b-creditinvoiceseparation-1024x391.png) これにより与信は事業者全体で管理しつつ、請求は支店ごとに行うようなユースケースに対応できます。ポイントは**債権の集計軸を Debt Service が中心的な概念として扱う**ことにあります。Credit Service は与信枠の軸だけを、Invoice Service は請求先の軸だけを関心に持ち、軸ごとの集計は Debt Service に委ねます。結果として、**与信の粒度（CreditLine）と請求の粒度（InvoiceAccount）を独立して設計 [[1]](#fn1) できます**。 ## 3. 事業者ごとに複数の与信枠を持てる 与信枠は事業者単位で 1 つではなく、**1 事業者が複数の与信枠（CreditLine）を持てる**構造にしました。店舗ごと・部門ごとといった、事業者で運用したい任意の単位で枠を切れます。これによってプロダクト毎に柔軟に利用制限を行うことができます。 ただし、複数の枠を切っても事業者全体の与信上限（CreditLimit）は超えられません。そこで最終的な利用可能額は、与信枠の利用可能額と事業者全体の利用可能額の小さい方で決まります。 **最終的な利用可能額 = min(CreditLine の利用可能額，事業者 CreditLimit の利用可能額)** ここで、似て非なる 2 つの「上限」を区別しておきます。 CreditLimit CreditLine 意味 **絶対に超えて立て替えない上限** クライアントが切れる**実用枠** 決め方 与信審査の結果 クライアントが任意設定 クライアントの変更 不可 更新可能 「審査で決まる硬い上限」と「運用で柔軟に切れる枠」を分けることで、安全性と柔軟性を両立しています。 ## 4. 与信の利用はライフサイクルに沿って状態を持つ 与信枠の利用は、一度の操作で完結するものではありません。実際の取引は、与信を押さえてから確定するまでに時間差があり、途中で取り消されることもあります。そこで与信の利用を、複数のフェーズを持つ**与信トランザクション（CreditTransaction）**として管理します。 取引開始時点で与信枠を押さえる**確保（Authorize）**、取引確定時点で債権として確定する**確定（Capture）**、確定前に押さえた与信を解放する**取消（Cancel）**という 3 つのフェーズを扱います。これにより、取引の途中で状態が変化しても、与信の消費と解放を一貫したモデルで管理できます。 ![image](https://storage.googleapis.com/prd-engineering-asset/2026/06/d91225dc-statustransition.png) **確保のタイミングを選択可能に（ReservationPolicy）** 与信をいつ・どう押さえたいかはプロダクトによって異なります。そこで確保の仕方を ReservationPolicy として選べるようにし、同じ Credit Service を要件に合わせて使い分けられるようにしました。 確保の仕方 動作 仮確保**（PROVISIONAL） 依頼時に仮の債権で与信を押さえ、確定で正式な債権にする／取消で解放する **確定時に確保**（CHECK_THEN_CAPTURE） 依頼時は利用可能額の確認だけ行い、確定時にまとめて確保する **即時確保**（IMMEDIATE） 依頼した時点で確保と確定を同時に行う **確定後の取消にも対応する（Reversal）** 運用上は、与信を確保して取引が確定した後**に取消が発生することがあります。確定後は与信を解放するだけでは済まず、すでに登録された債権をどう扱うかが問題になるため、確定後の取消を Reversal としてサポートしました。 Reversal では、取消したい金額をその時点の債権残額に応じて未返済分と返済済み分に切り分けます。未返済分は債権そのものを取り消し、返済済み分は債権を取り消せないため、返金すべき金額としてレスポンスで返して呼び出し元（Payment Service）が返金できるようにします。これにより、確保→確定→取消・返金という取引のライフサイクル全体に対して一貫した扱いができます。 ## 全体像：プラットフォーム全体で一気通貫に ここまで見てきた Credit Service は、単独で成り立つものではありません。プラットフォームには、Payment（決済）・Debt（債権）・Invoice（請求）・Bank（入金）・Balance（残高）・Settlement（精算）といった、それぞれ明確な責務を持つサービスがすでに存在していました。そこに Credit Service が新たに加わることで、各サービスが自分の責務に集中したまま連携し、**決済・与信管理・請求・精算がプラットフォーム全体で一気通貫に実現できる**ようになりました。 ![image](https://storage.googleapis.com/prd-engineering-asset/2026/06/8967b118-platformoverview-1024x812.png) この構成によって、新しいプロダクトがシームレスに事業者請求払いに対応することができます。あるプロダクトで事業者請求払いを利用したくなったら、必要なのは **与信枠（CreditLine）と請求先（InvoiceAccount）を新たに作るだけ**です。プラットフォームの各サービスに手を入れることなく、そのプロダクトの取引が、与信照会から決済・請求・返済までのライフサイクルに自然に乗ります。 ## おわりに 与信管理マイクロサービスが完成したことで、Payment Platform として事業者請求払いを実現できるようになりました。 Payment Platform は今後も進化していきますが、「各サービスが明確な責務を持ち、疎結合に連携する」という設計方針そのものは変わりません。この方針のもとに安全かつ拡張可能な決済基盤を今後も実現していきたいと考えています。 次の記事は nanacom さんと mattsuu さんです。引き続きお楽しみください。 [[1]](#ref1) この「債権を任意の軸で集計する仕組み」自体も独立した設計テーマであり、別記事で詳しく紹介される予定です。

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

関連記事

調べる

選ぶ

サイト