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