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

QR決済システムの発注は、発注形態を決め、要件をRFPにまとめ、費用と委託先を比べる流れで進みます。業務範囲、連携方式、責任分界を順に決めておくと、決済後の運用まで見通せます。

全体像はQR決済システム開発の完全ガイドもご覧ください。

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

・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。

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

店舗への既存サービス導入、POSやECへの決済API追加、複数ブランドの統合では、必要な外注先が異なります。独自の加盟店・残高・精算基盤では、必要な外注先がさらに変わります。そのため、発注の前に自社が実現したい業務を明確にします。

2025年の国内キャッシュレス決済比率は58.0%、決済額は162.7兆円でした。コード決済は10.2%、16.6兆円です（出典：経済産業省「2025年のキャッシュレス決済比率」、2026年）。市場が広がる中で、導入と開発を混同しない発注設計が必要です。

発注案件の3つのタイプ

発注形態は、店舗向けサービスの導入、既存システムへのAPI連携、決済基盤の構築の3つに分けられます。必要な開発範囲と運用責任を比べて、どれにするかを選びます。

• 導入型：対応ブランドや手数料、入金サイクルを比べ、POS連携も確認します。
• 連携型：決済結果、返金、WebhookをPOS・EC業務へつなぐ方式です。
• 基盤型：加盟店審査や精算まで含め、要件定義から委託する範囲です。

導入型はAirペイなどのサービスを使い、開発会社へ大規模な開発を依頼しません。

一方、基盤型では、加盟店審査や権限、売上管理の設計が必要です。精算、監査、本人確認も設計対象になります。そのため、SI会社や決済に詳しい受託開発会社へ、要件定義から依頼します。

QR方式と責任分界の決め方

QR方式によって、必要な運用と端末が変わります。固定QR、動的QR、利用者コードの読み取りを比べて、自社の業務に合う方式を選びます。

• 固定QR：偽QR対策の要否の判断。
• 動的QR：取引IDと有効期限、キャンセル、タイムアウトの管理。
• 利用者コード：読み取り端末と個人情報の扱いの決定。

MPM（Merchant-Presented Mode）は導入しやすい一方、店舗間違いや金額入力ミスに注意が必要です。

POS表示の動的QRは、二重入力を抑えやすい方式です。一方、利用者コードを読む方式では、カメラ端末や読み取り処理も論点になります。

発注前に、ブランドまたはPSPが認証、資金移動、売上処理を担う範囲を定めます。そのうえで、自社と開発会社が持つ画面や業務データ、Webhookの扱いを、書面にまとめます。消込と問い合わせ対応も、同じ書面に含めます。

決済完了画面の表示だけで成功と判断すると、通信断やWebhookの遅延により、二重決済や未計上が起きます。そのため、状態照会と台帳の整合性まで責任範囲に含めます。

発注形態の選び方

1ブランドを追加するなら、PSPやブランドAPIによる連携型が適しています。複数ブランドと加盟店管理を扱うなら、PSP中心の受託開発型が向いています。残高や精算を含む独自サービスの場合は、SI・決済基盤に強い会社との共同開発が望ましいです。

自社で処理を持つほど自由度は上がります。一方で、契約と審査、セキュリティと障害対応の責任も増えます。

既存サービス導入の開発費と運用費

自社店舗で決済を受け付ける場合は、既存サービスを機器と料金の両面から比べます。

• Airペイ：対象ブランドごとの料率と、必要な機器を確認します。
• PayPay：利用プランと月額費用を確認します。
• 年間費用：入金条件、端末、サポート、POS連携まで含めた合計額です。

Airペイは、初期費用と月額費用が0円です。運用費と振込手数料も0円です（出典：Airペイ「費用・料金・手数料・端末」、2026年8月確認）。必要なiPadまたはiPhoneなどの機器は、別途確認します。

Airペイで受け付ける場合のQR決済手数料は、COIN+が0.99%です。PayPayやd払いのほか、au PAYや楽天ペイなども2.95%です。

PayPayマイストアでは、制限プランが1.98%、ライトプランが1.60%です。

ライトプランの月額は1,980円（税別）です（出典：PayPay「PayPayマイストア ライトプラン」、2026年8月確認）。

年間費用を比べるときは、料率だけでなく、月額や振込回数、早期入金を含めて計算します。

PSP経由のAPI連携は最初の外注候補

ECやPOSに複数ブランドを加える場合は、PSPのAPIでブランドの差異をまとめる方法が現実的です。PSPが各ブランドとの接続と決済処理を担うため、ブランドごとに直接APIを実装するより、初期の比較検討を進めやすくなります。

• 自社の担当：注文、会員、売上データの管理。
• 見積範囲：決済開始から入金明細までの機能の指定。
• 運用責任：自社側と委託先側の担当の切り分け。

見積依頼では、対応ブランドも明記します。特にWebhook、照会、取消の範囲は、具体的に書きます。成功・失敗・保留や全額・一部返金、売上集計の扱いも、依頼書に書きます。

PSPを使っても、自社画面の誤表示や注文とのひも付けは自社の責任です。加えて、Webhookの重複、照合バッチの失敗、加盟店からの問い合わせについて、担当を定めます。

契約前には、SLAと障害通知の内容を確認します。また、ログの保存期間とデータの出し方も、確かめておきます。

直接APIやスクラッチ開発を選ぶ条件

差別化要件がある場合に直接APIやスクラッチを検討し、採用前に次を整理します。

• 差別化要件：特定ブランドのアプリ呼び出し、独自の加盟店画面、ポイントや会員ランク連携の検討。
• 連携方式：Web決済や動的ユーザースキャン、アプリ呼び出し、継続課金で方式が分かれます（出典：PayPay for Developers、2026年確認）。
• 見積依頼：「QRコードを出したい」より、連携方式と取引条件を具体的に伝えます。
• 独自基盤：独自ウォレットや残高・送金、第三者加盟店の精算は、金融・会計業務を含みます。
• 法務確認：資金決済法、前払式支払手段、資金移動の該当性を専門家に確認します。犯罪収益移転防止や個人情報保護も含め、論点を開発会社へ伝えます。

RFPと要件整理で決める内容

RFPは委託先を選ぶための資料であり、自社の決済業務を整理する設計図でもあります。

RFPには、誰が、いつ、どの画面で操作するかに加えて、例外時の処理まで書きます。

最低限の項目として、現状業務、対象ユーザー、利用方式を同じ形式にまとめます。

データ連携と非機能要件、運用・保守と見積条件も、あわせて揃えます。

事業モデルと取引量の具体化

RFPでは、事業モデル、取引規模、入金・会計の扱いを具体的に書きます。

• 事業モデル：店舗導入、EC決済追加、加盟店向けサービスを区別します。
• 取引量：店舗数、件数、取扱高を記載します。
• 入金・会計：受取人、入金時期、消込と連携条件を決めます。

対象ブランド、国・通貨、利用者数も明記します。加えて、ピーク時の同時実行数、1取引の上限額、返金件数も必要です。

数値は、たとえば店舗100店に加えて、月間10万件、昼12時台に1時間2万件、繁忙期は通常の1.5倍と示すと、インフラと監視を見積もりやすくなります。

日次消込か加盟店ごとの月次締めかで、台帳や管理画面の工数が変わります。そのため、取引データの保存期間、CSV出力、会計システムやERPとの連携条件も、初回見積に含めます。

決済状態と例外処理の機能要件

決済機能は、状態、例外処理、返金・売上消込の要件に分けて定義します。

• 決済状態：ブランドやPSPごとの状態を共通化します。
• 例外処理：通知の遅延や重複、画面離脱への対応を決めます。
• 返金・消込：返金条件と取引データの保持方法を定めます。

状態には、取引開始、認証中、成功のほか、失敗や保留、タイムアウトも含みます。

取消済み、返金済み、返金失敗まで、共通ステータスに変換します。

Webhookが届かないときの照会、通知の重複受信、画面を閉じた後の注文復元を定めます。これにより、二重計上を防ぎます。

返金では、可能な期間と権限を決めます。返金理由と結果の通知も定めます。全額返金と一部返金の両方を確認します。

取引IDと注文番号、加盟店IDは、一貫して保持します。

ブランドと決済日時、入金予定日も、取引データに残します。

手数料と税区分も、取引データに含めます。後回しにすると、経理や店舗サポートが手作業になり、運用費が膨らみます。

非機能要件とセキュリティ基準

運用条件と、扱う情報に応じたセキュリティ対策を、要件に含めます。

• 非機能要件：稼働・応答時間、ピーク性能、可用性、バックアップ、復旧目標、監視、障害通知、保守時間、ログ保存期間を指定します。
• 監視体制：平日日中対応か24時間365日の一次監視かで、体制と費用が変わります。
• セキュリティ要件：TLS、署名検証、APIキー保管、多要素認証、権限分離、監査ログ、WAF、レート制限、不正検知、脆弱性診断を含めます。
• 情報管理：カード情報を保持しなくても、個人情報や取引履歴にはアクセス制御と委託先管理が必要です。
• 専門家への確認：カード情報や自社の残高・送金を扱う場合、PCI DSSや資金決済関連法令の該当性を確認します。

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

発注後は、要件定義と設計、実装、テストの順に進みます。その後、パイロットと検収を経て、運用引き継ぎに入ります。契約、API仕様、テストアカウントの準備も、工程表に入れておきます。

外部ブランドの審査やサンドボックスの制約があるため、画面開発だけを先に進めないことが大切です。

要件定義と基本設計での業務内容の合意

利用者や店舗スタッフ、加盟店管理者の業務を確認します。経理や運用担当の業務も対象です。取引は、QR発行から読み取り、結果通知、注文確定を経て、返金、売上集計、入金照合まで続きます。これらを一つのシナリオにして、業務の流れを合わせます。

通信断や二度押し、決済成功後に画面へ戻らないケースは、対応を事前に合意しておきます。入金額の不一致についても、扱いを決めておきます。正常系だけで設計を終えないことが大切です。

基本設計では、ブランド差異を吸収するアダプター、取引台帳、Webhook受信を分けて設計します。照会、管理画面、監視・アラートも、機能ごとに切り分けます。注文と決済は自社の取引IDで結び、冪等性キーで二重処理を防ぎます。

工程の確実性による契約形態の使い分け

契約形態は工程の確実性で選び、作業範囲や変更時の条件を契約に反映します。

• 請負：成果物と検収条件を定義できる実装工程に用います。
• 準委任：調査や要件定義など、探索が必要な工程が対象です。
• 組み合わせ：要件定義、開発、保守で契約形態を分けられます。

請負では、納品物や品質基準、検収期間を明確にします。

瑕疵対応と納期遅延時の扱いも、あらかじめ決めておきます。

ただし、ブランド審査、API変更、POS調査のように先の見えない工程を固定価格の請負にすると、追加費用や仕様削減が起きやすくなります。

準委任では、稼働人員と期間、作業内容を定めます。

報告方法と上限時間も決めておきます。

要件定義は準委任、開発は請負、保守は月額の準委任とする組み合わせも可能です。

変更管理と追加単価、成果物の権利は、契約に記載します。

再委託やデータ返却も、あわせて書き込みます。

決済状態を基準にしたテストと検収

検収は、異常系の再現、取引データの整合、本番前の試験導入の順に進めます。

1. 拒否、残高不足、認証失敗、タイムアウト、Webhook遅延・重複、金額不一致、返金失敗、通信断、PSP停止を試験します。
2. 完了画面、Webhook、照会API、POS売上、加盟店画面、入金明細が同じ取引を指すか確認します。
3. 1〜数店舗で試験導入し、結果を測ります。

測定するのは、決済完了率、所要時間、手入力エラーです。加えて、返金時間、入金差異、問い合わせ件数も測ります。ブランドごとのエラーを店舗向けに案内できるかも、検収の対象です。

NTTデータは2025年5月下旬から、決済受付を順次稼働させました。対象は、ヤマト運輸の全国ドライバーが持つ約7万台の業務端末です（出典：NTTデータ「ヤマト運輸の全ドライバーが携帯する配送管理端末で決済受付を実現」、2025年）。この事例から、現場端末と業務フローを含めた導入検証の必要性が分かります。

運用引き継ぎと保守範囲

運用引き継ぎでは、リリース後の保守作業と契約範囲を具体的に決めます。

• 定常保守：仕様変更、証明書・APIキー更新、加盟店追加、返金権限の変更に対応します。
• 運用対応：月次消込、障害連絡、脆弱性対応の担当を定めます。
• 契約・成果物：受付時間、一次切り分け、復旧目標、ブランド窓口、軽微な改修範囲、追加単価、月次報告、手順書を含めます。

2026年2月、NTTデータとシャープは、QR読み取りに対応したPINPAD型端末を共同開発しました。2026年内の提供開始を予定しており、遠隔監視と更新ファイル配信も構想に含めています（出典：NTTデータ「新決済端末を共同開発」、2026年）。

取引検索、再照会、返金の手順書は成果物にします。監査ログの手順書も、必要な成果物です。端末管理や遠隔保守も、外注先の比較対象になり得ます。

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

QR決済に公的な標準価格はありません。

次の金額は、公開されている電子決済・POS開発の費用解説と、機能・運用要件を組み合わせた企画段階の目安です。

費用は、ブランド数や既存POS・ECの品質、加盟店管理で変わります。診断や24時間運用、データ移行によっても変動します。金額だけでなく、見積に含まれる範囲も確認します。

案件タイプ別の初期費用と期間の目安

初期費用と期間は、連携先や運用範囲で異なります。企画段階では、次の目安を比較の起点にします。

• 1ブランド連携：20万〜200万円、1〜3か月が目安です。
• 複数ブランド統合：300万〜1,000万円、3〜6か月程度です。
• 多店舗・基幹連携：500万〜2,000万円、6〜12か月程度です。
• 独自決済基盤：1,000万〜5,000万円以上、9〜18か月以上の場合があります。

1ブランド連携は、決済の開始と結果の反映が中心です。

最低限の返金とテストも含みます。

この目安は、既存ECやPOSへのAPI追加を想定しています。

既存システムの改修量が少ない場合は、目安の下端に近づきます。

複数ブランドの統合は、PSP経由での連携を想定しています。

Webhookや返金、売上管理が加わり、消込やPOS・EC連携も含みます。

多店舗案件では、POSや会員、ポイントの連携に加えて、基幹連携を含みます。

店舗や権限の管理、締めと入金の処理も必要です。

独自基盤を自社で構築する場合は、アプリや加盟店ポータル、残高台帳が対象になります。さらに、不正対策、本人確認、監査が加わり、高可用性も対象です。

費用は、決済事業を運営する範囲で決まり、QRコードの枚数で決まるわけではありません。

初期見積に含めるコスト項目

初期見積は、機能や作業の範囲ごとに分けて書きます。「開発一式」とまとめると、対象外の作業が分からず、追加費用につながりやすくなります。

• 企画・設計：要件定義とUX、画面設計を含めます。
• 開発・連携：API、バックエンド、管理画面、POS・EC、インフラを分けます。
• 導入作業：テスト、診断、審査・ストア対応、移行、マニュアルを含めます。
• 実費：外部サービス、端末、クラウド、診断、旅費、移行費を分けます。

固定QRの発行だけなら画面数は少なくても、加盟店登録・審査や権限、QR無効化の管理が加わり、管理機能が増えます。さらに、差し替え履歴の管理、売上検索、返金と入金照合も必要になります。

見積書には、機能ごとの工数と前提・除外条件を記載します。費用項目を分けておくと、追加される範囲を判断できます。

手数料と保守を含めたTCOでの比較

TCOでは、決済手数料、保守・運用、インフラを開発費と合わせて比べます。

• 決済費用：料率以外に月額、振込、早期入金、端末費も加えます。
• 保守費用：監視や障害対応、仕様変更などの範囲を確認します。
• インフラ費用：取引量や冗長化、ログ・監視の条件を揃えます。

月間取扱高1,000万円の場合、料率1.60%なら16万円、2.95%なら29.5万円です。差額は月13.5万円、年162万円です。

クーポンやポイントの原資も、費用に含めます。PayPayやAirペイの料金は改定やプラン条件で変わるため、見積を取る時点の公式ページで再確認します。

保守・運用費は、初期開発費の年15%前後を仮置きする方法もあります。ただし、固定率ではありません。

保守・運用費の実際の額は、脆弱性対応や消込の作業、問い合わせ、追加開発でも変わります。

小規模なインフラ費は、月数万円から数十万円で始められる場合があります。

バックアップの条件でも増えるため、月額の前提を見積書に残します。

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

委託先は価格だけでなく、決済業務の担当範囲で比べます。候補には、店舗導入ベンダーやPSP、ブランドAPI提供会社があります。受託開発会社や大規模SI会社も候補ですが、それぞれ役割が異なります。

3社以上へ同じRFPを渡し、同じ前提、期間、検収条件で提案を受けます。そうすると、費用差の理由を把握しやすくなります。

決済実績と担当チームの経験

決済業務の実績と、今回の案件を担う体制・設計力を確認します。

• 実績：店舗数や取引量、ブランド数、POS・基幹連携を照合します。
• 担当体制：PM、設計、セキュリティ、運用の役割を確認します。
• 運用設計：決済状態、Webhook冪等性、返金、消込、障害時対応を質問します。

決済開始から入金、返金、問い合わせまで説明できる担当者に、参加してもらいます。

再委託がある場合は、会社名と担当範囲を確認します。品質管理や障害時の連絡経路も、あわせて確かめます。

入金差異や店舗問い合わせに触れない提案は、実運用の経験が不足する可能性があります。

評価するのは、過去案件の画面より、今回のRFPへの設計判断とリスク説明です。

見積は機能・工数・前提条件を並べた比較

見積比較表では、作業範囲と条件、追加費用、総保有コストを横並びにします。

• 作業範囲：要件定義から保守までの機能と成果物を照合します。
• 見積条件：工数、単価、期間、担当、除外条件を揃えます。
• 追加費用：ブランド追加や仕様変更などの単価を確認します。

セキュリティ診断が一社だけ別料金の場合は、合計額だけで比べると、条件の違いが見えにくくなります。

ブランド・店舗の追加や返金変更の単価に加え、取引量の増加や納期短縮の単価も確認します。

決済成功時の画面反映だけの見積では、返金、一部返金、入金照合などが除外される場合があります。

監査ログや権限の設定に加えて、障害訓練や運用マニュアルも対象外になることがあります。

初期費用に、手数料や保守、インフラの費用を合算し、3年程度のTCOを試算します。端末、診断、追加改修も含めます。費用と業務負担の両面で比べます。

契約と発注後のリスクへの備え

契約条件と障害対応、引き継ぎは、発注の前に書面にしておきます。

• 契約条件：成果物、検収、納期、変更、瑕疵、賠償を定めます。
• 情報・権利：秘密情報、個人情報、再委託、知的財産を確認します。
• 障害対応：決済停止、切替、利用者表示、重複確認、返金・報告を決めます。
• 引き継ぎ：監視画面、ログ、手順書、訓練記録を検収します。

データ所有権や、サービス終了時の返却、保守終了時の引き継ぎも決めます。

PSP規約の変更による改修費の負担者も明記します。

SLAには、復旧時間だけでなく、検知から一次連絡、暫定対応までを記します。さらに、原因報告や再発防止、返金・消込完了までも含めます。

引き継ぎの検収では、自社で運用できる状態かを確認します。

個人情報の委託範囲と損害賠償条件は、契約書で確かめます。

よくある質問

費用や期間、ブランドに関する疑問に加え、セキュリティや既存システム連携についても答えます。

QR決済システムの開発費用は30万円で足りますか？

既存ECやPOSへ1ブランドを追加する小規模改修なら、30万円前後で収まる可能性があります。ただし、すべてのシステムに当てはまる金額ではありません。

複数ブランドや返金、Webhookを含めると、数百万円以上になるケースがあります。売上消込や加盟店管理、基幹連携は、その範囲をさらに広げます。

PSPと決済ブランドの直接APIはどちらがよいですか？

複数ブランドを早く統合し、接続窓口をまとめたい場合はPSPが向いています。

特定ブランドの体験を作り込む場合や、PSPの仕様が自社業務に合わない場合は、直接APIを検討します。

直接APIでは、契約と審査、仕様変更、障害対応を自社で管理する範囲が増えます。

カード情報を保持しなければセキュリティ対応は不要ですか？

カード情報を保持しない場合でも、セキュリティ対応は必要です。個人情報や取引履歴、アクセストークンを守る必要があり、加盟店情報も対象です。

権限や秘密情報、監査ログを管理します。脆弱性診断や委託先の管理も必要です。カード情報や残高・送金、本人確認を扱う場合は、PCI DSSや資金決済関連法令の該当性を専門家に確認します。

QR決済システムの発注は何から始めればよいですか？

まず、店舗導入、POS・ECへのAPI追加、独自基盤のどれにするかを決めます。そのうえで、ブランドや取引量、方式を整理します。返金・入金業務、既存システム、保守時間も整理対象です。

その後、決済状態と例外処理を含むRFPを作ります。同じ条件で複数社に相談すると、必要な費用と体制を比べやすくなります。

まとめ

発注では、導入型、連携型、基盤型のどれにするかを決めます。そのうえで、QR方式とPSPか直接APIかを選び、決済や返金、消込の担当に加えて、入金と障害対応の担当も決めます。

RFPと見積の運用までの比較

RFPから見積の比較までは、次の内容を押さえておきます。

• RFP：ブランドや方式、取引量に加え、決済の状態、返金、入金の扱いを必ず記載します。
• 連携とSLA：POS・基幹連携とSLAを書き、セキュリティやデータの保存、保守範囲も含めます。
• 見積の比較：開発一式では判断せず、TCOで比べます。
• TCOの内訳：要件定義から保守までの作業、インフラ、手数料、端末の費用です。
• 見積の依頼：3社以上へ同条件で依頼し、除外条件と追加単価も確認します。

最初の相談で伝える要件の未確定部分

未確定の要件があっても、相談は始められます。店舗数や利用者、ブランドを伝えます。POS・EC、取引量、困っている業務も、あわせて共有します。

未確定事項も含めて要件定義から支援できる会社を選びます。

決済後の業務まで一緒に設計すると、使い続けられるシステムにつながります。

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

▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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