多様な支払い手段と継続課金を安全に扱う「Mandate」の設計

はじめに

こんにちは。メルペイの Payment Core team/Backend Engineer の@tomo です。**

この記事は、Merpay & Mercoin Advent Calendar 2025の17日目の記事です。

都度払いから継続決済へ

これまでメルペイの決済は、メルカリでの買い物や、お客さまがスマホを取り出してバーコードを提示したりボタンを押したりすることで完了する、いわゆる都度決済（オンセッション決済）が中心でした。しかし、メルカリのエコシステムが拡大するにつれ、決済のあり方は大きく変化しています。

例えば、私たちが提供を開始したメルカリモバイルでは、毎月の利用料金を支払うためにお客さまが都度アプリを開くことはありません。システムがバックグラウンドで自律的に決済を実行します。 このように、決済はもはや単発のイベントではなくなりつつあります。お客さまの操作を伴わずに実行される オフセッション決済──サブスクリプション課金のように、継続的に行われる支払い形態が増えてきています。

そして、メルカリ特有の多様な支払い手段を組み合わせつつ、これらの継続決済を大規模に安全に実行するために、私たちは Mandate**（マンデート） と呼ばれる新しい概念を導入しました。

Mandate とは

「Mandate」という言葉は日常では馴染みが薄いかもしれませんが、Fintech の領域では口座振替依頼や自動引き落としの同意を表す一般的な用語です。Stripe の SetupIntent や、インド UPI の AutoPay など、世界中の決済プラットフォームで同様の仕組みが提供されています。

身近な例として、動画配信サービスのサブスクリプションがあります。お客さまは初回登録時にクレジットカード情報を登録し、「毎月このカードから定額を引き落としてよい」という包括的な許可を与えます。この「将来の支払いに関する包括的な同意」こそが Mandate の本質です。これらは一般に「オフセッション決済」と呼ばれます。請求の瞬間にお客さまが操作を行わずに決済が実行される決済形態を指します。

メルカリにおける Mandate も同じ考え方で、お客さまがサービス（例：メルカリモバイルサービス）に対して「メルペイ残高やポイントなどを用いて、未来の支払いを行ってよい」と認可するデジタルな契約を示します。

一般的な Mandate は、特定の「クレジットカード」や「銀行口座」に 1 対 1 で紐づきます。たとえば、あるサブスク A の支払いに対してクレジットカード B で契約するための Mandate を作成するという具合です。しかし、メルカリのお客さまは以下のような多様な決済手段を持っています。

• 売上金・残高

• 無償ポイント・有償ポイント

• メルペイのあと払い

• クレジットカード

「ポイントが余っていればポイントを優先し、足りなければ残高から、それでも足りなければあと払いで」――このような複合決済を毎回お客さまの操作なしに行うには、単一のカードへの紐付けでは不十分です。そのため、Payment Platform では、複数の決済手段に対して Mandate を作成できるようにしました。つまり Mandate は、「多様な支払い手段を組み合わせて継続的に課金する」というメルカリ特有の要件を、安全に実現するための基盤として設計されています。

メルペイにおける Mandate

Mandate を構成する 3 つの基本要素

オフセッション決済では、誰が → 誰に → どう支払うか の三要素がそろって初めて正しい権限判定ができます。この三要素によって Mandate のスコープを定めます。

• Customer（誰が支払うか）：お客さま

• Partner（誰に支払うか）：料金を受け取るサービス（例: メルカリモバイル）

• Payment Method（どう支払うか）：ポイント、残高、あと払い、クレジットカードなどの組み合わせ

Mandate をこの三軸の組み合わせで表すことで、余計な権限を持たせることなく、監査に耐える説明可能性を確保し、かつ決済実行時の判定を機械的に行えるようになります。

Mandate の管理は Wallet Service によって行われます。Wallet Service は、あんしん支払い設定など、お客さま固有の設定や支払い権限を管理する基盤サービスです。

決済サービスによる必須の Mandate 検証

オフセッション決済はお客さまの操作を伴わないため、何よりも安全性が求められます。Mandate が存在しない、あるいは範囲外の決済が誤って実行されることは絶対に避けねばなりません。

私たちはその安全性を担保するため、決済作成 API（CreateCharge）に Mandate 検証ロジックを統合しました。

クライアントはオフセッションとして決済を実行する意図を示すために mode=off_session を指定して CreateCharge を呼び出し、Mandate の有無を事前に確認する必要はありません。

Payment Service は mode=off_session を受け取ると、Wallet Service の CheckMandateExistence API を呼び出し同期的に検証を問い合わせます。Mandate が存在し、スコープ内で有効なものであれば決済を実行し、そうでなければ即座にエラーを返して処理を中断します。

こうしてプラットフォームが Gatekeeper として機能することで、サービス側の実装に依存しない堅牢な安全性を確保しています。

決済チェックアウトソリューションで Mandate-Free な開発者体験を実現する

オフセッションモードの CreateCharge では、クライアントは Mandate の存在を意識せずに使用できます。しかし、サービス契約時には Mandate 関連の API 呼び出しを実装する必要があります。つまり、サービス側のエンジニアは mandate の作成・削除などライフサイクルに関する仕様を理解し、実装しなければいけません。

そこで Payment Platform 側では、決済チェックアウトソリューションと組み合わせることで、クライアントが Mandate の API 仕様を意識せずに済む「Mandate-Free」な開発体験の実現を目指しました。

メルペイのチェックアウトソリューションは、決済向けの共通チェックアウト画面を提供する仕組みとして開発されました。決済 UI や 3DS（3-D Secure）対応をプロダクトが個別に実装する必要がなくなり、基盤側で統一的に提供できるようになったものです。

さらに今回、このチェックアウトソリューションに setup mode を新設し、支払い手段の登録フローも一括で管理できるようにしました。setup mode のチェックアウトソリューションを通じてお客さまがサービス利用のための支払い手段を登録すると、内部で Mandate 関連 API を呼び出し、Wallet Service に Mandate を作成・更新します。

結果として、クライアントはお客さまに支払い方法を設定させるために チェックアウトソリューション を呼び出すだけでよく、以降の継続課金も mode=off_session の CreateCharge を呼ぶだけで完結します。Mandate の検証やスコープチェックは Payment Platform 側が強制するため、クライアントは決済実行時に必要となる細かな権限管理ロジックを扱う必要がなくなります。

メルカリモバイルにおける実践

Mandate と チェックアウトソリューションの統合は、現在メルカリモバイルのクレジットカード決済で本番運用されています。

お客さまはサービス契約時に一度だけ チェックアウトソリューション を通じてクレジットカードを支払い手段として登録します。登録後、クレジットカードは内部的に Mandate と紐づけられ、以降の毎月の料金請求はオフセッションで自動的に処理されます。お客さまが特別な操作をすることはありません。

メルカリモバイル開発者にとっても、複雑なカード登録フローや Mandate 管理といった重たい実装から解放され、「契約時に チェックアウトソリューション を使用する」「毎月 off_session で CreateCharge を呼ぶ」という最小限の実装だけで安全な継続課金が実現できています。

おわりに

本記事では、メルカリの多様な支払い手段と複雑なビジネス要件を背景に、将来の支払い権限を管理する基盤としての Mandate と、その Mandate をお客さまにも開発者にも意識させない形で統合した チェックアウトソリューション（setup mode） の実践を紹介しました。

明日の記事は@Minatoさんです。引き続きお楽しみください。