電子決済システム開発のPoC・プロトタイプ・モックアップ開発について

電子マネーやコード決済のウォレットは、利用者から預かったお金（バリュー）を1円のズレもなく管理しなければならないため、いきなり本開発に進むのではなく、PoC（概念実証）やプロトタイプ、モックアップで核心となる仕組みを検証してからスケールさせるアプローチが特に重要になります。ここで押さえておきたいのは、本記事が扱う「電子決済システム」は、店舗やECサイトが決済を受け付けるために導入する加盟店側の仕組みとは立場が逆で、利用者の残高を自ら発行・管理し、チャージや送金を処理し、加盟店へ精算する「決済サービスを提供・発行する事業者側」——前払式支払手段発行者や資金移動業者が構築するウォレット・残高管理システムそのものだという点です。加盟店側のPoCが「決済代行のAPIをカートに組み込んで正しく決済できるか」を検証するのに対し、発行側のPoCは「チャージで増えた残高が決済で正しく減り、加盟店に精算されるまで、お金の流れが一貫して破綻しないか」という、バリューフローそのものの整合性を検証することが主眼になります。

本記事では、電子決済システム開発におけるPoC・プロトタイプ・モックアップについて、なぜバリューを扱うシステムで事前検証が重要なのかという位置づけから、チャージ→残高反映→決済→精算という一連のバリューフローの整合性検証、通信エラーや返品時のロールバックといった例外系の検証、QRコード方式（MPM/CPM）や送金・割り勘機能のプロトタイプ検証、不正利用検知のPoC、そしてMVPの進め方と失敗しやすいポイントまでを、具体的に解説します。なお、店舗のPOSやECサイト側で決済を受け付ける仕組みの検証については、別記事「決済システム開発」「オンライン決済システム開発」で扱っていますので、加盟店側の視点が必要な方はそちらもあわせて参照してください。

本テーマに関する全体ガイドは、以下の記事をご覧ください。

▼全体ガイドの記事
・電子決済システム開発の完全ガイド

電子決済システムにおけるPoC・プロトタイプの位置づけ

電子決済システムは、利用者から預かった残高というお金そのものを扱うため、一般的なWebサービスとは比べものにならない厳密さが求められます。バグによって残高が二重に増えたり、決済したのに残高が減らなかったり、逆にお金だけ引かれて残高に反映されなかったりすれば、それは即座に金銭的な損害と信頼の失墜につながります。だからこそ、いきなり全機能を作り込むのではなく、お金の流れの核心部分をPoCやプロトタイプで先に検証し、設計の妥当性を確かめてから本開発に進むアプローチが不可欠です。PoCで技術的な実現性とデータ整合性の担保方法を確認し、プロトタイプで利用者の操作フローやUXを検証し、モックアップで画面イメージと業務の流れを関係者間で合意する——この段階を踏むことで、本開発での致命的な手戻りを未然に防げます。

電子決済システムで最も検証しておくべきなのは、残高というバリューが常に正しく保たれるかどうかです。通常のWebサービスであれば、多少のデータ不整合が起きても後から修正できることが多いですが、お金を扱うシステムでは、一度でも残高が狂うと利用者の資産に直接影響し、原因究明と補償に膨大なコストがかかります。しかも、こうした不整合の多くは、正常に処理が完了する「正常系」ではなく、通信が途中で切れる、同じ操作が二重に届く、決済の途中でアプリが落ちるといった「例外系」で発生します。これらの例外は本番の負荷や実際の利用者の予測不能な操作でしか顕在化しないことも多く、机上の設計だけでは見落としがちです。だからこそ、PoCの段階で例外系を含めた残高の挙動を実際に動かして確かめ、設計が破綻しないことを確認しておく価値が高いのです。お金に直結する部分の検証を後回しにすると、本番稼働後に取り返しのつかないトラブルを招きます。

加盟店側の決済システムのPoCでは、決済代行会社のサンドボックス環境で「自社のカートやレジから決済を呼び出し、正しく決済結果が返ってくるか」「返金やキャンセルのAPIが期待どおり動くか」を検証するのが中心になります。決済の心臓部は決済代行会社が持っているため、加盟店はそれを正しく呼び出せるかを確かめれば十分です。これに対し、発行側の電子決済システムのPoCでは、残高を管理する元帳そのものを自社で持つため、検証の焦点が「お金の流れが一貫して破綻しないか」に移ります。すなわち、チャージで残高が増える処理、決済で残高が減る処理、それを加盟店へ精算する処理が、通信エラーや同時アクセスがあっても1円のズレもなく整合するかを、自社の実装に対して検証しなければなりません。加盟店側が「決済結果の受け取り」を確かめるのに対し、発行側は「残高というお金の発行・移動・保管」の正しさそのものを確かめる——この検証観点の違いを理解して、PoCの計画を立てることが重要です。

バリューフローの整合性検証

電子決済システムのPoCで最優先に検証すべきなのが、チャージ→残高反映→加盟店決済→精算という一連のバリューフローの整合性です。この流れのどこか一箇所でもデータがズレると、利用者の残高か加盟店への支払いのどちらかが狂い、事業として成立しなくなります。正常系だけでなく、通信エラーや返品といった例外が起きたときにも整合性が保たれるかを、実際に動かして確かめることがこのフェーズの目的です。

まず検証するのは、利用者がクレジットカードや銀行口座からウォレットへチャージした瞬間に残高が正しくプラスされ、実際の加盟店で決済した瞬間に残高が正しくマイナスされ、後日その分が加盟店へ精算されるまでのデータが、1円のズレもなく同期するかどうかです。ここで技術的に確かめるべきは、これらの処理がACID特性（原子性・一貫性・独立性・永続性）を担保しているか、すなわち「残高を減らす処理」と「加盟店の売上を増やす処理」が必ず同一のトランザクション内で実行され、途中でエラーが起きた場合は全て無効化（ロールバック）されるかという点です。また、残高を単純な数値の上書きで管理するのではなく、取引履歴（ジャーナル）を追記していくイミュータブルな設計にして、「現在の残高＝過去の全トランザクションの集計結果」が常に一致することをPoCで確かめておくと、後の突合や監査の土台が固まります。この同期がPoCで確実に成立することを確認できて初めて、本開発でスケールさせても安全だと判断できます。

正常系の同期が確認できたら、次に検証すべきは例外系の挙動です。とりわけ重要なのが、通信エラー時の「チャージ失敗」の扱いです。利用者の銀行口座やカードからお金だけが引かれたのに、ウォレットの残高には反映されない——このような二重の不整合が起きないよう、べき等性（同じトランザクションIDでのリクエストが二重に届いても結果が1回分にしかならない仕組み）が正しく機能するかを、意図的に通信を切断するテストで確かめます。また、返品や取消が発生したときに、決済で減った残高が正しく戻る「残高のロールバック（即時返金）」が期待どおり動くかも、PoCで必ず検証します。返品に伴う「売上取消→残高への返金」というフローは、要件定義の段階で明確にしておかないと稼働後にトラブルになりやすいため、PoCでこの例外パターンを一通り再現し、残高と精算データの両方が正しく元に戻ることを確認しておくことが欠かせません。例外系こそが電子決済システムの品質を決めるといっても過言ではありません。

QRコード方式と送金機能のプロトタイプ検証

バリューフローの整合性に続いて検証すべきなのが、利用者が実際に触れる決済手段の使い勝手と技術的な成立性です。とくにコード決済のQRコード方式と、利用者間の送金機能は、方式の選択や実装の作り込みが利用体験と安全性を大きく左右するため、プロトタイプでの実地検証が有効です。

QRコード決済には、店舗が提示したQRコードを客がスマホで読み取るMPM（店舗提示型）と、客のスマホに表示したQRコードを店舗のレジで読み取るCPM（利用者提示型）の2方式があり、それぞれ検証すべきポイントが異なります。MPMの場合は、客自身のスマホカメラの性能や、地下店舗などの通信環境、店内の明るさに読み取り成功率が左右されるため、「カメラ起動→QR読み取り→金額入力→決済完了画面への遷移」という一連の操作がさまざまな環境でスムーズに動くかを、実地でプロトタイプ検証します。一方CPMの場合は、スクリーンショットによる不正利用を防ぐため、アプリ側で数十秒ごとに動的に更新されるワンタイムQRコード・バーコードを生成するロジックが正しく機能するか、また店舗のレジ（バーコードリーダー）からの決済リクエストを数秒以内に処理して完了させる応答速度（SLA）を担保できるかを技術検証します。どちらの方式を主軸にするかは、想定する加盟店の業態や決済端末の環境によって変わるため、プロトタイプで両方式の体験を比較してから決めるのが賢明です。

利用者間で残高を送り合う送金機能や割り勘機能を実装する場合は、データの排他制御をプロトタイプで重点的に検証します。AさんからBさんへ送金する際、Aさんの残高が減る前にBさんの残高だけが増えてしまうと、システム全体で残高の総和が狂い、実質的にお金が増減してしまう致命的な不整合になります。これを防ぐため、送金処理では該当する利用者の残高レコードをロックし、送り手の減算と受け手の加算を必ず一体のトランザクションとして処理する設計が必要です。プロトタイプでは、この排他制御が、割り勘のように一度に多人数へ送金するケースや、ピーク時に大量の送金が同時に発生するケースでも正確に機能するかを、パフォーマンステストで確かめます。同一利用者が短時間に連続して送金・決済を行った場合に残高がマイナスにならないか、といった境界条件も併せて検証しておくと安心です。送金機能は資金移動業の登録要件にも直結するため、技術検証と並行して法規制上の位置づけも確認しておく必要があります。

不正利用検知のPoC

電子マネーのウォレットは、他人のクレジットカードを用いた不正チャージやアカウント乗っ取りの標的になりやすく、これらを見過ごすとチャージバックによる直接的な金銭損害を被ります。そのため、不正利用検知の仕組みが、正規利用者の利便性を損なわずに不正だけをブロックできるかを、PoCの段階で検証しておく価値があります。

不正利用を水際で防ぐための基本的な仕組みとして、PoCでまず検証したいのが、デバイス情報のフィンガープリント取得と、短時間の連続チャージ制限です。デバイスフィンガープリントは、利用者の端末固有の情報を組み合わせて識別することで、同一の端末から複数のアカウントで不正なチャージが繰り返されるパターンを検知する手がかりになります。また、他人のカードを使った不正チャージは、短時間に金額を変えながら試行を繰り返す傾向があるため、一定時間内のチャージ回数や金額に上限を設ける制限が有効です。PoCでは、これらのルールが実際の不正パターンを捕捉できるか、そして正規の利用者が普通に使う分にはブロックされないか（過検知が起きないか）を、想定シナリオを流して確かめます。制限を厳しくしすぎると正規利用者の離脱を招き、緩めすぎると不正を許すことになるため、この閾値の調整はPoCで実データに近い条件を試しながら詰めていくのが現実的です。

自社独自のルールエンジンだけで不正を捕捉するには限界があるため、PoCでは専門の不正検知システムをAPI連携させ、その効果を検証することも有効です。たとえばO-PLUXのような不正注文・不正アクセス検知システムは、多数のサービスで共有される最新の不正データベースやアルゴリズムを活用しており、自社単独では気づけない不正パターンをリアルタイムで判定できます。PoCでは、チャージや高額決済のリクエスト時にこの外部システムへ判定を問い合わせ、正規ユーザーの利便性を損なうことなく、クレジットカードの不正利用やなりすましをブロックできるかを検証します。あわせて、外部システムへの問い合わせがチャージや決済の応答速度に悪影響を与えないか、判定に時間がかかったときのタイムアウト処理をどう設計するかも確認します。自社ルールと外部システムをどう組み合わせ、どの取引にどこまでの検査をかけるかというバランスを、PoCの段階で見極めておくことで、本番稼働後の不正被害を最小化できます。

MVPの進め方と失敗しやすいポイント

PoCやプロトタイプで核心を検証できたら、次はMVP（実用最小限の製品）として最小構成で先行公開し、実利用のなかで残りの機能を段階的に育てていきます。この進め方には定石があり、同時に陥りやすい落とし穴も存在します。

電子決済システムのMVPは、最も利用頻度の高いチャージ手段と加盟店決済の正常系、そして基本的な取消処理に絞って構築するのが定石です。たとえば、まずはクレジットカードまたは主要銀行口座からのチャージと、加盟店でのコード決済、決済の取消という最小限の機能だけを備えたウォレットを作り、限られた利用者や店舗に先行公開して実運用のなかで検証します。その後、利用状況を見ながら、送金・割り勘機能や、コンビニ・ATMといった低頻度のチャージ手段、キャンペーン機能などを第2フェーズ以降に段階的に追加していきます。この進め方の利点は、事業として重要なチャージと決済のフローを早期に実地検証でき、利用者の反応を見ながら投資判断ができる点にあります。とくに送金・出金機能は資金移動業の登録という重い要件を伴うため、初回のMVPからは切り離し、支払い機能で事業の手応えを確かめてから踏み込むのが、リスクを抑えた現実的な順序です。

PoCやプロトタイプで陥りやすい落とし穴の第一は、例外処理の検証を先送りにしてしまうことです。「とりあえず動くモックアップ」を優先し、正常系だけを確認して満足してしまうと、通信エラー時のチャージ失敗や返品時の残高ロールバックといった、本番で必ず起きる例外の検証が漏れ、本開発の終盤で重大な手戻りが発覚します。対策は、例外処理を要件定義の段階で「システムで自動化するもの」「画面で手動対応するもの」「運用ルールで対応するもの」の3つに仕分け、PoCの検証項目に例外系を明示的に組み込むことです。第二の落とし穴は、完璧を目指しすぎてスコープが膨らむことです。あらゆるチャージ手段と例外パターンを最初から検証しようとすると、PoCが終わらず本開発に進めません。核心（最頻の決済フローと重大な例外）に絞ることが重要です。第三は、モック稼働・負荷テストの不足です。本番のネットワーク負荷や、決済途中でのアプリ終了といった特殊な操作は、実際に近い条件で動かさないと顕在化しません。PoCの段階から一定の負荷をかけ、想定外の操作を試すことで、稼働後のトラブルを未然に防げます。

まとめ

本記事では、電子マネー・コード決済を発行・運営する事業者側の視点で、利用者の残高を管理するウォレット・電子決済システムのPoC・プロトタイプ・モックアップ開発を解説しました。お金（バリュー）を扱う電子決済システムでは、残高が常に正しく保たれることが絶対条件であり、不整合の多くは正常系ではなく例外系で発生するため、PoCの段階で例外を含めた挙動を実際に動かして確かめる価値が高いことを述べました。最優先で検証すべきは、チャージ→残高反映→決済→精算というバリューフローの整合性（ACID特性・べき等性・イミュータブルな元帳）と、通信エラー時のチャージ失敗や返品時の残高ロールバックといった例外系です。あわせて、QRコード方式（MPM/CPM）のUX・技術検証、送金・割り勘の排他制御、デバイスフィンガープリントや連続チャージ制限・外部不正検知システムのAPI連携によるPoCも重要になります。MVPは最頻のチャージ手段と加盟店決済の正常系・基本取消に絞り、送金・出金は資金移動業の要件を伴うため第2フェーズ以降に回すのが定石です。陥りやすい落とし穴は、例外処理の先送り、完璧を目指したスコープ膨張、モック稼働・負荷テストの不足の3つでした。加盟店側で決済を受け付ける仕組みの検証については別記事「決済システム開発」「オンライン決済システム開発」も参照してください。まずは自社のバリューフローの核心をPoCで検証し、例外系まで含めて破綻しないことを確かめることから始めましょう。

▼全体ガイドの記事
・電子決済システム開発の完全ガイド

株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。