デビットカード基幹システム開発の進め方/やり方/流れや方法/手法/工程/手順

デビットカード基幹システムの開発は、発行方式の決定、取引要件の定義、接続設計・開発、認定・移行の順に進めます。この順で進めると、稼働後の安全な運用につながります。

取引が承認されてから返金までの流れを先に押さえると、各工程で何を決めるかが分かりやすくなります。

▼全体ガイドの記事
・デビットカード基幹システム開発の完全ガイド

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

デビットカード基幹システムの全体像

デビットカード基幹システムは、決済の承認や残高確認、資金の確保を中心に、売上確定から返金、精算までを担います。不正検知や監査も一貫して処理します。

クレジットカードは後日まとめて請求します。一方、デビットカードは原則として、利用の時点で預金口座とカード取引を連動させます。

カード管理とリアルタイム承認の機能

カード管理と承認では、各機能が担う範囲と、その責任の所在を設計します。

• ライフサイクル管理：申込、本人確認、審査結果、カード番号、有効期限、利用限度額を扱います。利用停止、再発行、紛失・盗難、退会も処理します。
• 承認判定：カードの有効性、口座残高、利用可能額を確認し、短時間で承認か否認かを返します。
• 追加の確認項目：加盟店、業種、国、時間帯、不正検知ルールも、判定の材料として使います。
• 取引記録と通知：元帳や勘定系に記録し、銀行アプリやメールで通知します。
• 外部サービスの責任：トークン化などで番号の保存を減らせますが、障害判断、顧客説明、照合、データ返却の責任は残ります。

承認から返金までの状態遷移の設計

デビットカードの取引は、承認だけでは完了しません。利用から返金まで状態が続くため、段階ごとに状態を管理します。

1. 利用要求を受けたら残高を確認し、利用額を一時的に確保します。
2. 売上確定データが届いた時点で、取引金額を確定します。
3. 取消や返金では、元の取引とのつながりを保ったまま資金を戻します。
4. 一意の取引IDを各段階に付け、再送による二重処理を防ぎます。

JCBは、利用時の引き落とし後に売上確定データとの差額を追加で引き落とすか、返金すると案内しています（出典：株式会社ジェーシービー「JCBデビットの引き落とし・返金について」、2026年確認）。

売上確定データが届かず、約60日後に返金されるケースもあります。また、通販では一時的な二重引き落としも起こります。

こうしたケースに備えて、返金待ち、期限到来、加盟店未送信、通信タイムアウトの扱いを業務仕様に定めておきます。

デビットカード基幹システムの進め方

企画では発行主体と対象ブランドを決めたうえで、要件定義、接続とセキュリティの設計、開発、非機能テストへ進みます。ブランド認定や移行、運用設計も行います。

画面やAPIの一覧に加えて、取引が失敗したときにどのシステムを正とするかを先に決めておきます。

企画・要件定義での発行スキームの確定

企画・要件定義では、発行スキームと業務要件、非機能要件をそろえます。

• 発行スキーム：発行主体を決めたうえで、Visa・JCBなどの国際ブランドにするか、J-Debitにするかを選びます。
• 対象と役割：顧客、口座、国内外の利用、ATM・EC、バーチャルカード、通知を決めます。収益モデルと、加盟店・PSP・銀行・ブランドの役割も整理します。
• 業務ルール：承認、残高不足、ホールド、売上確定、取消、返金の扱いを定義します。タイムアウト、再送、オフライン取引、為替差額、チャージバックも決めておきます。
• 非機能要件：月間取引件数、ピークTPS、応答時間、可用性、RTO・RPOを数値で示します。ログ保存期間、監査証跡、問い合わせ時間も数値に落とし込みます。
• 成果物：機能と接続先の一覧、状態遷移図、データ項目表、SLA案、責任分界表を作り、見積もりの比較に使います。

国際ブランド付きデビットとJ-Debitでは、接続先、審査、運用、精算の考え方が異なります。そのため、両方式の要件は同じものとして扱わず、それぞれ整理します。

設計・開発での責任分界と接続方式

カード管理や会員管理、オーソリゼーションを中心に、元帳・残高や精算までを役割ごとに分けます。また、APIゲートウェイや管理画面、監視・分析も設計の対象です。

勘定系や預金口座のシステムを正とするか、カード取引元帳を中間的な正とするかを定めます。そのうえで、照合の頻度と不一致時の訂正手順も決めておきます。

残高を参照した直後に別の取引が入ることもあります。このため、資金のホールド、解放、取消は一貫したトランザクションとして設計します。

開発方式は、標準機能と個別対応の範囲で大きく違います。

• 標準パッケージ・ASP：既製の機能を使います。
• クラウド型プロセッサ：決済処理を外部基盤に委ねる方式です。
• ハイブリッド：既存基幹と外部サービスの組み合わせです。
• フルスクラッチ：独自の要件に合わせ、一から構築します。

標準サービスは導入を早めやすい一方、独自の限度額ルールや複雑な返金には制約が出ることがあります。

クラウド型は拡張性を確保しやすいものの、データの所在、障害復旧、従量課金を確認する必要があります。さらに、マルチテナント環境と契約終了時のデータ返却も見ておきます。

2025年5月、TISはAWS上のミッションクリティカルな決済オーソリゼーションを目指す共同開発を発表しました（出典：TIS株式会社「TISとKort Valuta、決済システムの内製化に向けた共同開発を開始」、2025年）。決済基盤をクラウドに置くことは、実装と運用の選択肢の一つです。

テスト・認定・移行での確認事項

テストでは、正常系に加えて、取引の異常やピーク時の負荷、移行時の運用を確認します。

• 異常系：残高不足、カード停止、二重送信、通信タイムアウト、応答遅延の場面を再現します。
• 取引の継続：売上確定が遅れる場合や、取消と返金の順序が入れ替わる場合を試します。停止時の再送、保留確認、顧客案内も決めておきます。
• 負荷試験：平均値だけでなく、キャンペーンや給与支給日に取引が集中する場面を想定します。
• 本番移行：旧データの変換、カード状態の引き継ぎ、並行稼働、切替判定、ロールバック、問い合わせ窓口の準備を確認します。

ブランド試験、セキュリティ診断、脆弱性対応、総合テスト、運用リハーサルも行います。カード番号を扱う場合は、PCI DSS v4.0.1を前提にします。

その前提に沿って、暗号化と鍵管理、特権IDの扱い、脆弱性管理、ログ監視、委託先の証跡を確認します。

PCI Security Standards Councilは、v4.0.1を限定的な改訂とし、新要件の適用日は変更していないと説明しています（出典：PCI Security Standards Council「Just Published: PCI DSS v4.0.1」、2024年）。

デビットカード基幹システムの費用相場とコストの内訳

デビットカード基幹システムは公開されている定価が少なく、費用はカード枚数や取引量によって変わります。さらに、対象ブランドや勘定系、可用性、PCI DSSの範囲、移行データも費用に影響します。

この費用は、2025〜2026年時点の類似案件を参考にした編集部の推定です。カードプロセシング、決済ゲートウェイ、金融リアルタイム連携の案件を基にしています。公開価格の集計統計や正式見積ではありません。

初期開発費の対象範囲による違い

既存接続から全面スクラッチまで、開発範囲ごとの費用と期間の違いを比べます。

• 既存接続の小規模案件：3,000万円〜8,000万円、4〜8か月。
• パッケージ・クラウド導入：8,000万円〜3億円、8〜15か月。
• 複数ブランドなどの金融機関向け：3億円〜8億円、15〜24か月程度。
• 全面スクラッチ：8億円〜20億円超、24〜36か月以上となる可能性があります。
• 要件定義・PoC：1,000万円〜3,000万円、2〜4か月程度。

小規模案件は、1ブランドで既存の勘定系APIがあり、標準機能が中心という前提です。カードライフサイクル、承認、精算、通知、総合テストまでを含みます。

パッケージ・クラウド導入は、勘定系やアプリ、通知、データ移行との連携を含みます。複数ブランドや高可用基盤、24時間監視、DR、不正検知を含む、金融機関向けの案件もあります。

全面スクラッチでは、勘定系や周辺業務も含めて構築します。PoCでは、接続方式、性能、障害時の状態遷移を検証します。

残高ホールド、再送、返金、照合など、事故が起こりやすい機能は小さく試しておきます。全機能を作り込む前に検証しておけば、方式を決めた後の手戻りを抑えられます。

運用と認定を含むランニング費

運用費の推定の目安と、別途かかりうる費目を規模ごとに確認します。

• 標準的な小規模導入：クラウドなどの運用費は年1,000万円〜5,000万円程度。
• 大規模基盤：年5,000万円〜2億円超となる場合もあります。
• 別途費用：取引の従量課金、カードの発行と郵送、脆弱性診断、PCI DSS支援、ブランド認定試験。

運用費は、クラウド、プロセッサ利用料、接続回線、監視、保守の費目に分けて見積もります。障害対応や監査も、別の項目として扱います。

24時間365日の監視や障害代行、照合、未完了取引の調査も、総保有コストに影響します。加えて、法令やブランド仕様の変更、インシデント時の顧客対応も考慮します。

NTTデータのCAFISは1984年から運用され、最大で月間10億件の取引を処理します。さらに、24時間365日のサービス提供と監視を案内しています（出典：株式会社NTTデータ「CAFIS」、2026年確認）。自社構築の費用と、こうした運用実績を並べて比べます。

デビットカード基幹システムの見積もりを取る際のポイント

複数社に同じ条件を渡し、初期開発、導入支援、ライセンス、プロセッサ費に分けて見積もってもらいます。さらに、クラウド、保守、監査、取引従量費も費目ごとに出してもらいます。一式の見積もりでは、移行、ブランド認定、障害対応の除外を見落としやすくなります。

RFPに記載する取引量と非機能要件

RFPの条件は、取引量、接続先、非機能要件、セキュリティの観点で分けて記載します。

• 取引条件：カード枚数、月間取引件数、ピークTPS、ブランド、国内外比率、ATM・EC・モバイルウォレット対応。
• 接続・移行条件：勘定系製品名、接続方式、API、通知経路、本人確認・不正検知サービス、移行対象カード件数。
• 非機能要件：ピーク時応答時間、可用性、RTO・RPO、計画停止の扱い、ログ保存期間。
• カード情報の管理：保管場所、トークン化の担当、PCI DSSの対象範囲、証跡の責任者。

経済産業省は2025年3月に「クレジットカード・セキュリティガイドライン」の改訂を公表しました。カード情報の漏えいや不正利用を防ぐ関係事業者の対策は、引き続き重視されています（出典：経済産業省「『クレジットカード・セキュリティガイドライン』が改訂されました」、2025年）。

デビットカードの案件でも、委託先を含めて、セキュリティの責任をどこまで誰が受け持つかをRFPに盛り込みます。

ベンダーの実績と責任範囲による比較

実績、技術領域、障害対応、契約上の責任を、同じ条件で確認します。

• 類似実績：同じブランドや勘定系、同程度のピークTPSを扱った経験の有無を確認します。
• 得意領域：プロセッシング、ネットワーク、勘定系・アプリ連携、不正検知、運用について、担当範囲を比べます。
• 障害時の対応：タイムアウト時の資金の扱い、返金の担当と時期、二重要求の排除キー、縮退運転、顧客通知について質問します。
• 支援と契約：認定やPCI DSSの支援範囲、SLAを確かめます。

契約では、損害時の補償やインシデント報告、再委託先を定めます。さらに、データ返却、ソースコードや設定情報の引き継ぎ、ベンダー変更時の協力義務も決めておきます。

追加費用とプロジェクトリスクの先行管理

追加費用と運用リスクは、見積もりと実際の機能の両面から確認します。

• 追加費用の要因：複数ブランドや海外・多通貨、独自限度額、例外返金があります。大量移行、無停止切替、24時間監視、個別不正検知も含まれます。
• 見積範囲：「標準」「設定変更」「個別開発」「対象外」に分け、工数や認定待ち、受入テストの期間を確認します。
• 取引検証：画面の試作品だけでなく、実電文やサンドボックスで、残高照会からホールド、承認、売上確定、取消、返金、照合まで試します。
• 運用分担：標準機能と個別開発の境界、自社要員が担う監視・問い合わせ・障害判断を早めに定め、稼働後のベンダー依存リスクを抑えます。

よくある質問（FAQ）

費用、開発方式、期間、勘定系との関係について、担当者から寄せられやすい質問に答えます。自社に必要な範囲を判断する際の参考にしてください。

デビットカード基幹システムの開発費用はいくらですか？

費用は開発範囲によって変わります。ここで示す金額は、いずれも編集部の推定です。

• 既存プロセッサ接続：標準機能中心なら3,000万円〜8,000万円。
• パッケージ・クラウド連携：勘定系・アプリとの連携を含み、8,000万円〜3億円。
• 大規模・全面開発：複数ブランド、高可用性、DR、24時間運用、全面スクラッチを含むと、3億円〜20億円超の場合があります。

正式な見積もりを取るには、カード枚数、ピークTPS、接続先、SLA、移行件数を示すことが必要です。

デビットカード基幹システムの開発期間はどのくらいですか？

既存APIの接続から勘定系の刷新まで、構築範囲をそろえて期間を見積もります。

• 既存APIの小規模接続：4〜8か月。
• パッケージ・クラウド導入：勘定系・アプリ・移行・認定を含めて8〜15か月。
• 高可用基盤・全面刷新：複数ブランドは15〜24か月、全面スクラッチや勘定系刷新は24〜36か月以上となる可能性があります。

ブランド試験や外部機関の承認、切替リハーサルが遅れると、開発以外の理由でも稼働日が延びます。

決済APIを導入すれば基幹システムは不要ですか？

決済APIを使う場合でも、カード状態や口座残高、資金ホールド、売上確定、返金を管理する基盤が必要です。さらに、照合と監査も担う必要があります。

障害時の再処理も設計対象です。標準プロセッサを使う場合でも、勘定系との責任分界、データの正、ログ保存、障害時の顧客対応は、自社の運用として定めてください。

PCI DSS対応は開発会社に任せればよいですか？

開発会社だけに任せず、発行主体やサービス提供者が最終的な責任範囲を把握しておきます。そのうえで、カード情報の保管場所やトークン化、委託先の証跡、脆弱性対応を明確にします。

さらに、アクセス権やログ監視、監査資料の作成者も、契約と運用手順に落とし込みます。外部プロセッサへカード情報を預けて適用範囲を縮小しても、対象範囲がゼロになるとは限りません。

まとめ

デビットカード基幹システムは、カードの見た目や申込画面だけでなく、利用時点の資金移動を安全に処理する基幹です。承認、残高ホールド、売上確定、取消、返金、照合までの状態遷移を設計します。

勘定系やブランド、決済ネットワークに加え、アプリ、不正検知、運用の担当についても、どこまでを誰が受け持つかを明確にします。

成功のポイントは状態遷移と非機能要件

発行スキームとブランドを決めたら、取引の状態遷移と非機能要件を要件として固めます。非機能要件には、ピークTPS、応答時間、可用性、RTO・RPOなどが含まれます。そのうえで、PCI DSSと移行方針も要件に入れます。

費用は初期開発だけでなく、プロセッサやクラウド、監視、保守を含めて比べます。認定や監査、従量課金も比べる対象です。標準サービスを使う場合でも、自社に残る運用の責任は、RFPと契約に明記しておきます。

RFPとPoCの対象の整理

まず条件を整理し、そのうえで見積もりと開発方式を判断します。

• 条件の整理：カード枚数、月間取引件数、ピークTPS、ブランドを1枚にまとめ、勘定系やアプリ、外部プロセッサ、移行件数、SLAも書き加えます。
• PoCでの検証：残高不足、タイムアウト、二重要求、売上確定の遅れ、取消、返金、照合を試し、同じ条件で複数社に提案を依頼します。
• 開発範囲の選択：カード発行基盤、決済ゲートウェイ、勘定系連携を含むフル基幹の中から、必要な範囲を選びます。

必要な範囲を切り分けることが、適正な費用と安全な開発につながります。

▼全体ガイドの記事
・デビットカード基幹システム開発の完全ガイド

▼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を創業。