オンライン決済システムの開発では、手数料や入金サイクル、SLAが事業の利益と資金繰りに直結するため、要件定義とRFP（提案依頼書）の質が成否を分けます。RFPに盛り込む論点は、機能要件・非機能要件・契約条件・ベンダー選定の4つの軸で整理できます。
全体像は、オンライン決済システムの完全ガイドでご確認ください。
▼全体ガイドの記事
・オンライン決済システムの完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
RFPに盛り込む機能要件の固め方
RFPの出発点は、自社が決済システムに何をさせたいかを明確にし、機能要件を整理することです。ここが曖昧なままだと、ベンダーごとに前提の違う提案が返ってくるため、提案同士を比べにくく、見積もりもぶれてしまいます。
決済の機能要件は、対象とする業務によって変わります。ECか実店舗か、掛売りやサブスクがあるか、越境するかで、必要な機能は大きく違います。
まず自社の業態を明確にし、必要な決済手段と業務フローを書き下すことが第一歩です。
業態別の決済手段と業務フローの定義
機能要件の核は、自社の客層に合った決済手段をどこまで網羅するかを定めることです。SBペイメントの調査では「希望の支払手段がないと60%超が他店で購入する」とされており、決済手段の選定はそのまま売上機会に直結します。
業態ごとに必須の手段は異なります。たとえば、BtoCならクレカやQR決済、コンビニ決済、キャリア決済が候補になります。BtoBなら掛売り（請求書払い）、越境ECなら海外カードや現地の手段が候補です。
サブスクなら、継続課金と日割も必要になります。
RFPには、対応してほしい決済手段と対応時期を、優先度を付けて明記します。
あわせて、決済の前後の業務フローも要件にします。受注から入金消込までの一連の流れ（オーソリ、売上確定、取消・返金を含む）を図に起こし、どこを自動化したいかを示すことで、ベンダーは連携範囲を正確に見積もれます。
とくにサブスクでは、洗替やダニングといった固有のフローを明記しないと、都度課金を前提にした安い提案が返ってきます。
日割や解約処理も、あらかじめ書いておく必要があります。さらに、後から「継続課金は別料金」となりかねません。
一次データでも、継続課金機能は都度課金のみの場合より開発費が1.5〜2倍かかります。そのため、この前提を最初にそろえておくことが、見積もり比較の精度を高めます。
- 決済手段の優先度：対応時期を添えた、手段ごとの一覧
- 業務フローの範囲：受注から入金消込までの図と、自動化の対象
収益認識・会計連携の要件化
他社のRFP解説ではほとんど触れられていませんが、中堅・大手にとって極めて重要なのが、収益認識・会計連携の要件化です。
決済トランザクションを会計システムへAPI連携し、自動仕訳と入金消込を行う要件を最初に盛り込むことで、経理の手作業を減らせます。
サブスクでは、新収益認識基準に対応するため、前受金（繰延収益）をサービス提供期間に応じて日割で売上計上する処理が必要です。
新収益認識に沿った会計処理を決済システムとどう連動させるかを、RFPで問うべきです。
具体的には、決済手数料を売上から差し引く純額処理にするか総額処理にするか、振込手数料やトランザクション費用の仕訳をどう自動化するかといった、会計実務の要件を書き下します。
一次データでは、トランザクション費用は1回数円〜数十円、振込手数料は無料〜数百円、決済サービス利用料は決済金額の0.3〜1%とされています。また、これらが自動で正しく仕訳されないと、月次決算が滞ります。
会計連携を要件に入れることで、決済システムの投資対効果を「手数料削減」だけでなく「経理工数削減」でも測れるようになり、稟議も通しやすくなります。
- 仕訳の例示：手数料や振込手数料の仕訳を、ベンダーに実例で示させる
- 効果の測り方：手数料の削減に加え、経理工数の削減も指標に含める
非機能要件（セキュリティ・可用性）の定義
決済システムのRFPで、機能要件と同じくらい重要なのが非機能要件です。とくにセキュリティと可用性は、決済という事業の継続を支える要件です。
ここを甘く定義すると、コンプライアンス違反や障害時の売上停止という致命的なリスクを抱えます。そこで、非機能要件は数値で具体的に書くことが、ベンダー提案の比較を可能にします。
非保持化アーキテクチャとPCI DSSスコープ要件
セキュリティ要件の中心に据えるべきは、非保持化です。RFPに「PCI DSSの準拠範囲（監査スコープ）を最小化する構成を求める」と明記することで、ベンダーは非通過型・トークン決済のシステム構成を前提に提案します。
一次データでは、非保持化によって開発・セキュリティコストを50〜70%削減できるとされています。一方、カード情報を保持すると、QSA審査が年間数百万円規模になります。
ASVスキャンも数十万円かかり、大企業の改修では年間数千万円規模に膨らみます。
あわせて、EMV 3-Dセキュア2.xへの対応を必須要件として明記します。これは2025年3月末で原則義務化されたため、対応していない提案は検討の対象から外れます。
RFPでは、AIによる不正検知、3Dセキュアによる本人認証、異議申立（ディスピュート）時の証拠保全（アクセスログ・配送記録）といった機能を、どこまで実装するかを要件に含めます。
セキュリティ要件は「やればやるほどコストがかかる」領域だからこそ、自社のリスク許容度と取扱高に応じて、必須と任意を切り分けてRFPに書くことが重要です。
- 非保持化の前提：カード情報を自社で持たない構成を、提案の条件にする
- 必須と任意の区分：不正検知や本人認証などを、リスク許容度と取扱高で分ける
SLA（稼働率99.99%）と決済ルーティング要件
可用性要件の核は、SLA（サービス品質保証）の水準です。決済は止まると即座に売上も止まるため、業界水準の稼働率99.99%以上（月間4.3分以下のダウンタイム）をRFPの要件として明記します。
ベンダーには、稼働率99.99%を満たす構成と、未達時の補償（損害補償・サービスクレジット）を問います。
客単価680円×1日15人の離脱で月306,000円の損失という一次データの試算が示すように、決済停止の時間はそのまま機会損失になります。
取扱高が大きい事業者は、単一PSPの障害で全売上が止まるリスクを避けるため、複数の決済代行を束ねるマルチホーミングや、障害時の自動ルーティング（メイン障害時にサブへ自動切替）を要件に入れることも検討します。
これにより、1社のSLAに依存せず、システム全体としての可用性を高められます。RFPで「単一障害点を排除する冗長構成を求めるか」を明確にすることで、提案の方向性が変わります。
非機能要件は地味ですが、決済システムでは機能要件以上に事業継続を左右する論点です。
- 単一障害点：冗長構成を求めるかどうかを、RFPの段階で決めておく
- 自動ルーティングの要否：メインの障害時にサブへ切り替える仕組みの有無
契約条件・データポータビリティの要件化
RFPで機能と非機能を固めたら、次に詰めるべきなのが契約条件です。
決済は長期にわたって使い続けるシステムであるため、契約条件が後々の事業の自由度を左右します。入金サイクルや手数料、違約金に加え、データの持ち出し可否も、ここに含まれます。
これらを提案段階で明文化させることが、ロックインや隠れコストを防ぐことにつながります。
トークン移行（データポータビリティ）の契約明記
決済で最も見落とされやすい契約論点が、データポータビリティ、つまりトークンの移行可否です。
サブスクでは毎月課金するためにカードのトークンを保管しますが、このトークンが特定のPSPに固有だと、後で別の決済代行へ乗り換えるときに移行できません。その場合、全顧客にカードを再登録させる羽目になります。
移行できないままでは、事実上の乗り換え不能、すなわちベンダーロックインです。
トークン移行は、業界の標準的な仕組みとして可能な場合もあります。ただし、取り決めがないと、いざ乗り換えるときに「移行はできない」と言われるリスクがあります。
だからこそ、選定の段階で「将来別のPSPへ乗り換える可能性がある」前提に立ち、データポータビリティを契約要件にしておくことが、長期の交渉力を保つうえで欠かせません。
自社決済基盤をスクラッチで持つ場合は、トークンを自社で管理し、複数のPSPを抽象化する設計にすることで、この移行性を構造的に確保できます。
- 移行の条件：解約時の提供形式を、契約書の文言で担保する
- 自社管理の設計：スクラッチの場合のトークンの管理先と、PSPを抽象化する設計
条文に入れる例は、「解約時にトークンを移行可能な形で提供する」です。これが、移行拒否を防ぐ交渉ポイントになります。
チャージバック負担・手数料・隠れコストの条項
契約条件でもう一つ押さえたいのは、手数料体系を明確にしておくことです。
そのうえで、初期費用や月額、決済手数料率だけでなく、隠れコストもすべて洗い出させます。隠れコストには、取消手数料や振込手数料などがあります。さらに、違約金やトランザクション費用も対象になります。
一次データでは、取消処理が5円〜数十円、振込手数料が無料〜数百円、決済サービス利用料が0.3〜1%といった周辺手数料があります。これらの積み上げが、実質コストを押し上げます。
各社の料金例を見ると、初期費用や月額が無料で料率の高いプラン（Stripe 3.6%、Square オンライン3.6%）があります。一方で、月額固定で料率を抑えるプラン（stera pack 月3,000円・1.98%〜）もあります。
このほか、ゼウスは初期30,000円・月3,000円・〜3.5%・トランザクション30円です。自社の月商と決済比率によって、損益分岐点が変わります。
RFPでは、自社の想定取扱高を提示したうえで、トータルコストを試算させて比較することが大切です。料率の数字だけでなく隠れコストまで含めた実質コストで判断する姿勢が、後悔のない契約を結ぶ助けになります。
- 損失の負担：チャージバック時の負担者と、一定率を超えた場合の扱い
- 周辺手数料の試算：取消・振込・決済サービス利用料を、想定取扱高で比べる
一定の水準の例は、チャージバック率0.9%です。それを超えた場合のペナルティや決済停止の条件も、契約書で確認します。
ベンダー選定と提案評価の進め方
RFPを発行したら、最後は提案を評価してベンダーを選定します。決済は専門性が高く、ベンダーの実装力やセキュリティ知見によって品質が変わるため、価格だけでなく技術提案の中身を吟味することが欠かせません。
提案評価の軸を事前に定めておくことで、社内の合意形成もスムーズになります。
決済代行SaaSかスクラッチかの要件による見極め
選定の前提には、決済代行SaaSをそのまま使うのか、自社基盤をスクラッチで組むのかという方針があります。
決済代行SaaSは、初期無料〜数十万円、月額数千〜数万円で素早く始められる一方、料率や機能の自由度に制約があります。
スクラッチ開発は、シンプル（クレカのみ）で50〜200万円、中規模（複数手段・API・管理画面）で150〜400万円です。また、大規模（サブスク・多通貨/多言語・外部連携）で300〜500万円以上、フルスクラッチで500〜2,000万円超が相場です。
RFPで要件を固めると、SaaSで足りるのか、スクラッチが必要なのかが自ずと見えてきます。
マルチホーミング・収益認識連携・非保持化を高度に作り込みたい、トークンを自社で持って移行性を確保したいといった要件が強いほど、スクラッチや高度なカスタマイズが必要になります。
逆に、標準的なEC決済で十分なら、決済代行SaaSで素早く始めるのが合理的です。要件定義は、この「SaaSで足りるかスクラッチが要るか」を見極めるための作業でもあります。
- SaaSで足りる場合：標準的なEC決済で、料率や機能の制約を受け入れられるとき
- スクラッチの範囲：複数手段、サブスク、多通貨など、要件の広さで費用が変わる
人月単価・保守費用・実装体制の評価
保守費用は、月額で初期開発費の5〜10%（初期500万円なら月25〜50万円）が目安です。
決済はセキュリティ要件が高いため、安いエンジニア単価だけで判断すると、肝心のセキュリティ設計が手薄になるリスクがあります。
提案の体制に、決済やセキュリティの専門知見を持つメンバーが含まれているかを確認してください。
あわせて、リリース後の保守・運用体制も評価します。決済は法令改正（3Dセキュアの義務化など）やカードブランドの仕様変更に追随し続ける必要があり、作って終わりではありません。長期的に伴走できる体制があるか、SLA違反時の対応はどうかまで含めて評価することが、後悔のない選定につながります。
riplaは、フルスクラッチ受託と国内開発の立場から、決済の要件定義やRFP作成支援、非保持化・マルチホーミングを前提とした設計、長期保守までを一貫して支援しています。
- 人月単価：エンジニアと、セキュリティ/アーキテクトの単価を分けて確認する
- 保守体制：リリース後の運用と、SLA違反時の対応の範囲
一次データでは、60〜100万円と120〜200万円が人月単価の水準とされ、前者がエンジニア、後者がセキュリティ/アーキテクトに当たります。
まとめ
オンライン決済システムのRFP・要件定義書は、機能要件・非機能要件・契約条件・ベンダー選定の4層で整理すると、漏れを防げます。
とりわけ、業態別の決済手段と業務フロー、収益認識・会計連携、非保持化アーキテクチャとPCI DSSスコープの最小化は、押さえておきたい論点です。
SLA（稼働率99.99%）とチャージバック負担条項、そしてトークン移行（データポータビリティ）の契約明記は、後悔のない決済システムをつくるうえで欠かせません。これらを数値と契約条項で具体的に固めることが、ベンダー提案を正しく比較し、ロックインや隠れコストを防ぐことにつながります。
要件定義とRFPは、発注の手続きにとどまらず、決済という事業の継続を支える設計そのものです。自社の業態、取扱高、サブスクの有無を踏まえ、リスク許容度に照らして、機能から契約条件まで論点を漏れなく固めてください。
riplaは、フルスクラッチ受託と国内開発を組み合わせ、決済の要件整理やRFP作成から、非保持化・マルチホーミングを前提とした設計、長期保守までを一貫して支援しています。
全体像の確認には、あらためて完全ガイドをご活用ください。
▼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を創業。