オーソリシステム開発の進め方/やり方/流れや方法/手法/工程/手順

オーソリシステム開発は、対象範囲と数値目標を定めたうえで方式を選び、異常系まで設計・試験して段階的に移行すると、安全な決済運用につながります。

全体像、開発手順、費用相場、見積もりの確認点の順に見ていきます。全体像はオーソリシステム開発の完全ガイドもご覧ください。

▼全体ガイドの記事
・オーソリシステム開発の完全ガイド

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

オーソリシステム開発の全体像

オーソリシステムは、カード決済で「利用してよいか」をリアルタイムに判定する仕組みです。

加盟店や決済代行会社から取引情報を受け取り、カード番号やトークン、利用者の状態、利用可能枠、取引条件、不正リスクなどを確認します。そのうえで、カード会社や発行会社の判断を加盟店へ返します。

売上確定、請求、清算、入金までを一つの機能と誤解しやすいため、最初に範囲と、どこまでを誰が受け持つかを図にしておきます。

オーソリと決済周辺機能の境界

承認の前後には、本人認証や不正検知、売上の確定と清算が続いています。それぞれが受け持つ範囲は、下のとおりに分かれます。

• オーソリ：承認要求を受け、取引条件を確認して結果を返す役割。
• 3-Dセキュア・不正検知：本人認証と取引リスクの評価を担う役割。
• 売上確定・清算：承認済み取引の確定と、関係者間での金額の受け渡し。

これらは連携させますが、同じシステムにすべてをまとめる必要はありません。

開発の対象は、加盟店向けの決済ゲートウェイ、アクワイアラ側の中継基盤、イシュア側の与信・利用枠判定基盤のどれかで大きく変わります。既存PSPのAPIを呼び出すだけなら接続開発に近い一方、自社でカード発行、利用可能枠、残高、リスク判定、複数ブランド接続まで持つなら基幹刷新になります。

企画書には、作る範囲と作らない範囲、利用する外部サービスを明記しておきます。

主要機能の構成：受付・判定・応答・記録

機能を工程ごとに分けておくと、責任の範囲とデータ設計を整理しやすくなります。

• 受付：形式・認証情報の検証、加盟店・端末・カードの確認、金額・通貨・日時の確認。
• 判定：カード状態や利用可能額・回数、加盟店・MCC、地域・時間帯、不正スコアを組み合わせて判断する。
• 応答：承認・拒否・保留・要追加認証の結果を、所定の形式と時間内に返す。
• 記録：要求・応答、判定理由、参照した残高・枠、接続結果、操作・再送履歴を追跡できるように残す。

受付元は、APIや専用回線、CAFIS、CARDNETなどです。国際ブランドやPSPからの要求も受けます。判定では、カードの状態や3-Dセキュアの結果も判断材料になります。

取引IDや承認番号、加盟店IDなどの識別子は、システム全体で一貫して管理します。

ログは、必要な内容に絞って残します。

カード情報も必要以上に保存せず、マスキングや改ざん検知で守ります。

方式の比較：PSP・パッケージ・クラウド・スクラッチ

方式ごとに、どれくらい早く始められるかと、独自の要件にどこまで対応できるかが異なります。

• PSP・決済代行API：カード情報を自社環境に置かず、加盟店導入や新サービスの検証を始めやすい方式です。
• パッケージ：標準電文、カード状態、利用枠、監視の機能を活用できます。
• クラウド・スクラッチ：処理量や独自機能に合わせて構成を組めます。

パッケージでは、自社固有のルールをどこまで追加できるかと、保守期限を確認しておきます。一方、クラウドはピーク時の処理量やサービス追加に対応しやすい一方で、責任共有、鍵管理、データの所在、障害時の切替を設計する必要があります。

AWSは2025年12月にリファレンスを公開し、API Gateway、MSK、DynamoDB、EKS、Payment Cryptographyなどを使う構成を紹介しています。この構成は、毎秒数千件のトランザクションに拡張できる決済処理基盤です（出典：Amazon Web Services「AWSでのクレジットカード決済処理プラットフォームの構築」、2025年）。

クラウドを選んだ後も、PCI DSSへの準拠は別途確認が必要です。

オーソリシステム開発の進め方

開発は、現行業務と接続先を調べ、対象範囲とKPIを決めてから始めます。そのうえで、業務、データ、非機能の要件を固め、方式を選んだあと、設計、実装、試験を行い、移行と運用引き継ぎに進みます。

画面やAPIから先に作り始めると、判定ルールの責任者や障害時の扱いが決まらないまま進み、結合試験の前に手戻りが起きやすくなります。そこで、異常系も正常系と同じ粒度で設計します。

企画・要件定義での対象範囲と数値目標

要件定義では、まず立場と業務範囲をそろえ、そのうえで性能や運用の目標を決めます。

• 立場と接続範囲：加盟店、アクワイアラ、イシュア、PSP、カード会社の位置づけ。
• 業務範囲：ブランド、国内網、チャネル、カード種別、取引区分の整理。
• 機能範囲：本人認証、不正検知、売上確定、返金、請求、清算の扱い。
• 非機能目標：ピークTPSと応答時間を数値で定めます。稼働率、RTO、RPOも決めておきます。

イシュア側では、利用可能枠、残高、利用停止、会員状態、支払状況の正本も確認します。あわせて、対象システムと既存システムの境界を業務フローに示しておきます。

月間件数だけでなく、同時接続数や平均・最大応答時間も定義します。再送回数とログ保存期間も定めます。承認率と不正判定時間も、数値で押さえておきます。

「すぐ返す」「止めない」のような言い方は、そのままでは検証の基準になりません。そのため、応答や切替、許容データ損失を数値で表します。

運用、カード業務、セキュリティ、経理、法務の担当者は、要件定義の段階から参加させておきます。

経済産業省の2026年資料では、API未対応の事業者が新規に構築する場合、接続先が限られていても数億円規模の例が示されています。

一方、既存のAPI基盤への追加接続は、性能増強や大幅な変更がなければ数十万〜数千万円の例もあります（出典：経済産業省「クレジットカード分野に係るAPI連携の推進に係る検討会資料」、2026年）。この数字は、オーソリの一律価格ではなく、既存基盤の活用可否を調べる参考です。

設計・開発での電文と状態遷移

設計書には、処理の責務と、障害時の判断根拠を明記しておきます。

• 処理責務：受信、認証、トークン化、枠確認、リスク判定、記録、応答の区分。
• 接続・制御：ISO形式などの電文、回線、タイムアウト・鍵・証明書、再送・重複排除の定義。
• 運用設計：監視、アラート、運用画面、障害時の代行承認条件の決定。

状態は、受付、判定中、承認の段階に分けて扱います。拒否、タイムアウト、保留も状態として区別し、取消やリバーサルも別に扱います。加えて、売上確定や返金、期限切れも状態として管理します。

承認応答が届かず再送された場合は、取引IDや冪等性キーで同一の処理を見分けます。これにより、二重承認や残枠の二重減算を防げます。

タイムアウト時は、拒否とするか、照会で状態を確かめるか、リバーサルを送るかを、ブランドと接続先の仕様に合わせて決めます。

クラウドでは、APIゲートウェイ、ロードバランサ、コンテナ、メッセージング、分散DBを配置します。さらに、キャッシュやHSM、監視も置き、単一障害点を減らします。

TISとKort Valutaは2025年、AWS上での共同開発を公表しました（出典：TIS株式会社・株式会社Kort Valuta「決済システムの内製化に向けた共同開発を開始」、2025年）。

この事例は、TISのソフトウェアスタック「Lerna」を活用し、高可用性と高スループットを目指すものです。ただし、同社の検証結果は個別環境のもので、自社のSLAを保証する数字ではありません。そのため、発注時には自社の条件で性能試験を行います。

テスト・移行・リリースでの障害時の切替確認

試験から運用の引き継ぎまで、段階ごとに確認していきます。

1. 試験：単体、結合、総合、性能、セキュリティ、切替、受入の各試験。
2. 障害確認：2センター・複数リージョンの場合、片系停止などを試す。
3. 移行：一括切替を避け、低リスクのチャネルやカード種別から並行稼働する。
4. 運用移管：監視、障害連絡、鍵更新、脆弱性対応、教育の引き継ぎ。

試験では、正常な承認や拒否だけでなく、入力不備、期限切れカード、利用枠不足も再現します。また、リスク高判定、3-Dセキュア失敗、外部応答の遅延、ネットワーク分断、接続先停止も試します。

応答の重複、DB障害、監視通知の欠落も再現します。

実際のカード情報は使わず、マスキングやトークン化したデータで試します。

2センターや複数リージョンでは、通常時に加えて、片系停止、通信断、DB切替を確認します。キューの滞留と復旧後の再処理も見ます。次に、代行承認や縮退運転の条件、上限額、対象ブランドを定めます。

後から行う照合や解除の条件も決めておくと、復旧後の突合で不一致を見つけられます。そのためには、手動で訂正した履歴まで残せる状態にしておく必要があります。

移行では、カードや会員、利用可能枠の対応関係を整理します。加盟店や端末も対応づけ、取引と承認履歴の対応も押さえます。シャドートラフィック、カナリアリリース、日次照合、ロールバックといった方法を組み合わせます。

リリース後は、一次切り分けやブランド仕様変更への対応、運用教育までを含めて、引き継ぎを完了させます。

オーソリシステムの費用相場とコストの内訳

取扱高やカードブランド数だけで比べられる公開の定価は、ほとんどありません。そのため、2026年時点で、企画の初期に予算を置くための推定レンジを示します。

費用は、方式、取引量、ピークTPS、2センター、24時間運用、PCI DSSの対象範囲、レガシー基幹との連携によって変わるので、正式見積もりで精査します。

方式別の初期費用の幅

費用の幅をつかむには、接続規模と新規に構築する機能を分けて比べると分かりやすいです。初期費用は、PSP接続の300万円程度から、大規模刷新の数十億円以上まで広がります。

• PSP API接続：1つまたは少数の決済手段で、300万〜1,000万円程度です。
• 国内決済網接続：電文変換や接続試験を含み、1,000万〜3,000万円程度です。
• パッケージ・クラウド型：会員・枠・不正検知等を設定・追加開発し、2,000万〜8,000万円程度です。
• 自社判定基盤：判定・トークン化・枠・監視・BCPを新設し、5,000万円〜3億円程度です。
• 大規模刷新：複数センターや基幹刷新等を含み、数億円から数十億円以上です。

PSP接続の目安は、承認、取消、返金、Webhookと既存の会員・注文基盤との連携を行う場合のものです。

国内網接続には、障害時の再送、加盟店・端末の管理、接続試験も含みます。

どちらも、カード会社側の判定基盤や24時間365日の運用を新たに作らない前提です。

パッケージやクラウド型の目安は、会員、利用可能枠、不正検知、複数ブランド、基幹連携、管理画面を設定・追加開発する場合のものです。

自社で判定基盤を新設する場合、期間は12〜24か月以上になることがあります。大規模案件には、カード、会員、請求の刷新が含まれます。清算の刷新や国内外の接続も必要になり、24時間運用と監査対応まで求められます。

経済産業省の資料では、オープンAPI対応の専用システムについて、数十億〜100億円という意見も紹介されています。ただし、これはカード会社のAPI連携に近い領域の意見であり、オーソリの価格表ではありません（出典：経済産業省「第3回クレジットカード分野に係るAPI連携の推進に関する検討会」、2026年）。

費用の内訳：機能・接続・性能・セキュリティ・運用

見積書では、要件定義と基本設計、電文・API・専用回線の接続を別行にしておくと、内容を比べやすくなります。

• 初期費用：判定、枠・残高連携、トークン化、管理画面、監視・ログの各項目。
• 試験・移行：テスト環境、性能・セキュリティ試験、データ移行、リリース支援の各項目。
• 基盤・保守：クラウド、回線、DB、HSM、証明書、鍵管理、監視、接続料を含む費用。

「オーソリ機能一式」とある場合は、標準機能と追加開発の範囲、接続先、対象ブランドを確かめます。

ランニング費用には、ネットワークやDB、メッセージング、キャッシュ、不正検知サービスの費用も含まれます。小規模でも月額数十万円から始まりますが、ピーク処理や2センターを加えると、月額数百万円以上になる場合があります。

長期ログや24時間監視も、費用を押し上げます。

PCI DSS対応、脆弱性診断、ペネトレーションテスト、監査支援、ブランド仕様変更、OSやミドルウェアの更新は、初期開発費とは別の保守費用として見積もります。

PCI DSS v4.0.1の関連評価資料は、PCI Security Standards Councilの公式文書ライブラリに掲載されています。

カード会員データを保持・処理・伝送する範囲が広いほど、対象システム、権限、ログの負担が増えます。さらに、脆弱性対応や証跡作成の手間も重なります（出典：PCI Security Standards Council「PCI DSS v4.0.1」、2024年）。

自社でカード情報を保持しないトークン化構成であっても、専門家や決済事業者と、どこまでを誰が受け持つかや対象範囲を確認します。比べるときは、5年間の総保有コストで揃えます。

オーソリシステムの見積もりを取る際のポイント

見積もりの精度は、画面の詳細よりも、取引の流れと非機能要件がどこまで共有されているかで決まります。RFPには、対象範囲、カードブランド、接続先、月間とピークの取引件数、ピークTPSを記します。

見積もりの前提をそろえるため、RFPには応答時間と稼働率、RTO・RPOを数値で書きます。そのうえで、次の項目も前提として記載します。

• データ保管
• 既存基幹
• 移行対象
• 運用時間
• 予算上限

未確定の項目は、無理に決めず、調査やPoC、要件定義で確定する項目として分けておきます。

RFPに書く正常系・例外系と担当範囲

RFPでは、機能、例外、セキュリティの各要件と、その担当範囲をそろえて書きます。

• 機能：承認・拒否・保留・取消、返金・再送・照会、売上確定を含む要件。
• 例外：タイムアウト・重複・応答欠落、接続停止・データ不整合の定義。
• セキュリティ：暗号化・鍵・権限、MFA・診断、バックアップ・監査証跡の記載。

機能要件では、追加認証やリバーサル、利用可能枠の戻し、取引照合、手動訂正、管理者承認の扱いを決めておきます。

例外要件では、遅延応答や電文不備、カード会社の停止、監視通知の失敗を想定します。そのうえで、ケースごとに、最終状態を決めるシステム、手動で対応する担当者、何分以内に通知するかを定めます。

トークン化やHSMも要件に含め、鍵の生成、保管、更新の方法を決めておきます。

特権IDの扱いとログの改ざん検知を決めたうえで、脆弱性診断とペネトレーションテストを行います。

経済産業省は2025年3月に「クレジットカード・セキュリティガイドライン」を改訂しました。同ガイドラインは、関係事業者の情報保護や不正利用対策を示しています（出典：経済産業省「『クレジットカード・セキュリティガイドライン』が改訂されました」、2025年）。

開発会社だけに責任を負わせず、自社、PSP、カード会社、クラウド、評価機関で分担し、その内容をRFPに書きます。

発注先の比較観点：決済接続・基幹・運用の実績

候補会社には、接続、性能、障害対応、移行後の体制について、同じ条件で質問します。

• 接続実績：CAFIS、CARDNET、国際ブランド、PSPとの接続経験。
• 基幹・性能：イシュア・アクワイアラ対応、類似TPS、応答SLAの確認。
• 運用・移行：2センター、代行処理、基幹連携、障害訓練の確認。

既存のメインフレームや会計基盤との連携実績も質問します。ただし、公開された事例が、自社のカード種別や取引量にそのまま当てはまるとは限りません。そこで、匿名化された範囲で、性能試験の条件、障害訓練、移行期間、リリース後の体制を確かめます。

パッケージやクラウドでは、標準機能と設定、追加開発、外部サービスを分けて示してもらいます。ライセンス、従量課金、保守、終了時のデータ移行も、別項目として確認します。

スクラッチでは、独自化が必要な範囲と、将来のブランド追加や法令改定に伴う保守の担当を確かめます。

契約については、準委任、請負、ライセンス、マネージドサービスを区別したうえで、追加費用の条件を記載します。

安い見積もりの除外項目と障害時の対応

価格差の理由をつかむには、見積もりの前提と、検証の進め方を順に確かめます。

1. 対象外確認：性能試験、障害切替、移行、監視、保守、診断、教育、仕様変更との照合。
2. 事前検証：調査やPoCで、接続や性能、トークン化、障害時の整合性を試す。
3. 段階移行：低リスクから移行し、指標と復旧体制を確かめる。

他社より大幅に安い場合は、機能の差よりも、対象範囲の違いが価格差の理由かもしれません。

「標準API接続」に、タイムアウト、再送、重複、リバーサル、仕様変更、証明書更新が含まれるかを確かめます。

見積比較表では、各社の前提条件と対象外項目を同じ列に並べます。

段階移行では並行稼働を行い、承認率や応答時間に加えて、タイムアウト率、再送率、突合差異、障害復旧時間も見ます。

費用だけでなく、失敗時に戻れる設計と、運用担当者が判断できる体制も、発注条件に含めます。

オーソリシステム開発でよくある質問

加盟店の決済導入、FinTechのカード発行、カード会社の基幹刷新では、必要な範囲がそれぞれ異なります。よくある疑問ごとに、判断の目安を示します。

オーソリシステムはPSPと自社開発のどちらがよいですか？

方式は、開始時期と自社で担う機能に応じて選びます。

• PSP・決済代行API：短期間で決済を開始し、標準的な承認・取消・返金を使う場合の選択肢。
• パッケージ・クラウド：独自の利用枠などが必要な場合に、基盤へ追加開発する方式。
• 自社開発：カード発行、複雑な判定、複数ブランド、差別化が必要な場合の検討対象。
• ハイブリッド方式：競争力に直結する機能は独自化し、接続や標準処理は外部に任せる。

オーソリシステムの開発費用は最低いくらですか？

費用は接続範囲や新たに構築する機能によって変わります。

• PSP API接続：既存会員・注文基盤を使う場合、300万〜1,000万円程度が初期目安です。
• 国内網などを含む開発：複数ブランド、利用枠、不正検知を含めると1,000万円から数億円以上です。
• 大規模構成：2センター、データ移行、24時間運用を含める場合も数億円以上まで広がります。

正式見積もりを依頼する際は、ブランド、接続先、ピークTPS、既存基盤、セキュリティ、運用時間の条件を伝えます。そのうえで、初期費用と5年間の運用費を分けて見積もってもらいます。

クラウドでオーソリシステムを開発しても安全ですか？

クラウドでも安全性と高可用性は設計できます。ただし、採用しただけで安全になるわけではありません。

• カード情報の保護：保持・処理・伝送の範囲を縮め、トークン化、暗号化、HSMを使う。
• 運用対策：アクセス制御、MFA、脆弱性管理、監視、バックアップ、障害切替の整備と、監査証跡の保存。
• 責任の分担と訓練：PCI DSSの対象範囲の確認、自社条件での性能試験と復旧訓練。

クラウド事業者、PSP、開発会社、自社の受け持ち範囲を、それぞれ確かめます。

オーソリシステムの開発期間はどのくらいですか？

期間の目安は、方式と対象範囲によって異なります。

• PSP・ゲートウェイ：限定接続は2〜4か月、国内網や複数連携は4〜8か月が目安です。
• パッケージ・クラウド型：プロセッサ導入は6〜12か月程度が目安です。
• 自社判定基盤：複数ブランド、BCP、移行、24時間運用を含むと12〜24か月以上の場合があります。

期間は、開発人数だけでなく、接続先の認定試験やセキュリティ評価によっても決まります。並行稼働や切替リハーサルの日程も、期間を左右します。

まとめ

オーソリシステムの開発では、承認・拒否を返すAPIに加えて、周辺機能との関係まで見る必要があります。まず対象をPSP接続、加盟店向けゲートウェイ、アクワイアラ側、イシュア側に分け、周辺機能との担当範囲を決めます。

性能、可用性、セキュリティ、障害時の状態遷移、運用体制を数値化してから、方式を選びます。

開発前に一枚へまとめるべき項目

合意した事項を一枚にまとめ、関係者間で判断基準をそろえておきます。

• 処理条件：ブランド、チャネル、月間件数、ピークTPS、応答時間、稼働率の数値。
• データ・状態：カード情報、枠の正本、承認・拒否・保留・取消・リバーサルの定義。
• 運用・移行：RTO・RPO、接続先、2センター、移行範囲、監視時間の記載。

正常系と異常系を同じ粒度で書き、最終判断者と記録するログまで合意しておきます。

見積もりの依頼：初期費用と5年間の運用費の分け方

見積項目を分けておくと、方式間を比べやすく、将来の費用も把握できます。

• 初期開発：接続、性能試験、障害切替、評価、移行、並行稼働の区分。
• 継続運用：監視、保守、仕様変更、PCI DSS対応を含む範囲。
• 終了時：データやトークンの移行条件の確認。

300万円程度のAPI連携と、数億円以上の基幹刷新は、同じ条件では比較できません。そこで、既存の資産を活用し、独自化する範囲を絞って段階的に検証すると、承認率と安全性を保ちながら、開発リスクを抑えやすくなります。

▼全体ガイドの記事
・オーソリシステム開発の完全ガイド

▼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を創業。