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