プリペイドカード基幹システムの開発費用は、方式、カードの種類、連携・運用の範囲によって500万円から3億円以上まで変わります。費用を左右するのは、カードを使う範囲と外部基盤をどこまで使うかです。
▼全体ガイドの記事
・プリペイドカード基幹システム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
プリペイドカード基幹システムの全体像
プリペイドカード基幹システムは、カードやバーチャルカードの価値を一貫して管理する中核のシステムです。カードの発行からチャージ、利用承認、売上確定、加盟店精算、会計・監査まで、一連の業務を扱います。
中心になるのは、金額の増減を記録する残高台帳と、取引状態を追跡する監査ログです。なお、カード番号を発行する画面は、この基幹システム全体の一部にすぎません。
価値台帳を管理するシステムという位置づけ
価値の移動を正しく記録するには、発行から会計・監査までを一続きの業務として見ることが欠かせません。
- 発行・チャージ：カードの発行と、残高台帳への反映
- 利用承認：カードの利用可否の判定
- 売上確定・加盟店精算：確定した売上の処理と、加盟店への精算
- 会計・監査：取引の記録と、後からの追跡
利用承認後に通信が切れると、失敗表示でも残高だけが減る可能性があります。さらに、再送によって二重に減額される場合もあります。
そのため、取引ごとに一意な冪等キーを持たせる必要があります。あわせて、取引の状態を保留・確定・取消・返金・失効の段階に分けて管理し、日次締め時には残高の突合も行います。
機能の数で比べると、異常系の工数を見落としやすくなります。正常なチャージと利用だけをデモして安く見せる見積には、特に注意が必要です。
自家型・第三者型とハウス型・国際ブランド型による費用の違い
費用は、カードを使う範囲と外部基盤の利用範囲で変わります。比べるときは、次の区分を分けて見ることが大切です。
- 自家型・ハウス型：自社店舗や自社サービス内での利用
- 第三者型・国際ブランド型：加盟店網とブランド接続の広がり
- 外部プロセサ活用：残高やカードの処理を外部に任せる形
自家型のハウスプリペイドは、加盟店網やブランド接続が限られます。そのぶん、国際ブランド付きのカードより構成を小さくできる場合があります。
第三者型やVisa・JCBなどの国際ブランド型では、加盟店精算やブランド接続の範囲が広がります。さらに、チャージバック、不正利用対応、本人確認も扱う範囲に入ります。
外部プロセサを使い、会員画面やCRMだけを自社で開発する方式もあります。
たとえば、インフキュリオンのXardは、公式の機能情報でJCB・Visa決済とバーチャルカードのリアルタイム発行をAPIで提供すると説明しています。さらに、プリペイド残高管理、カードロック、利用上限設定もAPIで提供するとしています（出典: 株式会社インフキュリオン、2026年閲覧）。
外部基盤を使えば、開発費を下げられる可能性があります。ただし、月額費用・カード発行料・取引従量費は継続してかかるため、責任分界とあわせて確認が欠かせません。
プリペイドカード基幹システムの費用相場
費用相場は、小規模MVPで500万〜1,500万円、パッケージやASPの導入で1,000万〜3,000万円です。また、中規模の独自基幹は3,000万〜8,000万円、大規模スクラッチは8,000万円〜3億円以上です。
この相場は、類似するポイントカードや電子決済システムの公開価格と、残高台帳・精算・セキュリティの工数から組み立てた、2026年時点の推定レンジです。公的な平均値ではない点には、注意が必要です。
方式別の初期費用と開発期間の目安
方式ごとに費用と期間を並べると、必要な規模の見当をつけられます。
- 小規模MVP：クラウドやプロセサを使い、期間は3〜6か月
- パッケージ・ASP：業務に合わせ、期間は4〜9か月
- 中規模独自基幹：複数業務を含め、期間は9〜18か月
- 大規模スクラッチ：大規模連携を含め、期間は18〜30か月以上
小規模MVPは500万〜1,500万円が目安です。チャージ手段と利用チャネルはそれぞれ1つ、外部連携は1〜2個に絞ります。そのうえで、カード発行と残高照会、利用承認を検証し、簡易管理画面も確かめます。
プロセサや決済ゲートウェイを利用すれば、カード情報を保持する範囲や接続試験の負担を抑えられます。
パッケージ・ASP活用は1,000万〜3,000万円が目安です。業務に合わせ、チャージと残高の仕組み、加盟店と精算の機能を整えます。さらに、POS・EC・会員基盤との連携も加えます。
中規模独自基幹は3,000万〜8,000万円が目安です。複数チャネルや返金、会計・CRMに加えて、移行、不正対策、監査レポートまで含めます。
大規模案件は8,000万円〜3億円以上が目安です。国際ブランドや複数の加盟店網を扱い、冗長化と24時間監視を含む場合は、18〜30か月以上を見込みます。
初期開発費の台帳・精算・テストへの厚い配分
初期費用は、工程ごとの配分をそろえておくと、見積もりを比べやすくなります。
- 企画・法務・業務要件：10〜15%の配分
- 基本設計・詳細設計：15〜20%の配分
- 台帳・チャージ・承認・精算：35〜45%の配分
- 外部連携：10〜20%の配分
- テスト・性能・セキュリティ・移行：15〜25%の配分
実際には要件が重なるため、合計を厳密に100%にそろえるより、どの工程が見積に含まれるかを明示することが大切です。
類似する電子決済システムでは、小規模300万〜600万円、中規模600万〜1,500万円、大規模1,500万〜5,000万円以上という公開目安があります。
プリペイドカード基幹は、金銭性のある残高管理や返金・失効、加盟店精算に加えて、障害時の整合性も含みます。そのため、同じ画面数でも上振れしやすい領域です（出典: 株式会社ripla「電子決済システムの開発費用/コスト/値段や見積相場について」、2026年参照）。
月額費用と従量課金を含むTCO
ランニング費用は、初期費用とは別に、次の項目ごとに確認します。
- 基盤費用：クラウド利用料と、監視・保守の費用
- カード・決済費用：カード発行料、プロセサやブランドの利用料、決済手数料
- 外部サービス費用：本人確認、通知、脆弱性診断、PCI DSS対応
- 運用費用：問い合わせ対応と取引従量費
小規模MVPは月20万〜100万円、中規模は月100万〜300万円、大規模は月300万〜1,000万円以上が目安です。これらに取引従量費が加わる場合があります。
保守費を初期開発費の年15〜30%とする見積もりもありますが、あくまで目安です。
月10万件と月1万件の取引では、監視・ログ保管・性能設計の条件が異なります。
3年間のカード発行数と取引件数を前提にそろえたうえで、ピーク同時接続数や外部サービスの単価、解約時のデータ移行費まで合算します。初期費用が安い案と総額が安い案は、分けて評価します。
プリペイドカード基幹システムの費用が変動する要因
同じプリペイドカードでも、資金の流れや利用場所が違えば、見積もりは別物になります。カードの種類や発行規模が違う場合も、見積もりの前提が変わります。
費用を下げるには、まず機能を削る前に、自社の責任範囲を明確にします。
自家型・第三者型と資金決済法上の整理
払戻しや送金の有無、有効期限、失効の扱いは、データモデルと運用設計にも影響します。そのため、先に整理しておく必要があります。
- サービス区分：自家型か第三者型かの区分
- 資金機能：払戻しや送金機能の有無
- 有効期限・失効：残高の扱いの設計
- 加盟店精算：登録、売上確定、手数料、精算、問い合わせ対応の範囲
第三者型では、加盟店数や精算ルールが増えるほど、費用も増えていきます。
金融庁は2025年11月17日に、前払式支払手段に関する内閣府令の改正を公表しました。改正内容は、同年11月18日から施行・適用されています（出典: 金融庁、2025年）。
自社のサービスがどの制度に当たるかは、個別に判断する必要があります。そのため、要件定義の前に法務・コンプライアンス担当と確認し、届出や利用者保護、帳簿・報告、資産保全を見積条件に入れます。
チャージ手段・チャネル・外部連携の数
連携は、入金方法、利用チャネル、接続仕様の順に分けて見ていくと整理しやすくなります。
- チャージ手段：店頭、銀行振込、コンビニ、クレジットカード、アプリ内決済の各方法
- 利用チャネル：POS、EC、モバイルアプリ、外部加盟店、コールセンターでの利用
- 外部連携：接続方式や処理頻度、テスト環境、仕様変更の通知方法
チャージ手段を増やすと、入金受付や消込の実装が変わります。取消や返金、本人認証も、そのぶん作り込む範囲が広がります。
利用チャネルを加えると、APIやファイル連携、権限、障害時の再送処理も増えていきます。
見積の依頼では、連携先を「POS一式」とまとめず、単位ごとに分けてもらいます。たとえば、POSやEC、CRM、会計・ERPは、それぞれ別の行にします。本人確認と通知、分析基盤、カードプロセサも、行を分けて書きます。
接続先ごとに、APIかファイルか、リアルタイムか日次かを書いておくと、見積条件を会社ごとにそろえられます。テスト環境の有無や仕様変更の通知方法も加えて、会社ごとの違いを見ていきます。
性能・可用性・セキュリティ要件
非機能要件は、取扱高に加えて、ピークと復旧の条件から見ていきます。
- 性能：ピーク時間の同時利用数と許容応答時間
- 可用性：停止できない時間帯と障害時の復旧目標
- セキュリティ：PCI DSSの対象範囲と責任分界
24時間365日運用や複数リージョンの冗長化を求める案件では、RTO・RPOや監視とオンコールも必要になります。その分、開発費だけでなくクラウド・運用費も大きくなります。
トークン化や外部ウィジェットを採用できれば、PCI DSSの対象範囲を小さくできる可能性があります。ただし、対象範囲が自動的にゼロになるとは限りません。
PCI Security Standards Councilは、PCI DSS v4.0.1が限定的な改訂であり、新要件の適用日は変更しないと説明しています（出典: PCI Security Standards Council、2025年）。
委託先のAOCや責任分界、ログ・脆弱性管理、3Dセキュアの扱いは、見積に反映しておきます。
プリペイドカード基幹システム開発の進め方
開発では、カード券面や利用者画面より先に、資金の流れと取引の状態を定めます。工程ごとの成果物を先に確定しておくと、法務・精算・障害対応の要件が膨らむリスクを抑えられます。
企画・法務・要件定義で決める事項
まず、発行者とチャージ場所、利用者、精算先を決めます。そのうえで、カードの種類と資金条件も要件に含めます。
- 発行・チャージ・利用：誰が発行し、どこで入金し、誰が使えるか
- 精算：売上の支払先と支払時期
- カードと利用範囲：自家型・第三者型、ハウス型・国際ブランド型、リアルカード・バーチャルカードのどれにするか
- 資金条件：払戻し、送金、有効期限、加盟店手数料の扱い
取引は、受付から失効まで、保留や確定、取消、返金といった段階に分けて考えます。そのうえで、残高が増減する取引と、利用者に見せる残高、会計上の残高、加盟店へ精算する金額をそれぞれ定義します。
二重実行やタイムアウト、順序の逆転を、業務シナリオとして洗い出します。日付をまたぐ取引や締め後の取消も、シナリオに含めます。
成果物として、業務フローとデータ項目の一覧を残します。権限表や外部連携の一覧、非機能要件、RFPも文書にまとめます。
設計・実装で優先する残高整合性と責任分界
設計では、金額の持ち方や再送時の扱い、訂正履歴を先に決めておきます。
- 金額管理：通貨の最小単位を基準にした整数での保持
- 冪等性：外部受付番号と自社の冪等キーの付与
- 訂正履歴：理由と元取引を残す追記型の管理
- 責任分界：外部プロセサとの担当範囲を、契約と図に記載
同じ要求を再送しても、残高が一度だけ変わるように設計します。さらに、残高台帳を追記型にしておくと、監査や問い合わせの調査がしやすくなります。
外部プロセサを使うなら、カード番号と残高、利用承認の担当を明記します。返金やチャージバック、加盟店精算についても、担当をあわせて書いておきます。
API停止時に利用を止めるのか、一定条件でオフライン承認するのか、復旧後にどう突合するのかも決めておく必要があります。これを決めておけば、安価な構成でも運用上の不確実性を減らせます。
テスト・移行・パイロットの進め方
テストは、画面表示の確認で終わらせず、実取引に近い業務と異常系を組み合わせて確かめます。
- 一連の取引：チャージ、利用、取消、返金、失効、精算、日次締めを通しで行う
- 異常系：タイムアウト、重複要求、通信断、外部API遅延の再現
- 移行：残高、利用履歴、有効期限、停止状態、加盟店情報の照合
- パイロット：社内、限定店舗、限定会員の順での展開
テストでは、異常な連続チャージや権限のない返金も再現します。
性能テストでは、キャンペーン開始直後や締め時間帯のピーク件数を前提にします。
移行の前後で件数と金額を突合します。そのうえで、問い合わせ件数と精算差異を確認してから段階的に広げると、手戻りコストを抑えられます。
プリペイドカード基幹システムのコスト最適化ポイント
コストを抑えるといっても、テストや監査を削るのではありません。残高の正しさや利用者保護、障害復旧は守ったうえで、共通機能を外部基盤や標準機能に寄せます。
決済のコアは外部基盤、差別化領域は自社開発という分け方
専門性や運用実績が必要な機能と、自社の強みになる領域を分けると、構成を整理できます。
- 外部基盤：国際ブランド接続、トークン化、3Dセキュア、チャージバックの担当
- 自社開発：会員体験、利用制限、CRM、分析、販促の機能
- 比較条件：3年分の保守費と利用費で見る損益分岐点
たとえば、バリューデザインは、公式サイトで独自Payについて紹介しています。ハウス電子マネーの発行に加え、ポイントやデジタルギフト、販促、分析を提供し、導入事例も公開しています（出典: 株式会社バリューデザイン、2026年閲覧）。
外部基盤を選ぶ場合は、月額や従量費に加えて、API制約やデータ持ち出し、サービス終了時の移行費も評価します。
3年分の取引量という同じ条件で、スクラッチの保守費と外部基盤の利用費を比べます。
チャネルを絞ったMVPからの段階的な拡張
初期の段階で対象を絞ると、連携や権限、サポート、テストが同時に増えるのを抑えられます。
- 利用チャネル：1つに限ること
- チャージ手段：1〜2つに限ること
- 業務サイクル：発行・チャージ・利用・取消・日次突合までの一周を完成させること
- 拡張時期：残高差異と問い合わせの原因を解消したあと
カードの種類も絞ります。ただし、将来の拡張に備えて、APIとイベントの境界や取引状態と権限の境界は、初期から設計しておきます。
利用実績のない複雑なポイント連携や高度な分析、複数通貨、オフライン決済は、最初の段階では作り込みません。作らない機能をはっきり書くことも、予算を守る要件定義の一部になります。
RFPでの機能・連携・非機能の分け方
「プリペイドカードシステム一式」とだけ依頼すると、会社ごとに含まれる範囲が変わります。そのため、RFPでは比較する単位を分けておきます。
- 機能：発行・会員管理、チャージ、残高台帳、利用承認、カード制御ごとの切り分け
- 業務・連携：加盟店・精算、会計、管理画面、外部連携、移行ごとの切り分け
- 非機能：監視とセキュリティ診断、運用設計の項目
- 優先度：必須、希望、将来対応の3段階での記載
見積書は、要件定義から予備費まで、工程ごとの行に分けてもらいます。前提や除外事項、納品物の違いを見ます。検収条件と追加変更の単価も、並べて比べます。
条件をそろえると、単純な総額の競争になるのを避けられます。さらに、不要な重複開発も見つけられます。
プリペイドカード基幹システムの見積もりを取るポイント
相見積もりでは、同じ前提で比べられるように準備します。また、要件定義やPoCを先に発注して不確実性を減らし、そのあとで本開発の範囲と価格を確定する進め方もあります。
RFPに書くべき数値と業務条件
RFPには、規模と処理、運用、責任分界に関する条件を書きます。数値がまだ未確定なら、3シナリオで示します。
- 規模：年間発行額、取引件数、同時接続数、カード発行数、会員数
- 業務：チャージ手段や利用チャネル、加盟店数、精算サイクル、返金件数
- データ：ピーク時の1分間取引数と既存データ量
- 運用・安全：SLA、RTO・RPO、監査ログ、PCI DSSの責任分界
RFPには、対応時間や障害時の停止判断、監査ログの保管年数を明記します。そのうえで、権限を洗い出す方法や脆弱性診断、再委託の扱いを書きます。
データ所有権や解約時のデータ出力も、あわせて明記しておきます。
内閣府は、2026年7月に更新した基幹インフラ制度の資料で、第三者型前払式支払手段について、年間発行額1兆円以上かつ加盟店数1万店以上を指定基準の一例として示しています（出典: 内閣府、2026年）。
この基準に該当する可能性がある事業者は、システムの導入・維持管理の委託に関する手続きも、早めに確認する必要があります。
開発会社の得意領域と責任分界による選び方
開発会社は、カードの種類や自社の責任範囲に合う経験があるかどうかで比べます。
- ハウス電子マネー：販促、ポイント、POS連携の実績
- 国際ブランドカード：ブランド接続やカード業務、プロセシング、24時間運用の実績
- API型FinTech基盤：ドキュメント、Sandbox、Webhook、障害通知、データ出力の確認
候補の会社には、同規模の導入事例や現在提供している機能、再委託先を尋ねておきます。
障害時の再処理や、残高差異が出たときに調べる主体も、確かめておきます。
「残高台帳を誰が持つか」「加盟店への精算責任は誰か」の2点を、比べる軸にします。
「解約時にどのデータを何日で受け取れるか」も確かめておくと、乗り換えのリスクを評価できます。
契約・仕様変更・障害対応にかかる費用の確認
要件が固まらない段階では、調査・要件定義と本開発の契約を分けます。そのうえで、費用と対応範囲を左右する条件を先に確認します。
- 契約条件：検収条件、仕様変更、再委託、納期遅延
- 障害・安全：脆弱性対応と、障害時の連絡・復旧
- 終了条件：保守終了とデータ移行
- 追加費用：監視、診断、移行、マニュアル、休日対応の扱い
調査・要件定義は準委任で行い、成果物と範囲が確定した部分から請負に移す方法があります。その場合は、請負契約で外部サービスの仕様変更も確認します。
初期見積が安く見えても、後から監視やセキュリティ診断が追加されたり、移行や運用マニュアル、休日対応が加わったりすることがあります。そこで、「別途」「想定外」「オプション」といった言葉を一覧にします。
オプションを必須にした場合の追加額と、利用しない場合のリスクを、開発会社に説明してもらいます。また、予備費として初期開発費の10〜20%程度を置く場合は、用途を社内で決めておきます。
よくある質問（FAQ）
費用や発注時によく寄せられる質問に答えます。金額は予算策定の初期値として使い、RFPとPoCで具体化してください。
プリペイドカード基幹システムは最低いくらで開発できますか？
最低額を見るときは、初期費用と継続費用を分けて判断します。
- 小規模MVP：1チャネル、1〜2連携で、外部プロセサを活用する場合は500万〜1,500万円
- 別途費用：カード発行料、決済手数料、月額利用料、診断、移行、保守が加わる場合
カード発行料や決済手数料などが別途になることもあります。そのため、初期費用だけで最低額を判断せず、別途費用も含めて見ることが大切です。
開発期間はどのくらいかかりますか？
方式ごとに実装期間は異なります。また、法務や移行の準備期間も、計画に含めておきます。
- 小規模MVP・プロセサ接続型：3〜6か月
- ASP・パッケージ活用：4〜9か月
- 中規模独自基幹：9〜18か月
- 大規模スクラッチ：18〜30か月以上
法務整理やブランド審査、外部接続試験がある場合は、前後の準備期間も含めます。既存残高の移行やパイロット運用が入る場合は、その分の期間も見込みます。
クラウドや外部プロセサを使えば必ず安くなりますか？
クラウドや外部プロセサは、初期開発費を下げられる可能性がある一方で、総額を必ず下げるとは限りません。
- 抑えられる費用：初期開発工数やカード情報の保持範囲
- 増える可能性がある費用：月額・取引従量費、追加連携、移行費
API制約やベンダーロックインといった点も、あわせて考える必要があります。3年間の取引量と運用条件をもとに、外部基盤型と自社保有型のTCOを比べるとよいでしょう。
法規制やPCI DSSの費用は見積に含めるべきですか？
法規制とPCI DSSの対応費用は、開発費とは分けて見積に含めるのが望ましいです。
- 対応項目：法務・コンプライアンス、監査ログ、権限管理、脆弱性診断
- 責任確認：PCI DSS評価、委託先確認、障害訓練の担当
対象となる制度やPCI DSSの適用範囲は、事業形態と接続方式によって変わります。開発会社の説明だけを頼りにせず、必要に応じて専門家にも確かめてください。
まとめ
プリペイドカード基幹システムの開発費用は、小規模MVPで500万〜1,500万円、ASP・パッケージ活用で1,000万〜3,000万円です。
中規模の独自基幹は3,000万〜8,000万円、大規模スクラッチは8,000万円〜3億円以上が推定目安です。
公開相場は限られるため、金額だけで比べないことが大切です。チャージから監査までの範囲をそろえて比べます。その範囲には、残高台帳や利用承認、売上確定、加盟店精算、返金が含まれます。
方式とTCOをセットにした予算の決め方
カードの利用範囲と差別化領域を分けて考えると、方式を選びやすくなります。
- ハウス型：クラウドやパッケージが候補
- 国際ブランド・大規模加盟店網：実績あるプロセサや大手SIが候補
- 独自精算・データ活用：ハイブリッドやスクラッチが候補
初期費用や月額、従量費は、3年分で見積もります。カード発行料や保守、監査、移行も、同じ期間で合算します。そうすると、短期の安さに偏りにくくなります。
発注前の残高整合性と異常系の確認
発注の前には、まずRFPに事業条件と責任分界を記載します。PoCでは、残高と精算が正しく戻るかを確かめます。
- RFPの条件：自家型・第三者型、カードブランド、発行額、加盟店数、取引ピーク
- 連携・運用：連携先、SLA、RTO・RPO、PCI DSSの責任分界、データ所有権
- PoCの異常系：二重チャージ、返金未反映、通信断、締め差異、外部API障害、権限のない操作
プリペイドカード基幹システムは、カードを発行する仕組みにとどまらず、価値を安全に移動・記録・精算する基幹業務を再設計するものです。
責任範囲を見極めて、標準機能と自社の強みを分けることが、費用と運用リスクを抑える近道です。
▼全体ガイドの記事
・プリペイドカード基幹システム開発の完全ガイド
▼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を創業。