決済ゲートウェイシステムの発注は、要件整理、RFP作成、PoC・受入確認、契約・運用決定の順に進めると、追加開発を抑えやすくなります。
先に決済手段や連携する業務システムを決めておくと、各社の提案を同じ前提で比べられます。全体像は決済ゲートウェイシステム開発の完全ガイドもご覧ください。
▼全体ガイドの記事
・決済ゲートウェイシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
決済ゲートウェイシステムを発注する前に知るべき全体像
決済ゲートウェイは、ECやアプリ、店舗POSと、PSP、カード会社、銀行、コード決済事業者などをつなぐ中継基盤です。
認証・与信・売上確定・取消・返金・入金照合を処理するため、発注範囲には画面に加えて決済後の業務も含めます。そこで発注の際は、まず決済手段や販売チャネル、連携する業務システムを決めておきます。
PSPの導入と独自ゲートウェイ開発の違い
PSPのCheckoutやホスト型決済画面を使う場合、決済処理、カード情報のトークン化、本人認証は外部に任せられます。自社が開発するのは、注文画面と業務連携の部分です。
カード決済や定期課金を1つのサービスで始める企業にとっては、短期間で導入しやすい方式です。一方で、複数PSPの切り替えや手数料計算、分配・精算を統合するなら、独自ゲートウェイの開発案件になります。
発注書に記載する決済後の責任範囲
決済は成功したのに注文登録が失敗した場合や、Webhookが遅れた場合に備えて、確認担当と再処理システムを決めておきます。利用者が二重にボタンを押した場合の扱いも、あらかじめ定めます。
決済IDと注文IDの対応、冪等性キーは、発注の段階で定めておきます。そのほか、次の項目も決めておく必要があります。
- 顧客ID：顧客ごとに取引をたどる際の識別子
- 返金IDの対応：返金と元の決済を結び付ける
- リトライ回数：決済の再試行を何回まで行うか
- 手動再処理の権限：手動で処理をやり直せる人の範囲
未定義のままでは、本番運用で二重決済や返金漏れが起きるおそれがあります。
発注形態（パッケージ・クラウド・スクラッチ）の選び方
発注形態は、決済手段の数に加えて、独自業務、取引量、可用性、社内の運用体制をもとに選びます。標準機能で足りる場合にスクラッチを選ぶと、開発費に加えて、法令改訂やPSP仕様変更への対応費も膨らみます。
一方で、売上分配や複数PSPの障害切り替えが必要な場合に標準画面だけで済ませると、後から大規模な作り直しが生じることがあります。
標準決済を早く始めたい企業向けのホスト型・Checkout連携
ホスト型決済画面やCheckoutは、カード番号を自社環境で入力・保存する範囲を小さくできます。そのため、発注範囲を画面、API、Webhook、注文システムとの連携に絞りやすい方式です。
カード決済や継続課金を早く始めたいEC、SaaS、予約サービスに適しています。ただし、注文状態、返金、チャージバック、管理者権限、ログ、問い合わせ対応は別途整備が必要です。
業務の共通化を重視する企業向けのAPI連携・複数PSP統合
自社の購入画面やアプリを保ったまま、複数PSPを共通APIの裏側につなぐ方式です。PSPごとの仕様差を吸収し、条件に応じて接続先を選べます。
成功率、手数料、障害状況、地域、商品特性をもとにルーティングできます。マーケットプレイスやサブスクリプション、店舗とECを統合する事業に向きます。
PSPごとに異なる状態コード、Webhook、返金期限、売上確定の仕様は、共通の形にそろえる設計が必要です。
精算・ルーティング・高可用性が必要な企業向けの独自ゲートウェイ
独自ゲートウェイは、決済を事業の競争力や基幹業務の中心に置く企業に適しています。決済手段を増やすことだけが目的だと、開発範囲が過大になることがあります。
加盟店ごとの精算や売上分配が必要な場合、標準機能だけでは要件を満たしにくくなります。複数通貨、ルーティング、24時間監視、障害切り替え、監査証跡が必要な場合も、標準機能では足りなくなります。
発注先の候補には、アプリ開発会社に加えて、決済業務とインフラ運用を理解するSI会社も入れて比べます。
決済ゲートウェイシステムの発注・外注の進め方
発注は、販売形態と取引量、責任分界、PoC・開発・受入テストの順に進めます。発注者が決めることと、PSPや開発会社の専門知識を借りる部分を分けておくと、各社の提案を比べやすくなります。
1. 販売形態・取引量・対応決済の整理
利用先、取引規模、決済手段を順に定めて、必要な性能と運用を整理します。
- 利用先は、EC、アプリ、店舗POS、マーケットプレイス、予約、請求・継続課金から選びます。
- 月間件数、ピーク時の1分あたり件数、平均・最大単価、同時アクセス数を押さえます。
- 返金率、チャージバック想定、海外利用の有無も、取引規模の前提に入れます。
- 候補の決済手段は、カード、デビット、コンビニ、銀行振込、キャリア・コード決済です。
- Apple Pay、Google Pay、口座振替も候補に加えて、初期対象を絞り込みます。
同じ月間1万件でも、セール開始の5分間に集中する場合と、1日中均等に発生する場合では、必要な性能が異なります。
決済手段を増やすと、審査、売上確定、返金に加えて、入金サイクル、手数料、問い合わせ窓口も増えます。そこで、初期はカードと主要な決済手段に絞り、実績を見て広げる方法もあります。
2. PSP・自社・開発会社の責任分界
RFPでは、PSP、自社、開発会社のそれぞれがどこを受け持つかを明確にします。
- 決済情報：カード番号などを扱う場所
- 契約・審査：PSPとの契約主体と審査申請の担当
- 決済画面：決済画面の脆弱性を管理する担当
- 自社側の対策：サイトの脆弱性、埋め込みスクリプト、Webhook署名検証、管理画面権限、ログのマスキング
「セキュリティはPSPが対応する」とだけ書くと、責任範囲が曖昧になります。自社や開発会社に対策の責任が残る場合もあります。
2025年3月には、経済産業省の「クレジットカード・セキュリティガイドライン」が6.0版に改訂されました。
同版は、EC加盟店に脆弱性対策、EMV 3-Dセキュア、不正ログイン対策などを求めています（出典：経済産業省「クレジットカード・セキュリティガイドライン改訂」）。そのため、発注の際は対象となる対策と証跡を要件書に記載します。
3. PoC・開発・受入テストの段階分け
不確定な要素が残るときは、要件整理やPoCから発注し、そのうえで本開発の受入条件を定めます。
- PSP仕様、決済審査、注文・会計連携に不確定な要素が残る場合は、最初から本開発を請負契約にはしません。
- Sandboxでの確認項目は、決済受付、Webhook受信、注文反映、取消、全額・部分返金、失敗時の再照会です。
- 成果物には、画面、状態遷移図、API仕様、例外シナリオ、性能測定結果を入れます。
- 正常系の成功率に加えて、タイムアウト、通信断、Webhookの重複・順序逆転、3-Dセキュアのチャレンジも受入条件に含めます。
- 期限切れ、限度額超過、返金失敗、PSP障害、入金データの不一致もテスト対象です。
発注者、PSP、開発会社の三者で受入テストを確認しておくと、障害の原因を押し付け合う状況を減らせます。
RFPと要件整理による発注条件のそろえ方
RFPは、各社が同じ前提で提案・見積を作るための比較基準です。
完成した仕様書がなくても、事業目的、対象範囲、既存システム、希望時期を整理すれば、初回提案の質が上がります。決済手段、取引量、セキュリティ方針、運用体制も、あわせて整理します。
事業要件と機能要件の分け方
事業目的と機能範囲を分けたうえで、各機能に導入時期の優先順位を付けます。
- 事業目的：売上拡大、購入完了率改善、決済手段拡張、海外販売、請求効率化
- 決済機能：受付、与信、売上確定、取消、全額・部分返金、継続課金、カード情報更新、再試行
- 運用機能：チャージバック、入金照合、取引検索、管理者権限、監査ログ
- 優先順位：「必要」「初期リリースでは任意」「将来対応」に分類
初期は国内カードと月次一括の入金照合を必須にし、複数通貨や自動ルーティングを第二段階にする方法があります。
優先順位がないと、会社ごとに機能範囲が変わってしまいます。その結果、安い見積ほど重要な例外処理を含まないことがあります。
RFPの中心に置く異常系と運用シナリオ
決済APIのタイムアウト時や、PSPでは決済が成功しても自社が応答を受け取れない場合について、処理を決めます。また、Webhookが同じ取引に3回届く場合や、注文の失敗後に売上だけが確定した場合も対象になります。
再送の条件が曖昧なままだと、二重決済を防ぎにくくなります。そこでRFPには、受付、処理中、成功へと進む状態遷移を添付します。失敗、要確認、取消、返金に関する状態も含めます。
要確認の取引を自動で再照会するのか、担当者が管理画面で確認するのか、利用者に何を表示するのかも定めておきます。あわせて、売上とPSPの入金データを日次で突き合わせ、差異の通知と解消期限を記載しておくと、運用費を比べやすくなります。
数値で示すセキュリティ・性能・運用の非機能要件
非機能要件は数値や対象範囲で示し、セキュリティ対策もRFPに明記します。
- 性能・可用性：可用性、応答時間、ピーク処理件数、復旧時間
- 運用条件：バックアップ頻度、ログ保存期間、監視時間帯、一次連絡までの時間
- セキュリティ：脆弱性診断、WAF、秘密情報管理、ログのマスキング、権限分離
- 障害対応：監視とインシデント報告の範囲
24時間365日の監視にするか営業時間内の対応にするか、障害から何分以内に一次連絡するかによって、インフラ構成と保守費が変わります。
PCI DSS v4.0.1では、EC加盟店が決済ページのスクリプトを管理することが重視されています。改ざんや情報窃取のリスクを確かめるための考え方です。
埋め込み決済でも、決済に影響するスクリプトへの対策は必要です（出典：PCI Security Standards Council「e-commerce scripts FAQ」）。
契約形態と決済ゲートウェイシステムの費用相場
費用は、初期開発費のほかに、次の3つに分けて考えます。
- PSP手数料・月額：決済に関わる継続的な費用
- クラウド・監視：運用にかかる費用
- 保守・法改正対応費：法令改訂への対応にかかる費用
初期見積だけでなく、3年程度の総保有コストで比べます。
決済手数料、返金手数料、セキュリティ診断、障害対応が別料金の場合、初期見積が安く見えることがあります。
工程ごとの準委任・請負・保守契約の使い分け
工程ごとに契約を選び、完成責任と保守の範囲を合意しておきます。
- 準委任：要件整理やPoCなど、調査しながら成果物を決める工程
- 請負：完成機能、納期、受入条件に合意した本開発
- 保守：API・カードブランド・ガイドライン改訂、脆弱性、監視、障害一次対応、再処理、月次の入金照合支援
保守契約に問い合わせ対応が含まれるかも確認します。
準委任では、発注者と開発会社が作業を共有しながら、仕様の不確定な部分を減らしていきます。一方で、PSP審査や外部仕様まで請負の完成責任として一方的に含めると、契約上の争点になることがあります。
契約書には、重大度ごとの受付時間、一次回答、復旧目標に加えて、再委託、ソースコードや設計書の引き渡し条件も記載します。
初期開発費の幅（100万円台から1億円超）
公開された全国統計が少ないため、ここに示す額は開発工数と要件範囲から整理した記事上の推定値です。正式な見積ではなく、RFP前の予算検討に使う目安です。
- 標準連携：PSPのCheckoutやAPIを使い、100万〜400万円、1〜3か月
- カスタム連携：複数決済、会計・在庫・会員連携などで400万〜800万円、3〜6か月
- 独自ゲートウェイ：PSP統合、精算、ルーティング、障害切り替えで500万〜2,000万円、6〜12か月
- 大規模基盤：加盟店管理、二重化、災害対策、監査、24時間運用で2,000万円〜1億円超、12〜24か月以上になる可能性
PSP料金、審査費、カード情報の扱い、基幹連携、性能試験、24時間運用の有無で金額は変わります。
金額と期間は、公開統計ではなく、要件・取引量・セキュリティ範囲から推定したものです。見積では、要件定義と設計、テストに加えて、次の工程が含まれているかも確認します。
- 連携：決済と会計・在庫・会員などとの接続
- 移行：本番切り替えを含む作業の範囲
- 監視：24時間運用の有無で変わる範囲
- 脆弱性診断：別料金になる場合がある範囲
初期費用と分けて見る決済手数料・月額・保守費
初期費用と継続費用を分けて、PSPの公開料金や個別条件を比べます。
- Stripe：成功取引1件あたり国内カード3.6%、コンビニ3.6%（最低120円）、PayPay3.98%（出典：Stripe「料金体系と手数料」）。
- GMOイプシロン：カードの月額費用、売上に応じた手数料率、入金日を公開（出典：GMOイプシロン「決済料金一覧」）。
- 総額の比較：初期連携費、月額基本料、決済・返金・振込手数料、早期入金、管理画面費
Stripeの標準料金では、3-Dセキュアは無料です。一方で、返金、チャージバック、継続課金、外貨換算、個別契約は別条件になるため、売上規模を伝えて正式見積を取ります。
月間取扱高に応じて3年分の支払総額を試算すると、方式ごとの差が見えやすくなります。
委託先の選定と見積比較で確認すべきポイント
委託先は、画面開発の実績だけでなく、状態管理、PSP接続、返金・照合、セキュリティ、24時間運用まで見ていきます。そのうえで、会社ごとの得意領域と発注範囲を照らし合わせます。
取引の種類と運用まで見る決済領域の実績
実績は、取引の規模や種類に加えて、異常時の対応、保守体制まで確かめます。
- 取引実績：決済手段、月間件数、ピーク時の処理量
- 対応領域：定期課金、売上分配、店舗POS、海外決済、会計・ERP連携
- 資料・体制：構成図、障害対応例、テスト項目、匿名化した保守担当体制
- デモ：Sandboxの異常系、Webhook冪等処理、返金、チャージバック、日次照合、監視アラート
単純なカード決済と各領域では、必要な知見が異なります。そこで、要確認取引の担当作業、ログ追跡、再処理の承認フローも見て、実運用への理解度を評価します。
機能・工数・前提条件を同じ単位でそろえた見積比較
工程、試験、別料金、見積の前提を突き合わせてから、総額を比べます。
- 工程・成果物：要件定義、設計、実装、外部連携、テスト、移行、リリース、保守
- 試験範囲：3-Dセキュア、返金・取消、入金照合、負荷、脆弱性、障害訓練
- 別料金・前提：PSP費用別、インフラ実費、診断・本番切り替えの別途費用、取引量、対象ブラウザ、サポート時間
- 委託・納品条件：再委託先、クラウド、納品物の範囲
見積条件がそろわないまま価格だけで比べると、契約後に追加費用が膨らむおそれがあります。
提案比較で責任の所在を確かめる5つの質問
提案では、次の5点を質問して、担当と処理方法を確かめます。
- カード情報：取扱場所とPCI DSS・脆弱性対策の範囲
- 注文登録失敗：決済成功後の再照会と返金方針
- Webhook：重複、遅延、署名不正への処理
- PSP障害：代替経路、手動処理、利用者への案内
- 入金差異：注文データとの差を解消する担当と期限
担当者が図や状態遷移で説明できれば、開発後の運用まで考えている可能性があります。反対に、「PSPが対応」「運用で確認」と述べるだけで、ログや判断者を示さない提案には注意が必要です。
価格が近い場合は、追加費用の透明性、引き継ぎのしやすさ、障害時の連絡経路、契約終了時のデータ返却を比べます。
よくある質問（FAQ）
発注時の疑問は、自社の取引量や運用体制を前提に検討します。回答はそのまま仕様にせず、RFPの条件へ置き換えます。
決済ゲートウェイシステムの開発費はいくらですか？
PSPのCheckoutやAPIを使う標準連携は100万〜400万円、会計・在庫・会員などと連携するカスタム連携は400万〜800万円が目安です。PSP統合や精算、ルーティングを含む独自ゲートウェイは500万〜2,000万円、大規模基盤は2,000万円〜1億円超です。
公開統計ではなく、要件、取引量、連携先、セキュリティ、24時間運用から算出した推定値です。決済手数料、月額、保守、クラウド費用は、別途見積もります。
PSPを使えば決済ゲートウェイの開発は不要ですか？
PSPの導入で不要になるのは、PSPが提供する決済処理の範囲です。注文・会員・在庫・会計との連携、返金、入金照合は残ります。PSPに任せた後も残る業務は、誰が担当し、どこまで自社で持つかで運用の負担が変わります。その違いが出やすい5つの業務を挙げます。
- Webhookの冪等処理：同じ通知が複数回届いたときの扱い
- 取引検索：状態や履歴を調べる機能
- 権限：手動で再処理できる人の範囲
- 監視：24時間365日で見るか、営業時間内の対応か
- 問い合わせ対応：保守契約に含まれるかを確認する範囲
複数PSPの共通化や売上分配、独自精算が必要なら、PSPを使いながら自社ゲートウェイを開発する構成になります。
決済システムの外注は請負契約にすべきですか？
企画やPoCは準委任、本番機能は受入条件を定めた請負、リリース後の監視や仕様変更は保守契約というように、工程ごとに使い分けます。
PSP審査や外部仕様など、開発会社だけでは制御できない条件については、納期・責任・追加費用の扱いを合意しておきます。成果物、検収条件、障害対応、知的財産、再委託の扱いも確認します。
カード情報を扱わなければセキュリティ対策は不要ですか？
カード情報を扱わない場合でも、対策は必要です。ホスト型画面やトークン決済を使っても、自社サイトの脆弱性、決済ページのスクリプト、管理画面の権限、Webhook認証、ログ、開発環境の秘密情報は管理します。
PCI DSSや国内ガイドラインの対象範囲は、構成によって変わります。そのため、PSPと開発会社に適用範囲と必要な証跡を確かめます。
まとめ：決済ゲートウェイシステムの発注を成功させる進め方
発注では、PSPの標準機能と自社で開発する範囲を分けて考えます。そのうえで、販売形態、取引量、決済手段を整理します。RFPの責任分界では、次の項目の担当を分けて書きます。
- ピーク性能：集中時の処理件数の要件と、性能試験の担当
- 返金・チャージバック：対応の範囲を、PSPと自社、開発会社のどこが持つか
- 照合：売上とPSPの入金データを突き合わせる担当
- 既存連携：会計・在庫・会員など既存システムとの接続範囲
- セキュリティ・監視：脆弱性対策と障害発生時の対応の担当
見積は開発費だけでなく、PSP手数料、月額、クラウド、監視、保守、法改正対応を含む総額で比べます。
事業の複雑さと運用体制で決める発注形態
単一サービスのカード決済や定期課金なら、ホスト型・Checkout連携で開発範囲を絞れます。一方で、複数の決済手段やPSP、店舗とECの統合、独自精算や売上分配が必要なら、API連携や自社ゲートウェイを検討します。
独自基盤を選ぶ場合は、障害監視、手動再処理、照合、法令・PSP仕様変更に対応する社内体制も整えます。
異常系・契約・運用まで含めた委託先への提案依頼
委託先を評価し、契約や費用を比べるときは、技術対応と工程ごとの責任を確かめます。
- 技術・運用：Webhook、冪等性、返金、入金照合、チャージバック、脆弱性対策、障害復旧
- 契約の段階：PoC・要件定義は準委任、仕様と受入条件が固まった開発は請負
- リリース後：SLAを含む保守へつなぐ体制
範囲をそろえて比べることが、予算超過や本番障害の防止につながります。
発注に迷ったら、自社の決済業務と責任分界を整理して、専門会社に相談します。
事業目的、対応決済、取引量、希望時期、既存システム、課題を共有すると、標準PSP、カスタム連携、独自ゲートウェイのどれが適切か検討できます。
▼全体ガイドの記事
・決済ゲートウェイシステム開発の完全ガイド
▼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を創業。