電子マネーシステム開発の発注/外注/依頼/委託方法について

電子マネーシステムの発注・外注では、既存ブランドを受け付ける連携か、自社残高を発行する基盤かを最初に分けることが成功の条件です。

電子マネーを店舗、EC、スマートフォンアプリへ組み込みたい企業にとって、発注前の要件整理は費用と納期を左右する重要な工程です。この記事では、発注形態の選び方、RFPに書くべき内容、契約形態、費用相場、委託先の選び方、見積書の比較方法まで、外注を進める実務の順番に沿って解説します。成功系だけでなく、通信断や二重決済、取消、返金、入金差異の扱いまで確認できる状態を目指します。

▼全体ガイドの記事
・電子マネーシステム開発の完全ガイド

電子マネーシステムの全体像を整理する

電子マネーシステムという言葉には、複数の決済サービスを店舗やECで利用できるようにする仕組みと、企業が自社の残高やデジタル商品券を発行・管理する仕組みの両方が含まれます。両者は必要な機能、法務確認、開発費、運用責任が大きく異なるため、同じ見積条件で比較してはいけません。

Suica、楽天Edy、WAON、nanaco、iD、QUICPayなど、すでに利用者が保有している電子マネーを自社の店舗やECで受け付ける場合は、決済代行会社（PSP）、マルチ決済端末、クラウド型の接続サービスを利用する方法が基本です。発注対象は、決済サービスとの契約だけではありません。POSやECの注文情報との連携、決済成功後の売上確定、取消・返金、会計への仕訳、入金消込、管理画面、障害時の問い合わせ窓口まで含めて整理します。

店舗中心であれば、端末とサービスセンターを接続するASP型が候補になります。NTTデータのADAPTIS In-Storeのように、POSとサービスセンターを接続し、店舗側で決済サーバーを設置・運用しない方式もあります。自社で保有する範囲が小さくなるほど導入は早くなりますが、対応ブランド、端末機種、入金サイクル、カスタマイズの限界を契約前に確認することが大切です。

商業施設のハウスマネー、自治体のデジタル商品券、企業独自のポイント残高、会員向けのプリペイド残高を発行する場合は、利用者や加盟店の管理まで自社の業務になります。会員登録、本人認証、チャージまたは付与、残高照会、利用履歴、加盟店管理、手数料計算、精算、返金、利用停止、監査ログなどを一つの業務基盤として設計します。

特に残高を扱うシステムでは、同じ取引を二度処理しない冪等性、残高と取引履歴を追跡できる台帳、通信が途切れた場合の再送、処理途中で失敗した場合の補償処理が欠かせません。前払式支払手段に該当する可能性がある場合は、資金決済法上の自家型・第三者型の区分や、届出・登録、発行保証金などを専門家と確認します。金融庁は2025年にも前払式支払手段に関する内閣府令などの改正を公表しているため、過去のチェックリストだけで判断しないことが必要です。

電子マネーシステムの発注・外注を進める順番

発注を急いで開発会社に相談すると、会社ごとに前提が違う提案が届き、価格だけでは優劣を判断できなくなります。先に事業の目的と決済範囲を決め、その後にRFPを作成し、同じ前提で提案と見積を受ける流れにすると、比較の精度が上がります。

最初に決めるのは、電子マネーを導入すること自体ではなく、何を改善したいのかです。レジの会計時間を短縮したいのか、会員の再来店を増やしたいのか、自治体給付を利用しやすくしたいのかで、必要な機能は変わります。店舗だけで使うのか、ECでも使うのか、アプリに残高を表示するのか、複数店舗・複数加盟店で利用するのかも明確にします。

利用シーンは、顧客が決済を開始してから売上を確定し、利用者と加盟店に結果を表示するまでを一連の流れで書きます。たとえば店舗では、会計金額の提示、端末へのタッチ、承認結果の受信、POSの売上確定、レシート発行、日次締め、入金確認までが対象です。ECでは、注文作成、決済画面、非同期通知、在庫確保、注文取消、返金、チャージバックの扱いまで含めます。

既存ブランドの決済を短期間で導入するなら、PSPのAPI連携やマルチ決済端末を利用する方法が有力です。社内に決済専門の運用担当者が少なく、標準機能で要件を満たせる場合は、クラウドやASPを選ぶことで、サーバー運用やブランド追加の負担を抑えられます。端末サービスを選ぶ場合は、複数の契約を一本化できるか、POSとの連携方式が合うか、端末交換や通信障害の窓口が明確かを確認します。

自社残高や独自の加盟店精算が競争力になる場合は、発行プラットフォームを採用し、足りない部分だけを追加開発する方式が現実的です。業務が特殊で、既製サービスでは取引状態、精算ルール、権限、外部接続を満たせない場合に限り、スクラッチ開発を検討します。最初から全機能を自社開発するより、代表ブランド・代表店舗・限定会員を対象にした検証版で、決済の成立と異常系の動きを確かめる方が安全です。

開発会社へ委託した後は、いきなり全店舗へ展開せず、サンドボックスとパイロット店舗で確認します。まず代表ブランドを1〜2種類に絞り、少額の決済、取消、返金、通信断、タイムアウト、同じ要求の再送、端末の再起動、締め処理、入金差異を試験します。成功した取引だけを確認すると、本番で最も困る失敗時の責任分界が見えないためです。

パイロットでは、決済成功率、処理時間、取消率、返金完了までの時間、入金差異、問い合わせ件数を計測します。現場スタッフが迷わず使えるか、管理者が取引を検索して調査できるか、障害時に利用停止や再処理を行えるかも評価します。問題を修正した後に対象店舗を段階的に増やし、運用手順書と問い合わせ窓口を整えてから本番展開へ移行します。

RFPと要件整理で発注条件を揃える

RFPは、開発会社へ希望を伝える資料ではなく、各社が同じ前提で提案できるようにする発注条件書です。仕様を細部まで決め切る必要はありませんが、対象範囲、前提、制約、評価基準、納品物を明記します。曖昧なまま「電子マネーに対応したい」とだけ書くと、端末導入だけの提案と、アプリ・台帳・精算を含む提案が混在します。

RFPの冒頭には、事業目的、対象顧客、対象店舗、対応チャネル、導入予定時期、想定取引件数、月商、ピーク時間帯、既存システムの構成を書きます。次に、対応するブランド、前払い・後払いの区分、チャージの有無、利用上限、返金方法、加盟店への入金サイクル、手数料の計算方法を記載します。複数ブランドを扱う場合は、ブランドごとに利用可能なチャネルと取消・返金の条件が異なる点も明記します。

機能要件は、会員登録・認証、残高照会、決済、取消、返金、履歴、領収情報、加盟店管理、精算、レポート、問い合わせ対応に分けます。非機能要件には、可用性、応答時間、同時実行数、バックアップ、監視、ログ保存期間、災害復旧目標、保守時間、サポート体制を記載します。カード情報を扱う可能性がある場合は、PCI DSSの対象範囲と、PSP・開発会社・自社の責任分界を提案書に含めてもらいます。

POS、EC、アプリ、会計、CRM、在庫、会員基盤をどの方向に連携するかをRFPへ書きます。決済結果を同期APIで受けるのか、Webhookなどの非同期通知を使うのか、日次ファイルで精算するのかによって、必要な設計と監視が変わります。取引ID、注文ID、会員ID、加盟店ID、決済ブランド、取引状態をどのシステムが正とするのかも決めておきます。

異常系は、通信断、端末の電源断、応答遅延、同じ決済要求の二重送信、承認後のPOS障害、返金失敗、残高不足、締め処理の再実行、加盟店の入金先変更まで洗い出します。各ケースについて、利用者へ見せるメッセージ、取引を再実行できる条件、手動調査の方法、誰が返金を承認するかを決めます。開発会社には、異常系テストの観点表と試験結果を納品物として求めると、口頭説明だけで終わりません。

提案を評価するときは、見積総額だけでなく、要件適合度、決済・法務の経験、障害時の運用、セキュリティ、開発体制、保守費、拡張性を分けて採点します。たとえば、要件適合度30点、技術・セキュリティ25点、体制20点、費用15点、実績10点のように配点を決めると、安価ですが重要要件が抜けた提案を選びにくくなります。

提案書には、前提条件、対象外、追加費用が発生する条件、想定する自社作業、再委託先、納期の根拠を書いてもらいます。デモやサンプルAPIを確認し、管理画面で取引を検索できるか、返金の承認経路を設定できるか、失敗した取引を追跡できるかを確かめます。評価時点で不明な点が残る場合は、契約後に解決するのではなく、質問回答書に記録して見積条件へ反映します。

契約形態と責任分界を発注前に決める

電子マネーの外注では、開発会社との契約だけでなく、PSPやブランド事業者、端末会社、クラウド事業者との契約が重なります。誰が決済を承認するのか、誰が残高を管理するのか、誰が加盟店へ入金するのか、障害時に誰が利用者へ告知するのかを契約書と運用設計書の両方に落とし込みます。

要件、画面、API、試験範囲、納品物、受入条件を明確にできる部分は、請負契約で依頼しやすくなります。固定価格を選ぶ場合でも、何をもって完成とするかが曖昧なら、変更要求が追加費用や納期延長に変わります。受入条件には、機能試験だけでなく、性能、セキュリティ、異常系、ログ、バックアップ、運用手順書、ソースコードや設定情報の引き渡しを含めます。

請負契約に向くのは、標準的なAPI連携や、仕様が整理された管理画面の開発です。一方、PSPの審査やブランド接続の開始時期が未確定で、検証しながら要件を詰める場合は、最初から全工程を固定価格にすると双方が無理な前提を置きやすくなります。審査結果や技術検証に左右される部分は、契約を分ける方法もあります。

準委任契約は、専門家の稼働や作業支援を依頼する形で、要件定義、技術検証、アジャイル開発、運用改善に向いています。電子マネーのように外部審査、ブランド仕様、現場運用の確認を並行して進める案件では、初期の要件定義とプロトタイプを準委任で行い、確定した機能を請負で開発する組み合わせが有効です。

準委任では、成果物の完成を一方的に保証する契約ではないため、作業範囲、稼働時間、会議体、報告方法、意思決定者、優先順位の決め方を明記します。担当者が作業した時間だけが積み上がり、検証結果や設計判断が残らない状態を避けるため、要件一覧、課題管理表、設計書、試験観点表などを定例で更新します。

責任分界では、アプリやPOSの障害、PSPの障害、ブランド側の停止、通信回線の断、端末故障、入金処理の遅延を分けます。障害を検知する主体、一次切り分けの担当、エスカレーション先、復旧目標、利用者への告知者、返金の実行者を表にすると、契約後の押し付け合いを防げます。SLAを設定する場合は、稼働率だけでなく、受付時間、初動時間、復旧目標、計画停止の扱い、違反時の対応も確認します。

既存会員やポイントを移行する場合は、移行元と移行先のデータ項目、残高の基準日時、重複会員の扱い、移行後の照合、誤移行時の戻し方を定めます。データを受け渡す形式、暗号化、保管期間、削除証跡、個人情報の委託範囲も確認します。契約終了時に、取引履歴、監査ログ、設定、鍵、バックアップ、ソースコードをどこまで返却・消去するかも、発注時に決めるべき条件です。

電子マネーシステムの費用相場とコスト内訳

電子マネーの費用は、決済手数料とシステム開発費を分けて考えます。既存サービスの導入だけなら初期費用を抑えられますが、独自の残高、アプリ、加盟店精算、監査、障害対応まで作り込むと、開発費は数百万円から数千万円へ広がります。以下は公開料金と類似業務システムから算出した発注時の目安であり、ブランド数、チャネル、取引量、法務・セキュリティ要件で変動します。

既存のPSPや決済端末を導入するだけなら、初期費用は0〜15万円程度、期間は1〜4週間が一つの目安です。端末代が無料でも、月額利用料、通信費、ブランドごとの決済手数料、電子マネー機能の追加料金、審査・設置費用が発生する場合があります。PayPayが2026年5月時点で公表しているマルチ決済端末の例では、端末費用0円、月額1,980円から、電子マネー利用時は月額1,020円・台、ブランドにより決済手数料が異なる料金体系です。これは一社の公開例であり、全サービスの相場を示すものではありません。

既存のEC、POS、アプリへ電子マネーAPIを連携する開発費は、30万〜150万円程度、期間は1〜3か月程度が目安です。決済画面、注文状態、Webhook、取消・返金、テスト環境まで含め、UIの作り込みや複数ブランドの追加で100万〜300万円程度へ上がることもあります。自社ハウス電子マネーやデジタル商品券は300万〜1,000万円程度、3〜6か月程度、本格的な発行・加盟店・精算基盤は1,000万〜5,000万円以上、6〜12か月以上を想定します。全国規模で高可用性、災害対策、24時間監視が必要な場合は、5,000万円以上かつ12〜24か月以上になることもあります。

ランニングコストには、決済手数料、端末・通信費、PSPの月額利用料、クラウド費、監視、保守、脆弱性診断、ログ保管、バックアップ、問い合わせ対応、ブランド追加、返金・チャージバック、加盟店精算、振込手数料が含まれます。見積書に「保守一式」とだけ書かれている場合は、対応時間、対象範囲、月の作業時間、障害対応の優先度、追加開発との区別を確認します。

市場全体の利用規模を把握する材料として、経済産業省によれば2025年のキャッシュレス決済額は162.7兆円、決済比率は58.0%でした。そのうち電子マネーは6.0兆円、構成比3.7%です（出典: 経済産業省「2025年のキャッシュレス決済比率を算出しました」、2026年3月）。電子マネーはカードやコード決済と競合していますが、一定規模の利用が継続しているため、導入後の取引量と手数料を事業計画に置いて判断します。

たとえば月商100万円で決済手数料が2.5%なら、手数料は月2万5,000円です。月商1,000万円なら月25万円となり、月額利用料や保守費を含めると、料率の差が年間コストに大きく影響します。実際の料率はブランド、業種、売上規模、契約プランで変わるため、RFPには月商の想定、平均単価、月間件数、繁忙期の取引件数を記載し、固定費と変動費を分けて提示してもらいます。

開発費だけで判断せず、3年間の総保有コストで比較します。初期開発費、端末・設定費、PSPやクラウドの月額、決済手数料、保守、監視、法務・審査、セキュリティ診断、追加ブランド、データ移行、終了時のデータ返却を合算します。安い見積でも、返金機能や障害時の調査が別料金なら、本番運用後に予算を超える可能性があります。

委託先の選定と見積比較で確認するポイント

委託先は、知名度や見積の安さだけでなく、予定している方式に合うかで選びます。既存ブランドのオンライン連携に強いPSP型、店舗端末と多店舗運用に強いASP型、自社残高やデジタル商品券に強い発行プラットフォーム型、複雑な精算や大規模基盤を扱えるSI型を分けて比較すると、候補を絞りやすくなります。

面談では「決済システムの実績があります」という説明だけでなく、自社のケースに近い実績を確認します。店舗端末なのかEC APIなのか、自社残高なのか、加盟店精算まで含むのか、何店舗・何件規模だったのか、どの工程を担当したのかを聞きます。実績を開示できない場合でも、匿名化した構成図、障害対応の例、テスト観点、運用体制を示してもらうと、経験の深さを判断できます。

対応ブランドは「接続できる」と「希望するチャネルで安定運用できる」を分けて確認します。店舗端末で使えるブランドが、EC APIやアプリ内決済でも使えるとは限りません。ブランド追加時の審査期間、API仕様変更の通知、サンドボックスの有無、取消・返金の期限、入金データの形式、複数ブランドの一括照合が可能かも確認します。

見積書を受け取ったら、機能名だけでなく作業内容、工数、単価、前提、対象外を照合します。要件定義、UI設計、API連携、POS・EC改修、台帳、管理画面、精算、テスト、移行、リリース、監視、ドキュメントを分けてもらいます。「電子マネー対応」という一行に、どこまで含まれているかが会社ごとに違うためです。

比較表には、初期費用、月額固定費、従量費、決済手数料、端末費、審査費、保守費、追加ブランド費、返金・再処理費、障害対応費を並べます。さらに、納期、体制、再委託、知的財産権、データ保管場所、契約終了時の移行支援、SLA、瑕疵対応を並べると、価格以外の差も見えます。極端に安い項目がある場合は、対象外として別発注になる作業がないかを質問します。

カード情報を自社環境へ保存する設計は、PCI DSSの対象範囲を広げる可能性があります。PCI Security Standards Councilが公開するPCI DSS v4.0.1を基準に、カード番号を保持しないトークン化やホスト型画面を採用できるか、ログに機密情報が残らないか、管理者の多要素認証、最小権限、職務分離、鍵管理、脆弱性対応が実装されるかを確認します。PCI DSS v4.0で段階的に扱われていた要件が2025年3月31日以降に有効となっているため、古い資料だけで判断しないことが必要です。

運用評価では、24時間監視が必要か、夜間の障害通知を誰が受けるか、取引を検索して再処理できるか、残高差異を調査できるかを確かめます。利用停止の判断者、返金の承認者、加盟店への連絡方法、障害情報の公開基準、月次の利用状況レビューも決めます。開発会社が優れていても、自社に運用の意思決定者がいなければ、障害発生時に復旧が遅れるためです。

よくある質問

電子マネーシステムの外注では、導入費用、開発会社、法規制、納期について同じ疑問が繰り返し出ます。発注前に判断しやすいよう、特に相談の多い質問へ直接回答します。

既存PSPや端末の導入だけなら初期0〜15万円程度、EC・POS・アプリへのAPI連携なら30万〜150万円程度、自社残高を持つ基盤なら300万〜1,000万円程度が目安です。本格的な加盟店精算、複数チャネル、高可用性、厳格な監査を含めると1,000万〜5,000万円以上になる場合もあります。決済手数料、月額、保守、監視、審査、返金、セキュリティを含めた総額で見積を比較します。

相談はできますが、RFPがない状態で複数社の価格と提案を正確に比べることは難しくなります。最低限、既存ブランドの導入か自社残高の発行か、利用チャネル、対応ブランド、想定取引量、希望時期、既存システム、返金・精算の条件を整理します。要件が固まっていない場合は、要件定義や技術検証を先行する契約を提案してもらう方法があります。

必要です。利用者から事前に金銭を受け取り、商品やサービスの代金に使える残高を発行する場合は、前払式支払手段に該当する可能性があります。自社内の利用に限定されるか、第三者の加盟店で使えるか、払戻しの扱いはどうかで確認事項が変わるため、発注前に法務担当者や専門家へ相談し、必要な届出・登録、表示、資産保全、利用規約を整理します。

既存ブランドを標準機能で受け付けるだけなら、決済代行会社や端末サービスを直接利用する方法が適しています。POS・EC・アプリとの複雑な連携、自社残高、加盟店精算、独自の会員体験が必要なら、決済に詳しいシステム開発会社を加えます。両者を別々に発注する場合は、API仕様、障害窓口、返金、入金データ、責任分界を一つの設計書に統合できる体制を選びます。

まとめ

電子マネーシステムを発注・外注するときは、最初に「既存ブランドを受け付けるのか」「自社の残高を発行するのか」を分けます。次に、店舗・EC・アプリの利用シーン、対応ブランド、取引量、返金・精算、法務、セキュリティ、障害時の運用をRFPへ書き、同じ条件で複数社の提案を比較します。

見積依頼の前に、決済の目的、対象顧客、対象店舗、対応ブランド、利用チャネル、月間取引件数、希望時期を一枚にまとめます。RFPには成功系だけでなく、通信断、二重送信、タイムアウト、取消、返金、残高差異、入金遅延の試験と運用も含めます。費用は開発費だけでなく、手数料、端末、クラウド、保守、監視、法務、セキュリティを含む3年間の総額で比較します。

契約では、請負と準委任の範囲、成果物、受入条件、変更管理、障害時の責任分界、SLA、データ移行、契約終了時の返却条件を明確にします。候補会社には、過去の類似実績だけでなく、異常系テスト、取引調査、返金、入金消込、セキュリティ、運用引き継ぎまで提案してもらいます。小さなパイロットで検証してから段階展開すれば、電子マネーシステムを安全に発注し、利用者と現場の双方に定着させやすくなります。

▼全体ガイドの記事
・電子マネーシステム開発の完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

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

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

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

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

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。