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