クレジットカード・決済開発の発注/外注/依頼/委託方法について

クレジットカード・決済開発の発注は、対象範囲を分け、PSPに任せる機能を選び、責任を段階的に決めると、費用と納期を管理しやすくなります。

流れは、発注形態、RFPと要件整理、契約と費用、委託先選定の順です。全体像は、クレジットカード・決済開発の完全ガイドでも確認できます。

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

クレジットカード・決済開発を外注する前に知るべき全体像

接続後の記録や照合までを発注範囲に含める視点が分かります。

決済開発では、支払い画面に加え、オーソリ、売上確定、取消、返金、チャージバックも設計します。入金、会計連携、監査ログも同じ業務の一部です。範囲を分けると、不要な開発を避けつつ安全性を確保できます。

EC・SaaS・カード基幹の範囲の分け方

見積の前提を同じにするには、案件の規模と業務範囲を分けて考えます。

EC・予約サイト：PSPのCheckoutやAPIとの接続が中心です。
SaaS・マーケットプレイス：継続課金や従量課金、売上分配が加わります。
カード・金融基幹：会員、与信、精算、ネットワーク接続が対象です。

EC連携は、決済画面、注文更新、Webhook、返金、管理画面から始められます。一方で、SaaSやマーケットプレイスでは、複数通貨や加盟店管理も含まれるため、決済と請求台帳を分けて設計します。

基幹刷新では、24時間運用や災害対策も対象になります。そのため、EC連携の見積をそのまま当てはめないようにします。

決済処理と業務責任の図解

発注範囲をはっきりさせるには、決済の接続経路と管理対象を図にまとめます。

接続経路：EC、POS、アプリから自社API、PSPまたは決済オーケストレーターを経由し、カードネットワークやカード会社へつながります。
管理対象：顧客、注文、トークン、請求、返金、手数料
照合対象：入金、会計、監査ログまでの記録

タイムアウト後の再送には冪等キーを使い、二重請求を防ぎます。また、非同期Webhookは順序が入れ替わることがあります。そのため、順序が崩れても状態が壊れない設計が必要です。

売上と入金の差異も追跡します。

発注形態の選び方

独自に作り込む領域が広がるほど、検討する開発範囲も広がります。

発注形態は、自社で作り込む差別化の領域と、外部サービスに任せる標準の領域をどこで分けるかで決まります。優先する事項に応じて、候補を選びます。

早期導入：ホスト型CheckoutやPayment Linkを使う形
独自の会員・請求体験：PSPのAPIを連携する形
独自のルーティング・精算：決済基盤の開発を検討する

全面スクラッチの要否は、独自機能が売上や業務効率に与える効果で判断します。

取扱高は、その判断材料の一つとして見ます。

標準のCheckoutやPayment Linkを使う方法

ホスト型画面や決済リンクは、カード情報を自社サーバーに保存・通過させない構成を取りやすい方法です。

導入の速さ：初期費用と導入期間を抑えやすい
向く案件：ECの単発決済、イベント申込、少数の商品販売
確認事項：独自導線や店舗・EC一体管理には制約が出やすい

画面の自由度より早期公開を優先する案件に向いています。また、分割ルールやポイント充当にも制約が出る場合があります。さらに、将来の追加開発と移行条件も、発注時に確認しておきます。

PSPのAPI連携を開発会社へ外注する方法

PSPのAPI連携は、自社の注文・会員・請求システムと決済をつなぐ方法です。独自のUIや継続課金にも対応しやすくなります。

業務連携：会計、在庫、CRMとの接続を依頼する
例外処理：Webhookの再送、部分返金、失敗時の再試行まで含める
管理機能：権限管理と監査ログも範囲に入れる

決済状態の状態機械やカード有効期限の更新も依頼します。

PSPを変えるときにトークンを移行できるかは、契約前に文書で明確にしておきます。移行できない場合は、影響を受ける業務も確認しておきます。

決済オーケストレーターやスクラッチを選ぶ場合

独自の決済運用が競争力になる場合は、決済オーケストレーターや独自基盤が候補になります。

ルーティング：複数PSPへの振り分けと、障害時の切り替え
精算：加盟店別の手数料計算、売上分配
運用：監視と障害時の切り戻しまでを設計する

複数のルートを束ねるほど、トークン管理と台帳の正確性、責任の境目が複雑になります。また、カード番号を自社環境で扱う場合は、PCI DSS、脆弱性診断、アクセス制御への対応も見積もりに含めます。

ログ監視や24時間365日の運用体制も対象です。

開発費の安さだけで判断すると、運用の費用を見落としがちです。

ポイント

標準機能で足りるか、独自の会員・請求や精算が事業の差別化になるかを先に見ると、早期導入と独自開発のどちらが合うかを判断しやすくなります。

RFPと要件整理の準備範囲

RFPは、各社が同じ前提で提案できるようにするための文書です。

機能一覧はその一部で、未確定の事項は仮説と依頼事項に分けて示します。

事業前提：取扱高、決済件数、平均単価、販売チャネル
運用前提：対象国、入金サイクル、既存システム
計画前提：セキュリティ方針と公開の希望時期

「現時点の仮説」「提案してほしい選択肢」「見積に含める範囲」を分けて書くと、各社の回答を比べやすくなります。

RFPに書くべき事業・決済・システム情報

RFPでは、事業、決済、既存システムの情報を分けて整理します。

事業情報：商品、BtoC・BtoB、月間取扱高、繁忙期のピーク
決済情報：ブランド、課金方式、3Dセキュア、カード更新
システム情報：ECカート、POS、会員基盤、連携方式

事業情報には、平均単価、返金率、チャージバックの想定も含めます。

決済情報では、継続課金と従量課金の扱いを中心に、単発や分割、リボの区分も記します。再試行の扱い、複数PSP、越境決済も整理します。

システム情報には、注文・在庫・会計との連携を含めます。ERP、クラウド、既存APIの扱いも示します。また、認証基盤と監視の現状も記します。

RFPで指定する決済状態と例外系

状態ごとの条件と担当システムを決めておくと、納品後に例外処理を追加する事態を避けられます。

処理状態：未処理、認証中、認証済み、売上確定、失敗
取消・返金：取消、一部返金、返金後の通知
入金・紛争：チャージバックと入金済みの状態

二度押し、PSPの無応答、遅延Webhookは、必須のシナリオとして扱います。返金後の売上通知も、必須シナリオに含めます。

必須シナリオを書かずに「正常系を実装」とだけ記すと、重要な例外処理が追加費用になりやすくなります。

カード情報とセキュリティ責任の決め方

RFPの初期段階で、カード番号を自社で扱うか、PSPのホスト画面やトークン化を使うかを決めておきます。

対象範囲：非保持化で、PCI DSSの対象を小さくしやすい
残る対策：改ざん、脆弱性、権限、ログ、不正ログインへの備え
責任分担：設計、試験、運用の担当を委託先と合意

なお、2025年3月の改訂で、経済産業省はEC加盟店に脆弱性対策、EMV 3-Dセキュア、不正ログイン対策を求めています（出典：経済産業省「クレジットカード・セキュリティガイドライン」2025年）。

ポイント

未確定の事項は仮説と依頼事項に分けて示すと、各社の回答を同じ前提で比べられます。決済の状態や例外系は、書かないと納品後の追加費用になりやすい点に注意が必要です。

契約形態と開発プロセスの設計

要件の不確実性と安全性を踏まえ、工程ごとに契約を分けます。

たとえば、一括請負では未確定の要件が変更契約になりやすく、全工程を準委任にすると予算と納期を管理しにくくなります。

発注側と開発会社は、実装・試験と保守運用の各工程で、成果物と責任の担当を決めておきます。企画から本番移行までの全工程の内訳は、後の「企画から本番移行までの工程の区切り方」で示します。

請負契約と準委任契約の使い分け

納品物を完成させる工程と、調査や改善を続ける工程とで、契約を使い分けます。

請負契約：納品物と検収範囲を明確にしたい場合に向く
準委任契約：要件探索や専門人材の支援

請負では、画面やAPI、データ連携を納品物にできるほか、テスト仕様書や運用手順書も対象にできます。

検収条件と仕様変更の扱いも記します。

準委任では、作業範囲と稼働時間を定めます。会議体や成果報告も置きます。特に、調査しながら最適解を探す決済基盤の工程では、月次の作業範囲が予算管理に役立ちます。

契約書に入れる納品物・検収・変更管理

納品物と受入条件を具体化したうえで、追加開発の費用と承認手順を決めます。

設計資料：要件、画面・API、データ項目、決済状態図
試験・運用資料：計画、診断報告、運用設計、障害手順
引き継ぎ物：ソースコード、インフラ設定、引き継ぎ資料の確認

受入テストには、二重送信やタイムアウト、遅延Webhookを含めます。部分返金やカード更新も、試験の対象に加えます。

PSP障害や入金差異も、試験で確かめる対象です。追加する決済手段や課金ルールの見積方法と承認者は、変更管理表に記します。

企画から本番移行までの工程の区切り方

工程を分けると、要件と安全性を確認しながら本番へ進められます。

企画・現状把握：チャネル、決済手段、取扱高、基幹、入金周期、対象国の整理
要件定義：返金、チャージバック、状態、権限、台帳、監査ログ、SLA、障害時の連絡方法の決定
基本設計・PoC：画面、API、Webhook、会計、不正検知、監視、バックアップ、冗長構成の確認
実装・試験：通信断、二重送信、PSP障害、売上と入金の差異の検証
本番移行：加盟店審査、脆弱性診断、運用訓練を経たうえでの段階的な公開

ポイント

納品物を完成させる工程は請負、調査や改善を続ける工程は準委任と、工程の性質で契約を分けると判断しやすくなります。契約の種類がそろっていないと、見積の比較もしにくくなります。

クレジットカード・決済開発の費用相場

規模ごとに費用と期間の幅が異なることを見比べられます。

開発費の目安は幅が広く、標準PSP連携の100万〜400万円から、大規模基幹の5,000万円〜数億円以上までです。費用は案件ごとに異なり、決済手段や取扱高、既存基幹との接続、カード情報の扱いによって変わります。可用性や運用時間も、費用に影響します。

開発、PSP利用、セキュリティ、監視・保守を分けて、3年程度の総保有コストで比べます。

開発規模別の費用と期間の目安

規模別の概算は、機能範囲と必要期間を合わせて見比べます。

標準連携：100万〜400万円、1〜3か月が目安
カスタム連携：400万〜800万円、3〜6か月程度
決済基盤：500万〜2,000万円、6〜12か月程度
大規模基幹：5,000万円〜数億円以上、12〜18か月以上の場合があります

標準連携では、CheckoutやAPIを使って、決済と注文更新、返金を実装します。Webhookと最小限の管理画面も含みます。カスタム連携には、複数PSPや独自課金に加えて、会計・在庫・CRM連携、継続課金が含まれます。

決済基盤では、複数ルートの切り替えや独自台帳を扱います。加盟店・店舗の管理、不正判定も対象です。さらに、大規模基幹では、会員、与信、精算の業務から、ネットワーク接続やBCPまでを対象にする場合があります。

PSP利用料と運用費の見積もり

PSPの利用料は取扱高や契約条件で変わるため、項目別に見積もります。

初期費用：無料〜数十万円の相場
月額費：数千円〜数万円の相場
決済手数料：決済金額の2〜10％、利用料は0.3〜1％
処理費：1件数円〜数十円のトランザクション費用

これらの費用相場は、業種や商材、取扱高によって変わるほか、審査、入金サイクル、オプションでも変動します。相場は、SBペイメントサービス「決済代行の手数料とは？」（2026年更新）で示されているものです。

たとえば、月商1,000万円で手数料が3.6％なら、手数料は月36万円、年間432万円です。

Stripeの国内カード標準料金は、成功取引1件あたり3.6％です（出典：Stripe「料金体系 & 手数料」2026年確認）。この料率を含め、各社の料率は、自社の取扱高を前提に置いて比べます。

3年TCOによる費用の比較

3年TCOでは、初期開発費に加えて、継続費用と運用費も合算します。

決済関連：PSP初期・月額費、手数料、処理費
運用関連：返金、チャージバック、クラウド、監視
保守関連：診断、保守、障害対応、追加開発

初期開発費が300万円であっても、月商1,000万円で3.6％の手数料が3年続くと、手数料は1,296万円です。一方で、月額費が高いPSPでも、料率や入金サイクル、標準機能による追加開発の削減を含めて見ると、有利になる場合があります。

ポイント

開発費の安さだけで比べず、PSP利用料と運用費を足した3年TCOで比べると、規模や条件の違う提案も同じ基準で判断できます。

委託先選定と見積比較で確認すべきポイント

委託先は、知名度や最安値だけでなく、事業モデルと運用責任に合うかで選びます。

短期導入：PSP標準機能に強い会社を候補にする
複数決済：クラウド基盤や複数決済の経験
大規模運用：カード・金融基幹と24時間運用の実績

同じRFPを各社に渡し、回答を比べます。比べる観点は、機能と体制、安全性です。加えて、納期、費用、将来の移行性も見ます。

実績で確かめる決済の種類と運用規模

「決済実績あり」は、自社案件との類似性を確かめるための入口として見ます。

決済の種類：EC、店舗POS、継続課金、マーケットプレイスの区分
運用規模：月間件数、ピーク処理量、障害復旧事例
周辺業務：返金、チャージバック、会計連携、トークン移行

カード会社やアクワイアラ基幹の経験は、別に分けて尋ねます。なお、実績は匿名化できる範囲で説明を求めます。

例として、NTTデータはCAFISやADAPTISなどの顧客接点・決済基盤を展開しています。TISはPAYCIERGEを含む決済ソリューションを提供しています（出典：NTTデータ「顧客接点・決済」、TIS公式事例）。大規模基盤を比べる際は、公式事例と自社案件の類似性を照合します。

見積書の機能・工数・前提条件の比較

見積の「一式」は分解して、範囲と別料金の条件を確かめます。

工程：要件定義、基本設計、詳細設計、実装、単体・結合・総合・受入試験、移行、リリース、保守ごとに分ける
前提：環境、連携先、データ量、ピーク性能、対応ブラウザ
追加費用：「一式」に含む内容と別料金の確認

工数に加え、テスト件数、外部サービス費、セキュリティも明記してもらいます。また、3Dセキュアや不正検知、カード更新の扱いを確認します。継続課金や部分返金についても、見積に含まれるかを確かめます。

入金消込や障害監視も、標準かオプションかを確かめます。

障害・情報漏えい・返金差異の担当の分け方

障害が連鎖する場面を想定し、復旧と照合の担当を契約前に決めておきます。

障害対応：ログ保管、一次切り分け、連絡期限の決定
情報漏えい：報告、再委託先の管理、損害賠償の取り決め
復旧・照合：入金照合、バックアップ、災害復旧目標の設定

PSPや自社API、ネットワーク、Webhook、会計連携の障害は、互いに連鎖する場合があります。

脆弱性の修正期限も、契約に記しておきます。なお、PCI DSS v4.0の将来日付要件は、2025年3月31日から有効です（出典：PCI Security Standards Council、2025年）。準拠範囲と証跡の作成者を確認し、発注者側の責任も含めて合意します。

最終候補に投げる共通の質問

同じ質問票で回答を集めると、候補各社の運用力と契約後の体制を比べられます。

情報と認証：カード保持者、トークン移行、3Dセキュアについて
課金と精算：追加費用、失敗処理、返金、入金消込
運用体制：SLA、24時間365日対応、担当者の継続参加

チャージバックの担当や不正検知の範囲も見ておきます。回答が機能名だけの場合は、注意が必要です。

画面、状態遷移、運用手順、復旧訓練まで説明できるかを確認します。また、開発、セキュリティ、運用の責任者が参加するかも見ておきます。

ポイント

迷ったら、自社案件と同じ決済の種類や運用規模の実績があるか、障害時にどこまでを誰が受け持つかで候補を絞ると、判断しやすくなります。

よくある質問

発注前には、費用や期間、安全性、委託先の選び方について疑問が生じやすいものです。社内の稟議や相談で使える基準を、ここで整理します。

クレジットカード決済の外注費用は最低いくらですか？

標準CheckoutやAPIで、画面、注文更新、返金、Webhookを実装する場合は、100万〜400万円程度が企画初期の目安です。既存接続や会計連携に加えて、継続課金、3Dセキュア、不正検知を含めると増額します。

テストや運用設計も費用に影響します。なお、PSP利用料と決済手数料は別途かかります。

PSPを使うべきか自社開発すべきか迷ったらどうしますか？

発注方法は、カード情報をどう扱うかと、独自機能が必要かどうかで判断します。

標準案：カード情報を非保持化し、決済処理と認証はPSPに委ねる
独自機能：独自精算、手数料、加盟店管理、複数PSP切替が差別化になる場合は、API連携や決済オーケストレーター・独自基盤を検討する
大規模基幹：金融・決済基盤の実績があるSIerを、SLA、BCP、監査対応と合わせて比べる

ポイントや課金ルールが事業上の差別化になるかどうかも、判断材料の一つです。

カード情報を保持しなければセキュリティ対策は不要ですか？

カード情報を保持しなくても、対策と責任分担は必要になります。

PCI DSS：非保持化により、対象範囲を小さくしやすい
継続対策：脆弱性、管理者アカウント、不正ログイン、改ざん、ログ監視、3Dセキュアへの備え
責任分担：障害復旧の責任を自社と委託先で分け、非保持化の範囲、PSPの準拠証明、診断担当、連絡期限も契約と運用手順に記す

開発会社への見積依頼で最低限伝える情報は何ですか？

見積を依頼するときは、事業、決済、システム、運用の情報を伝えます。

事業・決済：販売チャネル、月間取扱高、平均単価、決済件数、ブランド、課金方式、返金率、チャージバック
システム・計画：既存システム、決済手段、入金サイクル、公開時期、会計・在庫・POS連携
安全性・変更：カード保持方針、3Dセキュア、不正検知、監視時間、SLA、将来のPSP変更
未確定事項：未確定の項目も伝え、各社に同じ前提で費用、期間、リスクを出してもらう

まとめ

標準機能で早く始める領域と、自社固有の業務として作る領域を分けます。そのうえで、発注前に確認する事項を整理します。

クレジットカード・決済開発では、EC、店舗、SaaS、マーケットプレイス、カード金融基幹を区別します。そのうえで、標準PSPに任せる範囲と自社開発の範囲を決めることが、費用と納期を管理する出発点です。

RFPには、課金モデル、状態、例外系、カード情報の扱いも記載します。安全性、SLA、検収条件も加えておきます。見積は開発費だけでなく、3年TCOで比べます。

PSP費用、返金・チャージバック、監視・保守、追加開発まで総額に含めます。委託先は、類似実績と障害時の責任の境目を確認して選びます。トークン移行や3Dセキュア、不正対策も見ておきます。

発注後も設計・試験・運用を一緒に管理できる体制が、安定した決済サービスにつながります。

発注前に確認する三つのポイント

提案の前提をそろえるには、確認事項を三つに絞って押さえます。

対象範囲：EC、店舗、SaaS、基幹の区分
処理と責任：カード保持者、決済状態、例外系の決定
総費用：開発費と運用費を分けたうえで、3年TCOを試算

この三点を固めると、開発会社の提案条件をそろえられます。

比較可能なRFPの作成と相談の始め方

完璧な仕様書を最初から作る必要はありません。必要な情報を一枚にまとめて、相談を始めます。

事業とシステム：取扱高、決済手段、既存システム
計画と安全性：希望時期とセキュリティ方針
比較案：標準PSP案とカスタム開発案を依頼する

両案を比べると、自社に適した発注形態を判断しやすくなります。

▼全体ガイドの記事
・クレジットカード・決済開発の完全ガイド

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