電子決済システム開発の開発期間・スケジュール・納期について

スマートフォンのウォレットにチャージした残高で買い物ができる電子マネー、店頭のQRコードを読み取って支払うコード決済、友人同士で残高を送り合う個人間送金——こうした「電子決済システム」を、決済サービスを提供・発行する事業者の立場でゼロから構築しようとすると、多くの担当者が最初に直面するのが「利用者から預かったお金（バリュー）をどう正確に管理し、いつまでに稼働させられるのか」というスケジュールの読みにくさです。ここで重要なのは、本記事が扱う「電子決済システム」は、店舗やECサイトが決済を受け付けるために導入する仕組み（＝加盟店側の決済システム）とは立場が正反対だという点です。すなわち、利用者の残高を発行・管理し、チャージや送金を処理し、加盟店へ精算を行う「決済サービスを提供・発行する事業者側」——前払式支払手段発行者や資金移動業者が自ら構築するウォレット・残高管理システムそのものを指します。お金の残高を1円単位で正確に管理し、資金決済法という金融規制に準拠する必要があるため、一般的なWebシステム開発には存在しない工程が期間を大きく左右します。

本記事では、電子決済システム開発の開発期間・スケジュール・納期について、自社経済圏限定のハウス電子マネーから複数加盟店に展開するコード決済・資金移動業まで規模別の期間目安を示したうえで、要件定義・バリュー設計から残高元帳の整合性設計、eKYC（オンライン本人確認）、テスト、本番稼働に至る工程別スケジュール、資金決済法対応や当局対応が納期に与える影響、チャージ手段や送金機能の実装範囲による期間差、開発手法による違い、そして納期遅延の典型要因と対策までを、具体的な数値とともに解説します。なお、店舗のPOS連携やECサイト側で決済を受け付ける仕組みについては、別記事「決済システム開発」「オンライン決済システム開発」でそれぞれ扱っていますので、加盟店側の視点が必要な方はそちらもあわせて参照してください。

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

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

電子決済システム開発期間の全体像

電子決済システムの開発期間は、発行するバリュー（残高）の性質と、それをどこまで自社で作り込むかによって大きく変動します。最も期間が短く済むのは、自社の店舗やアプリの中だけで使える「ハウス電子マネー」や「プリペイド残高」を発行するクローズドな構成で、外部加盟店への精算機能を持たない場合です。この構成なら約4〜6ヶ月、費用は1,000万円から数千万円規模が目安になります。一方、街中の複数加盟店で使えるコード決済や、利用者間送金・銀行口座への出金まで備えた資金移動業レベルのウォレットをゼロから構築する場合は、ウォレットアプリの開発に加えて加盟店管理・精算バッチ、他行口座からのチャージ用API連携、厳格なeKYC（オンライン本人確認）機能が必要となり、全体で半年から1年以上、費用も数千万円から数億円規模の大規模プロジェクトになります。電子決済システムは利用者から預かったお金を1円のズレもなく扱う必要があるため、バグを防ぐテストフェーズだけで全体工数の30〜40%を占めることも珍しくありません。

規模別に整理すると、小規模なケースは「自社経済圏のみで使えるハウス電子マネー・プリペイド残高の発行」です。利用範囲が自社の店舗やECサイトに閉じており、外部加盟店への精算や個人間送金がないため、残高のチャージ・利用・失効といった基本的なバリュー管理に集中でき、約4〜6ヶ月で構築できることが多くなります。中規模になると、複数の加盟店で使えるコード決済へと広がり、加盟店の登録・管理、日次の精算バッチ、銀行口座やクレジットカードからのチャージ連携が加わるため、全体で半年前後を見込む必要があります。さらに、利用者間送金や残高の銀行口座への出金（払い出し）まで備えた資金移動業レベルのウォレットになると、eKYCによる厳格な本人確認、マネーロンダリング対策、資金決済法に基づく資金保全の仕組みまで作り込むことになり、全体で1年以上、費用も数千万円から数億円規模に達します。まずは自社が「クローズドなハウスマネー型」「複数加盟店のコード決済型」「送金・出金対応の資金移動業型」のどこに位置するかを見極めることが、期間見積もりの出発点になります。

店舗やECサイトが決済を「受け付ける」ために構築する加盟店側の決済システムでは、決済代行会社（PSP）のAPIを組み込み、クレジットカードやコード決済といった手段を自社のレジやカートに統合することが開発の中心になります。これに対し、決済サービスを「発行・提供する」電子決済システムでは、利用者一人ひとりの残高を管理する元帳（台帳）そのものを自社で持ち、チャージで残高を増やし、決済で残高を減らし、後日その分を加盟店に精算するという、お金の流れの根幹を自前で設計・実装しなければなりません。加盟店側が「決済結果を受け取って自社業務に反映する」立場であるのに対し、発行側は「残高というお金を発行・保管・移動させる」立場であり、二重支払いの防止や残高の整合性、資金決済法への準拠といった、金融機関に近い厳密さが求められます。この根本的な立場の違いが、加盟店側の決済導入より開発期間が長くなる最大の理由です。

要件定義から本番稼働までの工程別スケジュール

電子決済システムの開発を正しくスケジューリングするには、プロジェクト全体を「要件定義・バリュー設計」「残高元帳・トランザクション整合性設計」「チャージ／決済／精算のフロー実装」「eKYC・不正検知の組み込み」「結合テスト・受入テスト」「当局対応・リリース」といった工程に分解し、それぞれの所要期間と依存関係を把握することが欠かせません。とくに電子決済システムでは、残高管理の設計を曖昧にしたまま実装に進むと後工程で致命的な手戻りが発生するため、上流の設計工程に十分な時間を確保することが、結果的に全体期間の安定につながります。

最初の要件定義フェーズでは、発行するバリューの種類（自社限定のハウスマネーか、街中で使えるコード決済か）、チャージ手段の範囲（銀行口座・クレジットカード・コンビニ・ATMのどこまで対応するか）、送金や出金といった資金移動機能を持たせるか、想定する利用者数と1日あたりの取引件数、そして自社の残高が資金決済法上の「前払式支払手段」に該当するのか「資金移動業」に踏み込むのかを整理します。ここでの判断は後続すべての工程のスコープと法規制対応を決定づけるため、法務や金融規制の知見を持つ担当者を早期に巻き込むことが重要です。バリューの設計で「送金機能を後から足したい」といった要件が固まらないまま実装に進むと、残高管理の根幹まで作り直しになりかねません。この上流の詰めに数週間を割くことが、全体スケジュールの安定に直結します。

電子決済システム開発で最も慎重に時間をかけるべきなのが、残高元帳とトランザクション整合性の設計フェーズです。ここでは、利用者の残高を単に「残高」という数値の上書き（UPDATE）で管理するのではなく、「いつ・誰が・いくら加算／減算したか」という取引履歴（ジャーナル）を必ず追記（INSERT）していく、銀行の勘定系に近いイミュータブルな設計を採用します。現在の残高は「過去の全トランザクションの集計結果」と常に一致していなければならず、この原則を最初から作り込むことで、後の突合や監査が成立します。あわせて、通信エラーで同じチャージや決済のリクエストが二重に届いても結果が1回分にしかならない「べき等性（同じトランザクションIDでの重複処理防止）」、同時アクセスで残高がマイナスにならないようレコードをロックする「二重支払い防止」、残高の減算と加盟店売上の加算を必ず同一トランザクションで実行し失敗時は全て取り消す「ACID特性」を設計に織り込みます。この設計フェーズを軽視すると、テスト工程で「二重に残高が増えた」「決済したのに残高が減っていない」といった致命的な不整合が噴出し、大幅な手戻りにつながります。

送金や出金を備えた資金移動業型のウォレットでは、口座開設に相当する厳格な本人確認（eKYC）の組み込みが工程に加わります。運転免許証などの本人確認書類と自撮り画像を突き合わせるeKYCは、専用ベンダーのサービスをAPI連携するのが一般的ですが、連携仕様の確認や本人確認フローのUI実装、確認失敗時の再申請導線まで含めると相応の期間を要します。その後の結合テスト・受入テストでは、チャージ→残高反映→加盟店決済→精算という一連のバリューフローが1円のズレもなく同期するか、通信切断時のロールバックや返品時の残高の戻しといった例外系が正しく動くかを、サンドボックス環境で網羅的に検証します。電子決済システムは正常系よりも例外系の検証に時間がかかるのが特徴で、テスト工程が全体の3〜4割を占めることを前提にスケジュールを組む必要があります。すべてのテストが完了し、資金決済法上の届出・登録が整った段階で本番環境へ切り替え、必要に応じて一部利用者への先行公開から段階的に展開します。

資金決済法対応・当局対応が期間に与える影響

加盟店側の決済システムでは「加盟店審査を受ける側」でしたが、決済サービスを発行する電子決済システムでは、自社が資金決済法上の届出・登録を行い、当局の監督を受ける「審査される側」に立ちます。この当局対応は開発チームの努力だけでは短縮できない外部プロセスであり、システムがそれに対応できる機能を備えているかどうかが、稼働時期を左右する隠れたクリティカルパスになります。

自社で発行する残高が「前払式支払手段」に該当する場合、毎年3月末および9月末を基準日として、その時点の未使用残高の半額以上を発行保証金として法務局などに供託（保全）する義務があります（未使用残高が基準額を超えた場合）。この義務に対応するには、システムが「基準日の特定時刻における1円単位の正確な未使用残高」を遅滞なく出力できる設計になっていることが前提になります。単に現在の残高合計を表示するだけでなく、休眠アカウントの失効処理や利用規約に基づく残高の扱いをバッチで正確に反映し、供託額算定に使える集計値を確定させる仕組みを開発しなければなりません。この供託残高集計機能を後付けにすると、基準日直前に慌てて集計ロジックを作ることになり、数値の正確性を担保できずリリース後の当局報告に支障をきたします。要件定義の段階から法定帳票・報告の要件を洗い出し、集計機能を初期スコープに含めておくことが、スケジュールを乱さないポイントです。

利用者間の送金や、残高を現金として銀行口座へ払い出す出金機能を持たせる場合は、前払式支払手段の枠を超えて「資金移動業」の登録が必要になり、規制のハードルが一段と高くなります。資金移動業では、滞留している利用者資金の100%以上を履行保証金として供託・保全する義務があり、さらに口座開設に相当する厳格なeKYC（オンライン本人確認）と、マネーロンダリング・テロ資金供与対策（AML/CFT）としての取引モニタリングをシステムに組み込むことが求められます。これらは単なる機能追加ではなく、登録審査の要件そのものであるため、システムの実装と当局対応を並行して進め、登録が下りるタイミングと本番稼働を合わせる段取りが不可欠です。eKYCベンダーの選定や本人確認フローの作り込み、疑わしい取引の検知・記録の仕組みは工数が大きく、これらを見込まずにスケジュールを引くと、システムは完成しているのに登録が下りず稼働できないという事態に陥ります。

チャージ手段・送金機能の実装範囲が納期に与える影響

電子決済システムの開発期間を見積もるうえで、加盟店側の決済導入とは異なる固有の変動要因が、「対応するチャージ手段の数」と「送金・出金といった資金移動機能の有無」です。この2つは、機能追加のたびに実装と検証が積み上がるため、スコープの線引き次第で納期が数ヶ月単位で変わります。

ウォレットへの入金手段を増やすことは利用者の利便性に直結しますが、チャージ手段ごとに実装工数と連携先の仕様が大きく異なります。クレジットカードからのチャージは、決済代行のAPIを使えば比較的短期間で組み込めますが、2025年3月末までに原則義務化されたEMV 3-Dセキュア（本人認証）への対応が必須です。一方、銀行口座からの即時引き落としチャージは、各金融機関が提供する更新系・参照系APIと接続する必要があり、銀行ごとに仕様や接続方式が異なるため、対応行を増やすほど開発工数と維持コストが膨らむ難所になります。さらに残高が一定額を下回ると自動で入金する「オートチャージ」を実装する場合は、チャージ失敗時の柔軟なリトライ処理（ダニング）まで作り込む必要があります。要件定義の段階で「初回リリースで対応するチャージ手段」と「第2フェーズで追加する手段」を明確に線引きしておかないと、対応行・対応手段が際限なく増え、納期が後ろ倒しになります。

利用者間で残高を送り合う送金機能や割り勘機能、残高を銀行口座へ払い出す出金機能は、電子決済システムに大きな付加価値をもたらす一方で、開発期間を最も押し上げる要素でもあります。送金では、送り手の残高が減る前に受け手の残高が増えてしまうと「二重に残高が増える」「マイナス残高になる」といった致命的な不整合が起こり得るため、ピーク時の大量アクセス下でも正確に機能する厳密な排他制御とトランザクション管理を作り込む必要があります。加えて、前述のとおり送金・出金機能を持たせること自体が資金移動業登録の要件に直結するため、eKYCやAML対応まで含めた大規模な追加開発が発生します。逆に、初回リリースでは支払い機能に絞り、送金・割り勘・出金は登録が整った第2フェーズ以降に回すと決めれば、開発期間を大きく圧縮できます。この機能範囲の判断は、納期とコストの両方を最も大きく動かす経営判断だと捉えるべきです。

開発手法による期間差と納期遅延の典型要因

同じ規模の電子決済システムであっても、採用する開発手法と、遅延要因への備え方によって、初回稼働までの期間は大きく変わります。残高というお金の根幹はウォーターフォール的に固め、チャージ手段や周辺機能の拡張はアジャイル・MVP的に進めるハイブリッド型が、電子決済システム開発における現実的な進め方です。

残高元帳やトランザクション整合性、供託残高の集計といったお金の根幹部分は、後から変更すると全利用者の残高計算に影響が及ぶため、上流工程で要件を丁寧に洗い出し、資金決済法の要件も踏まえて設計してから実装に入る、ウォーターフォール的な進め方が適しています。一方で、対応チャージ手段の追加、UI改善、キャンペーン機能といった周辺部分は、MVP（実用最小限の製品）やアジャイルの考え方を組み合わせることで初回リリースまでの期間を短縮できます。具体的には、まず最も利用頻度の高いチャージ手段と加盟店決済の正常系、基本的な取消処理に絞ったMVPを構築して一部利用者に先行公開し、その後、利用状況を見ながら送金・割り勘や低頻度のチャージ手段を段階的に追加していきます。反対に、すべての機能と例外処理を最初から作り込もうとすると、要件定義が終わらず稼働までに1年以上を要する典型的な失敗パターンに陥ります。

電子決済システムの納期遅延には、いくつかの典型パターンがあります。第一に、例外処理と突合の過少見積もりです。チャージ失敗・通信切断時のロールバック・返品時の残高の戻し・二重送金といった例外系の検証や、自社の残高合計と信託口座の入金額を突き合わせるリコンシリエーションの仕組みは、正常系より遥かに手間がかかります。これらを軽く見積もるとテスト工程が破綻し、稼働後に残高のズレが発覚する重大トラブルを招きます。対策は、例外処理を要件定義の段階で「システムで自動化するもの」「画面で手動対応するもの」「運用ルールで対応するもの」の3つに仕分け、テスト計画に例外系シナリオを網羅的に盛り込むことです。第二に、当局対応やeKYCベンダー選定の遅れです。資金決済法の届出・登録やeKYC連携は、着手が遅れると本番稼働のボトルネックになるため、システム実装と並行して早期に着手する必要があります。第三に、送金機能の後付けなどによるスコープクリープで、当初のスコープにない機能を途中で差し込むと、残高管理の根幹にまで影響が及び、遅延と予算オーバーを招きます。追加要望は必ず影響範囲を見積もり、フェーズを分けて対応するルールを最初に合意しておくことが重要です。

まとめ

本記事では、電子マネー・プリペイド・コード決済を発行・運営する事業者側の視点で、利用者の残高を管理するウォレット・電子決済システムの開発期間・スケジュール・納期を解説しました。開発期間の目安は、自社経済圏限定のハウス電子マネーで約4〜6ヶ月・1,000万円から数千万円規模、複数加盟店展開のコード決済や送金・出金対応の資金移動業型では半年から1年以上・数千万円から数億円規模と、発行するバリューの性質と作り込みの深さによって大きく変わります。工程は要件定義・バリュー設計から始まり、残高元帳・トランザクション整合性の設計、チャージ／決済／精算フローの実装、eKYC・不正検知の組み込み、結合テスト、当局対応・リリースへと進み、お金を扱うがゆえにテスト工程が全体の3〜4割を占めます。期間を左右する固有要因は、資金決済法の届出・登録や供託残高集計といった当局対応、対応するチャージ手段の数、そして送金・割り勘・出金といった資金移動機能の有無です。納期遅延の典型要因は、例外処理・突合の過少見積もり、当局対応・eKYCベンダー選定の遅れ、送金機能の後付けによるスコープクリープの3つでした。残高の根幹はウォーターフォールで固め、周辺機能はMVP・アジャイルで段階的に進めるハイブリッド型が現実的です。加盟店側で決済を受け付ける仕組みについては別記事「決済システム開発」「オンライン決済システム開発」も参照してください。まずは自社が発行するバリューの性質と機能範囲を整理し、資金決済法上の位置づけを見極めることから始めましょう。

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

株式会社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を創業。