JP2019061529A

JP2019061529A - 決済支援装置および決済仲介装置

Info

Publication number: JP2019061529A
Application number: JP2017186145A
Authority: JP
Inventors: 元治岡田; Motoharu Okada; 陽介瀬田; Yosuke Seta; 扶実齊藤; Fumi Saito
Original assignee: Cardservice Inc; LINK KK
Current assignee: Cardservice Inc; LINK KK
Priority date: 2017-09-27
Filing date: 2017-09-27
Publication date: 2019-04-18
Anticipated expiration: 2037-09-27
Also published as: JP6865665B2

Abstract

【課題】クレジットカードの加盟店における顧客のクレジットカード情報の非保持化を支援する。【解決手段】決済専用端末１８は、電話、郵便、宅配便、またはファクシミリを介して顧客から注文を受け付けるＭＯＴＯ加盟店に設置されたクレジットカード決済のための専用装置であり、加盟店内通信網１５には接続されない。ＭＯＴＯ加盟店のオペレータは、顧客のクレジットカード情報を決済専用端末１８に直接手入力する。決済専用端末１８は、本端末とＵＳＢ接続された業務用ＰＣ１２に入力された、注文に係る金額の情報を取得する。決済専用端末１８は、業務用ＰＣ１２から取得した金額情報と、オペレータにより入力されたクレジットカード情報を、携帯電話通信網を介して、クレジットカード決済を支援する決済ＧＷ装置２０へ送信する。【選択図】図１

Description

本発明はデータ処理技術に関し、特に決済支援装置および決済仲介装置に関する。

クレジットカードの加盟店や決済代行事業者等のサービスプロバイダにおいてクレジットカードの会員データを安全に取り扱うために、クレジットカード業界の国際セキュリティ基準として、ＰＣＩＤＳＳ（Payment Card Industry Data Security Standard）が策定されている。クレジットカード決済代行事業者は、事業の前提としてカード会社との包括代理契約が必要であるが、現在カード会社は、決済代行事業者のシステムがＰＣＩＤＳＳに準拠していることを契約の条件とすることがある。また、クレジットカードの加盟店にも、国際カードブランドや国内のクレジットカード会社等からＰＣＩＤＳＳへの準拠が要請されている。したがって、ＰＣＩＤＳＳに準拠したシステムを構築することがますます重要になってきている。

特開２０１５−８２７８７号公報

顧客がクレジットカードを使用して商品やサービスを購入できるようにクレジットカード会社と契約を結んだ小売店（加盟店）の中には、電話、郵便、宅配便、またはファクシミリを介して顧客から注文を受け付ける加盟店（以下「ＭＯＴＯ（Mail Order Telephone Order）加盟店」と呼ぶ。）が存在する。従来のＭＯＴＯ加盟店の情報システムは、顧客のクレジットカード情報を保持していた。クレジットカード情報の保護が求められる現在、ＭＯＴＯ加盟店には、ＰＣＩＤＳＳの準拠またはクレジットカード情報の非保持化が求められている。

しかし、ＰＣＩＤＳＳに準拠するには、初期投資および維持管理に多くの費用がかかり、多くのＭＯＴＯ加盟店にとってその費用を負担することは容易ではない。また、顧客のクレジットカード情報を保持しないようにＭＯＴＯ加盟店の業務フローを変更すると、ＭＯＴＯ加盟店の業務効率が大幅に低下する可能性がある。

本発明はこうした課題に鑑みてなされたものであり、１つの目的は、クレジットカードの加盟店における顧客のクレジットカード情報の非保持化を支援する技術を提供することにある。

上記課題を解決するために、本発明のある態様の決済支援装置は、電話、郵便、宅配便、またはファクシミリを介して顧客から注文を受け付ける企業に設置されたクレジットカード決済のための専用装置であって、本装置は、企業のネットワークに未接続であり、企業のネットワークに接続された外部装置であって、専用の通信経路を介して本装置と接続された第１の外部装置に入力された、注文に係る金額の情報を取得する取得部と、企業の従業員により顧客のクレジットカードの情報が入力される入力部と、取得部により取得された金額の情報と、入力部に入力されたクレジットカードの情報を、携帯電話通信網を介して、クレジットカード決済を支援する第２の外部装置へ送信する取引情報送信部と、を備える。

本発明の別の態様は、決済仲介装置である。この装置は、電話、郵便、宅配便、またはファクシミリを介して顧客から注文を受け付ける企業、または、その企業に設置されたクレジットカード決済のための専用装置と、決済代行事業者との対応関係を記憶する記憶部と、専用装置から携帯電話通信網へ送信された、注文に係る金額の情報と、顧客のクレジットカードの情報とを含む取引情報を取得する取得部と、取得部により取得された取引情報を、複数の決済代行事業者のうち記憶部において企業または専用装置に対応付けられた決済代行事業者の装置へ送信する取引情報送信部と、を備える。

なお、以上の構成要素の任意の組合せ、本発明の表現を、方法、プログラム、プログラムを格納した記録媒体などの間で変換したものもまた、本発明の態様として有効である。

本発明によれば、クレジットカードの加盟店における顧客のクレジットカード情報の非保持化を支援することができる。

実施例の情報処理システムの構成を示す図である。図１の決済専用端末の外観を模式的に示す図である。図１の決済専用端末の機能構成を示すブロック図である。図１の決済ＧＷ装置の機能構成を示すブロック図である。実施例の情報処理システムにおける処理の過程を示すシーケンス図である。

図１は、実施例の情報処理システム１０の構成を示す。情報処理システム１０は、業務用ＰＣ１２と、顧客情報管理システム１４と、決済代行事業者装置１６で総称されるＡ社装置１６ａ、Ｂ社装置１６ｂ、Ｃ社装置１６ｃと、決済専用端末１８と、決済ＧＷ装置２０を備える。

図１のＭＯＴＯ加盟店は、電話、郵便（葉書等であり電子メールではない）、宅配便、またはファクシミリを介して顧客から注文を受け付ける企業である。ＭＯＴＯ加盟店は、典型的には通信販売業者や旅行代理店である。顧客からの注文は、購入対象の商品またはサービスを指定する情報と、決済に使用する顧客のクレジットカード情報を含む。クレジットカード情報は、クレジットカード番号、クレジットカード有効期限、所有者名、セキュリティコードを含んでもよい。

ＭＯＴＯ加盟店には、業務用ＰＣ１２と顧客情報管理システム１４が設置される。業務用ＰＣ１２と顧客情報管理システム１４は、ＬＡＮ等の加盟店内通信網１５に接続され、加盟店内通信網１５を介してデータを送受信する。

顧客情報管理システム１４は、ＭＯＴＯ加盟店で商品やサービスを購入した複数の顧客のそれぞれに関する情報（以下「顧客情報」とも呼ぶ。）を管理する情報処理システムである。各顧客の顧客情報は、複数回の注文に関する複数の受注情報（取引結果、金額、ＩＤ、日時等）を含みうる。

業務用ＰＣ１２は、ＭＯＴＯ加盟店の従業員（以下「オペレータ」とも呼ぶ。）により操作される情報処理装置である。実施例ではＰＣとするが、スマートフォンやタブレット端末でもよい。業務用ＰＣ１２には、オペレータにより入力された受注情報を受け付け、その受注情報に基づく処理を顧客情報管理システム１４と連携して実行するアプリケーション（以下「受注業務Ａｐｐ」とも呼ぶ。）が導入される。

決済代行事業者装置１６は、決済代行事業者に設置される情報処理装置である。決済代行事業者装置１６は、クレジットカード決済を要求するための予め定められたＡＰＩ（Application Programming Interface）（以下「決済ＡＰＩ」とも呼ぶ。）を介して、クレジットカード情報と決済金額とを含む取引情報（言い換えれば決済要求）を受け付ける。決済代行事業者装置１６は、受け付けた取引情報に基づいてクレジットカード決済を実行する。

Ａ社装置１６ａ、Ｂ社装置１６ｂ、Ｃ社装置１６ｃは、異なる決済代行事業者であるＡ社、Ｂ社、Ｃ社に設置される。Ａ社装置１６ａ、Ｂ社装置１６ｂ、Ｃ社装置１６ｃは、異なる決済ＡＰＩを備える。各社の決済ＡＰＩは、通信プロトコル、通信フォーマット、データ項目の少なくとも１つが異なってもよい。例えば、Ａ社装置１６ａの決済ＡＰＩでは、クレジットカード情報として、クレジットカード番号、クレジットカード有効期限を指定する必要があってもよい。その一方、Ｂ社装置１６ｂの決済ＡＰＩでは、クレジットカード情報として、クレジットカード番号、クレジットカード有効期限、セキュリティコードを指定する必要があってもよい。

従来、ＭＯＴＯ加盟店の業務用ＰＣ１２から、そのＭＯＴＯ加盟店が契約する決済代行事業者の決済代行事業者装置１６へ、取引情報を直接送っていた。例えば、ＭＯＴＯ加盟店のオペレータは、電話等にて顧客から注文を受け付けると、決済代行事業者が提供するウェブページを業務用ＰＣ１２に表示させ、そのウェブページへ決済金額（商品価格）と顧客のクレジットカード情報を入力することで、クレジットカード決済を実施していた。

規定上、クレジットカード情報が通過し、クレジットカード情報を処理し、クレジットカード情報を保存することの少なくとも１つを満たせば、クレジットカード情報を保持することになる。したがって、従来の業務用ＰＣ１２は、クレジットカード情報を保持しており、ＰＣＩＤＳＳの準拠が求められることになる。しかし、費用等の面からＰＣＩＤＳＳの準拠は容易ではない。そこで、実施例の情報処理システム１０は、ＭＯＴＯ加盟店に決済専用端末１８を設置し、決済仲介事業者に決済ＧＷ装置２０を設置することにより、ＭＯＴＯ加盟店におけるクレジットカード情報の非保持化を実現する。

決済専用端末１８は、クレジットカード決済を支援する専用装置であり、公知の信用照会端末（CCT:Credit Center Terminal）と同等／相当のセキュリティの認定を受けたものである。決済専用端末１８は、決済仲介事業者がＭＯＴＯ加盟店に貸し出したものであり、決済専用端末１８の所有権は決済仲介事業者が有する。

決済専用端末１８は、加盟店内通信網１５には接続されず、専用の通信経路を介して業務用ＰＣ１２と接続される。実施例では、決済専用端末１８は、業務用ＰＣ１２とＵＳＢ（Universal Serial Bus）接続される。変形例として、業務用ＰＣ１２とＣＯＭポート接続されてもよい。また、決済専用端末１８は、ＳＩＭ（Subscriber Identity Module）カードを備え、携帯電話通信網２２（例えば３Ｇ網またはＬＴＥ（Long Term Evolution）網）と接続される。

決済ＧＷ装置２０は、携帯電話通信網２２を介して決済専用端末１８と接続される。実際には、決済ＧＷ装置２０は、インターネットから携帯電話通信網２２を経て決済専用端末１８に接続される。実施例における決済専用端末１８と決済ＧＷ装置２０は、共通鍵（AES:Advanced Encryption Standard）による暗号化通信（例えばＨＴＴＰＳ／ＴＬＳ１．２）を実行する。また、決済ＧＷ装置２０は、複数の決済代行事業者のそれぞれが指定した通信経路（指定通信網２４ａ、指定通信網２４ｂ、指定通信網２４ｃ）を介して、各事業者の決済代行事業者装置１６と接続される。指定通信網２４ａ〜指定通信網２４ｃは、ＬＡＮ、ＷＡＮ、インターネット、専用線のいずれかであってもよい。

決済ＧＷ装置２０は、決済仲介装置とも言え、決済代行事業者装置１６が提供する決済ＡＰＩとの連携機能を有する。具体的には、決済ＧＷ装置２０は、決済専用端末１８に入力されたクレジットカード情報を決済代行事業者装置１６へ中継する。また、決済ＧＷ装置２０は、決済専用端末１８を管理する機能を有する。具体的には、決済ＧＷ装置２０は、（１）暗号管理、（２）決済専用端末１８の情報管理、（３）決済専用端末１８のＯＳおよびアプリケーションのバージョン管理、（４）決済専用端末１８のアプリケーションおよび暗号鍵の更新を実行する。

ＭＯＴＯ加盟店のオペレータは、顧客のクレジットカード情報を決済専用端末１８に入力する。そして、そのクレジットカード情報が、決済専用端末１８〜決済ＧＷ装置２０〜決済代行事業者装置１６と伝達され、クレジットカード決済が行われる。実施例の情報処理システム１０では、ＭＯＴＯ加盟店の業務用ＰＣ１２、顧客情報管理システム１４、加盟店内通信網１５は、顧客のクレジットカード情報を保持しない。すなわち、ＭＯＴＯ加盟店におけるクレジットカード情報の非保持化が実現される。決済仲介事業者と決済代行事業者は、クレジットカード情報を保持するため、ＰＣＩＤＳＳの準拠が必要になる。一方、ＭＯＴＯ加盟店では、ＰＣＩＤＳＳの準拠は不要になる。

なお、図１にはＭＯＴＯ加盟店を１つ描いたが、実際には、複数のＭＯＴＯ加盟店が存在する。また、１つのＭＯＴＯ加盟店の中に、複数の業務用ＰＣ１２および決済専用端末１８が設置されてもよい。例えば、クレジットカード決済を依頼する決済代行事業者ごとに業務用ＰＣ１２と決済専用端末１８の組み合わせを設けてもよい。

図２は、図１の決済専用端末１８の外観を模式的に示す。決済専用端末１８は、入力部３０と表示部３２を備える。入力部３０には、ＭＯＴＯ加盟店のオペレータにより顧客のクレジットカード情報（例えばクレジットカード番号、有効期限等）が入力される。入力部３０は、複数のボタンを含んでもよい。表示部３２には、入力部３０を介して入力されたクレジットカード情報、業務用ＰＣ１２から取得された決済金額等が表示される。表示部３２は、ＬＣＤ（Liquid Crystal Display）により実現されてもよい。実施例の決済専用端末１８では、入力部３０をハードウェアキーとして構成するが、変形例として、入力部３０を、タッチスクリーン機能を有する表示部３２に表示されるソフトウェアキーとして構成してもよい。

図３は、図１の決済専用端末１８の機能構成を示すブロック図である。決済専用端末１８は、入力部３０、表示部３２、ＵＳＢ−ＩＦ３４、通信部３６、制御部３８、印字部５２を備える。本明細書のブロック図で示される各ブロックは、ハードウェア的には、コンピュータのＣＰＵ・メモリをはじめとする素子や機械装置で実現でき、ソフトウェア的にはコンピュータプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。これらの機能ブロックはハードウェア、ソフトウェアの組合せによっていろいろなかたちで実現できることは、当業者には理解されるところである。

ＵＳＢ−ＩＦ３４は、ＵＳＢ規格に基づいて外部機器とのインタフェース機能を提供する。通信部３６は、ＳＩＭカードを含み、携帯電話通信網２２と通信する。制御部３８は、ＭＯＴＯ加盟店におけるクレジットカード決済を支援するための機能を提供する。制御部３８は、ＵＳＢ−ＩＦ３４を介して、業務用ＰＣ１２とデータを送受信する。また、制御部３８は、通信部３６および携帯電話通信網２２を介して、決済ＧＷ装置２０とデータを送受信する。印字部５２は、所定のレシート用紙への印字処理を実行してもよい。

制御部３８は、カード情報取得部４０、金額取得部４２、取引情報送信部４４、取引結果取得部４６、取引結果転送部４８、表示制御部５０、印字制御部５４を含む。制御部３８における複数の機能ブロックは、これらの機能ブロックに対応する複数のモジュールを含むコンピュータプログラムとして実装されてもよい。このコンピュータプログラムは、記録媒体またはネットワークを介して決済専用端末１８のストレージへインストールされてもよい。決済専用端末１８のＣＰＵは、このコンピュータプログラムをメインメモリに読み出して実行することにより、制御部３８の各機能ブロックの機能を発揮してもよい。

カード情報取得部４０は、入力部３０に入力された顧客のクレジットカード情報を取得する。

金額取得部４２は、ＵＳＢ−ＩＦ３４を介して、業務用ＰＣ１２に入力されたクレジットカード決済の対象となる金額（以下「決済金額」と呼ぶ。）の情報を取得する。決済金額は、注文に係る金額とも言え、顧客が購入する商品またはサービスの販売価格とも言える。なお、業務用ＰＣ１２には、受注業務Ａｐｐが表示させた業務画面にオペレータが入力した決済金額を受注業務Ａｐｐから取得する端末連携アプリケーション（以下「端末連携Ａｐｐ」と呼ぶ。）が導入される。端末連携Ａｐｐは、ＵＳＢ接続された決済専用端末１８の金額連携用ＡＰＩをコールして、決済金額を決済専用端末１８に渡す。

取引情報送信部４４は、クレジットカード決済を要求する取引情報を、携帯電話通信網２２を介して決済ＧＷ装置２０へ送信する。取引情報は、（１）クレジットカード決済ごとにユニークな取引ＩＤと、（２）金額取得部４２により取得された決済金額の情報と、（３）カード情報取得部４０により取得されたクレジットカード情報と、（４）決済専用端末１８のＩＤを含む。

取引情報送信部４４が送信する取引情報は、クレジットカード決済を実行する決済代行事業者の種類、言い換えれば、取引情報の送信先となる決済ＡＰＩの種類や形式に非依存の共通形式であり、以下「共通取引情報」とも呼ぶ。また、取引情報送信部４４は、共通取引情報を予め記憶された共通鍵により暗号化し、共通取引情報の暗号化データを決済ＧＷ装置２０へ送信する。

取引結果取得部４６は、決済ＧＷ装置２０が携帯電話通信網２２へ送信した、取引結果を示す取引結果情報の暗号化データを取得する。取引結果取得部４６は、予め記憶された共通鍵により暗号化データを復号し、復号結果の取引結果情報を取得する。取引結果転送部４８は、取引結果取得部４６により取得された取引結果情報を、ＵＳＢ−ＩＦ３４を介して業務用ＰＣ１２へ転送する。

取引結果情報は、（１）取引ＩＤと、（２）クレジットカード決済に成功したことまたは失敗したことを示す決済成否と、（３）クレジットカード決済に使用されたクレジットカードごとに決済代行事業者が割り当てたユニークなＩＤ（以下「代替ＩＤ」とも呼ぶ。）を含む。一方、取引結果情報は、入力部３０に入力された顧客のクレジットカード情報を含まない。代替ＩＤには、顧客が使用したクレジットカードを一意に特定可能な値が設定される。また、代替ＩＤには、顧客が使用したクレジットカード情報（例えばクレジットカード番号、クレジットカード有効期限）とは異なる値であり、クレジットカード情報を類推することが困難な値が設定される。

表示制御部５０は、表示部３２における表示内容を制御する。例えば、表示制御部５０は、金額取得部４２により取得された決済金額の情報と、カード情報取得部４０により取得されたクレジットカード情報を表示部３２に表示させる。この際、表示制御部５０は、クレジットカード情報（例えばクレジットカード番号）の一部を非表示としてもよく、また、クレジットカード情報の一部を「Ｘ」「＊」等の代替文字により秘匿する態様で表示させてもよい。表示制御部５０はさらに、取引結果取得部４６により取得された取引結果情報を表示部３２に表示させてもよい。

印字制御部５４は、印字部５２を制御して、取引結果取得部４６により取得された取引結果情報をレシート用紙に印字させる。この際に、印字制御部５４は、取引結果情報に加えて、カード情報取得部４０により取得されたクレジットカード情報（例えばクレジットカード番号）をマスキング（文字列の一部をアスタリスクに置き換える等）した上で印字させてもよい。

図４は、図１の決済ＧＷ装置２０の機能構成を示すブロック図である。決済ＧＷ装置２０は、制御部６０、記憶部６２、通信部６４を備える。制御部６０は、ＭＯＴＯ加盟店と決済代行事業者の間で、クレジットカード決済を仲介するためのデータ処理を実行する。記憶部６２は、制御部６０により参照または更新されるデータを記憶する。通信部６４は、所定の通信プロトコルにしたがって外部装置と通信する。制御部６０は、通信部６４を介して外部装置とデータを送受信する。

記憶部６２は、店舗端末情報記憶部６６と更新データ記憶部６８を含む。店舗端末情報記憶部６６は、複数のＭＯＴＯ加盟店に設置された複数の決済専用端末１８に関する情報を記憶する。具体的には、店舗端末情報記憶部６６は、決済専用端末１８を単位とするレコードであり、決済専用端末１８のＩＤ、ＭＯＴＯ加盟店のＩＤ、取引情報の送信先となる決済代行事業者のＩＤ（例えば決済代行事業者装置１６のＩＤ）、ソフトウェアのバージョンとを対応付けた複数のレコードを記憶する。実施例におけるソフトウェアは、ＯＳ（Operating System）、ファームウェア、アプリケーションプログラムを含む。

取引情報の送信先となる決済代行事業者（例えば特定の決済代行事業者装置１６）は、実施例では決済専用端末１８を単位として定められる。そのため、同一のＭＯＴＯ加盟店に複数の決済専用端末１８が設置された場合、それぞれの決済専用端末１８から送信された取引情報を異なる決済代行事業者へ中継しうる。変形例として、取引情報の送信先となる決済代行事業者は、ＭＯＴＯ加盟店を単位として定められてもよい。

更新データ記憶部６８は、複数のＭＯＴＯ加盟店に設置された複数の決済専用端末１８におけるソフトウェアの更新データと、暗号化通信のための鍵（実施例では共通鍵）の更新データを記憶する。

制御部６０は、共通取引情報取得部７０、個別取引情報生成部７２、個別取引情報送信部７４、取引結果取得部７６、取引結果送信部７８、端末更新部８０を含む。制御部６０における複数の機能ブロックは、これらの機能ブロックに対応する複数のモジュールを含むコンピュータプログラムとして実装されてもよい。このコンピュータプログラムは、記録媒体またはネットワークを介して決済ＧＷ装置２０のストレージへインストールされてもよい。決済ＧＷ装置２０のＣＰＵは、このコンピュータプログラムをメインメモリに読み出して実行することにより、制御部６０の各機能ブロックの機能を発揮してもよい。

共通取引情報取得部７０は、通信部６４を介して、決済専用端末１８が携帯電話通信網２２へ送信したデータであり、取引情報の送信先となる決済代行事業者の種類に関わらない共通形式である共通取引情報の暗号化データを取得する。共通取引情報取得部７０は、予め記憶された共通鍵により当該暗号化データを復号し、復号結果として共通取引情報を取得する。

個別取引情報生成部７２は、共通取引情報取得部７０により取得された共通取引情報に基づいて、取引情報の送信先となる決済代行事業者装置１６が求める形式の個別取引情報を生成する。具体的には、個別取引情報生成部７２は、店舗端末情報記憶部６６を参照して、共通取引情報で指定された決済専用端末１８のＩＤに対応付けられた決済代行事業者装置１６のＩＤを特定する。すなわち、取引情報の送信先となる決済代行事業者装置１６（実施例ではＡ社装置１６ａ、Ｂ社装置１６ｂ、Ｃ社装置１６ｃのいずれか）を特定する。個別取引情報生成部７２は、送信先の決済代行事業者装置１６の決済ＡＰＩで規定された事業者個別形式にあわせて共通取引情報を変換することにより個別取引情報を生成する。

また、店舗端末情報記憶部６６が記憶するレコードは、複数のＭＯＴＯ加盟店のそれぞれから事前に登録された情報であり、クレジットカード情報や決済金額とともに決済代行事業者へ渡すべき情報（ここでは「加盟店登録情報」と呼ぶ。）を含む。個別取引情報生成部７２は、共通取引情報の送信元であるＭＯＴＯ加盟店の加盟店登録情報であり、言い換えれば、共通取引情報で指定された決済専用端末１８のＩＤに対応付けられた加盟店登録情報を、送信先の決済代行事業者の個別形式にあわせて設定した個別取引情報を生成する。

個別取引情報送信部７４は、個別取引情報生成部７２により生成された個別取引情報を、決済専用端末１８のＩＤに基づいて特定された送信先の決済代行事業者装置１６へ送信する。例えば、送信先がＡ社装置１６ａの場合、個別取引情報生成部７２は、Ａ社が予め定めた形式に準拠した個別取引情報を生成してもよい。個別取引情報送信部７４は、指定通信網２４ａを介して、当該個別取引情報を引数として、Ａ社が予め定めた決済ＡＰＩをコールすることにより、当該個別取引情報をＡ社装置１６ａへ送信してもよい。

取引結果取得部７６は、個別取引情報への応答として決済代行事業者装置１６から送信された取引結果情報を取得する。取引結果送信部７８は、取引結果取得部７６により取得された取引結果情報を予め記憶された共通鍵により暗号化し、取引結果情報の暗号化データを、携帯電話通信網２２を介して決済専用端末１８へ送信する。

既述したように、共通取引情報取得部７０により取得される共通取引情報は、取引ＩＤ、決済金額、クレジットカード情報、送信元である決済専用端末１８のＩＤを含む。また、取引結果取得部７６により取得される取引結果情報は、取引ＩＤ、決済成否、代替ＩＤを含む。共通取引情報取得部７０は、共通取引情報で指定された取引ＩＤと決済専用端末１８のＩＤとを対応付けて所定の記憶領域へ格納してもよい。取引結果送信部７８は、取引結果情報で指定された取引ＩＤに対応づけられた決済専用端末１８へ取引結果情報を送信してもよい。

なお、複数の決済代行事業者装置１６が送信する取引結果情報の形式が異なる場合、決済ＧＷ装置２０は、個々の決済代行事業者装置１６から受け付けた取引結果情報を共通形式の取引結果情報に変換する取引結果変換部をさらに備えてもよい。取引結果送信部７８は、取引結果変換部により生成された共通形式の取引結果情報を決済専用端末１８へ送信してもよい。

端末更新部８０は、複数のＭＯＴＯ加盟店に設置された複数の決済専用端末１８におけるソフトウェアと、暗号化通信のための共通鍵の少なくとも一方（実施例では両方）を、携帯電話通信網２２を介して更新する。具体的には、端末更新部８０は、決済仲介事業者の従業員の指示に応じて、または定期的に、更新データ記憶部６８に記憶されたソフトウェアの更新データ、および、共通鍵の更新データを決済専用端末１８へ送信する。

以上の構成による情報処理システム１０の動作を以下説明する。
図５は、実施例の情報処理システム１０における処理の過程を示すシーケンス図である。業務用ＰＣ１２は、ＭＯＴＯ加盟店のオペレータの操作にしたがって、受注業務Ａｐｐを実行し、業務画面をディスプレイに表示させる（Ｓ１０）。不図示だが、顧客は、ＭＯＴＯ加盟店へ電話し、購入対象の商品および自身のクレジットカード情報をＭＯＴＯ加盟店のオペレータへ伝える。オペレータは、販売対象商品と、その販売に伴い決済が必要な金額である決済金額を業務画面に入力する。業務用ＰＣ１２に導入された端末連携Ａｐｐは、業務画面に入力された決済金額を取得して決済専用端末１８へ送信する（Ｓ１２）。

オペレータは、顧客のクレジットカード情報を決済専用端末１８の入力部３０に直接手入力する一方、業務用ＰＣ１２には入力しない。決済専用端末１８のカード情報取得部４０は、入力部３０に入力されたクレジットカード情報を取得する（Ｓ１４）。決済専用端末１８の取引情報送信部４４は、クレジットカード情報と決済金額を含む共通取引情報を、携帯電話通信網２２を介して決済ＧＷ装置２０へ送信する（Ｓ１６）。決済ＧＷ装置２０の個別取引情報生成部７２は、共通取引情報を送信先の決済代行事業者装置１６に応じた個別取引情報へ変換し、個別取引情報送信部７４は、個別取引情報を決済代行事業者装置１６へ送信する（Ｓ１８）。

個別取引情報を受信した決済代行事業者装置１６は、個別取引情報で指定されたクレジットカード情報および決済金額に基づいて、クレジットカード決済のための所定のデータ処理を実行する（Ｓ２０）。決済代行事業者装置１６は、決済成否と、クレジットカード情報に対応する代替ＩＤとを含む取引結果情報を決済ＧＷ装置２０へ送信する（Ｓ２２）。決済代行事業者装置１６の取引結果送信部７８は、決済代行事業者装置１６から送信された取引結果情報を、取引情報送信元の決済専用端末１８へ転送する（Ｓ２４）。決済専用端末１８の取引結果転送部４８は、決済ＧＷ装置２０から送信された取引結果情報を業務用ＰＣ１２へ転送する（Ｓ２６）。不図示だが、決済専用端末１８は、取引結果情報を表示部３２に表示させてもよく、また、取引結果情報をレシート用紙に印刷してもよい。

業務用ＰＣ１２の端末連携Ａｐｐは、決済専用端末１８から送信された取引結果情報を取得して受注業務Ａｐｐに渡す。業務用ＰＣ１２の受注業務Ａｐｐは、取引結果情報が示す決済成否および代替ＩＤを業務画面に表示させる（Ｓ２８）。業務用ＰＣ１２の受注業務Ａｐｐは、オペレータの操作に応じて、取引結果情報に基づく受注情報（例えば決済成否、決済金額、代替ＩＤ、日時等）を顧客情報管理システム１４へ送信する（Ｓ３０）。顧客情報管理システム１４は、受注情報に基づき顧客情報を更新する（Ｓ３２）。例えば、既存顧客の顧客情報に今回の受注情報を追加する。

実施例の情報処理システム１０による効果を説明する。
実施例の決済専用端末１８は、決済仲介事業者からＭＯＴＯ加盟店へ貸与され、加盟店内通信網１５には接続されない。ＭＯＴＯ加盟店のオペレータは、クレジットカード情報を決済専用端末１８へ手入力し、決済専用端末１８は、加盟店内通信網１５とは独立した携帯電話通信網２２を介して、クレジットカード情報を決済ＧＷ装置２０へ渡す。これにより、ＭＯＴＯ加盟店におけるクレジットカード情報の非保持化と、クレジットカード決済による商品またはサービスの販売を両立させることができる。

また、決済専用端末１８は、業務用ＰＣ１２と連携し、業務用ＰＣ１２の業務画面に入力された金額情報を自動で取得する。これにより、オペレータ自身が金額情報を決済専用端末１８へ直接入力する場合に生じうるミスを抑制でき、また、ＭＯＴＯ加盟店における業務フローに大幅な変更が生じることを回避できる。

また、決済専用端末１８から業務用ＰＣ１２へ提供される取引結果情報は、正規のクレジットカード情報を含まない。これにより、ＭＯＴＯ加盟店におけるクレジットカード情報の非保持化を実現できる。

また、取引結果情報は、顧客が使用したクレジットカードごとにユニークな代替ＩＤを含む。これにより、ＭＯＴＯ加盟店において、クレジットカード情報の非保持化を実現しつつ、クレジットカード情報に代えて代替ＩＤをキーとした顧客情報管理が可能になる。例えば、ＭＯＴＯ加盟店が、販売チャネルとして通信販売用のウェブサイトを有する場合（ただしクレジットカード情報の入力時は決済代行事業者のウェブサイトへリダイレクトする）、当該ウェブサイトを介した購買履歴と、実施例に記載のＭＯＴＯを介した購買履歴とを代替ＩＤをキーとして関連づけることができる。さらにまた、ＭＯＴＯ加盟店から決済代行事業者へ代替ＩＤをキーとして取引内容等を問い合わせることができる。

また、実施例の決済ＧＷ装置２０は、複数の決済代行事業者装置１６と接続され、また、決済代行事業者間のインタフェースの相違を吸収する。これにより、ＭＯＴＯ加盟店は、決済専用端末１８、決済ＧＷ装置２０を利用する場合も、従来利用している決済代行事業者を変える必要がない（決済ＧＷ装置２０が対応することが前提）。また、ＭＯＴＯ加盟店が、利用する決済代行事業者を変更する場合、決済ＧＷ装置２０において管理されるＭＯＴＯ加盟店（もしくはＭＯＴＯ加盟店に設置された決済専用端末１８）と決済代行事業者との対応関係を変更すればよく、決済代行事業者の変更も容易に実現できる。

例えば、決済ＧＷ装置２０は、店舗端末情報記憶部６６のレコードを更新する店舗端末情報更新部をさらに備えてもよい。店舗端末情報更新部は、ＭＯＴＯ加盟店の装置（例えば業務用ＰＣ１２）から送信された、決済専用端末１８のＩＤ、ＭＯＴＯ加盟店のＩＤ、変更先の決済代行事業者を含む変更要求を受け付けてもよい。店舗端末情報更新部は、店舗端末情報記憶部６６のレコードの中から、変更要求が示す決済専用端末１８のＩＤとＭＯＴＯ加盟店のＩＤを含むレコードを特定し、当該レコードの決済代行事業者の情報を、変更先の決済代行事業者に変更してもよい。

また、実施例の決済ＧＷ装置２０は、決済専用端末１８のミドルウェアおよび暗号化通信のための共通鍵を更新する。これにより、決済専用端末１８を決済仲介事業者の管理下に置きつつ、また、決済専用端末１８のセキュリティの強度を維持することができる。

以上、本発明を実施例をもとに説明した。この実施例は例示であり、各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。

上記実施例では言及していないが、決済代行事業者装置１６および決済ＧＷ装置２０は、単体の情報処理装置により実現されてもよく、複数の情報処理装置が連携する情報処理システムとして実現されてもよい。

上記実施例の決済専用端末１８と決済ＧＷ装置２０は、共通鍵暗号方式による暗号化通信を実行した。変形例として、決済専用端末１８と決済ＧＷ装置２０は、公開鍵暗号方式による暗号化通信を実行してもよい。また、決済専用端末１８と決済ＧＷ装置２０は、トランザクション毎にデータの暗号鍵を交換（変更）する方式（例えばＤＵＫＰＴ（Derive Unique Key Per Transaction））による暗号化通信を実行してもよい。

上述した実施例および変形例の任意の組み合わせもまた本発明の実施の形態として有用である。組み合わせによって生じる新たな実施の形態は、組み合わされる実施例および変形例それぞれの効果をあわせもつ。また、請求項に記載の各構成要件が果たすべき機能は、実施例および変形例において示された各構成要素の単体もしくはそれらの連携によって実現されることも当業者には理解されるところである。

１０情報処理システム、１８決済専用端末、２０決済ＧＷ装置、３０入力部、４２金額取得部、４４取引情報送信部、４８取引結果転送部、６２記憶部、７０共通取引情報取得部、７４個別取引情報送信部、７８取引結果送信部、８０端末更新部。

Claims

電話、郵便、宅配便、またはファクシミリを介して顧客から注文を受け付ける企業に設置されたクレジットカード決済のための専用装置であって、
本装置は、前記企業のネットワークに未接続であり、
前記企業のネットワークに接続された外部装置であって、専用の通信経路を介して本装置と接続された第１の外部装置に入力された、前記注文に係る金額の情報を取得する取得部と、
前記企業の従業員により顧客のクレジットカードの情報が入力される入力部と、
前記取得部により取得された金額の情報と、前記入力部に入力されたクレジットカードの情報を、携帯電話通信網を介して、クレジットカード決済を支援する第２の外部装置へ送信する取引情報送信部と、
を備えることを特徴とする決済支援装置。
前記第２の外部装置から送信された取引結果を示す情報を前記第１の外部装置へ送信する取引結果転送部をさらに備え、
前記取引結果を示す情報は、決済に使用されたクレジットカードごとに割り当てられたユニークなＩＤを含むが、前記入力部に入力された当該クレジットカードの情報を含まないことを特徴とする請求項１に記載の決済支援装置。
電話、郵便、宅配便、またはファクシミリを介して顧客から注文を受け付ける企業、または、その企業に設置されたクレジットカード決済のための専用装置と、決済代行事業者との対応関係を記憶する記憶部と、
前記専用装置から携帯電話通信網へ送信された、前記注文に係る金額の情報と、顧客のクレジットカードの情報とを含む取引情報を取得する取得部と、
前記取得部により取得された取引情報を、複数の決済代行事業者のうち前記記憶部において前記企業または前記専用装置に対応付けられた決済代行事業者の装置へ送信する取引情報送信部と、
を備えることを特徴とする決済仲介装置。
前記決済代行事業者の装置から送信された取引結果を示す情報を前記専用装置へ送信する取引結果送信部をさらに備え、
前記取引結果を示す情報は、決済に使用されたクレジットカードごとに割り当てられたユニークなＩＤを含むが、前記専用装置から送信された当該クレジットカードの情報を含まないことを特徴とする請求項３に記載の決済仲介装置。
複数の企業に設置された複数の専用端末におけるソフトウェアと、暗号化通信のための鍵の少なくとも一方を、前記携帯電話通信網を介して更新する更新部をさらに備えることを特徴とする請求項３または４に記載の決済仲介装置。