電子決済システムの開発期間は、発行するバリュー（残高）の性質、利用範囲、送金・出金の有無によって、約4〜6ヶ月から1年以上まで変わります。
規模別の期間の目安、工程別のスケジュール、資金決済法や機能範囲による影響の順に説明します。全体像は電子決済システム開発の完全ガイドもご覧ください。
▼全体ガイドの記事
・電子決済システム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
電子決済システム開発期間の全体像
期間の差は、発行するバリュー（残高）の性質と、自社で作り込む範囲から生じます。自社の店舗やアプリ内に利用範囲を限り、外部加盟店への精算機能を持たない構成なら、約4〜6ヶ月が目安です。費用の目安は1,000万円から数千万円規模です。
複数加盟店向けのコード決済や、送金・銀行出金付きの資金移動業型は、半年から1年以上かかります。ウォレットアプリや加盟店管理、精算バッチが必要になるうえ、他行口座APIや厳格なeKYCも欠かせません。
この大規模な構成の費用は、数千万円から数億円規模が目安です。また、残高を1円単位で扱うため、バグを防ぐテストだけで全体工数の30〜40%を占めることも珍しくありません。
規模別の開発期間の目安
利用範囲と機能によって、開発期間の目安は型ごとに次のとおり異なります。
- ハウスマネー型：自社経済圏内で使い、期間は約4〜6ヶ月
- コード決済型：複数加盟店に展開し、全体で半年前後
- 資金移動業型：送金・出金まで備え、全体で1年以上
小規模なケースは、ハウス電子マネーやプリペイド残高で、自社店舗やEC内に利用を限るものです。外部精算や個人間送金がないため、チャージ・利用・失効の管理に集中できます。
コード決済型では、加盟店の登録・管理、日次精算バッチ、銀行口座やクレジットカードからのチャージ連携が加わります。資金移動業型では、eKYCやマネーロンダリング対策、資金決済法に基づく資金保全も必要になります。費用は数千万円から数億円規模に達します。
期間を見積もるには、まず自社がどの型に当たるかを見極めることが出発点になります。
加盟店側の決済システムとの期間差
開発期間に差が出るのは、決済を受け付ける側か、サービスを発行する側かという立場の違いによります。
- 加盟店側：PSPのAPIを自社のレジやカートに統合
- 発行側：利用者残高の管理と加盟店精算を設計・実装
加盟店側は、決済代行会社（PSP）のAPIを組み込み、クレジットカードやコード決済を自社業務に統合します。一方、発行側は残高元帳を自社で持ち、チャージで増やした残高を決済で減らしたうえで、後日加盟店へ精算します。
加盟店側が決済結果を受け取るのに対し、発行側は残高というお金を発行・保管・移動させます。そのため、二重支払いの防止、残高の整合性、資金決済法への準拠など、金融機関に近い厳密さが求められます。この立場の違いが、加盟店側の決済導入より期間が長くなる最大の理由です。
要件定義から本番稼働までの工程別スケジュール
スケジュールを組むには、各工程の期間と、工程どうしの依存関係を把握する必要があります。
- 上流設計：要件定義とバリュー設計、残高元帳・整合性の設計
- 機能実装：チャージ・決済・精算フロー、eKYC・不正検知
- 検証と稼働：結合・受入テスト、当局対応、リリース
残高管理の設計が曖昧なまま実装に入ると、後工程で大きな手戻りが発生します。そのため、上流設計に十分な時間を確保することが、全体期間の安定につながります。
要件定義・バリュー設計フェーズ
最初に、発行する残高の性質と機能範囲を、発注側と開発会社で決めます。
- バリューと範囲：自社限定か、街中で使えるコード決済か
- 入出金機能：チャージ手段と送金・出金の有無
- 規模と法的位置づけ：利用者数・1日あたりの取引件数、前払式か資金移動業か
チャージ手段は、銀行口座・クレジットカード・コンビニ・ATMのどこまで対応するかを決めておきます。
この判断が後続工程の範囲と法規制対応を左右するため、法務や金融規制に詳しい担当者を早い段階から加えておきます。
送金を後から追加すると、要件が固まらないまま実装に進み、残高管理の根幹から作り直す可能性があります。そこで、上流の要件整理に数週間を割くことが、全体スケジュールの安定に直結します。
残高元帳・トランザクション整合性設計フェーズ
最も慎重に時間をかけるのは、残高元帳と取引整合性の設計です。この工程で、残高と取引履歴を常に一致させます。
- 履歴の追記：加算・減算の取引をジャーナルに記録
- 重複処理の防止：同じ取引IDの再処理を防ぐ冪等性
- 同時処理の制御：レコードロックで二重支払いを防止
- 一括の整合性：残高減算と売上加算を同一トランザクションで処理
利用者残高はUPDATEで上書きせず、加減算の履歴をINSERTで追記していく不変設計です。銀行の勘定系に近い考え方で、残高を全取引の集計と一致させ、突合や監査に備えます。
また、通信エラーで同じチャージや決済の要求が二度届いても、処理結果は1回分に保たれます。
残高の減算と売上の加算は、途中で失敗しても全て取り消せるよう、ACID特性を設計に含めます。この設計を軽視すると、二重加算や決済後も残高が減らない不整合がテストで見つかり、大幅な手戻りになります。
eKYC組み込み・テスト・リリースフェーズ
送金や出金がある資金移動業型では、本人確認と例外系テストを含めて稼働の準備を進めます。
- eKYC：API連携、本人確認画面、失敗時の再申請導線
- 一連の取引検証：チャージから精算までの同期を確認
- 稼働準備：届出・登録後に本番へ切り替え、段階公開も検討
口座開設に相当するeKYCでは、運転免許証などの書類と自撮り画像を照合します。さらに、専用ベンダーとの連携仕様の確認や、本人確認フローのUI実装にも期間がかかります。
結合・受入テストでは、残高が1円もずれないかを確認します。加えて、通信切断時のロールバックや返品時の残高返却も、サンドボックスで網羅的に検証します。
例外系の検証は正常系より時間がかかるため、テストが全体の3〜4割を占める前提で計画を立てます。
テストを終えて届出・登録も整った段階で本番へ切り替えます。必要に応じて一部の利用者へ先行公開し、そのうえで段階的に展開します。
資金決済法対応・当局対応が期間に与える影響
加盟店側は審査を受けますが、発行側は資金決済法上の届出・登録を行い、当局の監督や審査を受けます。当局対応は開発作業で短縮できず、どの機能が必要かが稼働時期を左右します。
前払式支払手段の届出と供託残高集計機能
前払式支払手段に該当する残高では、基準日時点の未使用残高を把握しておく必要があります。
- 基準日：毎年3月末と9月末
- 保全額：未使用残高の半額以上を供託
- 集計機能：基準日の特定時刻の残高を1円単位で出力
供託の義務は、未使用残高が基準額を超えた場合に生じます。そのため、システムは現在残高の合計だけでなく、基準日時点の正確な残高を遅滞なく出力する必要があります。さらに、休眠アカウントの失効や規約に基づく残高処理もバッチで行い、供託額の算定に使う集計値を確定します。
集計機能を後から付けると、基準日直前の急造になって正確性を欠き、リリース後の当局報告に支障が出るおそれがあります。そこで、要件定義の段階で法定帳票と報告要件を確認し、初期範囲に含めます。
資金移動業登録とeKYC・AMLの作り込み
送金や銀行口座への出金は前払式の枠を超えるため、規制のハードルが高い資金移動業の登録が必要になります。
- 資金保全：滞留資金の100%以上を供託・保全
- 本人確認：厳格なeKYCを組み込む
- 取引監視：AML/CFTのモニタリングに対応
これらは登録審査で求められる要件です。AML/CFTとは、マネーロンダリング・テロ資金供与対策を指します。このため、システム実装と当局対応を並行させ、登録時期と本番稼働を合わせます。
eKYCベンダーや本人確認フロー、疑わしい取引の検知・記録にも工数がかかります。対応が遅れると、システムが完成しても登録が下りず、稼働できない場合があります。
チャージ手段・送金機能の実装範囲が納期に与える影響
加盟店側の決済導入と異なり、期間はチャージ手段の数と送金・出金機能の有無で変わります。機能を足せば実装と検証が増えるため、スコープの決め方次第で数ヶ月単位の差が出ます。
チャージ手段ごとの実装差と納期への影響
ウォレットへの入金手段が増えると利便性は上がります。一方で、手段ごとに工数や連携先の仕様が異なるため、初回に対応する範囲を決めておきます。
- クレジットカード：決済代行APIを利用、EMV 3-Dセキュアに対応
- 銀行口座：金融機関ごとのAPI・接続方式に対応
- オートチャージ：失敗時のリトライ処理も実装
カードチャージは、比較的短い期間で組み込めます。ただし、本人認証は2025年3月末までに原則義務化されたため、対応が必要です。
銀行口座から即時に引き落とす場合は、金融機関ごとの更新系・参照系APIに接続します。仕様や接続方式は銀行ごとに異なるため、対応行が増えるほど、開発工数と維持コストが膨らみます。
残高が一定額を下回ると自動で入金するオートチャージでは、失敗時に備えた柔軟なリトライ（ダニング）が必要です。また、初回リリースと第2フェーズで対応する手段を線引きしておかないと、対応行が増え続けて納期が後ろ倒しになります。
送金・割り勘・出金機能の追加インパクト
送金・割り勘・出金は大きな付加価値をもたらす一方、開発期間を最も押し上げる要素です。
- 残高制御：同時アクセス下で排他制御を実装
- 規制対応：資金移動業登録、eKYC、AML対応を追加
- 段階導入：支払いに絞り、送金等を第2フェーズ以降へ
送金では、送り手の減算より前に受け手が増額されると、二重加算やマイナス残高が起こり得ます。ピーク時でも正確に処理できるよう、トランザクション管理を作り込みます。
送金・出金は資金移動業の登録に直結するため、eKYCやAML対応を含む大規模な追加開発も発生します。初回リリースを支払い機能に絞り、送金等は登録後の第2フェーズ以降に回せば、期間を圧縮できます。機能範囲の判断は、納期とコストを大きく動かす経営判断です。
開発手法による期間差と納期遅延の典型要因
同じ規模でも、手法と遅延対策によって初回の稼働時期は大きく変わります。残高の根幹はウォーターフォール、周辺機能はアジャイルやMVPで進めるハイブリッド型が現実的です。
残高の根幹はウォーターフォール、拡張はMVPの進め方
変更の影響が大きい残高の根幹と、追加しやすい周辺機能とでは、進め方を分けます。
- 根幹部分：要件と法規制を洗い出してから設計・実装
- 周辺部分：MVP・アジャイルで段階的に追加
残高元帳、取引整合性、供託残高集計は、後から変えると全利用者の残高計算に影響します。そのため、上流で要件を詰め、資金決済法の要件を踏まえて設計してから実装します。
チャージ手段の追加、UI改善、キャンペーンなどは、MVP（実用最小限の製品）やアジャイルを活用して進められます。
最初の範囲は、利用頻度の高いチャージ、加盟店決済の正常系、基本的な取消処理に絞ります。一部の利用者へ先行公開し、利用状況を見ながら、送金・割り勘や低頻度のチャージを追加していきます。
全機能と例外処理を最初から作ろうとすると、要件定義が終わらず、稼働まで1年以上かかる失敗につながります。
納期遅延の典型要因と対策
納期遅延には典型的なパターンがあり、例外処理や外部手続き、追加要望の影響を早く見積もることが対策になります。
- 例外処理の不足：要件定義で対応方法を仕分け、試験に含める
- 外部対応の遅れ：当局手続きとeKYC選定を実装と並行
- 範囲の拡大：影響を見積もり、追加要望を別フェーズへ分ける
第一の要因は例外処理と突合の過少見積もりです。正常系より手間がかかり、チャージ失敗や二重送金の検証が必要です。さらに、通信切断時のロールバックと返品時の返金も検証対象になります。
自社の残高と信託口座への入金額を照合するリコンシリエーションも整備します。見積もりが不足すると、テストが破綻して、稼働後に残高のずれが発覚する重大なトラブルを招きます。
例外処理は「自動化」「画面での手動対応」「運用ルール」の3つに仕分けます。そのうえで、テスト計画には例外系のシナリオを網羅的に盛り込みます。
当局対応やベンダー選定が遅れると、本番稼働を遅らせる要因になります。したがって、資金決済法の届出・登録やeKYC連携には、早い段階から着手します。
送金機能の後付けなどのスコープクリープは、残高管理の根幹に影響し、遅延と予算超過を招きます。
まとめ
電子マネー、プリペイド、コード決済を発行・運営する側の立場から、残高ウォレットの開発期間、工程、納期を整理しました。期間はバリューと機能範囲で変わります。
自社内で使うハウス電子マネーは約4〜6ヶ月、費用は1,000万円から数千万円規模が目安です。
複数加盟店向けのコード決済や送金・出金型は、半年から1年以上、費用は数千万円から数億円規模です。
工程は、要件・バリュー設計、元帳・整合性設計、機能実装の順に進みます。そのあとに、eKYC・不正検知、テスト、当局対応・リリースが続きます。
テストは全体の3〜4割を占め、期間には法定対応、チャージ手段、資金移動機能も影響します。
納期遅延の主因は3つです。例外処理・突合の過少見積もり、当局・eKYC対応の遅れ、送金機能の後付けによるスコープクリープです。
残高の根幹を先に固め、周辺機能をMVP・アジャイルで段階導入する進め方が現実的です。
加盟店側で決済を受け付ける仕組みは、別記事「決済システム開発」「オンライン決済システム開発」もご覧ください。
まず発行するバリューと機能範囲を整理し、資金決済法上の位置づけを見極めましょう。
▼全体ガイドの記事
・電子決済システム開発の完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。