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