プリペイドカード基幹システムの発注は、まず事業と資金の流れ、責任の範囲を整理してから進めます。方式を選び、RFPや提案の比較、契約、段階稼働へと順に進めると、追加費用や納期の遅れを抑えやすくなります。
▼全体ガイドの記事
・プリペイドカード基幹システム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
プリペイドカード基幹システムの全体像
プリペイドカード基幹システムは、事前に購入・チャージされた価値をカード番号や会員情報とひも付けるシステムです。利用の判定から精算、会計、監査まで、一貫して管理します。
残高はポイントより金銭性が高いため、二重チャージや通信タイムアウトも設計の対象になります。そのため、正常に使える画面だけでなく、取消、返金、障害復旧まで設計しておく必要があります。
残高台帳と取引状態を管理する中核
中核となる業務は、発行・チャージから残高の更新、利用承認までです。その後に、売上確定、加盟店精算、会計・監査が続きます。
取引の状態は、台帳で次のとおり管理します。
- 状態管理：保留、確定、取消、返金、失効を取引単位で保持します。
- 金額管理：円などの最小単位を整数で扱い、浮動小数点計算を避けます。
- 二重処理防止：取引IDや冪等キーで同じ要求の再送を判別します。
応答がなく、画面上は失敗に見えても、金融機関側では成功している場合があります。そのため、単純に再送すると二重チャージにつながります。
通信異常時の処理状態は、台帳の状態管理とは別に、受付、保留、確定、要調査に分けて扱います。そのうえで、再照会と突合によって確定させる業務ルールを、RFPに明記しておきます。
発行方式ごとの責任範囲の違い
発行方式によって、連携先と担当の範囲が変わります。
発注前に、発行者、残高台帳の保有者、利用承認者を業務分担図に書き出しておきます。
- ハウス型：自社店舗が中心で、店舗・POS・会員アプリとの連携が主な担当範囲です。
- 第三者型・国際ブランド付き：複数の加盟店で使う場合、プロセシング、本人認証、不正対策、加盟店精算、規制対応まで担当が広がります。
前払式支払手段への該当や第三者型の登録、払戻しや送金機能の扱いは、法務・コンプライアンス担当と確認します。
金融庁は2025年11月に関連する内閣府令の改正を公布し、同月18日に施行・適用しました。
制度は改正されることがあるため、要件定義の前に、法令確認の担当者と更新方法を決めておきます。
根拠は、金融庁「前払式支払手段に関する内閣府令の一部を改正する内閣府令」の2025年公表資料です。
プリペイドカード基幹システムの発注・外注の進め方
発注では、まず事業と資金の流れを整理します。そのうえで方式を比べ、RFPをもとに提案と見積を比較して、契約に進みます。契約後は、要件定義、開発、テストの順に進みます。
方式や責任範囲の判断を早い段階で誤ると、後の工程で費用と納期が膨らみます。
事業・法務・資金フローの整理
最初にまとめるのは、事業モデルと資金フローです。購入・チャージから利用、売上確定、精算まで、誰がいつ、いくら受け取るかを書き出します。
- カード・方式：自家型と第三者型、ハウス型と国際ブランド型を比べます。
- 利用形態：カード型かバーチャル型か、店舗・ECのどこで使うかを選びます。
- 運用条件：発行額、残高上限、有効期限、失効、返金、停止、再発行を取り決めます。
- 問い合わせ：問い合わせ時の本人確認方法を決めます。
自社店舗が中心で、短期間の検証を先に行いたい場合は、クラウドやパッケージが候補になります。
ブランド接続や大規模な加盟店網が必要な場合は、プロセサや金融系SIerも候補に入ります。
独自の精算ロジックや顧客体験が競争力になる場合は、残高・カード処理を外部の基盤に置き、会員・CRM・分析を自社で開発するハイブリッドも有効です。
RFPとPoCによる提案の実現性の確認
各社が同じ前提で見積もれるよう、RFPには事業規模と性能条件を数値で示します。「大量」「リアルタイム」「高い安全性」のような表現では、各社の前提がそろいません。
- 規模：取扱高、月間取引件数、カード枚数、加盟店数を記載します。
- 性能：ピーク時の1秒あたりの要求数を示します。
- 範囲：チャージ手段、連携先、サービス時間、目標稼働率を記載します。
提案の段階では、代表的なシナリオをPoCで確かめます。試すのは、チャージ成功、利用承認、タイムアウト後の再送、利用取消、返金です。
加盟店精算や残高不一致の調査も対象に含めます。PoCで見るべきは、画面の見栄えより、業務として成り立つかどうかです。
さらに、APIの応答と冪等性、障害時の再処理を検証します。残高突合や監査ログも、あわせて確かめます。
候補を2〜3社に絞ったうえで、同じシナリオと同じデータ条件で比べます。
設計・開発後の段階稼働
基本設計では、業務の状態とデータモデルを確定させます。続く詳細設計では、APIや権限、ログの仕様を決め、エラーコードと再処理の手順も定めます。
テストは、単体・結合・総合に加えて、負荷、障害切替、バックアップ復旧を確かめます。業務面では残高突合や日次締め、返金、精算を確認し、セキュリティ面では脆弱性診断も行います。
- 社内利用：本番移行後、まず社内で運用します。
- 限定展開：限定店舗、限定会員の順に対象を増やします。
- 全体展開：差異や障害への対応を確かめたうえで、全体に広げます。
残高差異の補正では、権限と承認者を明確にしておきます。問い合わせ窓口やカード停止の判断者、プロセサへの連絡方法も、手順書にまとめます。また、自社でも、業務責任者と障害時の意思決定者を決めておきます。
RFP・要件整理で発注前に決める項目
RFPは、各社が同じ前提で提案と見積を出せるようにするための資料です。そのため、事業要件、機能要件、非機能要件を分けて書き、連携・移行・運用と契約条件も別の項目として示します。
要件の範囲をそろえておくと、必要な作業を含まない安い見積と、それを含めた見積を、同じ基準で比べられます。
事業要件と機能要件の記載
事業要件では、対象ユーザー、利用店舗、カード種類を書きます。発行・販売の方法やチャージ方法、収益モデルも記載します。また、加盟店への精算日と問い合わせ受付時間も決めておきます。
- 会員・カード：会員管理、カードの発行・停止・再発行を定義します。
- 残高・決済：チャージ上限、残高照会、利用承認、取消・返金、失効を定めます。
- 加盟店・管理：加盟店管理、手数料計算、帳票、監査ログまで決めます。
異常系では、通知遅延やチャージ要求の重複、売上確定の失敗を想定します。返金額と残高の不一致、加盟店の閉鎖も含めます。そのうえで、状態の遷移、確認者、補正の時期まで示します。
正常系だけを定めたシステムでは、事故が起きた際に現場が手作業へ戻るおそれがあります。そのため、異常時の対応も機能要件に含めます。
非機能要件と責任分界の数値化
RFPでは、稼働条件とカード情報の扱いを、数値と責任範囲に分けて示します。
- 性能条件：取引量、同時利用数、応答時間、稼働率、メンテナンス可能時間を決めます。
- 復旧・運用条件：RTO、RPO、保存期間、監視時間、障害連絡の初動時間を示します。
- 稼働・カード情報：24時間365日か店舗営業時間のみかを決め、カード番号を自社で持つか、トークン化してプロセサに預けるかを決めます。
求める稼働条件を踏まえて、冗長化や監視、人員の体制を見積もると、費用の差を把握できます。
PCI DSS v4.0.1は限定的な改訂で、新要件の追加や削除はありません。PCI Security Standards Councilも、新要件の有効日は2025年3月31日のまま変わらないと説明しています。
RFPでは、カード会員データ環境の範囲と、委託先のAOC・準拠状況も確かめます。
出典は、PCI Security Standards Council「Just Published: PCI DSS v4.0.1」の2025年資料です。
連携・移行・運用の見積対象
連携先は、決済、業務システム、会計の領域に分けて洗い出します。決済には、カードブランド、プロセサ、決済ゲートウェイが含まれます。業務システムでは、POS・EC、会員・CRMが対象です。本人確認と通知も、連携先に含めます。会計・ERP・分析基盤は、会計の領域で扱います。
- 接続方式：APIかファイルか、リアルタイムかバッチかを確認します。
- 接続条件：認証方式、レート制限、障害時の再送を決めます。
- 変更連絡：仕様変更の通知期限を決めます。
古いPOSや会計システムにはAPIがなく、CSVによる調整や手作業の承認が必要になることがあります。そのため、既存環境を調査して、工数に含めます。
移行対象は、カードの状態と残高、利用履歴に分けて考えます。失効日や加盟店、未精算取引も、対象として扱います。
件数だけでなく総額も、旧システムと新システムで突合します。そうすれば、全体の差異を見つける手がかりになります。
データの所有権、バックアップの所在、終了時のエクスポート形式と費用も決めておきます。合意しておけば、ベンダーロックインを抑えやすくなります。
準委任と請負の使い分け
契約は、要件の確定度、成果物と完成条件、作業の進め方を誰が管理するかで選びます。現実的なのは、業務整理と要件定義、仕様確定後の実装・テストで契約を分ける方法です。
要件定義や伴走型の開発での準委任の活用と発注側の役割
準委任を使う場合は、発注側の役割と、契約で定める事項を整理しておきます。
- 活用場面：専門家の知見や作業時間を得る契約で、要件定義や現行調査、方式比較、PoC、プロジェクト管理が対象になります。
- 発注側の役割：優先順位と受入条件を決め、法務・運用部門と仕様を調整します。
- 契約条件：品質責任を明確にし、作業範囲、稼働時間、会議体、成果物、報告、知的財産、秘密保持、再委託、情報セキュリティ、個人情報、事故連絡を定めます。
- 意思決定：自社の判断が止まると、契約の形によらず納期が延びます。
請負の使いどころと完成条件
請負は、合意した成果物を完成させ、検査と受入を行う形です。基本設計書やAPI仕様書、プログラム、テスト結果、移行手順書などを、成果物として定義します。
- 受入条件：検収期限と合格基準を定めます。
- 品質対応：瑕疵への対応と保証期間を定めます。
- 業務試験：残高計算・精算の正常系と異常系を確認します。
仕様変更の扱いや追加費用、納期の変更は、契約であらかじめ合意しておきます。要件が曖昧なまま全工程を請負にすると、変更のたびに見積や納期が変わってしまいます。
そこで、要件定義は準委任で行い、確定した実装を請負にする方法があります。また、小規模なMVPを請負で作り、次のフェーズは改めて契約する方法も選べます。
変更・障害・再委託・解約時の条項
解約や終了までを見据えて、事前に合意しておく条項を整理します。
- 変更・障害対応：仕様変更の判定方法、見積期限、優先順位、障害の重大度、初動時間、復旧目標、再処理の責任者を定めます。
- 再委託管理：クラウド、プロセサ、監視会社、コールセンターへの再委託の承認、監査権、情報管理、事故報告を定めます。
- データ返却：解約時のカード・会員・残高・取引履歴・監査ログの形式、返却後の消去方法、移行支援の日数を決めます。
- 終了費用：SaaSやプロセサのデータ出力、カード再発行、接続先変更、並行稼働の費用も見積もります。
プリペイドカード基幹システムの費用相場
全国一律の公開相場は確認できません。そのため、以下の金額は、類似するポイントカードや電子決済の公開費用と、台帳や精算などの追加工数から算出した予算目安です。2026年時点の数値です。
金額は、カードブランドや取扱高、加盟店数で変わります。連携先やPCI DSSの対象範囲、移行データ量によっても変わります。そのため、見積は金額だけで比べないことが大切です。
方式と規模別の初期費用の目安
方式と規模ごとの初期費用と期間は、次の範囲が目安です。
個別の要件をそろえてから、見積もりを比べます。
- 小規模MVP：クラウド・プロセサ接続、1チャネル、連携1〜2件、限定会員で500万円〜1,500万円、3〜6か月です。
- パッケージ・ASP：チャージ、残高、精算、POSまたはEC連携で1,000万円〜3,000万円、4〜9か月です。
- 中規模独自基幹：複数チャネル、会計・CRM連携、返金、不正対策、移行を含み3,000万円〜8,000万円、9〜18か月です。
- 大規模スクラッチ：国際ブランド、複数加盟店、冗長化、24時間監視、監査を含み8,000万円〜3億円以上、18〜30か月以上になる場合があります。
比較例として、株式会社riplaのポイントカードシステムは、パッケージ活用で150万円〜500万円、大規模なスクラッチで2,000万円〜5,000万円以上です。
電子決済システムは、小規模で300万円〜600万円、中規模で600万円〜1,500万円、大規模で1,500万円〜5,000万円以上とされています。
プリペイドカード基幹では、これらに、金銭価値を持つ台帳や精算、返金、監査、カード制御の工数が加わります。そのため、単純なポイントシステムより上振れする前提で、予算を置きます。
比較には、株式会社riplaのポイントカードシステム記事（2025年公開）と、電子決済システム記事（2026年4月）を参照しています。
初期費用とランニング費用の内訳
初期費用は、工程別に分けて見積もります。電子決済システムの公開情報では、要件定義が約10％、設計が10〜20％、開発が40〜60％、テストが10〜20％とされています。
- 初期工程：企画・法務、要件、基本・詳細設計、台帳・チャージ・承認・精算の実装です。
- 周辺作業：画面・API、外部連携、移行、テスト、インフラ、セキュリティ診断です。
見積は、工程一式ではなく、この粒度で依頼します。比率の根拠は、ripla「電子決済システムの開発費用」の2026年公開情報です。
ランニング費用には、クラウドや監視、保守、障害対応に加えて、カード発行料やブランド・プロセサ費、決済手数料も含まれます。SMSや本人確認、PCI DSS評価、診断も対象です。また、バックアップやログ保管も対象になります。
MVPは月額20万円〜100万円程度ですが、複数環境や24時間運用、高取引量では、月額300万円〜1,000万円以上まで幅があります。
年次保守は、初期開発費の15〜30％を仮に置きます。従量費は、取扱高のシナリオごとに試算します。
5年のTCOによる見積の比較
初期価格に偏らないよう、5年間の費用と予備費を同じ条件で比べます。
- 5年間の費用：初期開発費、固定費、従量費、クラウド増強、保守、監査・診断、制度変更、データ移行、終了時の切り替え費を含めます。
- 利用量別の試算：従量課金の増加を確認するため、月間1万件、10万件、100万件などで比べます。
- 予備費：要件・外部仕様の変更に備え、必須機能、初回リリース後の追加機能、将来検討する機能を分けて設定します。
委託先の選定と見積比較の観点
委託先は、カード業務と障害対応への理解で選びます。知名度や価格に加えて、自社の方式に近い実績と、説明できる責任者を確認します。
得意分野は、カード発行やハウス電子マネー、プロセシング、加盟店受入、API型金融サービスで異なります。必要な能力に合う候補を選びます。
自社の発注形態に合う候補
自社の発行方式に合う実績と、障害・解約時の対応力を、候補ごとに確かめます。
質問は「似た案件がありますか」で終わらせず、具体的な対応まで聞きます。
- ハウス型：POS、会員、販促、店舗運用まで支援できる会社を候補にします。
- 国際ブランド・大規模網：プロセシング、ブランド接続、24時間運用、監査対応の実績を確かめます。
- API利用：開発者向け資料やサンドボックス、接続テスト、障害時の再処理を確かめます。
- 台帳・異常処理：台帳の管理者と、取消・返金・二重実行への対応を質問します。
- 負荷・運用：ピーク負荷や障害時に、利用停止を判断した経験と判断者を聞きます。
解約時のデータ返却方法も聞きます。可能であれば、匿名化した画面、テスト仕様書、運用体制図を確認します。
見積書の粒度をそろえた比較
各社の費用差が、機能の差なのか、品質や体制の差なのかを判断できるよう、見積の内訳をそろえます。
- 見積内訳：要件定義から外部サービス費まで工程別に分け、機能、工数、前提、除外事項、納品物、担当を付けます。
- 金額差の確認：機能・品質・体制の差を見ます。「連携一式」などは内訳と成果物で確かめます。
- 評価表：機能適合性、規制、セキュリティ、性能、連携、移行、運用、契約柔軟性、TCO、体制を同じ表で採点します。
- 評価基準：価格だけでなくテストや監視の範囲を評価し、事前に重み付けを決めます。削減により本番後の事故対応費が増える場合があります。
規制・セキュリティ・基幹インフラの早めの確認
法務やセキュリティの面では、社内外の責任者と、適用される制度を早い段階で確認します。
- 責任分界：登録・届出、資産保全、個人情報、本人確認、不正対策、PCI DSSの担当範囲を、発行者・プロセサ・ブランド・クラウド・SIerごとに確認します。
- 対象制度：金融・クレジットカード分野で関係する可能性のある制度を、所管省庁や法務、委託先と確かめます。
指定を受けた特定社会基盤事業者が、特定重要設備の導入や維持管理などを委託する場合は、事前の届出と審査が必要です。
内閣官房の2026年7月7日付の説明会資料は、この制度を説明しています。対象かどうかは決めつけず、必要な場合は審査期間を予定に入れておきます。
出典は、内閣官房「経済安全保障推進法における特定社会基盤役務の説明会資料」の2026年7月資料です。
よくある質問（FAQ）
制度の適用や契約条件は、事業の内容によって変わります。最終的には、法務・セキュリティ・会計の担当者と委託先に確認します。
プリペイドカード基幹システムの開発費用は最低いくらですか？
限定会員・1チャネル・少数連携のMVPでも、残高台帳、チャージ、利用承認、返金、監査、テストが必要です。そのため、費用は500万円〜1,500万円程度から検討するのが現実的です。
カードブランドや加盟店精算、24時間運用、移行、不正対策が加わると、3,000万円以上になる可能性があります。
プリペイドカード基幹システムはどこまで外注できますか？
法務や業務要件の整理から、方式選定、RFP、プロセサ接続まで外注できます。さらに、アプリ・POS・会計連携やテストも任せられます。移行と運用設計も、外注の対象です。
発行者としての業務判断や資金フロー、利用停止・返金の承認は、自社に残す必要があります。予算と優先順位、障害時の経営判断も、自社で決める部分です。
要件定義から請負契約にしたほうがよいですか？
要件が決まっていない段階では、準委任で調査や要件定義、PoCを進める方法が適しています。成果物と完成条件が定まった範囲を請負にします。
全工程を請負にする場合は、仕様変更や検収基準、追加費用、瑕疵対応を細かく定めます。それは、認識のずれを防ぐためです。
何社に相見積もりを依頼すればよいですか？
比較できるRFPを用意して、2〜3社に依頼すると進めやすくなります。候補は、大手SIer、プロセサ・カード基盤、クラウド・パッケージ、業務アプリに強い会社から選びます。
候補が多すぎると、提案の評価に時間がかかるうえ、各社からの質問への回答も手薄になります。そのため、実績と方式の適合性で絞り込みます。
まとめ
プリペイドカード基幹システムの発注では、カードの種類より先に、発行者や資金フローを整理します。残高台帳や利用承認、返金、加盟店精算、会計・監査も、あわせて整理しておきます。
方式は、プロセサ・クラウド、パッケージ、スクラッチ、ハイブリッドから比べます。比べる観点は、費用、期間、責任範囲、将来の移行性です。
発注前の方式・責任分界・TCOの確認
RFPには、取扱高やピーク件数、連携先を書きます。加えて、RTO・RPO、カード情報の保持範囲、PCI DSSの責任分界も示します。そのうえで、移行や監視、障害対応、終了時のデータ返却も含めます。
見積は、初期費だけでなく5年間のTCOで比べます。カード発行料や従量課金、保守、監査、診断、制度変更も、その中で考えます。
委託先決定後の異常系対応と段階稼働
委託先を決めたあとは、契約の範囲と異常時の対応体制を詰めます。
- 契約の分け方：要件定義・PoCは準委任、完成条件が固まった実装・テストは請負にする方法があります。
- 委託先の確認：二重チャージや返金未反映などの異常系、障害時の責任者、再委託、データ移行、終了時の切り替えを質問します。
- 社内参加者：自社の業務責任者と法務・セキュリティ担当も選定に加わります。
要件と見積の前提を整理しておくと、追加費用や納期の遅れを抑えられ、将来のカード・加盟店・チャネルの拡張にも対応しやすくなります。
▼全体ガイドの記事
・プリペイドカード基幹システム開発の完全ガイド
▼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を創業。