決済システムの開発では、コードを書く作業より、RFP（提案依頼書）と要件定義の精度が成否を左右します。前提、専門要件、契約条項をそろえると、提案を同じ条件で比べられ、手戻りや追加費用も防ぎやすくなります。
決済には、セキュリティや会計、解約、乗り換えなど、表から見えにくい論点があります。発注者の視点から、RFPと要件定義書の実務的な書き方を見ていきます。
▼全体ガイドの記事
・決済システムの完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
決済システムのRFPで最初に固める前提
RFPでは、まず自社の決済がどの業態や事業フェーズにあるかを示します。業態によって必要な決済手段や手数料の傾向が異なるため、前提が曖昧だと、ベンダーは必要な構成を判断できません。
たとえば、BtoCのECと実店舗、BtoBの掛売りとでは、決済の前提がそれぞれ異なります。こうした違いも、ベンダーに伝えておく前提になります。
調査では、決済手数料率はECで3.0〜3.2%、サブスクで3.3〜3.4%とされています。一方、実店舗では3%未満の低い料率も計34.1%あります。越境ECでは3.3〜3.4%が最も多く、高コストという調査結果です。
業態・決済手段・取扱高の明記
見積もりの条件をそろえるため、RFPには事業と取引の規模を記載しておきます。
- 事業条件：業態、対応する決済手段、想定月商、決済件数、決済比率。
- 連携先：既存システムとの連携方向と、対象データ。
決済手段には、クレカやQRのほか、コンビニ払いや掛売りなどがあります。こうした手段ごとの数字がそろって初めて、ベンダーは適切なアーキテクチャと見積もりを示せます。
取扱高は、決済代行SaaSで足りるか、スクラッチで自社基盤を持つかを分ける重要な判断材料です。オンライン決済のスクラッチ開発費は、方式と規模で異なります。クレカのみのシンプルな構成なら50〜200万円、複数の決済手段やAPI、管理画面を含む中規模なら150〜400万円が目安です。
サブスクや多通貨を含む大規模では300〜500万円以上で、フルスクラッチでは500〜2,000万円超が目安です。
ECカート、販売管理、会計などとの連携も、前提に含めます。連携の工数を正しく見積もるには、対象と方向、扱うデータを示す必要があります。
前提が具体的であれば、各社の見積もりを同じ条件で比べられます。逆に前提が曖昧だと、安く見える見積もりに、必要な機能が入っていないことがあります。
費用の内訳と保守体制の要求事項
初期費用だけでなく、運用中に発生する費用と体制の提示も求めます。
- 保守・人員：月額費用と、担当者・フェーズごとの工数を明示してもらう。
- ランニングコスト：初期・月額・従量の費用一覧。
保守費用は、月額で初期開発費の5〜10%が目安です。たとえば初期開発費が500万円なら、月25〜50万円程度になります。
人月単価の相場は、エンジニアで60〜100万円、セキュリティ／アーキテクトで120〜200万円です。工数の内訳は、誰がどの段階に何人月かかわるかで確認します。
ランニングコストには、決済手数料やトランザクション費用のほか、振込手数料や取消手数料もあります。トランザクション費用は1回数円〜数十円で、30円などの例があります。
振込手数料は無料〜数百円、取消処理は5円〜数十円です。決済サービスの利用料は、決済金額の0.3〜1%です。
こうした費用が積み上がるため、総額は初期費用だけでは測れません。提示を受けるときは費用の全体を見比べられる形にしてもらうと、想定外の負担を避けやすくなります。
非保持化と会計連携の要件定義
要件定義では、専門性が問われる非保持化の構成と、収益認識・会計連携を詰めておきます。この二つは、ベンダーの提案を比べる際の差別化ポイントです。
これらをRFPで明確に求められるかどうかは、発注者のリテラシーの表れといっても過言ではありません。要件の具体性が、提案の中身を左右します。
非保持化とPCI DSSスコープ最小化の要件
カード情報を自社で持たない、非保持型（トークン決済）の構成を明確に求めます。
- 準拠範囲：PCI DSSのスコープを最小化する方式。
- 診断と認証：ASVスキャンの頻度と費用負担、EMV 3-Dセキュア 2.xへの対応を示してもらう。
PCI DSSは国際的なセキュリティ基準です。非保持化で準拠範囲（スコープ）を最小化すると、開発やセキュリティのコストを50〜70%削減できるという一次データもあります。
PCI DSS対応にかかる費用は、コンサルで数十万〜数百万円、QSA審査で年間数百万円規模です。大企業の改修では、年間数千万円規模に達します。
スコープの設計しだいで、トータルコストは大きく変わります。なお、EMV 3-Dセキュア 2.xは、2025年3月末で原則義務化されています。
ベンダーには、要求への回答とスコープ最小化の具体策を提案してもらいます。「PCI DSS対応します」の一文では済ませず、回答の中身を比べます。
収益認識と会計連携の要件
サブスク事業では、サービス提供期間に応じた日割りの売上計上が論点になります。そのため、決済と会計をどう連動させるかを、RFPで明確にします。
- 収益認識：新収益認識基準と前受金（繰延収益）の管理。
- 会計処理：API連携による自動仕訳と入金消込、総額／純額表示の方針。
多くの競合システムが手薄にしているのが、この収益認識と会計連携です。会計連携を詰めると、決済が1件ごとに自動で仕訳され、入金と売上の突き合わせ（消込）も自動化されます。その結果、経理の手作業が構造的に減ります。
要件に含めずに開発すると、決済はできても会計処理が手作業のまま残りがちです。「払う要件」と会計計上の要件を一体で設計できるかが、投資効果を左右します。
SLA・チャージバック負担などの契約条項
決済システムが止まれば、売上も止まります。そのため、RFPには可用性のSLA（サービス品質保証）と、チャージバックなどのリスク負担を契約条項として明記します。
機能要件だけを詰めると、非機能要件や契約面が抜け落ちることがあります。その場合、トラブル時に責任の所在が曖昧になります。
稼働率99.99%とサポート体制のSLA定義
売上機会を守るには、稼働率の数字だけでなく、障害時の対応と設計も決めておく必要があります。
- サービス水準：稼働率、復旧目標時間、受付時間、障害時の連絡フロー。
- 冗長化：複数の決済代行を切り替える構成の採否。
決済まわりの業界水準は、稼働率99.99%以上（月間4.3分以下のダウンタイム）とされています。この目標値を、契約条項として求めます。
サポート受付は、24時間365日か平日日中かを指定します。また、希望の支払手段がないと、60%超が他店で購入するという試算もあります。
客単価680円で1日15人が離脱すると、月306,000円の損失になるという試算も示されています。ダウンタイムを抑える保証は、売上の保護に直結します。
マルチホーミング（決済ルーティング）は、複数の決済代行を束ねて、障害時に自動で切り替える方法です。採用するかどうかは、要件として議論する価値があります。
単一の決済代行に頼ると、その障害がそのまま自社の売上停止につながります。そのため、SLAでは数値の約束に加えて、それを実現するアーキテクチャも要件に含めます。
チャージバック負担と不正対策の責任分界
チャージバックの責任分担が曖昧にならないよう、不正対策と発生時の対応を契約で定めます。
- 対策と負担：不正検知・3Dセキュアの範囲と損失負担者。
- 証拠と監視：証拠保全、率の監視、閾値前のアラート。
チャージバックは、不正利用によるカード会社からの返金請求です。率が一定の水準（例：0.9%超）を超えると、アクワイアラから違約金や決済停止のペナルティを受けるおそれがあります。そこで、率の監視方法や、閾値を超えそうなときのアラートも設計します。
異議申し立て（ディスピュート）には、アクセスログや配送記録などの証拠が必要です。そのため、保全の方法と対応フローを契約条項に明文化します。
責任の分け方が曖昧だと、対策を誰が担うかで揉めがちで、最悪の場合は決済停止に至ります。有事の手順と責任を契約に落とし込むことは、事業継続の備えになります。要件定義では、平時の機能だけでなく、有事の責任分担も含めます。
データポータビリティとロックイン回避の要件
RFPで見落とされやすいのが、将来、決済代行やシステムを乗り換えられるかどうかというデータポータビリティです。この点は、要件定義の段階で契約交渉の論点として織り込んでおくべきものです。
導入時には便利でも、乗り換えの際にカードのトークンを移せないことがあります。その場合、顧客にカードの再登録を求めることになり、ベンダーロックインにつながります。
トークン移行可否の契約要件
非保持化でカードをトークン化する場合、移行できるかどうかが乗り換えの自由度を左右します。
- 移行条件：トークン移行の可否と、手数料や条件。
- 終了条件：データ返還やエクスポート形式、違約金、最低契約期間。
移行を拒否されると、乗り換えの際に既存の顧客全員へカードの再登録を求める必要が生じます。その過程で、多くの顧客を失うおそれもあります。
この状態は、実質的なロックインといえます。そのため、RFPでは、トークン移行に応じるかどうか、移行時の手数料や条件は何かを、契約要件として確認します。
出口の条件を契約時に固めておくと、将来の選択肢を守れます。たとえばフルスクラッチなら、データの所有権を自社で握れます。
そのため、フルスクラッチで決済基盤を持つ場合は、ロックインの懸念を構造的に下げられます。riplaは、フルスクラッチ受託と国内開発の立場から、非保持化・会計連携・トークン移行までを見据えた要件定義を支援しています。
隠れコストの洗い出し
要件定義の最終段階では、契約後に表面化しやすい隠れコストを先回りして洗い出します。
- 費用項目：初期・月額・従量・隠れコストのすべて。
- 比較方法：自社の取扱高で総額を試算し、方式どうしを比べる。
返金や決済失敗時の手数料、オプション機能の追加課金のほか、最低利用料や解約時の違約金も、運用後に表面化しがちです。
こうした費用は初期見積もりに含まれていないことが多く、運用開始後に影響します。そこで、RFPで開示を求め、シナリオごとの内訳を比べます。
決済代行SaaSの導入費用は、400名規模のアンケートで「5万〜10万円未満」が18.8%で最多でした。また、「0円」も14.8%存在します。
月額は「5,000〜9,999円」が18.5%で最多です。ただし、月額が安く見えても、従量手数料や隠れコストを加えると、取扱高によってはスクラッチのほうが有利になることがあります。
ベンダーを選ぶ前に、この試算を済ませておきます。その数字が、判断材料になります。
まとめ
まず業態・決済手段・取扱高・費用内訳を固め、次に非保持化と収益認識・会計連携を詰めます。
さらに、SLA（稼働率99.99%）とチャージバック負担を明文化します。最後に、トークン移行や隠れコストなど出口の条件を洗い出します。
要件をそろえておくと、見積もりを比べやすくなり、開発後の手戻りや追加費用も防ぎやすくなります。
「払う機能」だけでなく、セキュリティや会計、可用性、乗り換えも要件に含めます。本文の項目を自社の業態や取扱高に照らして、比べやすい提案をベンダーに求めます。
riplaは、フルスクラッチ受託と国内開発を組み合わせ、非保持化・会計連携・SLA・データポータビリティまでを見据えた要件定義を一貫して支援しています。費用感や全体像の確認には、完全ガイドをご覧ください。
▼全体ガイドの記事
・決済システムの完全ガイド
▼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を創業。