QR決済システム開発の発注/外注/依頼/委託方法について

QR決済システムの発注・外注では、QRコードを表示する機能だけでなく、決済状態、返金、売上の消込、入金、障害対応までを含めて委託範囲を決めることが成功のポイントです。

店舗への既存サービス導入、ECやPOSへの決済API追加、独自の決済基盤開発では、適した発注形態も費用も異なります。この記事では、発注形態の選び方、RFPに書く内容、契約形態、費用相場、委託先の比較方法まで、QR決済システムを外注する実務を順番に解説します。

▼全体ガイドの記事
・QR決済システム開発の完全ガイド

QR決済システムを発注・外注する前の全体像

最初に整理すべきなのは、自社が何を実現したいのかです。既存の決済サービスを店舗に導入するのか、自社のPOSやECに1ブランドを追加するのか、複数ブランドをまとめるのか、独自の加盟店・残高・精算基盤を作るのかで、外注先に求める能力が変わります。2025年の国内キャッシュレス決済比率は58.0%、決済額は162.7兆円で、そのうちコード決済は10.2%、16.6兆円でした（出典: 経済産業省「2025年のキャッシュレス決済比率」、2026年）。市場が拡大しているからこそ、導入と開発を混同しない発注設計が必要です。

1つ目は、Airペイなどの店舗向けサービスを申し込み、端末や管理画面を使って運用する導入型です。開発会社へ大規模な開発を依頼するのではなく、対応ブランド、手数料、入金サイクル、POS連携の有無を比較します。2つ目は、既存のPOSやECにPayPayなどの決済APIを追加する連携型です。決済開始、結果反映、返金、Webhook、取引照会を自社業務へつなぐ設計が中心です。3つ目は、第三者の加盟店へ決済機能を提供するプラットフォーム型です。加盟店審査、権限、売上管理、精算、監査、本人確認などを含むため、SI会社や決済に詳しい受託開発会社へ要件定義から依頼する必要があります。

店舗に固定QRを掲示して利用者が金額を入力するMPM（Merchant-Presented Mode）は、導入しやすい一方で、店舗間違い、金額入力ミス、偽QRへの差し替えを防ぐ運用が重要です。POSが取引ごとに金額入りの動的QRを表示する方式は、金額の二重入力を抑えやすい一方、取引ID、有効期限、キャンセル、タイムアウトの管理が必要です。利用者のコードを店舗側で読み取る方式では、カメラ端末や読み取り処理、個人情報の取り扱いも論点になります。

発注時には、決済ブランドまたはPSPが認証・資金移動・売上処理を担い、自社と開発会社が画面、業務データ、Webhook、消込、問い合わせ対応を担うのかを文書化します。決済完了画面だけを成功の根拠にすると、通信断やWebhook遅延の際に二重決済や未計上が起こるため、決済状態の照会と台帳の整合性まで責任範囲に含めることが大切です。

発注形態はどれを選ぶべきですか？

結論から言うと、1ブランドの決済追加ならPSPやブランドのAPIを使った連携型、複数ブランドと加盟店管理まで必要ならPSPを中心にした受託開発型、残高や精算を含む独自サービスならSI・決済基盤に強い会社との共同開発型が適しています。自社で決済処理をすべて保有するほど自由度は上がりますが、契約、審査、セキュリティ、障害対応の責任も増えます。

自社店舗でQR決済を受け付けたいだけなら、まず既存の店舗向けサービスを検討します。Airペイの公式料金では、初期費用、月額費用、運用費、振込手数料が0円と案内され、QR決済手数料はCOIN+が0.99%、PayPay、d払い、au PAY、楽天ペイなどが2.95%です（出典: Airペイ「費用・料金・手数料・端末」、2026年8月確認）。iPadまたはiPhoneなどの必要機器は別途確認が必要です。

一方、PayPayの公式案内では、スキャン支払いの決済システム利用料は制限プランが1.98%、ライトプランが1.60%で、ライトプランは月額1,980円（税別）です（出典: PayPay「PayPayマイストア ライトプラン」、2026年8月確認）。同じ1店舗導入でも、料率だけでなく月額、振込回数、早期入金、端末、サポート、POS連携を合わせて年間費用を計算します。

ECやPOSに複数のQRブランドを追加する場合は、PSPのAPIを利用してブランド差異をまとめる方式が現実的です。自社は注文、会計、会員、売上データを管理し、PSPが各ブランドとの接続や決済処理を担う分担にすると、直接APIをブランドごとに実装するより初期の比較検討を進めやすくなります。見積依頼では、対応ブランド、決済開始、成功・失敗・保留、Webhook、取引照会、取消、全額返金、一部返金、売上集計、入金明細までを機能単位で書き出します。

ただし、PSPを使えば責任がなくなるわけではありません。自社画面の誤表示、注文と決済のひも付け、Webhookの重複受信、照合バッチの失敗、加盟店への問い合わせ対応は自社または委託先の責任です。SLA、障害通知、ログ保存期間、データのエクスポート方法を契約前に確認します。

特定ブランドのアプリ呼び出し、独自の加盟店画面、ポイントや会員ランクとの連携など、PSPの標準画面では実現できない要件がある場合は、ブランド直接APIやスクラッチ開発を検討します。PayPay for Developersでも、Web決済、動的ユーザースキャン、アプリ呼び出し、継続課金など連携方式が分かれているため、単に「QRコードを出したい」と伝えるだけでは正しい見積になりません（出典: PayPay for Developers、2026年確認）。

独自ウォレットや残高・送金、第三者加盟店の精算を含める場合は、決済画面の開発ではなく金融・会計業務を含む事業基盤の構築です。資金決済法、前払式支払手段、資金移動、犯罪収益移転防止、個人情報保護などの該当性を専門家に確認し、開発会社には法務論点を整理したうえで相談します。

RFPと要件整理では何を決めますか？

RFPは開発会社を選ぶための資料であると同時に、自社の決済業務を整理するための設計図です。機能名を並べるだけでなく、誰が、いつ、どの画面で、どのデータを使い、例外時にどう処理するかを書きます。最低限、現状業務、対象ユーザー、利用方式、データ連携、非機能要件、運用と保守、見積条件を同じフォーマットでまとめます。

RFPの冒頭には、店舗向け導入、EC決済追加、加盟店向けサービスのどれかを明記します。対象ブランド、対応国・通貨、店舗数、利用者数、月間取引件数、月間取扱高、ピーク時の同時実行数、1取引の上限額、返金件数を記載します。例えば「店舗100店」だけではなく、「月間10万件、昼12時台に1時間あたり2万件、繁忙期は通常の1.5倍」のように業務量へ変換すると、インフラと監視の見積を比較しやすくなります。

また、売上を誰が受け取り、いつ加盟店へ入金し、手数料をどの帳票で確認するかを決めます。決済事業者からの入金明細と自社注文を日次で消込するのか、加盟店ごとに月次締めするのかで、台帳や管理画面の工数が変わります。取引データの保存期間、CSV出力、会計システムやERPとの連携条件も初回見積に含めます。

機能要件は「決済する」では不十分です。取引開始、認証中、成功、失敗、保留、タイムアウト、取消済み、返金済み、返金失敗など、自社で扱う状態を定義し、ブランドやPSPの状態を自社の共通ステータスへ変換します。Webhookが届かない場合は一定時間後に照会する、同じ通知を複数回受けても二重計上しない、利用者が画面を閉じても注文状態を復元できる、といった例外処理を書きます。

返金は全額だけでなく一部返金、返金可能期間、返金権限、返金理由、返金結果の通知まで確認します。売上の消込では、取引ID、注文番号、加盟店ID、ブランド、決済日時、入金予定日、手数料、税区分を一貫して保持します。ここを後回しにすると、決済自体は成功しても経理や店舗サポートが手作業になり、運用費が膨らみます。

非機能要件には、稼働時間、目標応答時間、ピーク時性能、可用性、バックアップ、復旧目標、監視、障害通知、メンテナンス時間、ログ保存期間を記載します。決済は店舗営業時間やECの販売機会に直結するため、平日日中だけの保守でよいのか、24時間365日の一次監視が必要なのかで体制と費用が変わります。

セキュリティ要件には、TLS、署名検証、APIキーの保管、秘密情報のローテーション、管理者の多要素認証、権限分離、監査ログ、WAF、レート制限、不正検知、脆弱性診断を含めます。カード情報を保持しない構成でも、個人情報や取引履歴を扱う場合はアクセス制御と委託先管理が必要です。カード情報を扱う場合や、自社で残高・送金を扱う場合は、PCI DSSや資金決済関連法令の該当性を専門家と確認し、RFPに確認結果と責任分界を反映します。

要件整理から開発・検収までの進め方

発注後は、要件定義、設計、実装、テスト、パイロット、検収、運用引き継ぎの順に進めます。決済では外部ブランドの審査やサンドボックスの制約があるため、画面開発だけを先行させず、契約・API仕様・テストアカウントの準備を工程表へ入れます。

要件定義では、利用者、店舗スタッフ、加盟店管理者、経理、運用担当者の業務フローを確認します。QRの発行から読み取り、決済結果の通知、注文確定、返金、売上集計、入金照合までを1本の業務シナリオにし、正常系だけでなく「読み取り後に通信が切れた」「利用者が二度押しした」「決済は成功したが画面へ戻らない」「入金額が合わない」ケースも合意します。

基本設計では、ブランド差異を吸収するアダプター層、共通の取引台帳、Webhook受信、照会処理、管理画面、監視・アラートを分けます。外部APIを画面から直接呼び出すのではなく、注文と決済を自社の取引IDでひも付け、冪等性キーを使って二重処理を防ぐ設計を委託先から提示してもらいます。

要件が固まり、成果物と検収条件を定義できる実装工程は、請負契約が比較しやすい場合があります。納品物、品質基準、検収期間、瑕疵対応、納期遅延時の扱いを明確にできるためです。ただし、外部ブランドの審査、API仕様変更、既存POSの調査など発注時点で不確実な要素が多い場合、全工程を固定価格にすると、前提外の追加費用や仕様の削減が発生しやすくなります。

要件定義、PoC、既存システム調査、運用設計など探索が必要な工程は準委任契約とし、稼働する人員、期間、作業内容、報告方法、上限時間を定める方法があります。要件定義は準委任、開発は請負、保守は月額の準委任という組み合わせも可能です。契約形態そのものより、変更管理、追加費用の単価、成果物の権利、再委託先、データ返却を契約書に落とし込むことが重要です。

テストでは、成功する決済だけでなく、拒否、残高不足、認証失敗、タイムアウト、Webhookの遅延・重複、金額不一致、返金失敗、通信断、PSP停止を再現します。決済完了画面、Webhook、照会API、POSの売上、加盟店管理画面、入金明細が同じ取引を指しているかを確認します。ブランドごとの異なるエラーコードが、店舗スタッフにも理解できる案内へ変換されるかも検収項目にします。

本番前は1〜数店舗を対象にパイロットを行い、決済完了率、決済にかかる時間、手入力エラー、返金完了時間、入金差異、問い合わせ件数を測定します。NTTデータは2025年5月下旬から、ヤマト運輸の全国ドライバーが持つ約7万台の業務端末で決済受付を順次稼働させました（出典: NTTデータ「ヤマト運輸の全ドライバーが携帯する配送管理端末で決済受付を実現」、2025年）。この事例からも、決済機能単体ではなく、現場端末と業務フローを含めた導入検証が必要だと分かります。

リリース後は、決済ブランドの仕様変更、証明書やAPIキーの更新、加盟店追加、返金権限の変更、月次の消込、障害連絡、脆弱性対応が発生します。保守契約には、受付時間、一次切り分け、復旧目標、ブランド側との連絡窓口、軽微な改修の範囲、追加開発の単価、月次レポートを含めます。運用担当者が取引を検索し、再照会し、返金し、監査ログを確認できる手順書も成果物に含めます。

2026年2月には、NTTデータとシャープがQRコード読み取りに対応するPINPAD型の新決済端末を共同開発し、2026年内の提供開始予定を発表しました。端末の遠隔監視や更新ファイル配信も構想に含まれており、決済システムの外注では、APIだけでなく端末管理や遠隔保守まで比較対象になり得ます（出典: NTTデータ「新決済端末を共同開発」、2026年）。

QR決済システムの費用相場と見積の内訳

QR決済システムの費用に公的な標準価格はありません。以下は、公開されている電子決済・POS開発の費用解説と、QR決済の機能・運用要件を組み合わせた企画段階の目安です。ブランド数、既存POSやECの品質、加盟店管理の有無、セキュリティ診断、24時間運用、データ移行の量で大きく上下するため、見積書では金額だけでなく含まれる範囲を確認します。

既存ECやPOSへ1ブランドをAPI追加する場合は、初期費用20万〜200万円、期間1〜3か月が一つの目安です。決済開始、結果反映、最低限の返金、テストが中心で、既存システムの改修量が少ない場合に近いレンジです。PSP経由で複数のQRブランドを統合し、Webhook、返金、売上管理、消込、POSやEC連携まで行う場合は、300万〜1,000万円、3〜6か月程度を見込みます。

多店舗POS、会員、ポイント、基幹連携、店舗・権限・締め・入金管理を含める場合は、500万〜2,000万円、6〜12か月程度が目安です。独自ウォレット、利用者アプリ、加盟店ポータル、残高・台帳、不正対策、本人確認、監査、高可用性まで自社基盤として構築する場合は、1,000万〜5,000万円以上、9〜18か月以上を見込むことがあります。これらはQRコードの枚数ではなく、決済事業を運営する範囲で費用が決まる例です。

初期費用は、企画・要件定義、UXや画面設計、API連携、バックエンド、管理画面、POS・EC連携、インフラ構築、テスト、セキュリティ診断、審査・ストア対応、データ移行、マニュアル作成に分けて記載してもらいます。「開発一式」だけの見積は、何が含まれていないのか判断できず、後から追加費用が発生しやすくなります。

例えば、固定QRの発行だけなら画面数は少なくても、加盟店の登録・審査、権限管理、QRの無効化、差し替え履歴、売上の検索、返金、入金照合まで含めると管理機能が増えます。見積書には、機能別の工数、外部サービス費、端末費、クラウド費、診断費、旅費や移行費などの実費を分け、前提条件と除外条件を記載します。

決済手数料は開発費とは別のランニングコストです。月間取扱高1,000万円の場合、手数料率1.60%なら16万円、2.95%なら29.5万円となり、差額は月13.5万円、年162万円です。実際には月額利用料、振込手数料、早期入金料、クーポンやポイント原資、端末費を加えるため、料率だけで最安と判断しません。PayPayやAirペイの公式料金は改定やプラン条件があるため、見積取得時点の公式ページで再確認します。

保守・運用費は、初期開発費の年15%前後を仮置きする方法がありますが、これは契約を決める固定率ではありません。監視時間、障害時の連絡体制、ブランド仕様変更への追随、脆弱性対応、月次消込、加盟店問い合わせ、追加開発を含むかで変わります。インフラ費も小規模なら月数万円から数十万円の範囲で始められる場合がありますが、取引量、冗長化、ログ保存、監視、バックアップで増えるため、月額の前提を見積書に残します。

委託先の選定と見積比較で確認すべきポイント

委託先は、会社名や提示価格だけでなく、決済業務のどこまでを担えるかで比較します。店舗導入ベンダー、PSP、ブランド直接APIの提供会社、受託開発会社、大規模SI会社では役割が異なります。3社以上へ同じRFPを渡し、同じ前提・同じ期間・同じ検収条件で提案を受けると、安い理由と高い理由を把握しやすくなります。

実績確認では、「QR決済を作ったことがあるか」だけでなく、同程度の店舗数、取引量、ブランド数、POSや基幹連携の経験を質問します。可能なら、決済開始から入金・返金・問い合わせまでを説明できる担当者に参加してもらい、プロジェクトマネージャー、アーキテクト、セキュリティ担当、運用担当の役割を提案書に明記してもらいます。再委託がある場合は、会社名、担当範囲、品質管理、障害時の連絡経路も確認します。

提案時には、決済状態のモデル、Webhookの冪等性、返金と取消の扱い、消込方法、障害時の代替運用を説明できるかを見ます。APIを呼ぶだけの説明で、入金差異や店舗からの問い合わせに触れない場合は、実運用の経験が不足している可能性があります。過去案件の画面ではなく、今回のRFPに対する設計判断とリスクの説明を評価します。

見積比較表には、要件定義、設計、実装、テスト、移行、教育、保守を行ごとに並べ、機能、工数、単価、期間、担当、成果物、除外条件を記載します。A社だけがセキュリティ診断を含み、B社は別料金という状態では、合計金額だけ比較できません。ブランド追加、店舗追加、返金仕様変更、取引量増加、納期短縮の単価も確認します。

特に注意したいのは、安い見積が「決済成功時の画面反映」だけを対象にしているケースです。返金、一部返金、入金照合、監査ログ、管理者権限、障害訓練、運用マニュアルが除外されていれば、稼働後に別の発注が必要になります。初期費用、手数料、保守、インフラ、端末、診断、追加改修を合算した3年程度のTCOを試算し、費用と業務負担の両方で比較します。

契約書には、成果物、検収条件、納期、変更手続き、瑕疵修補、損害賠償の範囲、秘密情報、個人情報の委託、再委託、知的財産、データ所有権、サービス終了時のデータ返却、保守終了時の引き継ぎを記載します。決済事業者やPSPの規約が上位にある場合は、その規約変更による改修費を誰が負担するかも決めます。

障害時には、決済を止める判断、現金や別ブランドへの切り替え、利用者への表示、重複決済の確認、返金、加盟店・経理への報告が必要です。SLAに復旧時間だけを書くのではなく、検知、一次連絡、暫定対応、原因報告、再発防止、返金・消込の完了までを手順として定義します。発注先が作ったシステムを自社で運用できるよう、監視画面、ログ、手順書、訓練記録を検収対象にします。

よくある質問

QR決済システムの発注では、費用、期間、決済ブランド、セキュリティ、既存システムとの連携について同じ疑問が繰り返し出ます。ここでは、外注前に判断しやすいように結論から回答します。

既存ECやPOSへ1ブランドを追加する小規模な改修なら、30万円前後で収まる可能性がありますが、すべてのQR決済システムに当てはまる金額ではありません。複数ブランド、返金、Webhook、売上消込、加盟店管理、基幹連携を含めると、数百万円以上になるケースがあります。

複数ブランドを早く統合し、接続や運用の窓口をまとめたい場合はPSPが向いています。特定ブランドの体験を深く作り込みたい、またはPSPの仕様では自社の業務に合わない場合は直接APIを検討しますが、契約・審査・仕様変更・障害対応を自社側で管理する範囲が増えます。

不要ではありません。カード情報を保持しない構成でも、個人情報、取引履歴、アクセストークン、加盟店情報を守る必要があり、権限管理、秘密情報管理、監査ログ、脆弱性診断、委託先管理が必要です。カード情報、残高、送金、本人確認を自社で扱う場合は、PCI DSSや資金決済関連法令の該当性を専門家に確認します。

最初に、店舗導入、既存POS・ECへのAPI追加、独自決済基盤のどれかを決め、対応ブランド、取引量、決済方式、返金・入金業務、既存システム、保守時間を1枚に整理します。その後、決済状態と例外処理を含むRFPを作成し、同じ条件で複数の委託先へ相談すると、必要な費用と体制が見えやすくなります。

まとめ

QR決済システムの発注・外注では、まず導入型、API連携型、独自プラットフォーム型を分けます。そのうえで、固定QRか動的QRか、PSPか直接APIか、決済処理・返金・消込・入金・障害対応を誰が担うかを決めることが重要です。

RFPには、ブランド、方式、取引量、決済状態、返金、入金、POSや基幹連携、SLA、セキュリティ、データ保存、保守範囲を書きます。見積は開発一式の金額だけで判断せず、要件定義、設計、実装、テスト、診断、移行、保守、インフラ、決済手数料、端末費を含むTCOで比較します。3社以上へ同じ条件で依頼し、除外条件と追加単価まで確認すると、発注後の認識違いを抑えられます。

すべての要件を決めてからでなければ相談できないわけではありません。店舗数、利用者、対応ブランド、現在のPOSやEC、想定する取引量、困っている業務を伝え、未確定事項を含めて要件定義から支援できる委託先を選びます。QRコードの表示ではなく、決済後の業務まで一緒に設計することが、使い続けられるQR決済システムにつながります。

▼全体ガイドの記事
・QR決済システム開発の完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。