Web決済導入の費用相場｜選び方と外注手順

Web決済の導入費用は、既存サービスへの単発決済追加で30万〜100万円程度、注文・管理機能を含む新規開発で100万〜300万円程度が一般的な目安です。定期課金や売上分配があると高額になります。発注前に課金ルール、返金、審査、入金照合まで決めることが重要です。

※本記事の費用と期間は一般的な目安です。利用する決済代行会社、決済手段、既存システムの状態、セキュリティ要件、画面数などによって変わります。

• Web決済導入の費用相場と期間
  • 開発範囲別の費用相場
  • 決済代行会社へ支払う費用
  • 費用を左右する主な要因
• Webサービスに合う決済方式の選び方
  • 課金モデルを先に決める
  • 決済の実装方式を選ぶ
  • 決済代行会社の比較項目
• 決済開発を依頼する前の準備
  • 最低限決めておく事業ルール
  • 例外処理を一覧にする
  • セキュリティ・法務・運用の確認
• 外注の進め方と見積もり・会社選び
  • 外注から公開までの6ステップ
  • 見積書で確認する項目
  • 開発会社を見極める質問
  • よくある失敗と回避策
• まとめ
• よくある質問
  • Web決済は最初から複数の決済手段を用意すべきですか？
  • 決済代行会社の審査にはどのくらいかかりますか？
  • 開発会社にカード情報を保存してもらう必要はありますか？
  • 既存のWebサービスにも決済機能を追加できますか？

Web決済導入の費用相場と期間

Web決済の予算を考えるときは、決済代行会社に支払う利用料と、開発会社に支払う開発費を分けて整理します。月額料金や決済手数料だけを見ていると、注文管理、返金、入金照合などの開発費が予算から漏れやすいためです。

開発範囲別の費用相場

Web決済の開発費は、決済画面を表示するだけなのか、会員・注文・請求・返金まで一体で作るのかによって大きく変わります。

金額は決済関連機能を中心とした目安であり、検索、チャット、予約、配送、コンテンツ配信などの機能は別途必要です。既存サービスへ追加する場合も、ソースコードの品質やテスト環境の有無によって調査・改修費が増えることがあります。

新規事業では、決済機能だけで開発予算を決めず、企画、デザイン、インフラ、保守、決済手数料まで含めた総額で判断してください。予算全体の組み立て方は、システム開発予算の決め方｜発注前の算定手順でも解説しています。

決済代行会社へ支払う費用

決済代行会社とは、クレジットカード会社や各種決済サービスとの契約・通信をまとめて提供する事業者です。料金体系には、主に次の項目があります。

すべての費用が同時に発生するわけではありません。また、コンビニ決済、銀行振込、後払い、キャリア決済などは、クレジットカード決済とは異なる料金体系になる場合があります。

料率だけでなく、売上の入金日、振込手数料、最低振込額、返金時の扱いも確認してください。入金までの期間が長いと、売上が伸びても運転資金が不足する可能性があります。

費用を左右する主な要因

見積もりが高くなる主な要因は次のとおりです。

• 定期課金、従量課金、日割り計算を行う
• 無料体験、クーポン、初月割引を組み合わせる
• 複数の決済手段や通貨に対応する
• 出品者や講師など複数の受取人へ売上を分配する
• 一部返金、キャンセル料、利用後返金に対応する
• 決済失敗時の再請求や利用制限を自動化する
• 会計システムや顧客管理システムと連携する
• 管理画面から返金や請求状況の確認を行う
• 高い可用性や厳格な監査ログが求められる

発注のご相談を受ける立場では、「カード決済を付けたい」という一言から見積もりを始めることはできません。売上が誰に帰属し、いつサービスを提供したとみなし、どの条件で返金するのかまで確認して、初めて必要な開発範囲が分かります。

Webサービスに合う決済方式の選び方

決済方式は、利用者の好みだけではなく、事業の収益モデルから選ぶことが重要です。特に単発課金、定期課金、売上分配では必要なシステムが大きく異なります。

課金モデルを先に決める

初期開発では、例外の多い課金ルールを避けることも有効です。例えば、複数の締め日、利用者ごとに異なる料金、複雑な日割り計算を同時に導入すると、開発費だけでなく運用後の問い合わせも増えます。

まず標準的なプランで販売を開始し、需要が確認できてから課金パターンを追加するほうが、新規事業では投資を抑えやすくなります。ただし、将来の追加を想定して、注文と決済を別々に管理できる設計にしておく必要があります。

決済の実装方式を選ぶ

トークン方式とは、カード番号をそのまま自社サーバーへ送らず、決済代行会社が発行する代替文字列で処理する方法です。一般的なWebサービスでは、外部決済画面またはトークン方式を選び、自社でカード番号を保存しない構成を基本とします。

カード情報を直接扱うと、PCI DSS（カード情報を安全に扱うための国際的なセキュリティ基準）への対応範囲が広がります。開発だけでなく、継続的な監査や運用の負担も大きくなるため、安易に選ぶべきではありません。

決済代行会社の比較項目

決済代行会社は、手数料の低さだけでなく、事業要件を実現できるかで選びます。

• 必要な決済手段を利用できるか
• 自社の業種・商品が審査対象になるか
• 定期課金や従量課金に対応できるか
• マーケットプレイス向けの売上分配機能があるか
• 3Dセキュアなどの本人認証に対応しているか
• テスト環境と技術資料が整備されているか
• 返金、一部返金、取消を管理画面から行えるか
• 売上データをCSVやAPIで取得できるか
• 入金周期と振込手数料が資金計画に合うか
• 障害時の告知と問い合わせ窓口が明確か
• 将来別の決済代行会社へ移行できるか

3Dセキュアとは、カード決済時にパスワードや生体認証などで本人確認を行う仕組みです。利用者の離脱率だけでなく、不正利用やチャージバックを減らす観点から設計します。

決済代行会社のアカウントは、原則として発注企業自身の法人名義で契約してください。開発会社のアカウントへ売上を入金する形にすると、契約終了時の移管や会計処理が難しくなります。

決済開発を依頼する前の準備

依頼前には、画面一覧より先に「商品・注文・支払い・提供・キャンセル・返金」の流れを整理します。正常に支払えた場合だけでなく、決済失敗や二重操作などの例外も決めておくことが、見積もりの精度を高めます。

最低限決めておく事業ルール

次の項目を1〜3ページ程度にまとめると、開発会社が要件を把握しやすくなります。

• 誰が、誰に対して料金を支払うのか
• 商品・サービスの名称、価格、平均購入額
• 単発、定期、従量、売上分配のどれに該当するか
• 想定する月間利用者数と決済件数
• 対応したい決済手段と通貨
• 売上を確定するタイミング
• 無料体験、割引、クーポンの有無
• キャンセル可能な期間とキャンセル料
• 全額返金、一部返金を認める条件
• 定期課金の更新日、解約日、日割りの扱い
• 支払い失敗時に何回再請求するか
• 領収書、請求書、インボイス対応の要否
• 管理画面で担当者が行う操作
• 会計ソフトや顧客管理システムとの連携要否

業務の流れを可視化する方法は、業務フロー図の作り方｜開発依頼前の準備も参考にしてください。決済では、利用者の操作だけでなく、経理担当者の入金確認やカスタマーサポートの返金対応まで図に含めることが大切です。

例外処理を一覧にする

決済機能の品質は、成功時より失敗時の設計に表れます。少なくとも次のケースについて、画面表示、データの状態、利用者への通知、担当者の対応を決めます。

• 決済途中で利用者が画面を閉じた
• 通信が切れて結果を確認できない
• 支払いボタンを連続して押した
• 決済は成功したが完了画面を表示できない
• 決済代行会社から同じ通知が複数届いた
• 定期課金の更新に失敗した
• 解約と更新処理が同時に行われた
• 返金後にサービスが利用可能なままになった
• 管理者が誤って二度返金した

決済代行会社からシステムへ結果を自動通知する仕組みをWebhookと呼びます。Webhookは遅延したり、同じ内容が複数回届いたりする前提で設計しなければなりません。

また、同じ処理要求が複数回来ても二重決済にしない性質を冪等性といいます。発注者が技術仕様まで決める必要はありませんが、「二重決済をどのように防ぐか」「決済結果が不明な場合にどう確認するか」は開発会社へ質問してください。

セキュリティ・法務・運用の確認

Web決済では、開発以外の準備も必要です。

• 利用規約とプライバシーポリシーを用意する
• 特定商取引法に基づく表記の必要性を確認する
• 返品・キャンセル・解約条件を明示する
• 個人情報と決済情報の保存範囲を決める
• 管理画面の返金権限を必要な担当者に限定する
• 操作履歴を保存する
• 不正利用が疑われる注文の確認手順を決める
• 障害時の問い合わせ窓口と告知方法を決める
• 日次・月次の売上照合方法を決める

法令の適用範囲は、販売する商品、決済の仕組み、預かり金の有無などで異なります。特に利用者間の送金、残高の保持、ポイント換金、複数事業者への売上分配を行う場合は、決済代行会社だけでなく弁護士などの専門家にも確認してください。

外注の進め方と見積もり・会社選び

決済開発は、決済代行会社の審査とシステム開発を並行して進めるのが基本です。開発完了後に審査を始めると、公開予定日に利用できない可能性があります。

外注から公開までの6ステップ

1. 事業・課金ルールを整理する
   単発課金、定期課金、売上分配などの収益モデルと、返金・解約条件を決めます。目安は1〜2週間です。

2. 決済代行会社を比較する
   候補を2〜3社に絞り、対応機能、審査条件、手数料、入金周期を比較します。開発会社に選定支援を依頼することも可能です。

3. 審査を申請する
   法人情報、商品・サービス内容、Webサイト、利用規約などを提出します。審査期間は数日〜数週間程度が目安ですが、業種や決済手段によって変わります。

4. 要件定義と設計を行う
   要件定義（作るものを決める工程）で、画面、注文状態、決済状態、返金、通知、管理権限を決めます。目安は2〜4週間です。

5. 開発・テストを行う
   テスト環境で正常系と例外系を確認します。既存サービスへの単発決済追加なら1〜2.5か月、定期課金や売上分配では3か月以上かかる場合があります。

6. 少量の取引から公開する
   公開直後は取引件数を抑え、注文、決済、メール、サービス提供、入金データが一致するか確認します。異常を検知する監視と問い合わせ体制も用意します。

見積書で確認する項目

決済機能の見積書では、「決済連携一式」とまとめられていないか確認してください。少なくとも次の内訳が必要です。

• 決済代行会社の選定・審査支援
• 決済画面と完了・失敗画面の制作
• 注文データと決済データの設計
• 決済APIとの連携
• Webhookの受信と重複防止
• 定期課金、解約、再請求の処理
• 返金、一部返金、取消機能
• 管理画面と権限管理
• メールやアプリ内通知
• 売上・入金データの出力
• 正常系・異常系のテスト
• セキュリティ確認
• 本番環境への反映
• 操作マニュアルと運用引き継ぎ
• 公開後の保証・保守範囲

決済代行会社の初期費用、月額費用、決済手数料が開発見積もりに含まれているかも確認します。一般には、開発会社の見積もりとは別に発注企業が直接支払います。

金額だけでなく、前提条件も重要です。「定期課金は同一料金のみ」「一部返金は対象外」「決済代行会社の審査対応は含まない」などの条件が、小さく記載されていることがあります。各社の見積もりを比較するときは、対象機能と対象外業務を横並びにしてください。

開発会社を見極める質問

決済連携の実績だけでなく、事業運用まで考えられる会社を選びます。打ち合わせでは次の質問が有効です。

• 決済成功後に通信が切れた場合、どう整合性を保ちますか
• 同じ通知が複数回来ても二重処理になりませんか
• 支払い失敗や再請求を管理画面で確認できますか
• 返金権限と操作履歴はどのように管理しますか
• カード番号が自社サーバーを通過しない構成ですか
• 決済代行会社の障害時にはどのように検知しますか
• 売上と入金額を経理担当者が照合できますか
• 将来別の決済代行会社へ変更する場合、どこを改修しますか
• 公開後の問い合わせや障害対応は契約に含まれますか

技術用語を多用するだけでなく、利用者、運営担当者、経理担当者の動きに置き換えて説明できる会社が望ましいです。決済機能の新規導入や既存サービスへの追加を検討している場合は、要件整理の段階から開発のご相談はこちらをご利用ください。

よくある失敗と回避策

1. 手数料だけで決済代行会社を決める
必要な定期課金や売上分配に対応できず、設計後にサービスを変更することがあります。先に課金ルールと運用要件を整理してから比較してください。

2. 決済成功時の処理しか決めない
通信切断、重複通知、支払い失敗、返金などの例外が漏れると、売上とサービス提供状況が一致しなくなります。例外処理一覧を要件定義の成果物に含めます。

3. 決済代行会社の審査を後回しにする
システムが完成しても、本番決済を開始できない可能性があります。候補を絞った段階で必要書類を確認し、開発と並行して審査を進めます。

4. 開発会社名義のアカウントを利用する
契約終了時に売上や顧客情報を移管できないリスクがあります。アカウント、売上入金先、API認証情報は発注企業が管理できる形にします。

5. 経理・顧客対応の運用を決めない
返金、入金照合、領収書、支払い失敗の問い合わせが属人化します。公開前に担当者、権限、確認頻度、対応期限を決めてください。

まとめ

• 既存Webサービスへの単発決済追加は30万〜100万円程度、1〜2.5か月が一般的な目安です
• 注文・管理機能を含む新規開発は100万〜300万円程度、定期課金は150万〜400万円程度が目安です
• マーケットプレイス型の売上分配は、出品者審査や振込管理が加わるため高額になりやすいです
• 決済代行会社の利用料と開発会社の開発費は分けて予算化します
• 手数料だけでなく、対応機能、審査、入金周期、返金、移行性を比較します
• 発注前に課金、解約、返金、支払い失敗、入金照合のルールを決めます
• カード番号は自社で保存せず、外部決済画面やトークン方式を利用するのが基本です
• 決済代行会社の審査と開発を並行し、公開直後は少量の取引から検証します
• 見積書では正常系だけでなく、重複通知、再請求、返金、障害対応の範囲も確認します

よくある質問

Web決済は最初から複数の決済手段を用意すべきですか？

必須ではありません。初期段階では利用者が最も使う決済手段に絞り、需要を確認してから追加する方法が現実的です。ただし、後から追加しやすいデータ構造と画面設計にしておくことが重要です。

決済代行会社の審査にはどのくらいかかりますか？

数日から数週間程度が一般的な目安ですが、決済手段、業種、提出書類、サービス内容によって異なります。利用規約、特定商取引法に基づく表記、返金条件などを準備し、開発と並行して早めに申請してください。

開発会社にカード情報を保存してもらう必要はありますか？

通常は必要ありません。決済代行会社の決済画面やトークン方式を使い、自社のWebサービスではカード番号を保持しない設計が基本です。カード情報を直接扱う構成は、セキュリティと運用の負担が大きくなります。

既存のWebサービスにも決済機能を追加できますか？

多くの場合は追加できます。ただし、既存のソースコード、データベース、会員・注文管理の仕様、インフラ環境を確認しなければ正確な見積もりはできません。資料が不足している場合は、先に有償調査を行うこともあります。