この記事は、Merpay & Mercoin Tech Openness Month 2025 の5日目の記事です。
この記事では、Payment & Customer Platform (PCP) Vision 2.0の一環として進行中の、決済チェックアウトソリューション開発に関する背景、プロダクトビジョン、全体設計、そして現在の状況について紹介します。
はじめに
こんにちは。メルペイPayment & Customer Platform(PCP)チームのEngineering Headの@foghostです。
PCPの各ドメインチームが現在メルペイの事業だけでなく、メルカリグループが展開するすべての事業を支えるための決済、KYC、加盟店管理の社内共通ビジネス基盤(Foundation)の開発を行っています。 (現状をVision 1.0と定義します)
しかし、現状複数の事業に利用可能な共通機能の提供はできてるとはいえ、機能の拡張性が不足してたり、導入時のコストがかかったりする課題があり、各事業の立ち上げやグロースを爆速させる武器にはまだなりきれていない状況です。
昨年(2024年)から、今後の10年を見据えたTech Roadmapとして、新たなPCP Vision 2.0を策定し、事業拡大のスピードを大幅に加速させる共通ビジネス基盤への進化を目指して取り組んできました。
PCP Vision 2.0では、「Functionalities Evolution(機能の進化)」と「Domain Architecture Evolution(アーキテクチャの進化)」と2つの側面から、現在の課題を整理しながら、各ドメイン領域において考えられる将来の姿を定義し、取り組みを進めています。
今回ご紹介する決済チェックアウトソリューションは「Functionalities Evolution(機能の進化)」を実現するため、決済基盤の領域でチャレンジしている取り組みの一つになります。
課題定義
現在、メルペイは決済事業だけでなく、メルカリやメルカリShopsなどのEC事業にも同じ決済基盤を提供する決済APIを使用しています。
共通の決済APIソリューションの提供のみでも外部決済手段の接続、複合決済含めた決済トランザクションの管理、不正検知、会計連携など含めて共通化ができて各EC事業における決済機能の導入の開発負担を大きく削減できています。
しかし、決済APIのみでは、新しい決済手段(例:コンビニ支払い、ビットコイン支払い)に対応するには、各プロダクトごとに個別の実装が必要になります。このため、画面の改修やバックエンド処理のフローを含めた実装作業が必要です。プロダクトの企画、要件定義、機能設計、開発などをすべて含めると、数ヶ月かかる場合もあります。
また、プロダクトにおけるチェックアウトのコンバージョン率を向上させるためのチューニングや、チェックアウトのUX改善においても、複数のプロダクトで重複した開発労力が発生しています。
このような課題を解決するために、Stripeなどの海外の決済事業者が提供してるLow Code Checkout Solutionのような、社内向けのLow Code Solutionを開発できないかについて、2024年6月頃から検討を始めていました。
プロダクトビジョン
ソリューションの企画段階では、解決したい課題に向けて、US事業を含むEC事業におけるチェックアウトのユースケースを調査し、PMを含めて以下のようにソリューションのプロダクトビジョンを明確にしました。
- 各プロダクトにチェックアウトソリューションのClient/Frontendの画面実装をシームレスに組み込められる
- Low Codeで簡単にインテグレーションできる
- 社内統一したDesign Systemに基づいた統一感のあるUXの提供
- Configurable
- 利用可能な決済手段や、クーポンなどの共通要素はConfigでカスタマイズできる。設定すれば、すぐにその決済手段を利用できるようになる
- チェックアウト画面についてもConfigでカスタマイズが可能であり、プロダクト側の独自な画面要素も簡単に拡張することができる
- プロダクトを横断して、利用者の決済設定を共通化することができる
- 利用者が一度決済設定(クレジットカード情報など)をすれば、複数のプロダクトを横断して利用することができる
- 国内事業とGlobal事業、両方サポートできる
- 国内事業に向けて自社決済手段のサポート
- 台湾や香港の越境取引を行っているGlobal事業に向けて現地決済手段のサポートや、General Data Protection Regulation(GDPR)などの現地の法的規則に準拠するシステム設計
ソリューション設計
既存のAPIソリューションに加えて、Low Codeのソリューションを検討する際に考えられる実現方法はいくつかあります。以下の観点からそれぞれ5段階評価して選定しました。
- インテグレーションコストの削減効果
- これは最も解決したい課題であり、プロダクトに最小限のインテグレーションコストでチェックアウト機能を組み込むことを目指したい
- ガバナンスの容易さ
- 複数のプロダクトを横断してUX体験のガバナンスが可能
- 共通のチェックアウト機能・体験を横断的に最適化しやすい状態を目指したい
- フレキシビリティの高さ
- プロダクトごとに独自の画面設計や要素を拡張したいニーズが必ず存在するため、トレードオフが発生することもあるが、拡張性の高い仕組みを提供することを目指したい。
パータン | 手法 | インテグレーションコスト削減 | ガバナンスの容易さ | フレキシビリティーの高さ | チェックアウト画面のオーナーシップ |
---|---|---|---|---|---|
A | 決済APIのみ提供(比較のため) | 1 | 1 | 5 | プロダクトチーム |
B | 共通のチェックアウト画面を提供し、画面要素ごとに一定のカスタマイズ性を提供する | 5 | 5 | 2 | 決済基盤チーム |
C | チェックアウト画面を自由に組み立てる共通の仕組みを提供する。画面要素について共通の画面要素(Core Element)とプロダクト特有画面要素(Flex Element)どちらも組み込み可能にする | 4~5 | 4 | 4 | 決済基盤チーム |
D | 画面の組み立てはプロダクトに任せる、共通の画面要素(決済手段など)をSDKなどで提供する | <4 | 3 | 4.5 | プロダクトチーム |
最終的にソリューションの立ち上げ時の実装方法を「C」に決めました。また、タイミングもよく社内で一緒に共同開発できる新規事業のプロジェクトがあり、このプロジェクトはWebサービスであるため、最初は決済基盤側でself-hostedしたWebのチェックアウトソリューションの開発からスタートしました。将来必要があれば、蓄積された共通の画面要素をパターンDのようにSDKとしてプロダクトへ提供することも可能だと考えています。
プロダクト視点からチェックアウトソリューションを導入するときの処理フローが以下のようになります。初期のセットアップ、インテグレーションの実装が必要になるが、チェックアウトにおける各種共通機能(例: 決済手段、クーポン)を利用するにはチェックアウトの設定だけで対応できるようになります。
- プロダクトのチェックアウト要件に応じてチェックアウトの設定情報を作成する
- 購入処理をトリガーにバックエンド経由でチェックアウトのセッションを発行する
- チェックアウトセッションに含まれるチェックアウトのトップページの遷移URLへ遷移すれば、決済基盤が提供するチェックアウト画面が表示される
- それ以降プロダクトの利用者がチェックアウトが提供する各種決済手段を利用して決済処理できる
- 決済の結果についてCallback経由、もしくは非同期イベントの通知から受け取ることができる
- 受け取った決済結果に基づいて、プロダクトのバックエンド側で最終的なバリデーションを行い、決済を確定したり、キャンセルしたりすることができる
プロダクト特有画面要素のサポート
ソリューションとして一見簡単に見えますが、各プロダクトで共通化がまだ難しい画面要素をどのようにサポートすれば良いか、非常に悩ましい課題でした。
この課題を解決するために以下のように共通の画面要素とプロダクト特有の画面要素を分けて、それぞれ決済基盤とプロダクトサイドで開発できるためのフレームワークを開発してます。
- 複数のプロダクトで利用可能な共通の画面要素(例:決済手段、クーポン)については、「Core Element」として基盤チームが担当して開発を行う。
- プロダクト固有の画面要素については、「Flex Element」としてプロダクト側のエンジニアが独自で開発できる。
- プロダクトは、ゼロから自前で実装するのではなく、提供される共通の画面要素(Core Elements)と、独自で開発した画面要素(Flex Elements)を組み合わせて、製品固有のレイアウトを作成する。そうすることで、独自のカスタマイズされたチェックアウト体験を実現できるようになる。
開発の現状と今後の展望
現在、チェックアウトソリューションはメルカリの新規サービス「メルカリNFT」のリリースと共にすでに本番で機能提供し始めています。また他の新規サービスのリリース向けにも共同開発を進めており、既存プロダクトのチェックアウト機能のリプレースも現在検討しています。
今後は冒頭でもお伝えしたように、各事業の立ち上げや成長を加速させるための強力な武器となるよう、以下の観点からチェックアウトソリューションをさらに成熟させていきたいと考えています。
- 決済手段を含む共通画面要素の拡充
- 即時決済だけでなく、継続払いなど多様なユースケースへの対応
- プロダクトを横断した一貫性のあるチェックアウト体験の継続的な改善
チェックアウトソリューションに関連する記事が公開予定なので、あわせてご確認ください。
「チェックアウトソリューションのバックエンドアーキテクチャ」
6/18公開予定「Checkout frontend design」
明日の記事は sushoさんの「チェックアウトソリューションのバックエンドアーキテクチャ」です。引き続きお楽しみください。