プリペイドカード基幹システム開発の発注/外注/依頼/委託方法について

プリペイドカード基幹システムの開発を発注・外注するなら、カード発行画面の制作費ではなく、残高台帳・利用承認・返金・加盟店精算までを含む業務基盤として、方式と責任分界を先に決めることが重要です。

自家型か第三者型か、ハウスプリペイドか国際ブランド付きか、プロセサやパッケージを使うか独自開発するかによって、必要な要件、契約、費用、稼働までの期間が大きく変わります。この記事では、発注形態の選び方からRFPの作り方、準委任・請負の使い分け、2026年時点の費用目安、委託先の比較方法まで、発注担当者が社内で判断しやすい順番に解説します。

▼全体ガイドの記事
・プリペイドカード基幹システム開発の完全ガイド

プリペイドカード基幹システムの全体像を把握します

プリペイドカード基幹システムは、事前に購入・チャージされた価値をカード番号や会員情報とひも付け、利用可否の判定から精算、会計、監査までを一貫して管理する仕組みです。ポイント管理よりも金銭性の高い残高を扱うため、正常に使える画面だけでなく、二重チャージ、通信タイムアウト、取消、返金、障害復旧までを設計対象にします。

最低限の業務フローは「発行またはチャージ、残高台帳の更新、利用承認、売上確定、加盟店精算、会計・監査」です。台帳では残高の加算・減算だけでなく、保留、確定、取消、返金、失効の状態を取引単位で保持します。金額を浮動小数点で計算せず、円などの最小単位を整数で扱い、取引IDや冪等キーを使って同じ要求が再送されても二重に反映されない設計にします。

たとえばチャージ受付後に決済ゲートウェイから応答が返らない場合、画面上は失敗でも金融機関側では成功していることがあります。このとき単純な再送を許すと二重チャージにつながります。受付、保留、確定、要調査を分け、再照会と突合で確定させる業務ルールをRFPに明記します。

自社店舗だけで利用するハウスプリペイドは、店舗・POS・会員アプリとの連携が中心になりやすい一方、複数の加盟店で使う第三者型や国際ブランド付きカードでは、プロセシング、本人認証、不正利用対策、加盟店精算、規制対応の範囲が広がります。発注前に、誰が発行者となるのか、誰が残高台帳を持つのか、誰が利用承認を行うのかを一枚の業務分担図にします。

前払式支払手段に該当するか、第三者型の登録が必要か、払戻しや送金に当たる機能を持つかは、法務・コンプライアンス担当と確認します。金融庁は2025年11月に前払式支払手段に関する内閣府令の改正を公布し、同月18日から施行・適用しています。制度変更を見落とさないため、要件定義の前に法令確認の担当者と更新方法を決めます。根拠は金融庁「前払式支払手段に関する内閣府令の一部を改正する内閣府令」の2025年公表資料です。

プリペイドカード基幹システムの発注・外注はどう進めますか？

発注・外注は、いきなり開発会社へ機能一覧を渡すのではなく、事業と資金の流れを整理してから、方式比較、RFP、提案・見積比較、契約、要件定義、開発、テストへ進めます。特にプリペイドカードでは、早い段階で発注形態を誤ると、途中で規制対応や責任分界が変わり、見積と納期が大きく膨らみます。

最初の成果物は、画面一覧ではなく事業モデルと資金フローです。利用者がどこでカードを購入し、どのチャネルでチャージし、どの店舗やECで使い、いつ売上確定し、誰へいくら精算するのかを書き出します。発行額、残高上限、有効期限、失効、返金、利用停止、再発行、問い合わせ時の本人確認も決めます。

この時点で、自家型・第三者型、ハウス型・国際ブランド型、カード型・バーチャル型を比較します。自社店舗中心で短期検証したい場合はクラウドやパッケージを使い、ブランド接続や大規模加盟店網が必要な場合はプロセサや金融系SIerを含めます。独自の精算ロジックや顧客体験が競争力になる場合は、残高・カード処理を外部基盤に置き、会員・CRM・分析を自社開発するハイブリッドも有効です。

RFPでは、取扱高、月間取引件数、ピーク時の1秒あたりの要求数、カード枚数、加盟店数、チャージ手段、連携先、サービス時間、目標稼働率を数値で示します。「大量」「リアルタイム」「高い安全性」のような形容詞だけでは、会社ごとに異なる前提で見積もられるためです。

提案段階では、チャージ成功、利用承認、タイムアウト後の再送、利用取消、返金、加盟店精算、残高不一致の調査という代表シナリオをPoCで確認します。PoCは画面の見栄えを競う場ではなく、APIの応答、冪等性、残高の突合、監査ログ、障害時の再処理を確認する場です。候補を2〜3社に絞り、同じシナリオと同じデータ条件で比較します。

要件が固まった後は、基本設計で業務状態とデータモデルを確定し、詳細設計でAPI、権限、ログ、エラーコード、再処理手順まで決めます。テストでは、単体・結合・総合テストに加えて、負荷、障害切替、バックアップ復旧、脆弱性診断、残高突合、日次締め、返金、精算を行います。

本番移行は、一斉切り替えよりも、社内利用、限定店舗、限定会員、全体展開の順に広げる方式が安全です。旧システムとの残高差異が出た場合の補正権限と承認者、問い合わせ窓口、カード停止の判断者、外部プロセサへの連絡方法を運用手順書にします。開発会社に任せきりにせず、自社側にも業務責任者と障害時の意思決定者を置きます。

RFP・要件整理で発注前に決める項目は何ですか？

RFPの役割は、開発会社に正解を押し付けることではなく、同じ前提で提案と見積を出してもらうことです。事業要件、機能要件、非機能要件、外部連携、移行、運用、契約条件を分けて記載すると、安いが要件を含まない見積と、必要な作業を含めた見積を比較しやすくなります。

事業要件には、対象ユーザー、利用店舗、カードの種類、発行・販売方法、チャージ方法、収益モデル、加盟店への精算日、問い合わせ受付時間を記載します。機能要件には、会員管理、カード発行・停止・再発行、チャージ上限、残高照会、利用承認、取消・返金、失効、加盟店管理、手数料計算、帳票、監査ログを記載します。

異常系も機能要件に含めます。決済側の成功通知が遅れた場合、同じチャージ要求が2回届いた場合、利用承認後に売上確定が失敗した場合、返金額と残高が一致しない場合、加盟店が閉鎖した場合に、どの状態へ遷移し、誰が確認し、いつ補正するのかを示します。正常系だけで作ったシステムは、事故のときに現場が手作業へ戻ってしまいます。

非機能要件では、月間取引件数、ピーク時の同時利用数、応答時間、稼働率、メンテナンス可能時間、目標復旧時間であるRTO、目標復旧時点であるRPO、保存期間、監視時間、障害連絡の初動時間を決めます。24時間365日を求めるのか、店舗営業時間だけでよいのかで、冗長化、監視、人員、費用が変わります。

カード番号を自社が保持するのか、トークン化してプロセサ側に預けるのかも重要です。PCI DSS v4.0.1は限定改訂であり、新しい要件の追加や削除はありませんが、2025年3月31日という新要件の有効日は変わらないとPCI Security Standards Councilが説明しています。自社環境がどの範囲でカード会員データ環境に該当するか、委託先のAOCや準拠状況を含めてRFPで確認します。根拠はPCI Security Standards Council「Just Published: PCI DSS v4.0.1」の2025年資料です。

連携先は、カードブランドやプロセサ、決済ゲートウェイ、POS、EC、会員・CRM、本人確認、通知、会計・ERP、データ分析基盤に分けて記載します。各連携について、APIかファイルか、リアルタイムかバッチか、認証方式、レート制限、障害時の再送、仕様変更の通知期限を確認します。古いPOSや会計システムでは、APIがなく、CSVのレイアウト調整や手作業の承認が必要になる場合があります。

既存カードや会員を移行する場合は、カード状態、残高、利用履歴、失効日、加盟店、未精算取引を移行対象に分けます。残高移行は件数だけでなく総額を旧新システムで突合し、サンプルだけでなく全件の差異検知を行います。データ所有権、バックアップの所在、契約終了時のエクスポート形式と費用も、発注時に決めておくとベンダーロックインを抑えられます。

契約形態は準委任と請負をどう使い分けますか？

契約形態は、要件が固まっているか、成果物と完成条件を定義できるか、発注者と受託者のどちらが作業方法を管理するかで選びます。プリペイドカード基幹では、法務・業務整理や要件定義の段階と、仕様が確定した実装・テストの段階で、適した契約を分ける方法が現実的です。

準委任は、専門家の知見や作業時間の提供を受ける契約で、要件定義、現行調査、方式比較、PoC、プロジェクト管理に向きます。発注者側でも優先順位や受入条件を決めながら進められるため、法務や運用部門と調整しながら仕様を固める段階に適しています。

ただし、準委任だから品質責任が不要になるわけではありません。作業範囲、稼働時間、会議体、成果物、報告方法、知的財産、秘密保持、再委託、情報セキュリティ、個人情報、インシデント時の連絡を契約書や個別仕様書で明確にします。自社の担当者が意思決定を止めると、契約形態にかかわらず納期が延びます。

請負は、合意した成果物を完成させ、検査・受入を行う形に向きます。基本設計書、API仕様書、プログラム、テスト結果、移行手順書などを納品物として定義し、受入基準、検収期限、瑕疵への対応、保証期間を定めます。残高計算や精算処理は業務影響が大きいため、「動けば完成」ではなく、代表シナリオと異常系の合格条件まで書きます。

要件が曖昧なまま全工程を請負にすると、変更のたびに追加見積や納期延長が発生します。要件定義を準委任で行い、要件定義書とRFPへの回答を基に実装部分を請負へ移す、あるいは小さなMVPを請負で構築して次のフェーズを再契約する方法が、責任と柔軟性のバランスを取りやすいです。

契約前に、仕様変更の判定方法、変更要求の見積期限、優先順位の決め方、障害の重大度、初動時間、復旧目標、再処理の責任者を定めます。再委託先がクラウド、プロセサ、監視会社、コールセンターに広がる場合は、再委託の承認、監査権、情報管理、事故報告の流れも確認します。

解約時には、カード・会員・残高・取引履歴・監査ログをどの形式で返却するか、返却後に何を消去するか、移行支援を何日行うかを決めます。SaaSやプロセサを使う場合は、月額費用だけでなく、データエクスポート、カード再発行、接続先の切り替え、並行稼働の費用まで含めた終了条件を見積もります。

プリペイドカード基幹システムの費用相場はいくらですか？

プリペイドカード基幹システムだけの全国一律の公開相場は確認できないため、以下は2026年時点の類似するポイントカード・電子決済の公開費用と、残高台帳、精算、セキュリティ、外部連携の追加工数から算出した発注予算の目安です。カードブランド、取扱高、加盟店数、連携先、PCI DSSの対象範囲、移行データ量によって大きく変わるため、金額だけを独立して比較しないことが大切です。

クラウドやプロセサへ接続する小規模MVPで、チャネル1つ、外部連携1〜2件、限定会員から始める場合は、初期費用500万円〜1,500万円、期間3〜6か月が一つの目安です。チャージ、残高、精算、POSまたはEC連携をパッケージやASPで導入する場合は、初期費用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月）を参照しています。

初期費用は、企画・法務・業務要件、基本・詳細設計、台帳・チャージ・利用承認・精算の実装、画面・API、外部連携、移行、テスト、インフラ、セキュリティ診断に分けます。類似する電子決済システムの公開情報では、要件定義が全体の約10％、設計が10〜20％、開発が40〜60％、テストが10〜20％の目安とされています。自社見積でも、工程を一式にせず、この粒度で出してもらいます。工程比率の根拠は、株式会社ripla「電子決済システムの開発費用」の2026年公開情報です。

ランニング費用には、クラウド、監視、保守、障害対応、カード発行料、ブランド・プロセサ費、決済手数料、SMSや本人確認の従量費、PCI DSS評価、脆弱性診断、バックアップ、ログ保管が含まれます。月額20万円〜100万円程度のMVPから、複数環境・24時間運用・高い取引量で月額300万円〜1,000万円以上まで幅があります。初期開発費の15〜30％を年次保守の仮置きにし、従量費は取扱高のシナリオ別に試算します。

見積比較では、初期費用だけでなく、5年間の総保有コストであるTCOを計算します。初期開発費に、月額固定費、取引・カード発行の従量費、クラウド増強費、保守、監査・診断、制度変更対応、データ移行、終了時の切り替え費用を加えます。初期費用が安くても、取扱高が増えると従量課金が急増する契約があるため、月間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、プロセサ・カード発行基盤、クラウド・パッケージ、業務アプリに強い開発会社など、得意領域が異なる候補を含めます。候補数を増やしすぎると提案評価に時間がかかり、各社への回答条件も薄くなるため、実績と方式の適合性で絞ります。

まとめ

プリペイドカード基幹システムの発注では、最初にカードの種類を選ぶのではなく、発行者、資金フロー、残高台帳、利用承認、返金、加盟店精算、会計・監査までの業務を整理します。そのうえで、プロセサ・クラウド、パッケージ、スクラッチ、ハイブリッドの方式を、費用・期間・責任分界・将来の移行性で比較します。

RFPには取扱高、ピーク件数、連携先、RTO・RPO、カード情報の保持範囲、PCI DSSの責任分界、移行、監視、障害対応、解約時のデータ返却を具体的に記載します。見積は初期費用だけでなく、カード発行料、従量課金、保守、監査、診断、制度変更、5年間のTCOで比べます。

契約は、要件定義やPoCを準委任、仕様と完成条件が固まった実装・テストを請負とする分け方が基本です。候補企業には、二重チャージや返金未反映などの異常系、障害時の責任者、再委託、データ移行、終了時の切り替えまで質問し、自社の業務責任者と法務・セキュリティ担当を含めて選定します。

要件と見積の前提が整理できていれば、発注後の追加費用や納期遅延を抑えながら、将来のカード・加盟店・チャネル拡張にも対応しやすくなります。

▼全体ガイドの記事
・プリペイドカード基幹システム開発の完全ガイド

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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