JP2005174207A - 決済確認機能を有するサーバ及び決済確認方法 - Google Patents

Abstract

【課題】インターネット上での売買その他あらゆる決済において、決済行為者が本人であるかどうかを、簡易な方法でかつ安全に確認を行い、不正な決済を防止することができる決済確認システムを得る。
【解決手段】予めユーザが登録したメールアドレスを決済管理サーバに登録しておき、当該ユーザの決済指定情報を受信した際に、登録されているメールアドレスへ決済確認メールを送信し、前記メール受信者によりメール送信に伴い決済確認を行うための決済確認Ｗｅｂページから当該決済の承諾可否の通知を受け、前記通知が承諾の場合に当該決済は有効と判定し、その他の場合は当該決済を無効と判定する手段を有する。
【選択図】図１

Description

本発明は、購入代金の決済を確認する決済確認サーバ及び決済確認方法に関し、特に、インターネットを利用した商取引やカタログ通販やテレビショッピングなどの非対面取引に伴う代金決済において、取引行為に関連して決済指定情報を指定した者と実際の支払者との同一性を容易に確認することができ、成りすましなどの不正な決済を防止することができる決済確認機能を有するサーバ及び決済確認方法に関する。

今日、インターネットショッピングやカタログ通販やテレビショッピングなど様々な非対面取引が行われている。これらの非対面取引における代金決済については、クレジットカードやデビットカードやネット用のプリペイドカードなどの決済機能を有するカードなどが広く利用されている。これらクレジットカードやデビットカードなどによって決済を行う場合は、一般に、カードの番号や口座番号などが支払者又は販売者を通じてクレジットカードカード会社や金融機関に通知され、当該カード番号や口座番号が正しいものであることが確認されれば、当該決済が正しいものとして処理される。
しかしながら、非対面取引では、対面取引とは異なり、販売者又は決済者は運転免許証やパスポートなどの身分証明証を確認することはできない。したがって、このような非対面取引における販売者又は決済者は、カード番号や口座番号などの決済指定情報の入力者と本人（カード所有者、口座所有者）との同一性を確認することができない。よって、従来の決済確認システムでは、無効になっていないカード番号や口座番号が通知されてしまうと当該取引を本人による取引として処理せざるを得ず、容易に成りすましができてしまう。
そこで、従来、この成りすましを防止すべく、カード会社が管理する決済サーバ（クレジットカード決済サーバやデビットカード決済サーバなど）からユーザ登録をした本人へ決済確認メールを送信し、本人の確認がとれた場合にのみ決済を有効とするシステムが提案された（特許文献１、特許文献２参照）。
特開２００２−３４２６８７号公報 特開２００２−４２０３４号公報

しかしながら、上記従来の方法を導入するためには、各カード会社が相当の出費をして自己が管理する決済サーバの改造を行わなければならない。
また、上記従来の方法では、カード会社ごとに決済サーバのセキュリティレベルが異なり得るため、セキュリティレベルの低いカード会社のカードを所有するユーザについては成りすましを防止することができない。
また、カード会社によってセキュリティレベルが異なると、カード取り扱い時の運用（障害時のユーザ対応や、原因解明など）に負担がかかるので、上記従来の方法は、カードの加盟店にとっても、システム上の運用管理やユーザ対応などの点で不満が残るものであった。
そこで、かかる事情に鑑み、本発明は、特に非対面で取引が行われるインターネットの取引決済や通信販売による取引決済および、その他の決済において、当該決済指定情報の指定行為が本人によるものなのか本人以外の第三者によるものなのかを容易に確認することができるとともに、カード会社の出費が低く、また、カード会社によって成りすましを防止できたりできなかったりということがなく、さらには、カードの加盟店も満足のいく、決済確認機能を有するサーバおよび決済確認方法を提供することを目的とする。

本発明によれば、上記課題は、次の手段によって解決される。

第１の発明は、ユーザ情報とユーザのメールアドレスとを関連づけて管理するユーザ管理ファイル、を記憶する記憶手段と、前記ユーザ情報を含むユーザが指定した決済指定情報を受信する手段と、当該決済に関する承諾又は拒否を受付けるための確認ツールを含む決済確認Ｗｅｂページを作成する手段と、前記作成した決済確認Ｗｅｂページへのリンク機能を貼付した決済確認メールを作成する手段と、前記作成した決済確認メールを、前記ユーザ管理ファイルにおいて前記受信したユーザ情報と関連づけられているメールアドレスへ送信する手段と、前記決済確認Ｗｅｂページに含まれる確認ツールにより当該決済に関する承諾又は拒否を受付ける手段と、前記決済に関する承諾又は拒否の受付け結果にもとづいて当該決済を有効とするか無効とするかを判定する手段と、を備えることを特徴とする決済確認機能を有するサーバである。

第２の発明は、ユーザ情報とユーザのメールアドレスとを関連づけて管理するユーザ管理ファイル、を記憶する記憶手段と、前記ユーザ情報を含むユーザが指定した決済指定情報を受信する手段と、当該決済に関する承諾又は拒否を受付けるための確認ツールを含む決済確認メールを作成する手段と、前記作成した決済確認メールを、前記ユーザ管理ファイルにおいて前記受信したユーザ情報と関連づけられているメールアドレスへ送信する手段と、前記決済確認メールに含まれる確認ツールにより当該決済に関する承諾又は拒否を受付ける手段と、前記決済に関する承諾又は拒否の受付け結果にもとづいて当該決済を有効とするか無効とするかを判定する手段と、を備えることを特徴とする決済確認機能を有するサーバである。

第３の発明は、ユーザ情報とユーザのメールアドレスとを関連づけてユーザ管理ファイルで管理するステップと、前記ユーザ情報を含むユーザが指定した決済指定情報を受信するステップと、当該決済に関する承諾又は拒否を受付けるための確認ツールを含む決済確認Ｗｅｂページを作成するステップと、前記作成した決済確認Ｗｅｂページへのリンク機能を貼付した決済確認メールを作成するステップと、前記作成した決済確認メールを、前記ユーザ管理ファイルにおいて前記受信したユーザ情報と関連づけられているメールアドレスへ送信するステップと、前記決済確認Ｗｅｂページに含まれる確認ツールにより当該決済に関する承諾又は拒否を受付けるステップと、前記決済に関する承諾又は拒否の受付け結果にもとづいて当該決済を有効とするか無効とするかを判定するステップと、を決済確認機能を有するサーバにおいて有することを特徴とする決済確認方法である。

第４の発明は、ユーザ情報とユーザのメールアドレスとを関連づけてユーザ管理ファイルで管理するステップと、前記ユーザ情報を含むユーザが指定した決済指定情報とを受信するステップと、当該決済に関する承諾又は拒否を受付けるための確認ツールを含む決済確認メールを作成するステップと、前記作成した決済確認メールを、前記ユーザ管理ファイルにおいて前記受信したユーザ情報と関連づけられているメールアドレスへ送信するステップと、前記決済確認メールに含まれる確認ツールにより当該決済に関する承諾又は拒否を受付けるステップと、前記決済に関する承諾又は拒否の受付け結果にもとづいて当該決済を有効とするか無効とするかを判定するステップと、を決済確認機能を有するサーバにおいて有することを特徴とする決済確認方法である。

本発明によれば、インターネット取引や通信販売取引などの主として非対面取引での決済において、本人以外の第三者による不正決済を防止し、安全な決済を実現することが可能となる。
また、本発明に係る決済確認サーバを用いれば、各カード会社による決済サーバの改造は不要となるため、成りすまし防止のために必要となるカード会社の出費を抑えることができる。
また、本発明によれば、すべてのカードが同一のセキュリティレベルで処理されるため、どのカード会社のカードを使用したかにかかわりなく、成りすましを防止することができる。
また、本発明によれば、すべてのカードが同一のセキュリティレベルで処理されるため、カード取り扱い時における運用（障害時のユーザ対応や、原因解明など）の負担を軽減できる。
このように、本発明によれば、カード会社、カードの加盟店、ユーザの３者が満足のいく、決済確認システムを実現することができる。よって、本発明によれば、インターネットビジネスや通信販売ビジネス市場を拡大することができる。

本発明を実施するための最良の形態として、図１に記載のシステムを示す。図１のシステムは、ユーザ１０、ユーザ１０のパソコン２０、パソコン２０にインターネット３０を介して接続された決済管理サーバ４０、決済管理サーバ４０に通信網８０を介して接続されたクレジットカード決済サーバ９０およびデビットカード決済サーバ１００を備えている。また、決済管理サーバ４０の記憶手段には、ユーザ管理ファイル５０、決済確認ファル６０、決済確認Ｗｅｂページ７０が記憶されている。
図２は、決済管理サーバ４０の記憶手段に記憶されているユーザ管理ファイル５０のデータレコードの一例を示す図である。ユーザ管理ファイルは、ユーザ情報を管理するためのファイルであり、このファイルのデータレコードには、管理するユーザを識別するためにユーザ毎に付与されるＩＤ番号欄５１、ユーザの氏名欄５２、ユーザの住所欄５３、ユーザ登録日欄５４、ユーザのメールアドレス欄５５、ユーザの性別欄５６、ユーザの生年月日欄５７、ユーザの趣味欄５８、その他ユーザに関する情報を登録する欄が設けられている。
図３は、決済管理サーバ４０の記憶手段に記憶されている決済管理ファイル６０のデータレコードの一つの例を示す図である。決済管理ファイル６０は、決済を確認するためのファイルであり、このファイルのデータレコードには、ユーザのＩＤ番号欄６１、決済年月日欄６２、決済を管理するためのカウンター番号欄６３、支払金額欄６４、支払方法欄６５、確認年月日欄６６、確認結果欄６７、およびその他の管理に必要な情報を登録する欄が設けられている。
図４は、決済管理サーバ４０がユーザ登録したユーザに対して送信する決済確認メールのイメージを表した図、および決済確認メールの受信者が決済確認メールに基づいて決済の確認を行うための決済確認Ｗｅｂページのイメージ図である。
図４において、１１０、１２０は、決済管理サーバから送信される決済確認メールの一例を示す図であり、１１０は決済確認Ｗｅｂページへのリンクボタンが貼付してある場合の例であり、１２０は決済ＯＫ、決済ＮＯの意思を決済管理サーバ４０側へ通知するボタンが決済確認メールに直接貼付されている場合の例を示す。また、７０は決済確認メール１１０のリンクボタンをクリックすることによりユーザ側のパソコンに送出される決済確認Ｗｅｂページの例を示す図で、ユーザに決済の内容を示すとともに、決済ＯＫ、決済ＮＯの意思を決済管理サーバ４０側に通知するボタンが貼付されている。
図５は、決済指定情報を受信した決済管理サーバ４０がユーザ管理ファイル５０に登録されているメールアドレスに対して決済確認メール１１０又は１２０を送信するまでの処理の流れの一例を示す図である。
図６は、決済管理サーバ４０が送信した決済確認メール１１０の受信者が当該メールを受信して、決済ＯＫ、決済ＮＯの意思を決済管理サーバ４０へ通知する処理の流れの一例を示す図である。なお、この図は、決済確認メール１１０に決済確認Ｗｅｂページ７０へのリンクボタンが貼付されている例についてのものであり、リンク先の決済確認Ｗｅｂページ７０から決済ＯＫ、決済ＮＯの意思が通知される。

つぎに、インターネット上のショッピングサイトにおける物品の売買に伴う代金決済に本発明を応用した場合の実施例を説明する。
本実施例の決済サーバを利用してインターネット上のショッピングサイトで物品の売買に伴う代金決済サービスを利用する場合、ユーザ１０は予め決済管理サーバ４０に対して、ユーザ登録を行い、氏名「山田太郎」、住所「東京都文京区本郷・ ・ ・」、生年月日「昭和４０年１月１日」、性別「男」、趣味「テニス」、メールアドレス「ｙａｍａｄａ．ｔａｒｏｕ＠ａｂｃｄ．ｎｅ．ｊｐ」をユーザ管理ファイルに登録しておく。本実施例においては、決済の確認にメールアドレスを利用するため、代金決済を行う前にこのユーザ登録を完了しておく必要がある。
決済管理サーバ４０に対してユーザ登録手続を実行すると、決済管理サーバ４０は、個々のユーザを識別するためのＩＤ番号をユーザごとに付与し、この付与したＩＤ番号を当該登録ユーザ１０に通知するとともに、前記ユーザ管理ファイル５０のＩＤ番号欄５へ登録しておく。なお、ＩＤ番号を利用するための許可情報としてパスワードを設定しセキュリティを高めることは、実際のシステムとしては必要であるが、本実施例の重要な構成要件ではないので、パスワード処理に関する説明は省略する。

こうして決済管理サーバ４０に対するユーザ登録手続が完了すれば、ユーザ１０は、ユーザ１０のパソコン２０を用いてインターネット上のショッピングサイトで物品を購入し、その購入代金の支払（以下「決済」という）を本実施例に係るシステムの決済管理サーバ４０を通じて行うことができる。
決済を行う場合、ユーザは、決済管理サーバ４０から与えられたＩＤ番号や支払金額や支払方法などの決済指定情報を、インターネットショッピングサイト若しくは、決済管理サーバ４０が提供する決済受付けサイトから決済管理サーバ４０へ送信する。ユーザは、クレジットカード、デビットカード、ネットバンキング、ネット用プリペイド、その他電子マネーなどの中から支払方法を選択できる。
なお、インターネットショッピングサイトを経由して決済管理サーバ４０に決済指定情報を送信すれば、支払先や支払金額などはインターネットショッピングサイト側が保有しているので、ユーザ１０による指定を省略することができる。また、インターネットショッピングサイトとのシステム連携をせずに、ユーザ１０が決済管理サーバ４０に対して決済指定情報を直接送信する場合は、支払先や支払金額をユーザ１０が指定するようにする。

ユーザ１０から決済指定情報を受信した決済管理サーバ４０は、ユーザ１０が指定した支払方法を確認し、ユーザ１０がクレジットカードによる決済を指定した場合であれば、ユーザ１０が指定したクレジットカード番号による決済が可能かどうかを当該クレジットカードの決済を提供するクレジットカード決済サーバ９０へ照会する。なお、ユーザ１０がデビットカートによる決済を指定した場合は、決済が可能かどうかデビットカード決済サーバ１００へ照会する。

決済管理サーバ４０からユーザが指定したクレジットカード番号による決済が可能かどうかの照会を受けたクレジットカード決済サーバ９０では、前記照会のあったクレジットカード番号で当該支払金額の決済が可能かをチェックしてその結果を決済管理サーバ４０へ送信する。クレジットカード決済が可能かどうかの判断方法は、当該クレジットカード番号が紛失カードや盗難カードに該当していないこと、当該クレジットカード番号による利用残高が当該支払金額を含めて所定の利用限度額を超えないこと、当該クレジットカード番号の利用に関して未払いがないことなどをチェックし、問題がなければ決済を可とし問題があれば不可と判定する。

クレジットカード決済サーバ７０から当該クレジットカード番号による決済可否のチェック結果を受信した決済管理サーバ４０は、その結果が決済可能であると判断されていた場合は、登録ユーザによる決済の確認を行うための決済確認Ｗｅｂページ７０を作成して記憶手段に格納しておく。決済確認Ｗｅｂページ７０はブラウザで表示可能な形式で作成され、決済確認メール１１０の受信者からの読み出し要求に対して記憶手段から読み出され、決済確認メール１１０の受信者のパソコンなどで表示される。なお、１つのＩＤ番号で複数の決済確認が生じる場合が考えられるため、決済確認を特定するためのカウンター番号を決定して前記決済確認Ｗｅｂページ７０に付与して記憶しておく。
例えば、ユーザ「ＩＤＮ３２」が３つの物品の購入代金の決済をする場合であれば、「００１」、「００２」、「００３」のようにそれぞれの決済に対応してカウンター番号が決定され、ＩＤ番号＋カウンター番号を単位として、前記決済確認Ｗｅｂページが作成される。図４の決済確認Ｗｅｂページ７０は、ＩＤ番号が「ＩＤＮ３２」でカウンター番号が「００１」の場合を示している。

つづいて、決済の指定をしたユーザが、ユーザ登録されている本人からのものであるかどうかを確認するため、決済管理サーバ４０は、ユーザ１０が決済指定情報に指定したＩＤ番号に基づいて、ユーザ管理ファイル５０を検索して該当ＩＤ番号のデータレコードのメールアドレスあてに決済確認メール１１０を送信する。
決済確認メール１１０には、前記作成した決済確認Ｗｅｂページ７０へのリンクボタンが貼付されており、メール受信者はこのリンクボタンをクリックすることで、前記決済確認Ｗｅｂページ７０にジャンプして決済の内容を確認する。

また、決済確認Ｗｅｂページ７０には、支払先、支払金額、支払方法、などの決済の内容の他に、確認ツールとして、決済を承諾するためのＯＫボタン、決済を拒否するためのＮＯボタンが貼付されており、メール受信者は決済の内容に問題がなければＯＫボタンをクリックし、決済の内容に問題があればＮＯボタンをクリックすることで、当該決済についての承諾可否を通知して決済管理サーバ４０に当該決済の承諾可否を認識させることができる。
前記のように決済確認メール１１０に決済確認Ｗｅｂページ７０へのリンクボタンを貼付する場合の他、確認ツールとして、決済確認Ｗｅｂページ７０に貼付するＯＫボタンとＮＯボタンの機能を直接決済確認メール１２０のように貼付しておき、メール受信者は受信したメールからダイレクトに決済の確認および決済の承諾可否を通知して決済管理サーバ４０に当該決済の承諾可否を認識させることもできる。

メール受信者により、当該決済の承諾可否の通知を受付けた決済管理サーバ４０は、前記通知がＯＫであれば当該決済は登録ユーザ本人が承諾したものであり有効と判定して、当該決済行為者へ手続完了などの通知をし、またクレジットカード決済サーバ９０へも有効に処理された旨を通知して当該決済確認処理を終了する。なお、メール受信者からＮＯの通知を受付けた場合は、当該決済行為者が登録ユーザ本人でない、又は支払金額などの内容に誤りがあるものとして当該決済を無効と判定し決済行為者およびクレジットカード決済サーバ９０へその旨を通知して当該決済確認処理を終了する。また、決済確認メール１１０又は１２０の送信時を起算時として応答時間期限を設定しておき、メール受信者からこの時間期限内に承諾可否の通知が無かった場合も当該決済を無効と判定するようにしてもよい。

このように、本実施例では、インターネットショッピングの決済において、ＩＤ番号を指定した人物が、決済管理サーバ４０に事前登録したユーザ本人であるかどうかを確認する方法として、ユーザ管理ファイル５０に登録してある当該ＩＤ番号のメールアドレス（ユーザ登録者本人のメールアドレス）へ決済確認メール１１０又は１２０を送信し、前記決済確認メール１１０又は１２０の受信者がその決済の内容を確認するようにしているので、登録ユーザ本人以外の人物が当該ユーザのＩＤ番号を用いて決済行為をしたとしても、本人でないことを容易に発見することができる。
また、本実施例では、ユーザ情報がユーザのＩＤ番号の場合の例を示したが、ユーザ情報は、例えばユーザのメールアドレスであったり、ユーザの氏名と生年月日の組み合わせや、ユーザの携帯電話番号など、決済確認のためのメールアドレスを特定することができる情報であれば何でもよい。
なお、本発明の実施適用例として、インターネット上のショッピングサイトにおける物品等の売買に伴う代金決済を行う場合で説明したが、本発明は、物品の売買代金決済の確認に限定されるものではなく、たとえば同窓会やＯＢ会その他の団体・サークルなどにおける会費の集金を行う際の確認や、募金、寄付金等の収受に関する確認などにも利用することができる。

本発明によればインターネットショッピング、カタログ通信販売、その他の場合の決済において、決済行為が本人によるものであるかどうかを確認する手段を提供できる。本発明は特に非対面の決済場面での利用効果が高いので、本発明をインターネットショッピングなどの決済に導入すれば、消費経済の活性化を図ることができる。

本発明を実施するための最良の形態を示す図である。 ユーザ管理サーバ５０のデータレコードの例を示す図である。 決済確認ファイル６０のデータレコードの例を示す図である。 決済確認メール、決済確認Ｗｅｂページ、決済確認ファイルの関係の例を示す図である。 決済確認メールを送信するまでの処理の流れの例を示す図である。 決済確認処理の流れの例を示す図である。

符号の説明

１０ ユーザ
２０ ユーザの使用するパソコン
３０ インターネット
４０ 決済管理サーバ
５０ ユーザ管理ファイル
５１ ＩＤ番号欄
５２ 氏名欄
５３ 住所欄
５４ 登録日欄
５５ メールアドレス欄
５６ 性別欄
５７ 生年月日欄
５８ 趣味欄
６０ 決済確認ファイル
６１ ＩＤ番号欄
６２ 年月日欄
６３ カウンター番号欄
６４ 支払金額欄
６５ 支払方法欄
６６ 確認年月日欄
６７ 確認結果欄
７０ 決済確認Ｗｅｂページ
８０ 通信網（決済サーバとの通信）
９０ クレジットカード決済サーバ
１００ デビットカード決済サーバ
１１０ 決済確認メール

Claims (4)

1. ユーザ情報とユーザのメールアドレスとを関連づけて管理するユーザ管理ファイル、を記憶する記憶手段と、
   前記ユーザ情報を含むユーザが指定した決済指定情報を受信する手段と、
   当該決済に関する承諾又は拒否を受付けるための確認ツールを含む決済確認Ｗｅｂページを作成する手段と、
   前記作成した決済確認Ｗｅｂページへのリンク機能を貼付した決済確認メールを作成する手段と、
   前記作成した決済確認メールを、前記ユーザ管理ファイルにおいて前記受信したユーザ情報と関連づけられているメールアドレスへ送信する手段と、
   前記決済確認Ｗｅｂページに含まれる確認ツールにより当該決済に関する承諾又は拒否を受付ける手段と、
   前記決済に関する承諾又は拒否の受付け結果にもとづき当該決済を有効とするか無効とするかを判定する手段と、
   を備えることを特徴とする決済確認機能を有するサーバ。
2. ユーザ情報とユーザのメールアドレスとを関連づけて管理するユーザ管理ファイル、を記憶する記憶手段と、
   前記ユーザ情報を含むユーザが指定した決済指定情報を受信する手段と、
   当該決済に関する承諾又は拒否を受付けるための確認ツールを含む決済確認メールを作成する手段と、
   前記作成した決済確認メールを、前記ユーザ管理ファイルにおいて前記受信したユーザ情報と関連づけられているメールアドレスへ送信する手段と、
   前記決済確認メールに含まれる確認ツールにより当該決済に関する承諾又は拒否を受付ける手段と、
   前記決済に関する承諾又は拒否の受付け結果にもとづき当該決済を有効とするか無効とするかを判定する手段と、
   を備えることを特徴とする決済確認機能を有するサーバ。
3. ユーザ情報とユーザのメールアドレスとを関連づけてユーザ管理ファイルで管理するステップと、
   前記ユーザ情報を含むユーザが指定した決済指定情報を受信するステップと、
   当該決済に関する承諾又は拒否を受付けるための確認ツールを含む決済確認Ｗｅｂページを作成するステップと、
   前記作成した決済確認Ｗｅｂページへのリンク機能を貼付した決済確認メールを作成するステップと、
   前記作成した決済確認メールを、前記ユーザ管理ファイルにおいて前記受信したユーザ情報と関連づけられているメールアドレスへ送信するステップと、
   前記決済確認Ｗｅｂページに含まれる確認ツールにより当該決済に関する承諾又は拒否を受付けるステップと、
   前記決済に関する承諾又は拒否の受付け結果にもとづいて当該決済を有効とするか無効とするかを判定するステップと、
   を決済確認機能を有するサーバにおいて有することを特徴とする決済確認方法。
4. ユーザ情報とユーザのメールアドレスとを関連づけてユーザ管理ファイルで管理するステップと、
   前記ユーザ情報を含むユーザが指定した決済指定情報を受信するステップと、
   当該決済に関する承諾又は拒否を受付けるための確認ツールを含む決済確認メールを作成するステップと、
   前記作成した決済確認メールを、前記ユーザ管理ファイルにおいて前記受信したユーザ情報と関連づけられているメールアドレスへ送信するステップと、
   前記決済確認メールに含まれる確認ツールにより当該決済に関する承諾又は拒否を受付けるステップと、
   前記決済に関する承諾又は拒否の受付け結果にもとづいて当該決済を有効とするか無効とするかを判定するステップと、
   を決済確認機能を有するサーバにおいて有することを特徴とする決済確認方法。

Images