決済ゲートウェイシステム開発の発注/外注/依頼/委託方法について

決済ゲートウェイシステムの発注・外注では、PSPの標準機能で済む範囲と自社で開発する範囲を切り分け、決済成功後の注文反映、返金、入金照合、障害復旧までを要件に含めることが重要です。

決済ゲートウェイシステムをこれから発注する企業に向けて、発注形態の選び方、RFPに入れるべき項目、要件整理の進め方、契約形態、費用相場、委託先の選定方法、見積比較のポイントを解説します。決済代行会社のサービスを導入するだけの案件と、複数のPSPを束ねる自社ゲートウェイを開発する案件では、必要な体制も予算も大きく異なるため、最初に発注範囲を明確にしていきます。

▼全体ガイドの記事
・決済ゲートウェイシステム開発の完全ガイド

決済ゲートウェイシステムを発注する前に知るべき全体像

発注前に最も重要なのは、決済画面の見た目ではなく、どの決済手段を、どの販売チャネルで、どの業務システムへ連携するかを決めることです。決済ゲートウェイは、ECサイトやアプリ、店舗POSとPSP、カード会社、銀行、コード決済事業者などをつなぎ、認証・与信・売上確定・取消・返金・入金照合を処理する中継基盤です。

PSPのCheckoutやホスト型決済画面を利用する場合は、決済処理、カード情報のトークン化、本人認証などを外部サービスへ任せ、自社では注文画面や業務連携を開発します。単一のサービスでカード決済や定期課金を始める企業には、短期間で導入しやすい方式です。一方、複数PSPの切り替え、決済手段ごとのルーティング、加盟店ごとの手数料計算、複雑な分配・精算を自社で統合する場合は、独自ゲートウェイの開発案件になります。

決済が成功した後に注文登録が失敗した場合、PSPからのWebhookが遅れて届いた場合、利用者が二重にボタンを押した場合に、誰が取引状態を確認し、どのシステムが再処理するかを決めます。決済ID、注文ID、顧客ID、返金IDの対応関係、冪等性キー、リトライ回数、手動再処理の権限まで定義しないと、正常系のデモは動いても本番運用で二重決済や返金漏れが起きます。

発注形態はパッケージ・クラウド・スクラッチをどう選びますか？

発注形態は、対応する決済手段の数だけでなく、独自業務の大きさ、取引量、可用性、社内の運用体制で選びます。標準機能で足りるのにフルスクラッチを選ぶと、開発費だけでなく、法令改訂やPSPの仕様変更への対応費も膨らみます。反対に、マーケットプレイスの売上分配や複数PSPの障害切り替えが必要なのに標準画面だけで済ませると、後から大規模な作り直しが発生します。

ホスト型決済画面やCheckoutを使う方式では、カード番号を自社環境で入力・保存する範囲を小さくできます。画面、API、Webhook、注文システムとの連携に発注範囲を絞りやすく、カード決済や継続課金を短期間で開始したいEC、SaaS、予約サービスに適しています。ただし、カード情報をPSPへ任せても、注文状態、返金、チャージバック、管理者権限、ログ、問い合わせ対応まで自動で完了するわけではありません。

自社の購入画面やアプリを維持しながら、複数のPSPを共通APIの裏側へ接続する方式です。決済手段ごとの仕様差を吸収し、決済成功率、手数料、障害状況、地域、商品特性に応じて接続先を選べる点が強みです。複数ブランドを扱うマーケットプレイス、サブスクリプション、店舗とECを統合する事業では有力ですが、各PSPの状態コード、Webhook、返金期限、売上確定の仕様を正規化する設計が必要です。

独自ゲートウェイを発注するのは、単に決済手段を増やしたい企業ではなく、決済を事業の競争力や基幹業務の中心に置く企業です。加盟店ごとの精算、売上分配、複数通貨、決済ルーティング、24時間監視、PSP障害時の切り替え、監査証跡などが必要になると、標準機能だけでは要件を満たしにくくなります。発注時はアプリ開発会社だけでなく、決済業務とインフラ運用を理解するSI会社を含めて比較します。

決済ゲートウェイシステムの発注・外注はどの順番で進めますか？

発注は、いきなり開発会社へ機能一覧を渡すのではなく、事業要件、責任分界、異常系、運用条件の順に整理します。発注者が決めることと、PSPや開発会社の専門知識を借りることを分けると、提案の比較がしやすくなります。次の順番で進めると、見積後の大幅な追加開発を抑えやすくなります。

最初に、EC、アプリ、店舗POS、マーケットプレイス、予約、請求・継続課金のどれに使うかを決めます。次に、月間取引件数、ピーク時の1分あたり件数、平均単価、最大単価、同時アクセス数、返金率、チャージバックの想定、海外利用の有無を整理します。たとえば月間1万件でも、セール開始の5分間に処理が集中するサービスと、1日中均等に処理するサービスでは必要な性能が異なります。

決済手段は、クレジットカードだけでなく、デビットカード、コンビニ、銀行振込、キャリア決済、コード決済、Apple PayやGoogle Pay、口座振替まで候補を並べます。決済手段を増やすほど購入者の選択肢は広がりますが、審査、売上確定、返金、入金サイクル、手数料、問い合わせ窓口が増えます。初期リリースではカードと主要な一つの決済手段に絞り、利用実績を見て拡張する計画も有効です。

RFPには、カード番号などの決済情報をどこで扱うか、PSPとの契約主体は誰か、審査申請を誰が担当するか、決済画面の脆弱性を誰が管理するかを記載します。「セキュリティはPSPが対応する」という表現だけでは不十分です。自社サイトの脆弱性、埋め込みスクリプト、Webhookの署名検証、管理画面の権限、ログのマスキングなどは、自社と開発会社の責任として残る場合があります。

2025年3月に改訂された経済産業省の「クレジットカード・セキュリティガイドライン」6.0版では、EC加盟店に脆弱性対策、EMV 3-Dセキュア、不正ログイン対策などが求められています（出典：経済産業省「クレジットカード・セキュリティガイドライン改訂」）。発注時には、対象となる対策と証跡を要件書へ落とし込みます。

PSPの仕様、決済手段の審査、既存の注文・会計システムとの連携に不確定要素がある場合は、最初から本開発を請負契約にせず、要件整理やPoCを小さく発注します。PoCでは、決済受付、Webhook受信、注文反映、取消、全額返金、部分返金、失敗時の再照会までを実際のSandboxで確認します。成果物は画面だけでなく、状態遷移図、API仕様、例外シナリオ、性能測定結果にします。

本開発の受入条件には、正常系の成功率だけでなく、タイムアウト、通信断、Webhookの重複・順序逆転、3-Dセキュアのチャレンジ、カード期限切れ、限度額超過、返金失敗、PSP障害、入金データとの不一致を入れます。受入テストを発注者・PSP・開発会社の三者で確認すれば、障害の原因を相手に押し付ける状況を減らせます。

RFPと要件整理で決済ゲートウェイの発注条件をそろえます

RFPは、開発会社に機能を丸投げするための資料ではなく、各社が同じ前提で提案・見積を作るための比較基準です。完成した仕様書でなくても、事業目的、対象範囲、既存システム、希望時期、決済手段、取引量、セキュリティ方針、運用体制を整理すれば、初回提案の質が上がります。

事業要件には、売上拡大、購入完了率の改善、決済手段の拡張、海外販売、請求業務の効率化などの目的を書きます。機能要件には、決済受付、与信、売上確定、取消、全額・部分返金、継続課金、カード情報の更新、再試行、チャージバック、入金照合、取引検索、管理者権限、監査ログを整理します。

各機能は「必要」「初期リリースでは任意」「将来対応」に分けます。たとえば初期は国内カードと月次一括の入金照合を必須とし、複数通貨や自動ルーティングは第二段階にする方法です。優先順位をつけずに「すべて対応」と書くと、会社ごとに含める機能が変わり、安い見積ほど重要な例外処理を含まない結果になりやすいです。

決済システムの品質は、成功画面が表示されるかだけでは評価できません。決済APIがタイムアウトしたとき、PSPでは成功しているが自社が応答を受け取れていないとき、Webhookが同じ取引について3回届いたとき、注文は失敗したのに売上だけ確定したときの処理を決めます。「再送する」だけでは、二重決済を防ぐ条件が不足します。

RFPには、取引状態を受付、処理中、成功、失敗、要確認、取消、返金受付、返金完了などに分けた状態遷移を添付します。要確認になった取引を自動再照会するのか、担当者が管理画面から確認するのか、利用者へどの表示を出すのかも決めます。売上データとPSPの入金データを日次で突合し、差異が出た場合の通知と解消期限まで記載すると、運用費の見積も比較しやすくなります。

非機能要件は「安全に」「止まらないように」ではなく、可用性、応答時間、ピーク処理件数、復旧時間、バックアップ頻度、ログ保存期間、監視時間帯で表します。24時間365日の監視が必要なのか、営業時間内の対応でよいのか、障害発生から何分以内に一次連絡が必要なのかで、インフラ構成と保守費は変わります。

PCI DSS v4.0.1では、EC加盟店が決済ページのスクリプトを適切に管理し、改ざんや不正なスクリプトによる情報窃取のリスクを確認する考え方が重視されています。PCI Security Standards Councilは、埋め込み決済ページを使う場合でも、決済に影響するスクリプトへの対策を確認する必要があると説明しています（出典：PCI Security Standards Council「e-commerce scripts FAQ」）。RFPには脆弱性診断、WAF、秘密情報管理、ログのマスキング、権限分離、監視、インシデント報告の範囲を記載します。

契約形態と決済ゲートウェイシステムの費用相場

決済ゲートウェイの費用は、開発会社へ支払う初期開発費、PSPの決済手数料・月額費用、クラウドや監視の運用費、保守・法改正対応費に分けて考えます。初期見積だけを比べると、決済手数料や返金手数料、セキュリティ診断、障害対応が別料金の会社を安く見誤るため、3年程度の総保有コストで比較します。

要件整理やPoCのように、調査しながら成果物を決める工程は準委任契約と相性がよいです。発注者と開発会社が時間や作業内容を共有し、仕様の不確定要素を減らしていきます。完成させる機能、納期、受入条件を合意できた本開発は請負契約を検討できますが、PSPの審査や外部仕様に左右される部分まで一方的に完成責任を負わせると、契約上の争点になりやすいです。

保守契約では、問い合わせ対応だけでなく、PSPのAPI変更、カードブランドやガイドラインの改訂、脆弱性対応、監視、障害一次対応、再処理、月次の入金照合支援を含むか確認します。障害の重大度ごとの受付時間、一次回答、復旧目標、再委託の有無、ソースコードや設計書の引き渡し条件も契約書へ記載します。

決済ゲートウェイ単独の公的な全国統計は少ないため、次の金額は、決済連携・業務システム開発の工数と要件範囲から整理した記事上の推定値です。正式な見積ではなく、RFPを作る前の予算検討に使います。PSPの利用料金、審査費、カード情報の扱い、既存基幹との連携、性能試験、24時間運用の有無で金額は大きく変わります。

PSPのCheckoutやAPIを使った標準的な連携は、初期開発費100万〜400万円、期間1〜3か月が目安です。複数の決済手段、会計・在庫・会員システム連携、独自の継続課金や管理画面を含むカスタム連携は、400万〜800万円、3〜6か月程度を見込みます。複数PSPの統合、精算、ルーティング、障害切り替えを含む独自ゲートウェイは500万〜2,000万円、6〜12か月程度が一つの検討レンジです。

大規模な決済インフラとして、複数事業者向けの加盟店管理、二重化、災害対策、監査対応、24時間運用まで構築する場合は、2,000万円〜1億円超、期間12〜24か月以上になる可能性があります。これらは公開統計ではなく、要件・取引量・セキュリティ範囲からの推定です。見積書では、要件定義、基本設計、連携開発、テスト、移行、監視、脆弱性診断の各費用が分かれているか確認します。

たとえばStripeの日本向け料金ページでは、標準料金として国内カードの成功取引1件あたり3.6%、コンビニ決済3.6%で最低120円、PayPay3.98%が掲載されています。また標準料金では3-Dセキュアが無料とされています（出典：Stripe「料金体系と手数料」）。ただし、返金、チャージバック、継続課金、外貨換算、個別契約の料金は別条件になるため、売上規模を伝えて正式な見積を取得します。

GMOイプシロンの料金ページでは、クレジットカードの月額費用や売上に応じた手数料率、入金日が公開されています（出典：GMOイプシロン「決済料金一覧」）。このような公開料金を比較する場合も、初期の連携開発費、月額基本料、決済手数料、返金・振込手数料、早期入金、管理画面の追加費用を同じ表に並べます。開発費だけでなく、月間取扱高に応じた3年分の支払総額を試算すると、方式の差が見えやすくなります。

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

委託先は、決済画面を作った経験だけでなく、決済の状態管理、PSPとの接続、返金・照合、セキュリティ、24時間運用まで確認します。決済事業者、SI会社、アプリ開発会社では得意領域が異なるため、自社の発注範囲に合う体制を選ぶ必要があります。

「決済実績あり」という一言ではなく、どの決済手段を、月間何件、どの程度のピークで処理したのかを聞きます。カードだけの単純なEC連携と、定期課金、マーケットプレイスの売上分配、店舗POS、海外決済、会計・ERP連携では必要な知見が異なります。可能であれば、実績案件の構成図、障害対応例、テスト項目、保守開始後の担当体制を匿名化した資料で確認します。

候補会社には、PSPのSandboxで再現した異常系、Webhookの冪等処理、返金やチャージバックの管理、日次入金照合、監視アラートのデモを依頼します。画面の操作デモだけでなく、取引が要確認になったときの担当者の作業、ログの追跡、再処理の承認フローまで見れば、実運用への理解度を評価できます。

見積比較では、総額の順位を先に決めません。要件定義、設計、実装、外部連携、テスト、移行、リリース、保守の工程ごとに、工数と成果物を並べます。特に、3-Dセキュアの状態別試験、返金・取消、入金照合、負荷試験、脆弱性診断、障害訓練が含まれているかを確認します。

「PSP費用は別」「インフラ費用は実費」「セキュリティ診断はオプション」「本番切り替えは別途」といった前提は、見積書の下部ではなく項目ごとに明記してもらいます。開発会社が想定する取引量、対象ブラウザ、サポート時間、再委託先、利用するクラウド、納品物の範囲も質問します。条件が違う見積を価格だけで比較すると、契約後の追加費用が膨らみます。

第一に、カード情報をどこで扱い、PCI DSSや脆弱性対策の対象範囲をどう整理するかを聞きます。第二に、決済成功後に注文登録が失敗した場合の再照会と返金方針を聞きます。第三に、Webhookの重複、遅延、署名不正をどう処理するかを確認します。第四に、PSP障害時の代替経路、手動処理、利用者への案内を確認します。第五に、入金データと注文データの差異を誰が、いつまでに解消するかを聞きます。

この質問に対して、担当者が図や状態遷移で説明できる会社は、開発後の運用まで考えている可能性が高いです。反対に「PSPが対応します」「運用で確認します」だけで、どのログを見て誰が判断するかが示されない提案は注意が必要です。価格が近い場合は、追加費用の透明性、引き継ぎやすさ、障害時の連絡経路、契約終了時のデータ返却を比較します。

よくある質問（FAQ）

決済ゲートウェイシステムの発注でよくある疑問について、判断の軸を簡潔に回答します。自社の取引量や運用体制によって最適解は変わるため、回答をそのまま仕様にせず、RFPの前提条件へ置き換えて検討します。

PSPの標準CheckoutやAPI連携なら100万〜400万円、複数PSPの統合や独自精算を含むと400万〜2,000万円、大規模な決済基盤では2,000万円〜1億円超が目安です。これらは公開統計ではなく、要件、取引量、連携先、セキュリティ、24時間運用の範囲から算出した推定値です。決済手数料、月額、保守、クラウド費用は別に見積もります。

不要になるのは、PSPが提供する決済処理の範囲だけです。自社の注文・会員・在庫・会計との連携、Webhookの冪等処理、返金、取引検索、入金照合、権限、監視、問い合わせ対応は残ります。複数PSPを共通化する場合や、売上分配・独自の精算がある場合は、PSPを使いながら自社ゲートウェイを開発する構成になります。

要件が固まっていない企画・PoCは準委任、本番機能の開発は受入条件を定めた請負、リリース後の監視や仕様変更は保守契約というように、工程で使い分けます。PSP審査や外部サービスの仕様変更など、開発会社だけでは制御できない条件は、納期・責任・追加費用の扱いを契約書で合意します。契約形式だけでなく、成果物、検収条件、障害時の対応、知的財産、再委託を確認することが重要です。

不要ではありません。ホスト型決済画面やトークン決済でカード番号が自社環境を通らない範囲を広げても、自社サイトの脆弱性、決済ページのスクリプト、管理画面の権限、Webhookの認証、ログ、開発環境の秘密情報は管理が必要です。PCI DSSや国内ガイドラインの対象範囲は構成によって変わるため、PSPと開発会社に適用範囲と必要な証跡を確認します。

まとめ：決済ゲートウェイシステムの発注を成功させる進め方

決済ゲートウェイシステムを発注するときは、まずPSPの標準機能で足りる範囲と、自社で開発する範囲を分けます。次に、販売形態、取引量、ピーク性能、決済手段、返金、チャージバック、入金照合、既存システム連携、セキュリティ、監視を整理し、責任分界をRFPに明記します。見積は開発費だけでなく、PSPの手数料、月額、クラウド、監視、保守、法改正対応を含む総額で比較します。

単一サービスのカード決済や定期課金なら、ホスト型・Checkout連携を使って開発範囲を絞る方法が現実的です。複数の決済手段、複数PSP、店舗とECの統合、独自の精算や売上分配が必要なら、API連携や自社ゲートウェイを検討します。独自基盤を選ぶ場合は、開発会社に任せて終わりではなく、障害監視、手動再処理、照合、法令・PSP仕様変更への対応を担う社内体制も同時に整えます。

委託先を選ぶときは、決済画面の実績だけで判断せず、Webhook、冪等性、返金、入金照合、チャージバック、脆弱性対策、障害復旧を確認します。PoCや要件定義を準委任で行い、仕様と受入条件が固まった部分を請負で開発し、リリース後はSLAを含む保守へつなぐ進め方も有効です。安い見積を選ぶのではなく、含まれる範囲と含まれない範囲を揃えて比較することが、予算超過と本番障害を防ぎます。

決済ゲートウェイシステムの発注で迷ったら、まず自社の決済業務と責任分界を整理し、専門会社へ相談してください。事業目的、対応決済、取引量、希望時期、既存システム、困っている業務を共有するだけでも、標準PSPで足りるのか、カスタム連携が必要なのか、独自ゲートウェイを検討すべきなのかを具体化できます。

▼全体ガイドの記事
・決済ゲートウェイシステム開発の完全ガイド

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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