JP2007213305A - 決済処理装置、決済処理方法、及びプログラム - Google Patents

Abstract

【課題】複数の加盟店から、複数の金融機関に対する決済処理をプロトコルや変数に影響されずに行うことが可能な決済処理装置を提供する。
【解決手段】決済処理装置１は、加盟店端末装置１１−１から送られる決済要求情報であるリクエスト電文２９を受信する。決済処理装置１は、記憶部１７に格納する加盟店別定義ファイル１９と銀行別定義ファイル２１を参照して、加盟店端末装置１１−１で扱うデータの情報形態（変数の数、型、桁数、単位等）を、指定される銀行サーバ１３−１が扱う情報形態に変換する。決済処理装置１は、変換したデータに改竄検証用のハッシュ値を付加してリクエスト電文３１を生成し、銀行サーバ３−１に送信する。加盟店３は決済処理装置１を介することで、独自の決済システムを構築することなく、指定する金融機関での決済処理を行うことができる。
【選択図】図１

Description

本発明は、複数の加盟店が、複数の金融機関において行う決済処理を媒介する決済処理装置に関する。

現在、オンラインショッピングシステムや証券会社のオンライントレーディングシステム等は決済処理を行う際に、銀行等の提携金融機関のオンラインバンキングシステムを利用して決済処理を行っている。オンラインショッピングシステムや証券会社のオンライントレーディングシステム等はそれぞれのＷＥＢサイトを有し、ユーザとの間で商品の売買を行う際に、複数の提携金融機関のオンラインバンキングシステムでの決済処理環境をユーザに対して提供する。

オンラインショッピングシステムや証券会社のオンライントレーディングシステム等は、各々の独自のシステム内で使用する決済処理に関する変数等を、それぞれの提携金融機関の扱う変数に変換し、提携金融機関のオンラインシステムに適合するデータ仕様に変換して決済処理を行っていた。

各提携金融機関との間の送受信データには決済情報が含まれるため、データには暗号化が施される。暗号化方法は金融機関毎に採用するプロトコルが異なり、例えばＭＤ５（Ｍｅｓｓａｇｅ Ｄｉｇｅｓｔ ５）、３ＤＥＳ（Ｔｒｉｐｌｅ ＤＥＳ）、ＳＳＬ（Ｓｅｃｕｒｅ Ｓｏｃｋｅｔ Ｌａｙｅｒ）等の暗号化方式が用いられる。従って、オンラインショッピングシステムや証券会社のオンライントレーディングシステム等は、金融機関毎に暗号化のプロトコルの設定を行っていた。

ＸＭＬ言語（ｅＸｔｅｎｓｉｂｉｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）で共通のフォーマットを定義することで複数のサービス提供者（例えば証券会社のオンライントレーディングサイト）間で情報の共有を可能とし、各サービス提供者に変換された情報を異なるインターフェースで表現することを可能にしたオンライン証券システムがある（特許文献１）。即ちサービス提供者は独自にトレーディングサーバを開発する必要性がなくなり、サービス提供者は独自のインターフェースのデザインとそれへ変換する手段を開発するのみで、取引者に対しては独自のオンライン証券システムを構築しているかのように見せることができる。

特開２００２−２３０２９０号公報

しかしながら、特許文献１のオンライン証券システムは、トレーディングシステムのインターフェース（ＷＥＢサイトのデザイン等）が異なっても、情報変換手段により内部の情報の共有化を行うものであり、各種金融機関のオンラインバンキングを利用した決済方法におけるシステムの共通化については言及されていない。

また、従来のオンラインショッピングシステムや証券会社のオンライントレーディングシステム等は、それぞれ独立したシステムにおいて、決済方法をそれぞれの提携先の金融機関毎に構築する必要があり、システムが複雑化し、システム構築にもコストがかかるという問題点があった。

また、オンラインショッピングシステムや証券会社のオンライントレーディングシステム等は提携先の金融機関が増えると、その度に当該金融機関が採用するプロトコルや変数（パラメータ）に対応するシステムを追加構築しなくてはならないという問題点がある。

本発明は、このような問題を鑑みてなされたもので、その目的とするところは、複数の加盟店からの、複数の金融機関に対する決済処理をプロトコルや変数に影響されずに行うことが可能な決済処理装置を提供することである。

前述した目的を達成するための第１の発明は、複数の加盟店側に属する端末装置と複数の金融機関側に属する金融機関サーバとにネットワークを介して接続され、前記端末装置と前記金融機関サーバとの間における決済要求情報及び決済応答情報を含む決済情報を処理する決済処理装置であって、前記加盟店ごとの前記決済情報の仕様を含む加盟店定義ファイルと前記金融機関ごとの前記決済情報の仕様を含む金融機関定義ファイルとを保持する保持手段と、前記加盟店定義ファイルと前記金融機関定義ファイルとを参照して、前記端末装置から送られる前記決済要求情報を前記端末装置が指定する前記金融機関サーバが利用可能な情報形態に変換して当該金融機関サーバに送信する第１の変換送信手段と、前記加盟店定義ファイルと前記金融機関定義ファイルとを参照して、前記金融機関サーバから送られる前記決済応答情報を前記端末装置が利用可能な情報形態に変換して当該端末装置に送信する第２の変換送信手段と、を具備することを特徴とする決済処理装置である。

加盟店とは、インターネット等のネットワークを利用するオンラインショッピングシステム提供会社やオンライントレーディングシステムを提供する証券会社等を想定する。加盟店は、ネットワークを介して決済処理を行う際に、銀行等のオンラインバンキングシステムに接続して決済処理を行う。

金融機関は、銀行、郵便局等のオンラインバンキングシステムを備える金融機関であることを想定する。当該金融機関にネットワークを介して接続して決済処理を行う際には、決済データの安全確保のため送受信データには暗号化処理を施す必要がある。各金融機関は暗号化方式を独自に採用し、更に決済処理に使用する変数（パラメータ）やその条件（桁数、変数の型、単位等）も独自に設定している。

決済要求情報は、加盟店から金融機関に送られる決済処理を要求する情報であり、金融機関名、商品の単価、商品の数、金額、決済日時等の情報が含まれる。

決済応答情報は、加盟店からの決済要求情報に対して金融機関から加盟店に返される情報である。決済応答情報には決済処理の結果に関する情報が含まれる。

加盟店定義ファイルは、加盟店毎の当該加盟店に関する情報（加盟店名、電話番号、住所、代表者名、加盟店を識別するための加盟店ＩＤ、加盟店のアクセス先ＵＲＬ等の情報）、決済情報の仕様（加盟店が決済処理に使用する変数の型、桁数、単位等の情報と、当該決済システム１で使用する変数との変換表）等を含む。

金融機関定義ファイルは、金融機関毎の当該金融機関に関する情報（金融機関名、電話番号、住所、代表者名、金融機関を識別するための金融機関ＩＤ、金融機関のアクセス先ＵＲＬ、リダイレクト先ＵＲＬ、プロトコル、暗号化方式、改竄検出のためのハッシュ値生成規則、タイムアウト等の情報）、決済情報の仕様（加盟店が決済処理に使用する変数の型、桁数、単位等の情報と、当該決済システム１で使用する変数との変換表）等を含む。

情報形態とは、送受信される情報のプロトコルや暗号化方式、決済情報の送受信データに使用する変数の数や、変数の型・桁数・単位等である。

第１の発明による決済処理装置は、加盟店ごとの決済情報の仕様を含む加盟店定義ファイルと金融機関ごとの決済情報の仕様を含む金融機関定義ファイルとを保持し、加盟店定義ファイルと金融機関定義ファイルとを参照して、端末装置から送られる決済要求情報を端末装置が指定する金融機関サーバが利用可能な情報形態に変換して当該金融機関サーバに送信し、加盟店定義ファイルと金融機関定義ファイルとを参照して、金融機関サーバから送られる決済応答情報を端末装置が利用可能な情報形態に変換して端末装置に送信する。

前記加盟店定義ファイル及び前記金融機関定義ファイルは、決済処理に必要な変数データに関する情報を含み、前記第１の変換送信手段及び前記第２の変換送信手段は、前記加盟店定義ファイルまたは前記金融機関定義ファイルを参照して、前記決済情報から決済処理に必要な変数データを抽出し、当該抽出した変数データについて前記金融機関サーバまたは前記端末装置が利用可能な情報形態に変換して送信することが望ましい。
変数データは、決済処理に必要な変数と値である。

前記加盟店定義ファイル及び前記金融機関定義ファイルは、それぞれ、前記加盟店が使用する変数データまたは前記金融機関が使用する変数データと、内部処理用変数データと、の対応付けに関する情報を含み、前記第１の変換送信手段及び前記第２の変換送信手段は、前記内部処理用変数データを介して、前記加盟店が使用する変数データと前記金融機関が使用する変数データとの間の変換を行うことが望ましい。

前記加盟店定義ファイル及び前記金融機関定義ファイルは、前記加盟店毎または前記金融機関毎に改竄検出用のハッシュ値の算出規則に関する情報を含み、前記加盟店定義ファイルまたは前記金融機関定義ファイルの前記ハッシュ値算出規則を参照して送信情報に基づいて生成したハッシュ値を前記送信情報に付して送信するハッシュ値生成送信手段と、前記加盟店定義ファイルまたは前記金融機関定義ファイルの前記ハッシュ値算出規則を参照して受信情報に基づいて生成したハッシュ値と、前記受信情報から検出したハッシュ値と、を比較して検証するハッシュ値検証手段とを具備することが望ましい。
ハッシュ値は、所定のデータから生成される一意の固定長の数値であり、所定のハッシュ値算出規則に基づいて生成される。同一のデータについて送信前に算出するハッシュ値と、ネットワーク等を介して受信された後に算出するハッシュ値とを比較してデータの改竄の有無を検証することができる。

前記加盟店と前記金融機関との間で授受される一連の前記決済情報には、同一の決済識別情報が付与されることが望ましい。
決済識別情報は、一連の送受信データに付与される同一の情報であり、例えば注文番号やＷＥＢアプリケーションが発行するセッションＩＤやハッシュ値等を決済識別情報として用いても良い。

本発明による決済処理装置は、加盟店毎の定義ファイルと金融機関毎の定義ファイルを参照して、加盟店で扱う情報形態と金融機関扱う情報形態とを変換することで、加盟店が独自の複雑なシステムを構築することなく、当該決済処理装置を介することで、指定する金融機関での決済処理を簡単に行うことを可能にする。

第２の発明は、複数の加盟店側に属する端末装置と複数の金融機関側に属する金融機関サーバとにネットワークを介して接続され、前記端末装置と前記金融機関サーバとの間における決済要求情報及び決済応答情報を含む決済情報を処理する決済処理装置が実行する決済処理方法であって、前記加盟店ごとの前記決済情報の仕様を含む加盟店定義ファイルと前記金融機関ごとの前記決済情報の仕様を含む金融機関定義ファイルとを保持する保持ステップと、前記加盟店定義ファイルと前記金融機関定義ファイルとを参照して、前記端末装置から送られる前記決済要求情報を前記端末装置が指定する前記金融機関サーバが利用可能な情報形態に変換して当該金融機関サーバに送信する第１の変換送信ステップと、前記加盟店定義ファイルと前記金融機関定義ファイルとを参照して、前記金融機関サーバから送られる前記決済応答情報を前記端末装置が利用可能な情報形態に変換して当該端末装置に送信する第２の変換送信ステップと、を具備することを特徴とする決済処理方法である。

第２の発明は、決済処理装置が実行する決済処理方法に関する発明である。

第３の発明は、コンピュータを第１の発明の決済処理装置として機能させるプログラムである。
尚、上記のプログラムをＣＤ−ＲＯＭ等の記録媒体に保持させて流通させてもよいし、このプログラムを通信回線を介して送受することもできる。

本発明によれば、複数の加盟店から、複数の金融機関に対する決済処理をプロトコルや変数に影響されずに行うことが可能な決済処理装置を提供することができる。

以下に、図面に基づいて本発明の実施の形態を詳細に説明する。最初に図１及び図２を参照しながら、本発明の実施の形態に係る決済処理装置１の機能の概略について説明する。

（１．決済処理装置１の構成）
（１−１．機能の概略構成）
図１および図２は、決済処理装置１の機能の概略を示す図である。
図１は、決済処理装置１が加盟店端末装置１１−１から送信される決済要求情報（リクエスト電文２９）を受信し、銀行５−１が扱う情報形態を有する決済要求情報（リクエスト電文３１）に変換して当該銀行５−１宛に送信する機能を示す。

加盟店３−１〜３−ｍは、オンラインショッピングシステム提供会社やオンライントレーディングシステムを提供する証券会社等である。ユーザ７は加盟店３−１〜３−ｍが提供するＷＥＢサイト等を利用して商品等を購入する顧客である。ユーザ端末装置９、加盟店端末装置１１−１〜１１−ｍ、決済処理装置１、銀行サーバ１３−１〜１３−ｎは、コンピュータ等の情報処理装置である。ユーザ７は、ユーザ端末装置９を加盟店３−１の加盟店端末装置１１−１にネットワーク等を介して接続し、オンラインシステムを利用して商品の購入発注や決済要求を行う。

コンピュータ等の情報処理装置から成る決済処理装置１のハードウェア構成の詳細については後述する（図３参照）。決済処理装置１はＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）等の中央処理装置からなる制御部１５と、ＨＤＤ（Ｈａｒｄ Ｄｉｓｃ Ｄｒｉｖｅ）等の記憶部１７を備える。図１に示す制御部１５は、電文受信手段２２、パラメータ取得手段２３、ハッシュ値生成手段２５、及び電文作成送信手段２７等の機能を備える。記憶部１７は、内容の詳細については後述するが、加盟店別定義ファイル１９と銀行別定義ファイル２１等を備える。

決済処理装置１は、加盟店端末装置１１−１から送信される決済要求情報であるリクエスト電文２９を電文受信手段２２で受信する。パラメータ取得手段２３は、記憶部１７に格納する加盟店別定義ファイル１９と銀行別定義ファイル２１を参照して、リクエスト電文２９に含まれる決済情報に関連する変数（パラメータ）やデータ値を、指定された銀行５−１で使用可能な変数（パラメータ）やデータ値に変換する。

ハッシュ値生成手段２５は、後述するハッシュ値生成規則を用いて、指定された銀行５−１宛に生成される決済要求情報から、改竄検出用のハッシュ値を生成する。電文作成送信手段２７は、当該ハッシュ値を付加した決済要求情報をリクエスト電文３１として生成し、指定された銀行５−１の銀行サーバ１３−１宛に送信する。

図２は、決済処理装置１が、加盟店３−１側からの決済要求情報であるリクエスト電文３１（図１参照）に対して銀行サーバ１３−１から返される決済応答情報（レスポンス電文３９）を受信し、当該加盟店３−１の加盟店端末装置１１−１が扱う情報形態を有する決済応答情報（レスポンス電文４１）に変換して当該加盟店端末装置１１−１宛に送信する機能を示す。

銀行サーバ１３−１は、加盟店端末装置１１−１から送られる決済要求情報であるリクエスト電文３１（図１参照）を受信し、決済処理を実施した後、決済応答情報（レスポンス電文３９）を作成して決済処理装置１に送信する。決済応答情報とは、例えば「決済終了」、「決済内容確認の必要あり」等の、決済処理の結果に関する情報である。

図２に示す決済処理装置１の制御部１５は、電文受信復号手段３３、ハッシュ値抽出手段３５、ハッシュ値生成手段２５、ハッシュ値検証手段３７、パラメータ取得手段２３、及び電文作成送信手段２７等の機能を備える。

決済処理装置１の制御部１５は、銀行サーバ１３−１から送信される決済応答情報であるレスポンス電文３９を電文受信復号手段３３で受信し、暗号化されているレスポンス電文３９を復号する。

ハッシュ値抽出手段３５は、受信し復号したレスポンス電文３９中から付加されているハッシュ値を抽出する。ハッシュ値生成手段２５は、受信し復号したレスポンス電文３９から後述するハッシュ値生成規則を基にして、ハッシュ値を生成する。ハッシュ値検証手段３７は、抽出されたハッシュ値と、生成したハッシュ値とを比較検証する。同一のハッシュ値が得られた場合は、レスポンス電文３９に通信中の事故（改竄等）がなかったものと判定することができる。

パラメータ取得手段２３は、記憶部１７の加盟店別定義ファイル１９と銀行別定義ファイル２１を参照して、レスポンス電文３９に含まれる決済情報に関連する変数（パラメータ）やデータ値を、返信先の加盟店端末装置１１−１で使用可能な変数（パラメータ）やデータ値に変換する。電文作成送信手段２７は、決済応答情報として生成されたレスポンス電文４１を加盟店端末装置１１−１宛に送信する。

（１−２．決済処理装置１のハードウェア概略構成）
次に、決済処理装置１のハードウェアの概略構成について説明する。図３は、決済処理装置１のハードウェアの概略構成を示す図である。

決済処理装置１は、メディアドライブ装置等の出力部４３又は入力部４５と、ＣＲＴや液晶画面等の表示装置からなる表示部４７と、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）等のメモリ４９と、中央処理装置（ＣＰＵ）等の制御部１５と、ネットワークに接続するモデムやＬＡＮボード等の通信部５１と、ＨＤＤ（Ｈａｒｄ Ｄｉｓｃ Ｄｒｉｖｅ）等の記憶部１７等と、から構成され、それぞれがシステムバス５３で接続されている。尚、出力部４３として外部記憶装置、印刷装置等が接続されていても良い。また入力部４５として、キーボード、マウス等が接続されていても良い。

決済処理装置１の通信部５１は、ネットワーク５５を介して加盟店３−１〜３−ｍの加盟店端末装置１１−１〜１１−ｍと接続される。また、加盟店３−１を利用するユーザ７のユーザ端末装置９は、加盟店３−１の加盟店端末装置１１−１と接続され、ユーザ７は加盟店３−１の提供する商品やサービスを購入する。尚、ユーザ端末装置９と加盟店端末装置１１−１は、ネットワーク５５を介して接続するようにしても良い。

また、決済処理装置１の通信部５１は、ネットワーク５５を介して銀行５−１〜５−ｎの銀行サーバ１３−１〜１３−ｎと接続される。決済処理装置１は加盟店端末装置１１−１〜１１−ｍから決済要求情報を受信すると、加盟店３の指定する銀行５の仕様に変換した決済要求情報を、当該銀行５宛に送信し、当該銀行５が処理した決済応答情報を、決済要求情報を送った当該加盟店３の仕様に変換して当該加盟店３に返信する。

決済処理装置１の制御部１５は、図１及び図２に示した電文受信手段２２と、パラメータ取得手段２３と、ハッシュ値生成手段２５と、電文作成送信手段２７と、電文受信復号手段３３と、ハッシュ値抽出手段３５と、ハッシュ値検証手段３７等の機能を実行する。

制御部１５は、ＨＤＤ（記憶部１７）、ＲＯＭ（メモリ４９）、又は記録媒体等に格納される実行プログラム、ＯＳ（オペレーションシステム）のプログラム、アプリケーションプログラム等をメモリ４９のＲＡＭ上のワークメモリ領域に呼び出して実行し、演算処理（四則演算や比較演算等）等を行い、上記機能を実現する。

記憶部１７は、ＨＤＤ等の記憶装置であり、各種プログラム（実行プログラムやアプリケーションプログラム等）やデータファイル等を格納する。図１及び図２に示すように、記憶部１７は、加盟店別定義ファイル１９と銀行別定義ファイル２１を格納する。

（２．加盟店別定義ファイル１９と銀行別定義ファイル２１）
加盟店別定義ファイル１９と銀行別定義ファイル２１の詳細について図４及び図５を用いて説明する。

（２−１．加盟店別定義ファイル１９）
図４は加盟店別定義ファイル１９の内容の詳細を示す図である。加盟店別定義ファイル１９は、加盟店３ごとの加盟店に関する情報、使用する変数の変換に関する情報等を含む。例えば加盟店３−１の定義ファイル１９−１では、加盟店に関する情報として、加盟店ＩＤ５６、アクセス先ＵＲＬ５７等の情報の他、加盟店名、電話番号、メールアドレス、代表者名、住所等の情報を格納しても良い。

使用する変数の変換に関する情報としては、加盟店３−１で使用するパラメータ（変数）と、決済処理装置１内で使用するパラメータとの変換規則が、加盟店３−１から受信する受信パラメータの変換規則５８と、加盟店３−１へ送信する送信パラメータの変換規則５９として格納される。

例えば受信パラメータの変換規則５８（図４参照）では、加盟店３−１から送られる決済要求情報に使用される変数「ｉｔｅｍ」は決済処理装置１内では変数「ｔｍｐ．ｓｙｏｈｉｎ」に対応する。同様に変数「ｎｕｍ」は「ｔｍｐ．ｋｏｓｕ」に、変数「ｍｏｎｅｙ」は「ｔｍｐ．ｋｉｎｇａｋｕ」に対応する。

例えば送信パラメータの変換規則５９（図４参照）では、加盟店３−１に送信する決済応答情報に使用する変数「ｒｅｓｕｌｔ」は決済処理装置１内の変数「ｔｍｐ．ｋｅｋｋａ」に対応し、同様に変数「ｓｔａｔｕｓ」は変数「ｔｍｐ．ｊｏｕｔａｉ」に対応する。

また、使用する変数の変換に関する情報は、使用する変数の型や桁数や単位に関する情報を含む。例えば加盟店３−１から受信する受信パラメータの変換規則５８では、「ｉｔｅｍ（ｃｈｒ、４０）」は、変数名「ｉｔｅｍ」が最大４０桁の文字変数（ｃｈｒ）であることを示す。例えば変数名「ｉｔｅｍ」は、商品名が格納される。
「ｎｕｍ（ｉｎｔ、６）」は、変数名「ｎｕｍ」が最大６桁の整数であることを示す。例えば変数名「ｎｕｍ」は、決済処理商品の注文個数を示す。
「ｍｏｎｅｙ（ｉｎｔ、８）」は、変数名「ｍｏｎｅｙ」が最大８桁の整数であることを示す。例えば変数名「ｍｏｎｅｙ」は、決済処理を行う商品の注文金額を示す。

（２−２．銀行別定義ファイル２１）
図５は銀行別定義ファイル２１の内容の詳細を示す図である。銀行別定義ファイル２１は、銀行５ごとの銀行に関する情報、使用する変数の変換に関する情報等を含む。例えば銀行５−１の定義ファイル２１−１では、銀行に関する情報として、銀行を識別する銀行ＩＤ６１、プロトコル６２、送受信データを暗号化するための暗号化方式６３、改竄検証に使用するハッシュ値算出のためのハッシュ値生成規則６４、ブラウザアクセス方式６５、アクセス先ＵＲＬ６６、リダイレクト先ＵＲＬ６７、タイムアウト６８等の情報の他、銀行名、電話番号、メールアドレス、代表者名、住所等の情報を格納しても良い。

使用する変数の変換に関する情報としては、銀行５−１で使用するパラメータ（変数）と、決済処理装置１内で使用するパラメータの変換規則が、銀行５−１へ送信する送信パラメータの変換規則６９と、銀行５−１から受信する受信パラメータの変換規則７１として格納される。

例えば送信パラメータの変換規則６９（図５参照）では、銀行５−１に送る決済要求情報に使用される変数「ｓｅｎｄｐａｒａｍ．Ａ」は決済処理装置１内では変数「ｔｍｐ．ｓｙｏｈｉｎ」に対応する。同様に変数「ｓｅｎｄｐａｒａｍ．Ｂ」は「ｔｍｐ．ｋｏｓｕ」に、変数「ｓｅｎｄｐａｒａｍ．Ｃ」は「ｔｍｐ．ｋｉｎｇａｋｕ」に対応する。

例えば受信パラメータの変換規則７１（図５参照）では、銀行５−１から送信される決済応答情報に使用される変数「ｒｅｃｅｉｖｅｐａｒａｍ．Ａ」は、決済処理装置１内の変数「ｔｍｐ．ｋｅｋｋａ」に対応し、同様に変数「ｒｅｃｅｉｖｅｐａｒａｍ．Ｂ」は変数「ｔｍｐ．ｊｏｕｔａｉ」に対応する。

尚、図５のプロトコル６２とは、「ｈｔｔｐ」又は「ｈｔｔｐｓ（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ Ｓｅｃｕｒｉｔｙ）」の選択を示す。「ｈｔｔｐｓ」はデータ送受信用のプロトコルであるＨＴＴＰにＳＳＬ（Ｓｅｃｕｒｅ Ｓｏｃｋｅｔ Ｌａｙｅｒ）によるデータの暗号化機能を付加したプロトコルであることを示す。
ネットワーク５５として専用線等を用いる場合には、ｈｔｔｐプロトコルを用いてもよいが、ネットワーク５５としてインターネット等の公衆回線を用いる場合には、ｈｔｔｐｓプロトコルを用いることが望ましい。

暗号化方式６３の項目は、送受信データの暗号化方式を示す。３ＤＥＳ（Ｔｒｉｐｌｅ ＤＥＳ）、ＭＤ５（Ｍｅｓｓａｇｅ Ｄｉｇｅｓｔ ５）、ＳＳＬ（Ｓｅｃｕｒｅ Ｓｏｃｋｅｔ Ｌａｙｅｒ）等のうちのいずれかが設定される。

ハッシュ値は、所定のデータから生成される一意の固定長の数値であり、ネットワーク等を介して送信されたデータの整合性を検証する値として用いられる。ハッシュ値生成規則６４は、ハッシュ値を生成する演算規則を設定する項目である。ハッシュ値生成規則６４は、ハッシュ値算出の元になるデータ範囲の指定や算出方法などを規定したものである。共通のハッシュ値生成規則６４を利用して、受信データのハッシュ値と送信前のデータのハッシュ値とを比較することでデータが改竄されているかどうかを判定することができる。

ブラウザアクセス方式６５とは、ハンドオフ方式とリダイレクト方式のいずれかの選択を示す項目である。本実施の形態における「ハンドオフ方式」とは、加盟店３−１と銀行５−１間の決済処理（決済要求情報と決済応答情報）のやりとりを、決済処理装置１がその都度媒介して行う方式である。「リダイレクト方式」とは、加盟店３−１からの決済処理が銀行５−１側からの制御に変更され、決済処理が終了するまでは加盟店３−１と銀行５−１が直接やりとりを行う方式である。従って、アクセス先ＵＲＬ６６は銀行５−１のＵＲＬが格納され、リダイレクト先ＵＲＬ６７には、加盟店３−１にリダイレクトされる銀行５−１の決済処理サイトのＵＲＬが格納される。

タイムアウト６８の項目には、タイムアウト時間（例えば１８０秒）が設定される。例えば銀行サーバ１３−１と決済処理中のユーザ７のユーザ端末装置９が操作されることなく所定の時間（設定されいてるタイムアウト時間）放置された場合に、データの安全性確保のためユーザ端末装置９と銀行サーバ１３−１との接続が切断される。

（３．決済処理装置１の処理手順）
次に、図６、図７を用いて本実施の形態における決済処理装置１の処理手順について説明する。尚、図１乃至図５を適宜用いて説明する。
図６は、決済処理装置１の加盟店端末装置１１−１からの決済受付処理を示すフローチャートである。
図７は、決済処理装置１が銀行サーバ１３−１から取得する決済通知の処理を示すフローチャートである。

（３−１．決済受付処理）
図６を参照して決済処理装置１における加盟店端末装置１１からの決済受付処理について説明する。
例えば加盟店３−１がオンライントショッピングサイトを有する加盟店であるとする。ユーザ７はコンピュータ等のユーザ端末装置９を当該加盟店３−１のオンラインショッピングサイトに接続し、所定の商品購入を決定して、決済処理を行うものとする。加盟店端末装置１１−１は、ユーザ７のユーザ端末装置９から決済処理要求を受けると、当該決済処理要求を含むリクエスト電文２９を生成し、決済処理装置１に送信する（ステップ１００１）。

リクエスト電文２９（図６参照）には、決済処理装置１のＵＲＬ、決済を行う銀行の銀行ＩＤ、加盟店ＩＤ、及び決済内容を示す変数「ｉｔｅｍ」、「ｎｕｍ」、「ｍｏｎｅｙ」とその値が含まれる。例えば、変数「ｉｔｅｍ」、「ｎｕｍ」、「ｍｏｎｅｙ」はそれぞれ加盟店端末装置１１−１が「商品名」、「商品個数」、「決済金額」として扱う変数でありそれぞれに値が格納される。

決済処理装置１の制御部１５の電文受信手段２２（図１参照）は、加盟店端末装置１１−１から送られるリクエスト電文２９を受信する。制御部１５のパラメータ取得手段２３（図１参照）は、記憶部１７の加盟店別定義ファイル１９（図１参照）の加盟店３−１の定義ファイル１９−１（図４）からパラメータを取得しリクエスト電文２９の変数を変換する（ステップ１００２）。即ち、パラメータ取得手段２３は、加盟店３−１の加盟店ＩＤ５６「ＳＰ００１」を参照して加盟店３−１の定義ファイル１９−１を抽出する。また、パラメータ取得手段２３は、受信パラメータの変換規則５８（図４）を参照して加盟店３−１から送られる決済要求情報に使用される変数を決済処理装置１内で使用する変数に変換する。即ち、パラメータ取得手段２３は、「ｉｔｅｍ→ｔｍｐ．ｓｙｏｈｉｎ」、「ｎｕｍ→ｔｍｐ．ｋｏｓｕ」、「ｍｏｎｅｙ→ｔｍｐ．ｋｉｎｇａｋｕ」の変換を行う。

次に、パラメータ取得手段２３（図１参照）は、記憶部１７の銀行別定義ファイル２１（図１参照）の銀行５−１の定義ファイル２１−１（図５）からパラメータを取得しリクエスト電文２９の変数を変換する（ステップ１００３）。即ち、パラメータ取得手段２３は、銀行５−１の銀行ＩＤ６１「ＢＫ００１」を参照して銀行５−１の定義ファイル２１−１を抽出する。また、パラメータ取得手段２３は、送信パラメータの変換規則６９（図５）を参照して、決済処理装置１内で使用する変数を銀行５−１に送信する決済要求情報に使用する変数に変換する。即ち、パラメータ取得手段２３は、「ｔｍｐ．ｓｙｏｈｉｎ→ｓｅｎｄｐａｒａｍ．Ａ」、「ｔｍｐ．ｋｏｓｕ→ｓｅｎｄｐａｒａｍ．Ｂ」、「ｔｍｐ．ｋｉｎｇａｋｕ→ｓｅｎｄｐａｒａｍ．Ｃ」の変換を行う。

次に制御部１５は銀行５−１の定義ファイル２１−１（図５）を参照して、銀行５−１に電文を送信する際のプロトコル６２、暗号化方式６３、アクセス先ＵＲＬ６６を抽出して銀行５−１の銀行サーバ１３−１宛のリクエスト電文３０−１を作成する（ステップ１００４）。リクエスト電文３０−１は、ステップ１００２及びステップ１００３で、銀行サーバ１３−１が利用可能な変数に変換された変数を用いて生成される。

更に制御部１５のハッシュ値生成手段２５（図１参照）は、銀行５−１の定義ファイル２１−１（図５）のハッシュ値生成規則６４を参照して、リクエスト電文３０−１からハッシュ値２４を生成する（ステップ１００５）。ハッシュ値２４は所定のデータから生成される一意の固定長の数値である。ハッシュ値生成規則６４は、ハッシュ値算出の元になるデータ範囲や算出方法を規定する。尚、加盟店端末装置１１−１から送られたリクエスト電文２９をインプットデータとしてハッシュ値２４を生成することもできる。

制御部１５の電文作成送信手段２７は、リクエスト電文３０−１にハッシュ値２４を付加したリクエスト電文３０−２を生成する（ステップ１００６）。更に電文作成送信手段２７は、銀行５−１の定義ファイル２１−１（図５）の暗号化方式６３を参照してリクエスト電文３０−２を暗号化し、リクエスト電文３１を生成する（ステップ１００７）。電文作成送信手段２７は、銀行５−１の銀行サーバ１３−１に生成したリクエスト電文３１を送信する（ステップ１００８）。

銀行サーバ１３−１は、リクエスト電文３１を受信し（ステップ１００９）、決済要求を受け付ける。図示していないが、銀行サーバ１３−１は受信したリクエスト電文３１を復号し、決済処理を行う。また、銀行サーバ１３−１は付加されているハッシュ値２４を利用してリクエスト電文３１の改竄を検証するようにしても良い。

以上の過程を経て、決済処理装置１は加盟店端末装置１１−１から送られる決済要求情報（リクエスト電文２９）に含まれる変数（パラメータ）やデータ値を、指定された銀行サーバ１３−１で使用可能な変数（パラメータ）やデータ値に変換し、改竄検証用のハッシュ値２４を付加して暗号化し、当該銀行サーバ１３−１に送信する。このように、決済処理装置１は、加盟店端末装置１１−１から銀行５を指定した決済要求を取得し媒介することで、目的の銀行５に加盟店端末装置１１−１からの決済要求を行うことができる。加盟店端末装置側は銀行サーバ側の仕様を考慮することなく決済要求情報を送信することができる。

（３−２．決済通知処理）
次に、図７を参照して決済処理装置１が銀行サーバ１３−１から取得する決済通知の処理について説明する。適宜図１乃至図４を用いて説明する。
銀行サーバ１３−１は、受信したリクエスト電文３１（図１、図６参照）の内容に基づいて決済処理を行い、決済処理の結果を含む決済応答情報であるレスポンス電文３９を作成し、決済処理装置１宛に送信する（ステップ２００１）。尚、銀行サーバ１３−１が作成するレスポンス電文３９は改竄検証のためのハッシュ値７３（後述する）が添付され、更に暗号化が施されて決済処理装置１宛に送信される。

決済処理装置１の制御部１５の電文受信復号手段３３（図２参照）はレスポンス電文３９を受信し、復号する（ステップ２００２）。レスポンス電文３９（図７参照）は、決済処理の結果に関するデータに、改竄検証に用いるハッシュ値７３が付加されている（図７参照）。尚、電文受信復号手段３３は銀行５−１の定義ファイル２１−１（図５）の暗号化方式６３を参照して、当該レスポンス電文３９を復号する。

ハッシュ値抽出手段３５（図２参照）は、復号されたレスポンス電文３９から銀行サーバ１３−１が生成して付加したハッシュ値７３を抽出する（ステップ２００３）。
次にハッシュ値生成手段２５（図２参照）は、銀行５−１の定義ファイル２１−１（図５）のハッシュ値生成規則６４を参照し、復号されたレスポンス電文３９のデータに基づいてハッシュ値７５を生成する（ステップ２００４）。

次にハッシュ値検証手段３７（図２参照）は、ハッシュ値抽出手段３５が抽出したハッシュ値７３と、ハッシュ値生成手段２５が生成したハッシュ値７５とを比較し、レスポンス電文３９のデータが途中で改竄されていないかどうかを検証する（ステップ２００５）。即ち、送信前に銀行サーバ１３−１が生成したハッシュ値７３と受信後に決済処理装置１が生成したハッシュ値７５とが同一であれば、レスポンス電文３９のデータがネットワークを経由する間に改竄されていないことを検証することができる。

レスポンス電文３９には、決済処理装置１のＵＲＬ、銀行ＩＤ、加盟店ＩＤ、及び決済処理内容を示す変数「ｒｅｃｅｉｖｅｐａｒａｍ．Ａ」、「ｒｅｃｅｉｖｅｐａｒａｍ．Ｂ」とその内容が含まれる。例えば、変数「ｒｅｃｅｉｖｅｐａｒａｍ．Ａ」は決済結果の内容（例えば「決済終了」、「決済不成立」等）が含まれ、「ｒｅｃｅｉｖｅｐａｒａｍ．Ｂ」は決済状態の内容（例えば決済の日付や内容）が含まれる。

パラメータ取得手段２３（図２参照）は、レスポンス電文３９の銀行ＩＤ６１「ＢＫ００１」を参照して銀行５−１の定義ファイル２１−１（図５参照）を抽出する。パラメータ取得手段２３は、受信パラメータの変換規則７１（図５）を参照して銀行５−１から受信した決済応答情報（レスポンス電文３９）に使用される変数を決済処理装置１内で使用する変数に変換する（ステップ２００６）。即ち、パラメータ取得手段２３は、「ｒｅｃｅｉｖｅｐａｒａｍ．Ａ→ｔｍｐ．ｋｅｋｋａ」、「ｒｅｃｅｉｖｅｐａｒａｍ．Ｂ→ｔｍｐ．ｊｏｕｔａｉ」の変換を行う。

次にパラメータ取得手段２３は、レスポンス電文３９の加盟店ＩＤ５６「ＳＰ００１」を参照して加盟店３−１の定義ファイル１９−１（図４参照）を抽出する。パラメータ取得手段２３は、送信パラメータの変換規則５９（図４）を参照して決済処理装置１内で使用する変数を加盟店３−１に送信する決済応答情報に使用する変数に変換する（ステップ２００７）。即ち、パラメータ取得手段２３は、「ｔｍｐ．ｋｅｋｋａ→ｒｅｓｕｌｔ」、「ｔｍｐ．ｊｏｕｔａｉ→ｓｔａｔｕｓ」の変換を行う。

次に、電文作成送信手段２７は、加盟店３−１の定義ファイル１９−１（図４）を参照して、アクセス先ＵＲＬ５７等を抽出して加盟店端末装置１１−１宛のレスポンス電文４１を生成する（ステップ２００８）。レスポンス電文４１は、ステップ２００６及びステップ２００７で、加盟店端末装置１１−１が利用可能な変数に変換された変数を用いて生成される。

電文作成送信手段２７は、レスポンス電文４１を加盟店３−１の加盟店端末装置１１−１宛に送信する（ステップ２００９）。

加盟店端末装置１１−１はレスポンス電文４１を受信する（ステップ２０１０）。加盟店端末装置１１−１は、決済処理の結果を決済要求情報送信元であるユーザ７のユーザ端末装置９に送信し、例えばユーザ端末装置９の表示部に「決済処理終了」通知を表示させ決済処理を終了する（ステップ２０１１）。

以上の過程を経て、決済処理装置１は銀行サーバ１３−１から加盟店端末装置１１−１宛に返される決済応答情報（レスポンス電文３９）を復号し、ハッシュ値を利用してデータ改竄を検証の後、当該レスポンス電文３９に含まれる変数（パラメータ）やデータ値を当該加盟店端末装置１１−１で使用可能な変数（パラメータ）やデータ値に変換して加盟店端末装置１１−１に送信する。このように、決済処理装置１は銀行サーバ１３−１から返される決済応答情報の安全確保をしつつ、当該決済応答情報を目的とする加盟店端末装置１１−１に返信することができる。銀行サーバ側は加盟店端末装置側の仕様を考慮することなく決済応答情報を返信することができる。

尚、上記実施の形態では、決済処理装置１と銀行５−１〜５−ｎ間で送受信されるリクエスト電文３１及びレスポンス電文３９に、改竄を検証するハッシュ値が付加され暗号化されることを説明したが、決済処理装置１と銀行５−１〜５−ｎ間に限らず、ネットワーク５５を介して送受信される決済情報に関する電文には、ハッシュ値を付加し暗号化して送受信することが望ましい。例えば、ユーザ端末装置９と加盟店端末装置１１−１間、加盟店端末装置１１−１と決済処理装置１間等で送受信される電文にハッシュ値を付加し暗号化するようにしても良い。

（４．ブラウザアクセス方式）
次に、図５に示す銀行別定義ファイル２１の項目として上げた「ブラウザアクセス方式」６５について説明する。
図８は、ハンドオフ方式によるブラウザアクセス方式を示す図である。図９は、リダイレクト方式によるブラウザアクセス方式を示す図である。図１乃至図７で説明した本実施の形態による決済処理装置１の銀行サーバ１３へのブラウザアクセス方式６５（図５参照）は、ハンドオフ方式によるものとして説明した。

ハンドオフ方式について図８を用いて説明する。ユーザ７がコンピュータ等のユーザ端末装置９の表示部７７に所定の加盟店によるＷＥＢページ８１を表示させ、決済処理を行うものとする。ユーザ端末装置９のＷＥＢページ８１−１からの決済処理であるアクション１０１は、決済処理装置１のＷＥＢアプリケーション７９を介して、指定された銀行サーバ１３に送信され、応答情報が再びＷＥＢアプリケーション７９を介してユーザ端末装置９に戻される。次のＷＥＢページ８１−２からのアクション１０２、及びＷＥＢページ８１−３からのアクション１０３も同様にその都度ＷＥＢアプリケーション７９を介して、銀行サーバ１３にアクセスし、応答情報もＷＥＢアプリケーション７９を介して、ユーザ端末装置９に戻される。

リダイレクト方式について図９を用いて説明する。ユーザ７がコンピュータ等のユーザ端末装置９の表示部７７に所定の加盟店によるＷＥＢページ８３を表示させ、決済処理を行うものとする。ユーザ端末装置９のＷＥＢページ８３−１からの決済処理であるアクション２０１が、決済処理装置１のＷＥＢアプリケーション７９にアクセスすると、決済処理装置１は当該決済処理に関する一連の通信電文に付加する固有のセッションＩＤ８５を生成する。決済処理装置１の記憶部１７には上記セッションＩＤ８５が格納される。

ＷＥＢページ８３−１からのアクション２０１は、リダイレクト方式であるので、指定された銀行サーバ１３へ直接アクセスするアクション２０２に移行する。ＷＥＢページ８３−２からのアクション２０３で銀行サーバ１３との決済処理が終了すると、次のＷＥＢページ８３−３からのアクション２０４は決済処理装置１のＷＥＢアプリケーション７９に戻る。リダイレクトによりユーザ端末装置９と銀行サーバ１３が直接やりとりする処理では、ＷＥＢアプリケーション７９（決済処理装置１）が処理を把握することができない。従って、前述のセッションＩＤ８５を決済処理装置１で保持すると共に、このように１つの決済処理に関する一連のアクション（Ａ２０１乃至Ａ２０４）に、同一のセッションＩＤ８５を付加してやりとりを行う。

アクション２０４で、一連の処理が決済処理装置１に戻ったとき、アクション２０４に付加しているセッションＩＤ８５と、決済処理装置１が保持しているセッションＩＤ８５とを照合することにより、どの注文に関する処理であるかをＷＥＢアプリケーション７９（決済処理装置１）で識別することができる。
尚、図８に示すハンドオフ方式においても、一連のアクション（Ａ１０１乃至Ａ１０３）にセッションＩＤ８５を付加しても良い。

本実施の形態においても、１つの決済処理に関する一連の送受信電文に同一のセッションＩＤ８５を付加するようにしても良い。ブラウザアクセス方式が、ハンドオフ方式やリダイレクト方式に係らずセッションＩＤ８５を付加することで、一連の送受信電文の識別、及びセッション管理を行うことができる。また、セッションＩＤ８５に代えて、注文番号やハッシュ値等の各決済処理を識別可能な情報を用いてもよい。

（５．効果等）
以上、説明したように、本実施の形態による決済処理装置１を介することで、複数の加盟店が提携金融機関それぞれに対する決済処理に対応するシステムを構築する必要がないので、加盟店は提携金融機関との間で簡単に決済処理を行うことが可能になる。
従って小規模な加盟店であっても、本実施の形態による決済処理装置１を介することで手軽に複数の金融機関のオンラインバンキングシステムを利用して決済処理を行うことができる。

本実施の形態による決済処理装置１が、決済処理を行う金融機関毎のプロトコルや暗号化方式、変数の変換情報等を格納しているので、加盟店は当該決済処理装置１を介して金融機関を指定するのみで簡単に目的の金融機関で決済処理を行うことができる。

また、加盟店が、決済処理を行う提携金融機関を追加する場合にも、本実施の形態による決済処理装置１が対応している（即ち、銀行別定義ファイル２１に登録されている）銀行であれば、即座に対応することができる。決済処理装置１が対応していない場合でも、当該銀行の定義ファイルを追加登録する簡単な作業を行うことで効率的に対応することができる。

また、本実施の形態では、決済情報に改竄検証に利用するハッシュ値を付加し、暗号化して送受信を行うので、決済情報の安全性を確保することができる。また、本実施の形態では、一連の決済情報に同一のセッションＩＤを付加することで、決済情報の識別、及びセッション管理を簡単に行うことが可能になる。

尚、本発明の技術的範囲は、前述した実施の形態に限られるものではない。当業者であれば、本願で開示した技術的思想の範疇内において、各種の変更例または修正例に想到し得ることは明らかであり、それらについても当然に本発明の技術的範囲に属するものと了解される。

本実施の形態における決済処理装置１の機能の概略を示す図 本実施の形態における決済処理装置１の機能の概略を示す図 決済処理装置１のハードウェア構成の概略を示す図 加盟店別定義ファイル１９を示す図 銀行別定義ファイル２１を示す図 決済処理を対象の銀行サーバ１３−１に送るフローチャート 銀行サーバ１３−１からの決済処理終了通知を加盟店端末装置１１−１に送るフローチャート ハンドオフ方式による銀行サーバ１３との送受信を示す図 リダイレクト方式による銀行サーバ１３との送受信を示す図

符号の説明

１………決済処理装置
３−１、３−２、・・、３−ｍ………加盟店
５−１、５−２、・・、５−ｎ………銀行
７………ユーザ
９………ユーザ端末装置
１１−１〜１１−ｍ………加盟店端末装置
１３−１〜１３−ｎ………銀行サーバ
１５………制御部
１７………記憶部
１９………加盟店別定義ファイル
２１………銀行別定義ファイル
２２………電文受信手段
２３………パラメータ取得手段
２４、７３、７５………ハッシュ値
２５………ハッシュ値生成手段
２７………電文作成送信手段
２９、３１………リクエスト電文
３３………電文受信復号手段
３５………ハッシュ値抽出手段
３７………ハッシュ値検証手段
３９、４１………レスポンス電文
４３………出力部
４５………入力部
４７………表示部
４９………メモリ
５１………通信部
５３………システムバス
５５………ネットワーク
５６………加盟店ＩＤ
５７、６６………アクセス先ＵＲＬ
５８、７１………受信パラメータの変換規則
５９、６９………送信パラメータの変換規則
６１………銀行ＩＤ
６２………プロトコル
６３………暗号化方式
６４………ハッシュ値生成規則
６５………ブラウザアクセス方式
６７………リダイレクト先ＵＲＬ
６８………タイムアウト
７７………表示部
７９………ＷＥＢアプリケーション
８１〜８１−３、８３−１〜８３−３………ＷＥＢページ
８５………セッションＩＤ

Claims (7)

1. 複数の加盟店側に属する端末装置と複数の金融機関側に属する金融機関サーバとにネットワークを介して接続され、前記端末装置と前記金融機関サーバとの間における決済要求情報及び決済応答情報を含む決済情報を処理する決済処理装置であって、
   前記加盟店ごとの前記決済情報の仕様を含む加盟店定義ファイルと前記金融機関ごとの前記決済情報の仕様を含む金融機関定義ファイルとを保持する保持手段と、
   前記加盟店定義ファイルと前記金融機関定義ファイルとを参照して、前記端末装置から送られる前記決済要求情報を前記端末装置が指定する前記金融機関サーバが利用可能な情報形態に変換して当該金融機関サーバに送信する第１の変換送信手段と、
   前記加盟店定義ファイルと前記金融機関定義ファイルとを参照して、前記金融機関サーバから送られる前記決済応答情報を前記端末装置が利用可能な情報形態に変換して当該端末装置に送信する第２の変換送信手段と、
   を具備することを特徴とする決済処理装置。
2. 前記加盟店定義ファイル及び前記金融機関定義ファイルは、決済処理に必要な変数データに関する情報を含み、
   前記第１の変換送信手段及び前記第２の変換送信手段は、前記加盟店定義ファイルまたは前記金融機関定義ファイルを参照して、前記決済情報から決済処理に必要な変数データを抽出し、当該抽出した変数データについて前記金融機関サーバまたは前記端末装置が利用可能な情報形態に変換して送信することを特徴とする請求項１に記載の決済処理装置。
3. 前記加盟店定義ファイル及び前記金融機関定義ファイルは、それぞれ、前記加盟店が使用する変数データまたは前記金融機関が使用する変数データと、内部処理用変数データと、の対応付けに関する情報を含み、
   前記第１の変換送信手段及び前記第２の変換送信手段は、前記内部処理用変数データを介して、前記加盟店が使用する変数データと前記金融機関が使用する変数データとの間の変換を行うことを特徴とする請求項１または請求項２に記載の決済処理装置。
4. 前記加盟店定義ファイル及び前記金融機関定義ファイルは、前記加盟店毎または前記金融機関毎に改竄検出用のハッシュ値の算出規則に関する情報を含み、
   前記加盟店定義ファイルまたは前記金融機関定義ファイルの前記ハッシュ値算出規則を参照して送信情報に基づいて生成したハッシュ値を前記送信情報に付して送信するハッシュ値生成送信手段と、
   前記加盟店定義ファイルまたは前記金融機関定義ファイルの前記ハッシュ値算出規則を参照して受信情報に基づいて生成したハッシュ値と、前記受信情報から検出したハッシュ値と、を比較して検証するハッシュ値検証手段と、
   を具備することを特徴とする請求項１から請求項３までのいずれかに記載の決済処理装置。
5. 前記加盟店と前記金融機関との間で授受される一連の前記決済情報には、同一の決済識別情報が付与されることを特徴とする請求項１から請求項４までのいずれかに記載の決済処理装置。
6. 複数の加盟店側に属する端末装置と複数の金融機関側に属する金融機関サーバとにネットワークを介して接続され、前記端末装置と前記金融機関サーバとの間における決済要求情報及び決済応答情報を含む決済情報を処理する決済処理装置が実行する決済処理方法であって、
   前記加盟店ごとの前記決済情報の仕様を含む加盟店定義ファイルと前記金融機関ごとの前記決済情報の仕様を含む金融機関定義ファイルとを保持する保持ステップと、
   前記加盟店定義ファイルと前記金融機関定義ファイルとを参照して、前記端末装置から送られる前記決済要求情報を前記端末装置が指定する前記金融機関サーバが利用可能な情報形態に変換して当該金融機関サーバに送信する第１の変換送信ステップと、
   前記加盟店定義ファイルと前記金融機関定義ファイルとを参照して、前記金融機関サーバから送られる前記決済応答情報を前記端末装置が利用可能な情報形態に変換して当該端末装置に送信する第２の変換送信ステップと、
   を具備することを特徴とする決済処理方法。
7. コンピュータを請求項１から請求項６までのいずれかに記載の決済処理装置として機能させるプログラム。

Images