電子決済システムを外部のベンダーに開発・導入してもらうとき、成否を分ける最大の要因が、RFP（提案依頼書）と要件定義の質です。決済は「お金を扱う」システムであり、セキュリティ・可用性・会計連携・乗り換え条件といった要件を曖昧にしたまま発注すると、リリース後にコストが膨らんだり、ベンダーに囲い込まれて身動きが取れなくなったりします。逆に、押さえるべき要件を最初から契約条件として明文化しておけば、複数ベンダーの提案を同じ土俵で比較でき、後の手戻りやトラブルを大幅に減らせます。
本記事は、電子決済システムのRFP・要件定義書・提案依頼書に盛り込むべき要件を、発注企業の視点から体系的に整理する「要件定義特化」の解説です。カード情報を持たない非保持化アーキテクチャの要件、収益認識や会計連携の要件、稼働率99.99%といったSLAやチャージバック負担の条項、トークン移行によるデータポータビリティの確保まで、競合の決済記事ではあまり踏み込まれない実務的な要件を具体的に解説します。なお、電子決済システム全体の費用相場や仕組みをまだ把握していない方は、まず電子決済システムの完全ガイドから読むことをおすすめします。要件定義の精度が、決済システム投資の成否を決めます。
▼全体ガイドの記事
・電子決済システムの完全ガイド
非保持化アーキテクチャの要件
決済システムのRFPでまず明記すべきが、カード情報をどう扱うかというセキュリティの根幹要件です。カード情報を自社サーバーに通過・保存させない「非保持化（トークン決済）」を要件に据えるかどうかで、開発コストとセキュリティ監査の負担が大きく変わります。ここを曖昧にしたまま発注すると、後から重いセキュリティ要件が追加され、費用が想定を超えます。
PCI DSS監査スコープ最小化を要件に明記する
PCI DSSはカード情報を扱う事業者に課されるセキュリティ基準で、対応には相応のコストがかかります。一次データでは、コンサルで数十万〜数百万円、QSAによる審査が年間数百万円規模、ASVスキャンで数十万円、大企業の改修になると年間数千万円に達するとされています。RFPには、カード情報を自社で保持しない非保持型・トークン決済のシステム構成を採用し、PCI DSSの準拠範囲を最小化することを明確な要件として記載すべきです。
非保持化によってPCI DSSの対象範囲を縮小すると、開発・セキュリティコストを50〜70%削減できるのが一次データの目安です。RFPで「どこまでのデータを自社で保持し、どこからをトークン化するか」をアーキテクチャ要件として提示すれば、ベンダーは監査スコープを意識した設計を提案します。逆にここを丸投げすると、ベンダーによって設計思想がばらつき、提案の比較が困難になります。セキュリティ要件は「PCI DSSに準拠すること」と書くだけでなく、「非保持化で監査範囲を最小化すること」まで踏み込んで定義するのが、コストを抑える鍵です。
EMV 3-Dセキュア2.x・不正検知を必須要件にする
セキュリティ要件のもう一つの柱が、本人認証と不正検知です。EMV 3-Dセキュア 2.x は2025年3月末でECサイトへの導入が原則義務化された必須要件であり、RFPに対応を明記しないと、リリース後に追加対応が必要になります。あわせて、リスクベース認証によって正常な取引のカゴ落ちを抑える要件や、AI不正検知でチャージバックを未然に防ぐ要件も盛り込むべきです。
不正対策の要件では、チャージバック率の管理も視野に入れます。チャージバック率が一定（例として0.9%超）を超えると、アクワイアラから違約金を科されたり決済停止に至ったりするため、不正検知の精度をどう担保するかを要件として問うことが重要です。セキュリティは「導入すれば終わり」ではなく、運用フェーズでどう監視・改善するかまで含めて要件化することで、事業継続のリスクを下げられます。
収益認識・会計連携の要件
決済システムの要件で、競合が最も見落としているのが収益認識と会計連携です。決済は「お金を受け取る」だけでなく「正しく会計に落とす」ところまで設計しないと、経理の負担が残り、決算時の処理ミスにつながります。とくにサブスク事業では、課金のタイミングと売上計上のタイミングが異なるため、ここを要件化しておくことが極めて重要です。
前受金・繰延収益と日割り売上計上の要件
新収益認識基準では、サービスを提供する前に受け取った代金を前受金（繰延収益）として管理し、サービス提供期間に応じて売上を計上する必要があります。年額一括で課金したサブスクなら、課金時に全額を売上にするのではなく、毎月分割して計上していくのが原則です。RFPには、決済システムが課金イベントと売上計上イベントを切り分けて記録し、日割りでの売上計上に対応できることを要件として明記すべきです。
この処理を手作業で行うと、契約数が増えるほどミスが増え、決算の精度が下がります。要件定義の段階で、月の途中での加入・解約・プラン変更時の日割り計算と、それに連動した売上計上のロジックを定義しておけば、ベンダーはこれを織り込んだ設計を行います。総額表示・純額表示の処理（手数料を含めて売上計上するか差し引くか）も、業態によって扱いが分かれるため、要件として確認しておきましょう。会計の要件を後回しにすると、経理が毎月手作業で帳尻を合わせる事態になります。
自動仕訳・入金消込のAPI連携要件
会計連携の核心は、決済トランザクションのAPIから自動的に仕訳を生成し、入金消込まで自動化することです。RFPには、利用予定の会計システムや販売管理システムと、どのAPIで、どのデータ項目を連携するかを具体的に要件として記載します。連携対象が曖昧だと、ベンダーは最小限の連携しか実装せず、結局は経理が手作業でデータを突き合わせることになります。
あわせて、ECカートや既存の販売・会計システムとの互換性も要件化が必要です。スクラッチ開発の場合、外部システムとのAPI連携の数や複雑さが開発費に直結します。一次データでは、複数手段・API・管理画面を備えた中規模のオンライン決済スクラッチ開発で150〜400万円、サブスクや多通貨・外部連携を含む大規模で300〜500万円以上、要件次第では1,000万円を超えるとされています。連携要件を最初に固めておけば、ベンダーは正確な見積もりを出せ、発注側も費用の妥当性を判断できます。会計連携は、決済システムの投資対効果を左右する重要要件です。
SLA・チャージバック負担条項の要件
決済システムは止まれば売上が止まるため、可用性に関するSLA（サービス品質保証）の要件化は欠かせません。あわせて、チャージバックが発生したときに誰がどう負担し対応するかを契約条項として定めておかないと、トラブル時に責任の所在が曖昧になります。これらは「契約要件」として明文化することに意味があります。
稼働率99.99%とマルチホーミングのSLA要件
決済システムの稼働率は、99.99%以上、つまり月間のダウンタイム4.3分以下が業界水準とされています。RFPには、求める稼働率の水準と、その水準を下回った場合の対応（補償・ペナルティ）を要件として記載します。あわせて、複数の決済事業者（PSP）をAPIで束ね、メイン障害時にサブへ自動的に切り替えるマルチホーミングの要件を盛り込めば、単一PSP依存による全停止リスクを下げられます。
SLA要件を定義するときは、稼働率の数字だけでなく、障害時の検知・通知・復旧の手順（インシデント対応フロー）も含めて問うべきです。決済が止まった瞬間に売上がゼロになることを考えれば、SBペイメントの調査が示す「希望の支払手段がないと60%超が他店で購入する」という機会損失の大きさは、SLAへの投資を正当化します。可用性は、決済システムにおいて費用対効果を測りにくい領域ですが、事業の生命線として要件化する価値があります。
チャージバック・ディスピュート対応の条項
チャージバック（不正利用などを理由としたカード会社からの返金請求）が発生したとき、その負担と対応をどう分担するかは、契約で明確にしておくべき重要項目です。ディスピュート（異議申立）では、アクセスログや配送記録といった証拠を提出して取引の正当性を主張しますが、その証拠をシステムがどう記録・提供するかを要件化しておかないと、いざというときに反論できません。
RFPには、チャージバックの発生時に必要な証拠データ（取引ログ、本人認証の記録、配送追跡情報など）を保全・出力できることを要件として記載します。あわせて、チャージバック率が一定の閾値を超えた場合のアクワイアラからの違約金や決済停止のリスクを、誰がどう管理するかも整理しておくべきです。決済代行を使う場合は、チャージバック対応の支援範囲を契約で確認します。これらの条項を最初に詰めておくことが、トラブル時の損失と責任の所在を明確にし、安心して事業を運営する基盤になります。
データポータビリティ（トークン移行）の要件
要件定義で見落とされがちで、しかし将来の自由度を大きく左右するのが、データポータビリティ、つまり別の決済システムへ乗り換えるときにデータを持ち出せるかという要件です。これを契約段階で確保しておかないと、いざ乗り換えたくてもカード情報を移せず、実質的にベンダーへ囲い込まれてしまいます。
トークン移行可否を契約交渉のポイントにする
カード情報を非保持化してトークンで管理する構成では、そのトークンを別の決済事業者へ移行できるかどうかが、乗り換えの自由を決めます。トークン移行が拒否されると、顧客に再度カード情報を入力してもらう必要が生じ、その手続きの過程で大量の顧客を失いかねません。RFPと契約には、解約・乗り換え時にトークンを含む顧客データを移行できることを、明確な要件・条項として盛り込むべきです。
トークン移行は、決済代行各社の方針によって可否が分かれます。だからこそ、契約締結前にこの点を交渉のテーブルに乗せることが、ベンダーロックインを回避する最大のポイントになります。「将来乗り換えるときにデータを持ち出せるか」を最初に確認しておけば、ベンダーとの力関係が対等に保たれ、サービス品質や料率の改善交渉もしやすくなります。データポータビリティの要件は、目先の機能ではなく、数年先の事業の自由度を守るための保険です。
隠れコスト・違約金をRFPで洗い出す
要件定義の最終段階で確認したいのが、契約後に発生する隠れコストです。決済では、初期費用や月額だけでなく、トランザクション費用（1回数円〜数十円、30円など）、振込手数料（無料〜数百円）、取消処理（5円〜数十円）、返金や決済失敗時の費用、決済サービス利用料（決済金額の0.3〜1%）といった周辺コストが積み上がります。RFPでこれらの費用項目をすべて開示させ、総コストで比較することが重要です。
あわせて、中途解約時の違約金や、オプション機能の追加課金の条件も要件として確認しておきます。提示された手数料率が安く見えても、トランザクション費用やオプション課金を含めた実質コストでは高くつくことがあります。riplaはフルスクラッチ受託と国内開発の立場から、こうした要件・契約条件をRFPの段階で明文化し、複数ベンダーを同じ土俵で比較できるよう支援しています。要件定義とは、機能を並べることではなく、コスト・セキュリティ・可用性・乗り換えの自由を契約条件として固める作業だと言えます。
まとめ
電子決済システムのRFP・要件定義で押さえるべきは、カード情報を持たない非保持化アーキテクチャでPCI DSSの監査スコープを最小化する要件、前受金管理と日割り売上計上を含む収益認識・会計連携の要件、稼働率99.99%のSLAとチャージバック負担を定める契約条項、そしてトークン移行を確保するデータポータビリティの要件という四つの軸です。これらはいずれも、機能一覧には現れにくいものの、決済システムの総コスト・安全性・将来の自由度を決める実務上の急所です。
要件定義で大切なのは、目先の機能の網羅ではなく、コスト・セキュリティ・可用性・乗り換えの自由を契約条件として最初に明文化することです。非保持化で開発コストを50〜70%削減し、トークン移行可否でロックインを回避し、隠れコストを総額で比較する。この一手間が、リリース後の手戻りとトラブルを防ぎます。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を創業。