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

電子マネーシステムの発注は、方式の選定、要件整理、契約と責任分界の確定、パイロット検証の順に進めると、決済と運用の条件をそろえられます。

発注形態、RFPと契約、費用相場、委託先の選び方を順に見ていきます。全体像は電子マネーシステム開発の完全ガイドもご覧ください。

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

・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。

電子マネーシステムの全体像

電子マネーシステムには、既存の決済サービスを店舗やECで使う仕組みと、自社残高やデジタル商品券を発行・管理する仕組みがあります。両者は必要機能、法務確認、開発費、運用責任が異なるため、同じ見積条件では比べられません。

既存ブランドを受け付ける決済連携

利用者が持つSuica、楽天Edy、WAON、nanaco、iD、QUICPayなどの電子マネーを、自社の店舗やECで受け付ける場合が対象です。その際は、決済代行会社（PSP）、マルチ決済端末、クラウド型接続サービスを使う方法が基本になります。

• 店舗中心：端末とサービスセンターをつなぐASP型が候補です。
• 導入速度：自社で持つ範囲が小さいほど、導入を早く進められます。
• 契約前の確認：ブランド、端末、入金周期、カスタマイズ範囲です。

NTTデータのADAPTIS In-Storeのように、POSとサービスセンターをつなぎ、店舗側で決済サーバーを設置・運用しない方式もあります。

発注範囲には、POSやECとの連携、決済成功後の売上確定、取消・返金、会計仕訳、入金消込を含めます。管理画面と障害時の窓口も、あわせて決めておきます。

自社残高・デジタル商品券を発行する基盤

商業施設のハウスマネーや自治体のデジタル商品券、独自ポイント、会員向けプリペイド残高を発行する場合は、利用者と加盟店の管理も自社の業務になります。

• 利用者機能：会員登録と本人認証、チャージまたは付与、残高照会、履歴を扱う機能です。
• 加盟店業務：加盟店の管理、手数料計算、精算、返金、利用停止を設計する範囲です。
• 監査対応：取引履歴と操作を追跡できるログを残すことです。

同じ取引の二重処理を防ぐ冪等性と残高台帳が欠かせません。加えて、通信断時の再送と失敗時の補償処理も必要です。

前払式支払手段に該当する可能性がある場合は、資金決済法上の自家型・第三者型の別、届出・登録、発行保証金を、専門家と確かめます。

金融庁は2025年にも、関連する内閣府令などの改正を公表しています。そのため、過去のチェックリストだけで判断しないことが必要です。

電子マネーシステムの発注・外注の進め方

発注を急ぐと、各社の前提が異なる提案が届き、価格だけでは優劣を判断しにくくなります。先に事業目的と決済範囲を決め、RFPを作ってから見積を受けると、同じ前提で提案を比べられます。

事業目的と利用シーンの事前決定

目的によって必要な機能が変わるため、まず電子マネー導入の目的を定めます。会計時間の短縮と再来店の促進、自治体給付の利用促進では、求められる機能がそれぞれ違います。

• 利用場所：店舗、EC、アプリのどこで使うかです。
• 利用範囲：単独店舗か、複数店舗・加盟店かの区分です。
• 店舗の流れ：金額提示から入金確認までの順序です。
• ECの流れ：注文から、非同期通知、在庫、取消、返金、チャージバックまでを記す項目です。

利用シーンは、決済の開始から売上確定後、利用者と加盟店に結果を表示するまでを一連の流れとしてつなげます。店舗では、タッチから承認、POS確定、レシート発行、日次締めまでを順に確認します。さらに、ECでは決済画面の内容も利用シーンに含めます。

PSP・パッケージ・スクラッチの発注形態の選び方

発注形態は、必要な決済機能と社内の運用体制を基準に選びます。

• PSP・端末：既存ブランドを短期間で導入する場合に向いています。
• クラウド・ASP：標準機能で足りて、決済担当者が少ない場合、サーバー運用やブランド追加の負担を抑えられる形です。
• 発行基盤：自社残高や独自の加盟店精算を扱う場合に使います。
• スクラッチ：既製サービスで取引状態、精算ルール、権限、外部接続を満たせない場合に限り、検討の対象になります。

端末サービスを選ぶ場合は、契約の一本化、POSとの接続、端末交換、通信障害の窓口を確かめます。一方、自社残高や独自精算が競争力になる場合は、発行基盤を使い、足りない部分だけを追加で開発します。また、自社開発を広げる前に、代表ブランド、代表店舗、限定会員の検証版で、決済の成立と異常系を確かめておきます。

パイロット導入から本番展開まで

全店舗へ一斉に展開せず、サンドボックスとパイロット店舗で検証します。成功した取引だけでは、失敗時の責任分界が見えにくいためです。

検証では代表ブランドを1〜2種類に絞ります。

• 決済操作：少額決済、取消、返金を実際に試す項目です。
• 通信・端末：通信断やタイムアウト、再送、再起動が起きたときの動作です。
• 運用処理：締め処理と入金差異の確認です。

成功率、処理時間、取消率を計測します。さらに、返金時間、入金差異、問い合わせ件数も計測します。

加えて、現場の使いやすさを評価します。取引調査、利用停止、再処理についても確かめます。

問題を直したあとで、対象の店舗を段階的に増やします。運用手順書と問い合わせ窓口を整えてから、本番展開に進みます。

発注条件をそろえるRFPと要件整理

RFPは、各社が同じ前提で提案できるようにするための発注条件書です。仕様を細部まで決め切らなくても、対象範囲と前提、制約を明記すれば足ります。評価基準と納品物も、あわせて書いておきます。

たとえば、「電子マネー対応」とだけ書くと、端末導入だけの提案と、アプリや台帳、精算まで含む提案が混在します。

RFPに書く業務範囲と決済条件

会社ごとに提案の条件がぶれないよう、事業の前提から機能と運用の要件までを、RFPにそろえて記載します。

• 事業条件：目的や顧客、店舗、チャネル、時期を書きます。想定取引件数と月商も添えます。
• 決済条件：ブランド、前払い・後払い、チャージ、上限、返金、入金周期を記します。
• 機能要件：認証、残高、決済、取消・返金、履歴などを分けて記します。領収情報から問い合わせ対応までの機能も、別に書きます。
• 非機能要件：可用性、応答時間、同時実行、バックアップ、監視の条件です。ログ保存期間や災害復旧目標、保守時間、サポートも含みます。

ピーク時間帯と既存システムの構成も記します。また、ブランドごとに利用チャネルや取消・返金の条件が違うことも明記します。

カード情報を扱う可能性があるなら、PCI DSSの範囲と、PSP・開発会社・自社の責任分界を提案書に含めてもらいます。

データ連携と異常系の条件の明文化

POS、EC、アプリ、会計の連携方向を定めます。CRM、在庫、会員基盤も含めて、どちらからどちらへデータを渡すかを決めます。同期API、Webhookなどの非同期通知、日次ファイルのどれを選ぶかで、必要な設計と監視が変わります。

• 識別情報：取引、注文、会員、加盟店それぞれのIDを決める項目です。
• 正となるデータ：決済ブランドと取引状態を、どのシステムで管理するかです。
• 異常時の対応：再実行の条件、手動での調査、返金の承認者です。

通信断や端末の電源断、応答遅延、二重送信を洗い出します。さらに、承認後のPOS障害、返金失敗、残高不足も対象です。

各ケースで、利用者に何を表示するか、どの条件で再実行できるかを決めます。手動調査の方法と返金承認者も、あわせて決めておきます。

締め処理の再実行や、加盟店の入金先の変更も対象になります。異常系のテスト観点表と試験結果は、納品物に含めます。

提案評価の基準の事前設定

見積総額に加えて、適合度や決済・法務の経験、障害運用を採点します。さらに、セキュリティや体制、保守費、拡張性も評価の対象にします。

• 要件適合度：30点を配点する例です。
• 技術・セキュリティ：25点とする例もあります。
• 体制・費用・実績：20点、15点、10点と配点する例があります。

提案書には、前提や対象外、追加費用の条件を書いてもらいます。自社作業、再委託先、納期の根拠も書いてもらいます。

デモやサンプルAPIで、取引検索、返金承認、失敗取引の追跡を確かめます。

不明点は契約後に持ち越さないよう、質問回答書に記録し、見積条件に反映します。

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

開発会社との契約に加えて、PSPやブランド事業者との契約が重なる場合があります。端末会社やクラウド事業者との契約が加わることもあります。

誰が決済承認や残高管理を担うかを、契約書と運用設計書に記します。加盟店入金と障害時の告知についても、担当を書いておきます。

請負契約の成果物と受入条件

請負にする範囲は、成果物と完成の判定条件をはっきり決められるかで選びます。

• 向く作業：標準API連携や、仕様が定まった管理画面です。
• 定める条件：要件、画面、API、試験、納品物、受入条件です。
• 受入確認：機能、性能、セキュリティ、異常系、ログ、バックアップまでを含みます。

固定価格でも、完成条件が曖昧なままだと、変更要求が追加費用や納期延長につながります。受入条件には、運用手順書やソースコード、設定情報の引き渡しも含めます。

PSP審査やブランド接続の開始時期がまだ決まっていない場合は、全工程を固定価格にせず、審査や技術検証の契約を分ける方法もあります。

検証と継続改善に向く準委任契約

準委任は、専門家の稼働や作業支援を依頼する契約です。

• 向く業務：要件定義、技術検証、アジャイル開発、運用改善です。
• 契約の組み合わせ：初期の要件定義と試作は準委任、確定した機能は請負で開発します。
• 定める項目：作業範囲、稼働時間、会議体、報告方法、意思決定者、優先順位の決め方です。

外部審査、ブランド仕様、現場運用を並行して確認する案件で有効です。ただし、成果物の完成を一方的に保証する契約ではありません。

作業時間だけが積み上がらないよう、定例で更新する資料を決めておきます。要件一覧や課題管理表、設計書、試験観点表がその対象です。

障害・返金・データ移行の責任分界

契約後の混乱を防ぐため、障害対応とサービス水準、データ移行の担当範囲をあらかじめ整理します。

• 障害の対象：アプリ、POS、PSP、ブランドを分けます。回線、端末、入金処理も切り分けて扱います。
• 対応担当：検知、一次切り分け、告知、返金、復旧を担う人を決める項目です。
• SLA：稼働率、受付時間、初動、復旧目標、計画停止の取り決めです。

会員やポイントを移行する場合は、項目や残高の基準日時、重複会員を決めておきます。移行後の照合と、誤移行時の戻し方も定めます。

データの形式や暗号化、保管期間、削除の証跡を確認します。個人情報の委託範囲も、同じように確かめます。

契約終了時の取引履歴、ログ、設定、鍵の扱いも、発注時に決めます。バックアップやソースの返却・消去も対象です。

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

電子マネーの費用は、決済手数料と開発費を分けて考えます。既存サービスの導入は、初期費用を抑えやすい傾向があります。一方で、独自残高やアプリ、加盟店精算、監査、障害対応まで作り込むと、数百万円から数千万円へ広がります。

次に示す金額は、公開料金と類似業務システムから算出した発注時の目安です。ブランド数やチャネル、取引量、法務・セキュリティ要件によって変わります。

方式別の初期費用と開発期間

導入方式によって必要な初期費用と期間が異なるため、規模ごとの目安を比べます。

• PSP・端末：初期0〜15万円程度、期間1〜4週間が目安です。
• API連携：30万〜150万円程度、期間1〜3か月が目安です。
• 自社残高：300万〜1,000万円程度、期間3〜6か月が目安です。
• 本格基盤：1,000万〜5,000万円以上、6〜12か月以上を想定します。

端末が無料でも、月額や通信、ブランド別の手数料がかかる場合があります。電子マネーの追加や審査、設置費も、別途必要になることがあります。

たとえば、PayPayの2026年5月時点の公開例では、マルチ決済端末は端末費0円、月額1,980円からです。電子マネー利用は月額1,020円・台で、ブランドごとに手数料が異なります。これは一社の公開例で、全サービスの相場を示すものではありません。

API連携には、決済画面や注文状態、Webhook、取消・返金、テスト環境が含まれます。UIを作り込む場合や、複数ブランドを追加する場合は、100万〜300万円程度になることがあります。さらに、全国規模で高可用性や災害対策、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・アプリ連携なら30万〜150万円程度が目安です。

自社残高基盤は300万〜1,000万円程度です。加盟店精算や複数チャネル、高可用性、厳格な監査まで含めると、1,000万〜5,000万円以上になる場合もあります。

決済手数料や月額、保守、監視を含めた総額で比べます。審査、返金、セキュリティも総額に含めます。

RFPがなくても開発会社へ相談できますか？

相談はできますが、RFPがないと、複数社の価格や提案を正確に比べにくくなります。

まず、既存ブランドか自社残高か、チャネル、ブランド、取引量を整理します。希望時期、既存システム、返金・精算条件も書き出します。

要件が固まっていない場合は、要件定義や技術検証を先に行う契約を提案してもらえます。

自社電子マネーを発行するとき法規制の確認は必要ですか？

必要です。事前に金銭を受け取り、商品やサービスに使える残高を発行する場合は、前払式支払手段に該当する可能性があります。

自社内か第三者加盟店か、払戻しの扱いによって、確認事項が変わります。法務担当者や専門家と、届出・登録、表示、資産保全、規約を整理します。

委託先は決済代行会社とシステム開発会社のどちらを選ぶべきですか？

既存ブランドを標準機能で扱うなら、決済代行会社や端末サービスが適しています。一方で、複雑な連携や自社残高、加盟店精算、独自の会員体験が必要なら、開発会社を加えます。

別々に発注する場合は、API、障害窓口、返金、入金データ、責任分界を一つの設計書にまとめられる体制を選びます。

まとめ

発注時は、まず既存ブランドの受付か自社残高の発行かを分けます。RFPには、店舗・EC・アプリ、ブランド、取引量の条件を書きます。返金・精算、法務、セキュリティ、障害運用も書き、同じ条件で提案を比べます。

発注前に決めるべき最初の一歩

見積依頼の前に、目的や顧客、店舗、ブランド、チャネルを一枚にまとめます。月間取引件数と希望時期も書き添えます。

RFPには、成功系に加えて、通信断、二重送信、タイムアウトの試験を含めます。取消、返金、残高差異、入金遅延については、試験と運用の両方を書きます。

費用は、開発費に加えて、手数料や端末、クラウドを含めます。保守や監視、法務、セキュリティも加えた3年間の総額で比べます。

委託先との合意を成果につなげる方法

発注の成果を運用につなげるため、契約条件、委託先への依頼、展開方法を一続きで合意します。

• 契約条件：請負か準委任かの範囲と、成果物、受入条件を定めます。変更管理や障害責任、SLA、移行、終了時の返却も決めます。
• 委託先への依頼：類似実績と異常系試験、取引調査を確かめます。返金、入金消込、セキュリティ、運用引き継ぎも確認します。
• 展開方法：小さなパイロットで検証し、段階的に展開して、利用者と現場への定着を図ります。

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

▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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