以下、図面を参照して本発明の実施形態について説明する。なお、以下に説明する実施の形態は、電子決済システムに対して本発明を適用した場合の実施形態である。
[1.電子決済システムの構成及び機能概要]
先ず、図1等を参照して、本実施形態に係る電子決済システムSの構成及び概要機能について説明する。図1は、本実施形態に係る電子決済システムSの概要構成例を示す図である。図1に示すように、電子決済システムSは、ユーザ端末1、店舗端末2、第1電子マネー管理サーバ3、第2電子マネー管理サーバ4、クレジットカード管理サーバ5、ポイント管理サーバ6、口座管理サーバ7、及びウォレットサーバ8等を含んで構成される。第1電子マネー管理サーバ3、第2電子マネー管理サーバ4、クレジットカード管理サーバ5、ポイント管理サーバ6、口座管理サーバ7、及びウォレットサーバ8は、それぞれ、ネットワークNWに接続されている。ネットワークNWは、例えば、インターネット、移動体通信網(基地局等を含む)、及びゲートウェイ等により構築される。なお、クレジットカード管理サーバ5、口座管理サーバ7、及びウォレットサーバ8は、例えば専用回線を介して、金融機関(例えば銀行、信用金庫、信用組合、労働金庫等)により運営される金融機関システム9に接続可能になっている。金融機関システム9は、多数の口座を有し、クレジットカード管理サーバ5、口座管理サーバ7、またはウォレットサーバ8からの要求によって、口座間の資金移動が行うことが可能なコンピュータシステムである。
ユーザ端末1は、制御部11、記憶部12、操作・表示部13、HTTP(Hypertext Transfer Protocol)等に基づく通信機能を有する通信部14、及び近距離無線通信(例えばNFC(Near field radio communication)、BLE(Bluetooth Low Energy)、IrDA(Infrared Data Association)などの規格に準拠した通信)機能を有する近距離無線通信部15等を含んで構成される。なお、ユーザ端末1には、スマートフォン、携帯電話機、タブレット端末、PDA(Personal Digital Assistant)、または携帯ゲーム機などの携帯端末が適用されるとよい。制御部11は、CPU(Central Processing Unit),ROM(Read Only Memory),及びRAM(Random Access Memory)等を備える。
記憶部12は、OS(Operating System),アプリケーションプログラム,及びWebブラウザプログラム等を記憶する。ユーザ端末1にインストールされるアプリケーションプログラムには、取引対象(商品またはサービス)に対する決済を求めるユーザが利用可能な複数の決済方法のうち少なくとも1つの決済方法による決済(これを、「実決済」という)の前段階で暫定的(一時的)に行われる仮の決済(これを、「仮決済」という)を要求することが可能なユーザ側仮決済用プログラムが含まれる。このような決済方法の例として、電子マネー決済、クレジット決済、ポイント決済、及び即時引落決済が挙げられる。また、記憶部12には、ユーザ端末1のユーザのユーザID(ユーザの識別情報)が記憶されている。このユーザIDは、例えばユーザ側仮決済用プログラムがユーザ端末1にインストールされたときに表示される設定画面から入力される。なお、本実施形態では、ユーザ端末1、第1電子マネー管理サーバ3、第2電子マネー管理サーバ4、クレジットカード管理サーバ5、ポイント管理サーバ6、口座管理サーバ7、及びウォレットサーバ8で管理されるユーザIDは、同じユーザについて同一であるものとするが、同じユーザについて各サーバ間で異なるユーザIDが管理されてもよく、この場合、例えばウォレットサーバ8で同じユーザの複数のユーザIDが互いに対応付けられて管理される。操作・表示部13は、例えば、ユーザの指やペン等による操作を受け付ける入力機能と、情報を表示する表示機能を有するタッチパネルを備える。
制御部11は、OS上でユーザ側仮決済用プログラムを実行することにより、後述するように、取引対象に対する仮決済をウォレットサーバ8へ要求するための処理等を実行する。なお、ユーザ側仮決済用プログラムは、所定のサーバからユーザ端末1にダウンロードされてもよいし、CD、DVDなどの記録媒体に記録(コンピュータにより読み取り可能に記録)されており、当該記録媒体から読み込まれて記憶部12に記憶されるようにしてもよい。また、制御部11は、通信部14によりネットワークNWを介して所定のWebサーバ(図示せず)、第1電子マネー管理サーバ3、第2電子マネー管理サーバ4、クレジットカード管理サーバ5、ポイント管理サーバ6、口座管理サーバ7、及びウォレットサーバ8等との間で通信を行うことが可能になっている。また、制御部11は、近距離無線通信部15により店舗端末2との間で近距離無線通信を行うことが可能になっている。
店舗端末2は、制御部21、記憶部22、操作・表示部23、HTTP等に基づく通信機能を有する通信部24、近距離無線通信機能(例えばNFC、BLE、IrDAなどの規格に準拠した通信)を有する近距離無線通信部25、及び外部のリーダライタRWとのインターフェースを担うI/F26等を含んで構成される。なお、店舗端末2には、CAT(Credit Authorization Terminal)機能を備えるPOS(Point of sale)端末が適用されるとよい。制御部21は、CPU,ROM,及びRAM等を備える。記憶部22は、OS,アプリケーションプログラム,及びWebブラウザプログラム等を記憶する。店舗端末2にインストールされるアプリケーションプログラムには、上述した仮決済を要求することが可能な店舗側仮決済用プログラムと、通常の決済用プログラムとが含まれる。また、記憶部22には、店舗端末2が設置される店舗の店舗ID(店舗の識別情報)が記憶されている。この店舗IDは、例えば店舗側仮決済用プログラムが店舗端末2にインストールされたときに表示される設定画面から入力される。操作・表示部23は、例えば、店舗の店員の指やペン等による操作を受け付ける入力機能と、情報を表示する表示機能を有するタッチパネルを備える。
制御部21は、OS上で店舗側仮決済用プログラムを実行することにより、後述するように、取引対象に対する仮決済をウォレットサーバ8へ要求するための処理等を実行する。なお、店舗側仮決済用プログラムは、所定のサーバから店舗端末2にダウンロードされてもよいし、CD、DVDなどの記録媒体に記録(コンピュータにより読み取り可能に記録)されており、当該記録媒体から読み込まれて記憶部22に記憶されるようにしてもよい。また、制御部21は、通信部24によりネットワークNWを介して第1電子マネー管理サーバ3、第2電子マネー管理サーバ4、クレジットカード管理サーバ5、ポイント管理サーバ6、口座管理サーバ7、及びウォレットサーバ8等との間で通信を行うことが可能になっている。また、制御部21は、近距離無線通信部25によりユーザ端末1との間で近距離無線通信を行うことが可能になっている。また、制御部21は、I/F26によりリーダライタRWと通信を行うことが可能になっており、OS上で通常の決済用プログラムを実行することにより、ユーザが所有する決済用のカード(例えば国際標準規格等で寸法が定められた平板状のカードである)からリーダライタRWにより読み取られた情報を取得し、取得した情報に基づいて、通常の決済(電子マネー決済、クレジット決済、ポイント決済、または即時引落決済)を行うことができる。決済用のカードの例として、電子マネーカード、クレジットカード、ポイントカード、デビットカードなどがある。
ここで、電子マネーカードは、例えば非接触型ICチップ(ICモジュール)を備えており、当該ICチップの不揮発性メモリには、貨幣価値に対応させた電子バリューの残高、電子マネー番号、及びログデータ等の情報が記憶されている。この電子バリューは、ストアドバリュー型前払い式の電子マネー(以下、「ストアド型電子マネー」という)である。電子マネー番号は、電子マネーカード毎に固有の番号であり、これにより、電子マネーカードの発行対象者であるユーザを特定することができる。電子バリューの残高及び電子マネー番号等の情報は、電子マネーカードの非接触型ICチップから店舗端末2のリーダライタRWにより読み取られ、電子マネー決済(以下、「ストアド型電子マネー決済」という)に用いられる。ログデータの例として、利用履歴データ、及びチャージ履歴データがある。利用履歴データは、電子バリューが決済(支払い)に利用された履歴を示すデータであり、ストアド型電子マネー決済時に店舗端末2により生成される。利用履歴データには、例えば利用日(ストアド型電子マネー決済による決済日であり、例えば、年月日の他、時刻を含んでもよい、以下同様)、利用店舗名、及び利用額等の情報が含まれる。チャージ履歴データは、電子バリューがチャージ(つまり、電子バリューの残高が増額)された履歴を示すデータであり、電子バリューのチャージ時に店舗端末2により生成される。チャージ履歴データには、例えばチャージ日、及びチャージ額等の情報が含まれる。なお、ストアド型電子マネーを管理するアプリケーションプログラムが、ユーザ端末1にインストールされてもよい。この場合、ユーザ端末1に搭載される非接触型ICチップの不揮発性メモリには、電子バリューの残高等の情報が店舗端末2のリーダライタRWにより読み取り可能に記憶される。また、電子マネーカードは、後述するサーバ型前払い式の電子マネー(以下、「サーバ型電子マネー」という)の電子マネー番号等の情報を記憶するものであってもよい。この場合、サーバ型電子マネーの電子バリューの残高は、第2電子マネー管理サーバ4で管理される。
クレジットカードは、例えば非接触型ICチップを備えており、当該ICチップの不揮発性メモリには、クレジットカード番号、クレジットカードの発行対象者であるユーザの氏名、及びクレジットカードの有効期限等の情報が記憶されている。クレジットカード番号は、クレジットカード毎に固有の番号であり、これにより、クレジットカードの発行対象者であるユーザを特定することができる。クレジットカード番号、ユーザの氏名、及びクレジットカードの有効期限等の情報は、クレジットカードの非接触型ICチップから店舗端末2のリーダライタRWにより読み取られ、クレジット決済に用いられる。なお、電子マネーカードとクレジットカードとは一体型の共用カードであってもよい。この場合、共用カードの非接触型ICチップの不揮発性メモリには、電子バリューの残高等の情報と、クレジットカード番号等の情報とが店舗端末2のリーダライタRWにより読み取り可能に記憶される。なお、クレジットカードは、店舗端末2で通常の決済に利用される他にも、所定のWebサイト(例えばショッピングモールサイト)でのクレジット決済にも用いられる。或いは、クレジットカードは、定期的な支払いが生じる取引対象の支払金額(例えば、ガス代、水道代、その他の公共料金、家賃、保険料、携帯キャリア利用料金など)のクレジット決済にも用いられる。
ポイントカードには、ポイントカード番号がバーコードまたは2次元コードにより記載されている。ポイントカード番号は、ポイントカード毎に固有の番号であり、これにより、ポイントカードの発行対象者であるユーザを特定することができる。ポイントカード番号は、バーコードまたは2次元コードから店舗端末2のリーダライタRWにより読み取られ、ポイント決済に用いられる。なお、電子マネーカード(またはクレジットカード)とポイントカードとは一体型の共用カードであってもよい。この場合、共用カードの非接触型ICチップの不揮発性メモリには、電子バリューの残高等の情報(またはクレジットカード番号等の情報)と、ポイントカード番号とが店舗端末2のリーダライタRWにより読み取り可能に記憶される。或いは、ポイントカード番号を管理するアプリケーションプログラムが、ユーザ端末1にインストールされてもよい。この場合、ユーザ端末1に搭載される非接触型ICチップの不揮発性メモリには、ポイントカード番号が店舗端末2のリーダライタRWにより読み取り可能に記憶される。或いは、この場合、ユーザの操作に応じて当該ポイントカード番号を有するバーコードまたは2次元コードがユーザ端末1の操作・表示部13に表示され、当該バーコードまたは2次元コードから当該ポイントカード番号が店舗端末2のリーダライタRWにより読み取られてもよい。なお、ポイントカードは、店舗端末2で利用される他にも、所定のWebサイト(例えばショッピングモールサイト)でのポイント決済にも用いられる。
デビットカードは、例えば非接触型ICチップを備えており、当該ICチップの不揮発性メモリには、デビットカード番号、デビットカードの発行対象者であるユーザの氏名、デビットカードを発行した金融機関を識別する金融機関ID、及びデビットカードの有効期限等の情報が記憶されている。デビットカード番号は、デビットカード毎に固有の番号であり、これにより、デビットカードの発行対象者であるユーザを特定することができる。デビットカード番号、ユーザの氏名、金融機関コード、及びデビットカードの有効期限等の情報は、デビットカードの非接触型ICチップから店舗端末2のリーダライタRWにより読み取られ、即時引落決済(デビット決済)に用いられる。なお、キャッシュカードがデビットカードとして用いられる場合もある。なお、デビットカードは、店舗端末2で利用される他にも、所定のWebサイト(例えばショッピングモールサイト)においても即時引落決済に用いられる。なお、デビットカードは、店舗端末2で通常の決済に利用される他にも、所定のWebサイト(例えばショッピングモールサイト)での即時引落決済にも用いられる。或いは、デビットカードは、定期的な支払いが生じる取引対象の支払金額(例えば、ガス代、水道代、家賃、保険料、携帯キャリア利用料金など)の即時引落決済にも用いられる。この場合、例えば月毎に定められた支払金額が毎月の引落日にユーザの口座から自動的に引き落とされる。
第1電子マネー管理サーバ3は、ストアド型電子マネーの情報を管理するサーバである。第1電子マネー管理サーバ3の記憶部には、電子マネー番号、ストアド型電子マネーの電子バリューの残高、ログデータ、及びユーザID等の情報がユーザ毎に対応付けられて記憶される。上述したように、例えば店舗端末2においてストアド型電子マネー決済が行われた場合、店舗端末2からネットワークNWを介して第1電子マネー管理サーバ3へ、上記利用履歴データ、及び電子マネー番号が送信(例えば即時送信、または定期的に送信)され、第1電子マネー管理サーバ3の記憶部に記憶される。このとき、電子バリューの残高が更新される。なお、電子マネーカードの非接触型ICチップに記憶された電子バリューの残高と、この残高と同一の電子マネー番号が対応付けられている残高であって第1電子マネー管理サーバ3の記憶部に記憶されている電子バリューの残高とは、タイムラグにより一致しない場合がある。また、例えば店舗端末2において電子バリューのチャージが行われた場合、店舗端末2からネットワークNWを介して第1電子マネー管理サーバ3へ、上記チャージ履歴データ、及び電子マネー番号が送信(例えば即時送信、または定期的に送信)され、第1電子マネー管理サーバ3の記憶部に記憶される。このとき、電子バリューの残高が更新される。
第2電子マネー管理サーバ4は、サーバ型電子マネーの情報を管理するサーバである。サーバ型電子マネーの例として、インターネット上の所定のWebサイトで利用可能なオンライン電子マネーが挙げられる。第2電子マネー管理サーバ4の記憶部には、サーバ型電子マネーの電子バリューの残高、電子マネー番号、ログデータ、及びユーザID等の情報がユーザ毎に対応付けられて記憶される。ログデータの例として、上記と同様、利用履歴データ、及びチャージ履歴データがある。さらに、第2電子マネー管理サーバ4の記憶部には、サーバ型電子マネーの電子バリューの残高、及びサーバ型電子マネーの取扱い店舗を識別する店舗ID等の情報が店舗毎に対応付けられて記憶される。そして、第2電子マネー管理サーバ4は、所定のWebサイト(例えばショッピングモールサイト)におけるWebサーバへアクセスしたユーザ端末1からのサーバ型電子マネーによる決済要求(ユーザID、及び支払金額等を含む)に応じて、当該ユーザIDに対応付けられた電子バリューの残高を減らす(つまり、支払金額分だけ減額する)電子マネー決済(以下、「サーバ型電子マネー決済」という)を行う。このとき、第2電子マネー管理サーバ4は、利用履歴データを生成する。
クレジットカード管理サーバ5は、クレジットカードの情報を管理するサーバである。クレジットカード管理サーバ5の記憶部には、クレジットカード番号、クレジットカードの発行対象者であるユーザの氏名、クレジットカードの有効期限、与信限度額(与信枠)、利用可能額、利用履歴データ、ユーザ口座情報、及びユーザID等の情報がユーザ毎に対応付けられて記憶される。与信限度額は、例えばクレジットカードを利用した買い物やキャッシングの累積に対して許容される上限額である。利用可能額とは、現時点でクレジットカードを利用することができる総額(例えば、与信限度額から当月利用額を減じた額)である。利用履歴データは、クレジットカードが決済に利用された履歴を示すデータであり、クレジット決済による決済日に例えばクレジットカード管理サーバ5により生成される。この利用履歴データには、例えば利用日、利用店舗名、及び利用額等の情報が含まれる。この利用日は、例えば、クレジット決済による決済日である。ユーザ口座情報には、クレジット決済に係る支払金額が引き落とされる引落口座(ユーザの口座)の口座番号、引落日、及び当該口座を管理する金融機関を識別する金融機関ID等が含まれる。
さらに、クレジットカード管理サーバ5の記憶部には、クレジットカードの取扱い店舗(加盟店)を識別する店舗ID、及び店舗口座情報等の情報が店舗毎に対応付けられて記憶される。店舗口座情報には、クレジット決済に係る支払金額が振り込まれる口座(店舗の口座)の口座番号、及び当該口座を管理する金融機関を識別する金融機関ID等が含まれる。そして、クレジットカード管理サーバ5は、例えば店舗端末2或いは所定のWebサイトからの与信照会(クレジットカード番号、有効期限、及び支払金額等を含む)に応じてクレジットカードを用いたクレジット決済が可能であるか否かの与信照会を行い、例えば有効期限が過ぎておらず、且つ取引対象の支払金額が利用可能額を超えていない場合に、与信承認OKメッセージを店舗端末2へ返信する。なお、クレジットカードによる与信承認は、本発明において信用承認とは同じでなく区別されるものである。そして、与信承認OKメッセージが受信された場合、クレジット決済が行われる。すなわち、店舗端末2により売上が計上され、当該取引対象の支払金額を請求する請求データ(店舗ID及び支払金額を含む)がクレジットカード管理サーバ5へ送信され、さらに、クレジットカード管理サーバ5から金融機関システム9へ資金移動要求が送信される。これにより、当該取引対象の支払金額が立替払取次業者(例えば、クレジットカード会社)の口座(口座の残高)から引き落とされてユーザと取引を行った店舗の口座に振り込まれる。その後、当該取引対象の支払金額及び手数料が当該ユーザの口座から引き落とされる。
ポイント管理サーバ6は、所定の換算率で支払いに利用可能なポイントの情報を管理するサーバである。ポイント管理サーバ6の記憶部には、ポイントカード番号、残りポイント数(残高)、ログデータ、及びユーザID等の情報がユーザ毎に対応付けられて記憶される。このログデータの例として、利用履歴データ、及び獲得履歴データがある。利用履歴データは、ポイントが決済に利用された履歴を示すデータであり、例えばポイント決済時にポイント管理サーバ6により生成される。利用履歴データには、例えば利用日、利用店舗名、及び利用ポイント数等の情報が含まれる。獲得履歴データは、ポイントが獲得(例えば、商品購入、アンケート回答、或いはキャンペーン応募により残りポイント数が増加)された履歴を示すデータであり、ポイントの獲得時に例えばポイント管理サーバ6により生成される。獲得履歴データには、例えば獲得日、及び獲得ポイント数等の情報が含まれる。
さらに、ポイント管理サーバ6の記憶部には、残りポイント数、及びポイントの取扱い店舗を識別する店舗ID等の情報が店舗毎に対応付けられて記憶される。そして、ポイント管理サーバ6は、例えば店舗端末2または所定のWebサイトからのポイントによる決済要求(ポイントカード番号、及び支払金額等を含む)に応じて、当該ポイントカード番号に対応付けられた残りポイント数を減らす(つまり、支払金額を所定の換算率で換算したポイント分だけ減らす)ポイント決済を行う。このとき、ポイント管理サーバ6は、利用履歴データを生成する。
口座管理サーバ7は、口座の情報を管理するサーバである。口座管理サーバ7の記憶部には、デビットカード番号、デビットカードの発行対象者であるユーザの氏名、デビットカードの有効期限、ログデータ、ユーザ口座情報、及びユーザID等の情報がユーザ毎に対応付けられて記憶される。ログデータの例として、利用履歴データ、及び振込履歴データがある。利用履歴データは、デビットカードが決済に利用された履歴を示すデータであり、例えば即時引落決済時に口座管理サーバ7により生成される。この利用履歴データには、例えば利用日、利用店舗名、及び利用額等の情報が含まれる。振込履歴データは、デビット決済に利用される口座(ユーザの口座)に振込された履歴を示すデータであり、例えば振込時に口座管理サーバ7により生成される。この振込履歴データには、例えば振込日、及び振込額等の情報が含まれる。なお、ユーザの口座には、例えばユーザの給料など、定期的に振り込まれる場合(自動振込)がある。ユーザ口座情報には、即時引落決済に係る支払金額が引き落とされる口座(ユーザの口座)の口座番号、残高(預金残高)、及び当該口座を管理する金融機関を識別する金融機関ID等が含まれる。
さらに、口座管理サーバ7の記憶部には、デビットカードの取扱い店舗(加盟店)を識別する店舗ID、及び店舗口座情報等の情報が店舗毎に対応付けられて記憶される。店舗口座情報には、例えば即時引落決済に係る支払金額が振り込まれる口座(店舗の口座)の口座番号、及び当該口座を管理する金融機関を識別する金融機関ID等が含まれる。そして、口座管理サーバ7は、例えば店舗端末2または所定のWebサイトからの即時引落による決済要求(デビットカード番号、及び支払金額等を含む)に応じて、取引対象の支払金額の移動要求(ユーザの口座の口座番号、店舗の口座の口座番号、及び支払金額を含む)を金融機関システム9へ送信する。これにより、当該取引対象の支払金額がユーザの口座(口座の残高)から引き落とされて当該ユーザと取引を行った店舗の口座に振り込まれ、口座管理サーバ7が記憶するユーザ口座情報と店舗口座情報中の残高が更新される。このとき、口座管理サーバ7は、利用履歴データを生成する。なお、口座管理サーバ7は、金融機関システム9の構成要素として組み込まれてもよい。
ウォレットサーバ8は、上述した仮決済及び実決済を行うサーバである。すなわち、ウォレットサーバ8は、取引対象に対する決済を求めるユーザの代わりに当該取引対象の支払金額を一時的に立て替えて店舗へ支払い、その後、仮決済された支払金額を、当該ユーザが利用可能な1または複数の決済方法により実決済する。さらに、ウォレットサーバ8は、各決済方法で利用可能な金額の全部または一部のチャージを受け付け、決済方法毎に区別してチャージ額を管理するウォレット機能を有する。例えば、ウォレットサーバ8は、ユーザの操作により電子マネーカードからユーザ端末1により取得された電子バリューを取得し、当該ユーザ端末1のユーザのユーザIDに対応付けて記憶する。なお、サーバ型電子マネー決済、クレジット決済、ポイント決済、及び即時引落決済で利用可能な貨幣価値に対応するチャージ額をウォレット機能により管理することもできる。
図2は、ウォレットサーバ8のハードウェア構成例を示す図である。ウォレットサーバ8は、図2に示すように、通信部81、記憶部82、及びシステム制御部83等を備え、これらの構成要素はシステムバス84に接続されている。なお、ウォレットサーバ8は、サーバ装置の一例である。通信部81は、ネットワークNWに接続され、通信状態の制御を行う。システム制御部83は、通信部81によりネットワークNWを介して、ユーザ端末1、店舗端末2、第1電子マネー管理サーバ3、第2電子マネー管理サーバ4、ポイント管理サーバ5、クレジットカード管理サーバ6、及び口座管理サーバ7のそれぞれとの間で通信を行うことが可能になっている。なお、システム制御部83は、第1電子マネー管理サーバ3、第2電子マネー管理サーバ4、ポイント管理サーバ5、クレジットカード管理サーバ6、及び口座管理サーバ7のそれぞれと専用回線を介して通信してもよい。記憶部82は、例えば、ハードディスクドライブ等により構成されており、OS及び決済用プログラム(本発明の情報処理プログラムを含む)等の各種プログラムを記憶する。なお、決済用プログラムは、所定のサーバからウォレットサーバ8にダウンロードされてもよいし、CD、DVDなどの記録媒体に記録(コンピュータにより読み取り可能に記録)されており、当該記録媒体から読み込まれて記憶部82に記憶されるようにしてもよい。
また、記憶部82には、店舗情報データベース(DB)82a、ユーザ情報データベース(DB)82b、及び決済方法情報データベース(DB)82c等が構築される。なお、ウォレットサーバ8以外のサーバに設けられてもよい。図3(A)は、店舗情報データベース82aの内容の一例を示す図であり、図3(B)は、ユーザ情報データベース82bの内容の一例を示す図である。図4は、決済方法情報データベース82cの内容の一例を示す図である。
店舗情報データベース82aには、図3(A)に示すように、本電子決済システムSの利用登録を行った店舗の店舗ID、パスワード、店舗の名称、店舗の連絡先、及び店舗口座情報等の情報が店舗毎に対応付けられて格納されている。ここで、店舗ID及びパスワードは、ウォレットサーバ8へのログイン等の認証処理に用いられる。店舗の連絡先には、店舗の住所、電話番号、電子メールアドレス等が含まれる。また、店舗口座情報には、仮決済に係る支払金額が振り込まれる口座(店舗の口座)の口座番号、及び当該口座を管理する金融機関を識別する金融機関ID等が含まれる。なお、店舗情報データベース82aに格納される情報は、例えばそれぞれの店舗の店員の操作に応じてウォレットサーバ8にアクセスした店舗端末2からの設定要求に応じて格納される。
ユーザ情報データベース82bには、図3(B)に示すように、本電子決済システムSの利用登録を行ったユーザのユーザID、パスワード、ユーザの氏名、ユーザの連絡先、ユーザが所有するカードの番号等(クレジットカード番号の場合、ユーザの氏名、及びクレジットカードの有効期限が含まれてもよい)の情報がユーザ毎に対応付けられて格納されている。ここで、ユーザID及びパスワードは、ウォレットサーバ8へのログイン等の認証処理に用いられる。ユーザの連絡先には、ユーザの住所、電話番号、電子メールアドレス等が含まれる。図3(B)の例では、ユーザa(ユーザID:U0001)は、1つの電子マネーカードと、1つのクレジットカードと、1つのポイントカードと、1つのデビットカードとを所有している。また、ユーザb(ユーザID:U0002)は、2つの電子マネーカードと、1つのクレジットカードと、1つのデビットカードとを所有している。また、ユーザc(ユーザID:U0003)は、1つの電子マネーカードと、1つのデビットカードとを所有している。なお、ユーザ情報データベース82bに格納される情報は、例えばそれぞれのユーザの操作に応じてウォレットサーバ8にアクセスしたユーザ端末1からの設定要求に応じて格納される。
決済方法情報データベース82cには、図4に示すように、本電子決済システムSの利用登録を行ったユーザのユーザID、ユーザが利用可能な決済方法(例えば、決済方法を識別する決済種別IDでもよいし、文字列でもよい)、利用可能額、入出金履歴、割振の可否、割振の優先順位、及び利用ロック額等の情報がユーザ毎に対応付けられて格納されている。図4の例では、ユーザID“U0001”には、ユーザaが利用可能な決済方法として、電子マネー決済、クレジット決済、ポイント決済、及び即時引落決済が対応付けられている。また、ユーザID“U0002”には、ユーザbが利用可能な決済方法として、電子マネー決済1(例えば、ストアド型電子マネー決済)、電子マネー決済2(例えば、サーバ型電子マネー決済)、クレジット決済、及び即時引落決済が対応付けられている。また、ユーザID“U0003”には、ユーザcが利用可能な決済方法として、電子マネー決済、及び即時引落決済が対応付けられている。
また、図4に示す利用可能額及び入出金履歴は、ユーザが利用可能な決済方法の情報の一例である。電子マネー決済に対応付けられた利用可能額には、電子バリューの残高が該当する。電子マネー決済に対応付けられた入出金履歴中の入出金日には、利用履歴データに含まれる利用日(出金日)と、チャージ履歴データに含まれるチャージ日(入金日)とが該当する。電子マネー決済に対応付けられた入出金履歴中の入出金額には、利用履歴データに含まれる利用額(出金額:図4の例では、−(マイナス)で表す)と、チャージ履歴データに含まれるチャージ額(入金額:図4の例では、+(プラス)で表す)とが該当する。電子バリューの残高、利用履歴データ、及びチャージ履歴データは、例えばユーザIDまたは電子マネーカード番号をキーとして、第1電子マネー管理サーバ3または第2電子マネー管理サーバ4から所定のタイミング(定期的(例えば、1日毎)、或いは後述する信用承認額の算出の際など)で取得され、決済方法情報データベース82cに格納される。
一方、クレジット決済には、利用可能額と共に与信限度額が対応付けられており、利用可能額は、与信限度額から当月利用額を減じた額が該当する。例えばユーザID“U0001”、且つクレジット決済に対応付けられた入出金日“2016/1/15”の入出金額“\20,000”は当月利用額(2016/1/22時点)である。クレジット決済に対応付けられた利用履歴(図4の例では、便宜上、入出金履歴と記す)中の入出金日には、利用履歴データに含まれる利用日(決済日)が該当する。クレジット決済に対応付けられた利用履歴中の入出金額には、利用履歴データに含まれる利用額(決済額)が該当する。与信限度額、利用履歴データ、及びチャージ履歴データは、例えばユーザIDまたはクレジットカード番号をキーとして、クレジットカード管理サーバ5から所定のタイミング(定期的(例えば、1日毎)、或いは後述する信用承認額の算出の際など)で取得され、決済方法情報データベース82cに格納される。
一方、ポイント決済に対応付けられた利用可能額(ポイント決済の利用可能額)には、残りポイント数(残高)が該当する。ポイント決済に対応付けられた入出金履歴中の入出金日には、利用履歴データに含まれる利用日(出金日)と、獲得履歴データに含まれる獲得日(入金日)とが該当する。ポイント決済に対応付けられた入出金履歴中の入出金額には、利用履歴データに含まれる利用ポイント数を所定の換算率で通貨に換算した額(出金額)と、獲得履歴データに含まれる獲得ポイント数を所定の換算率で通貨に換算した額(入金額)とが該当する。残りポイント数、利用履歴データ、及び獲得履歴データは、例えばユーザIDまたはポイントカード番号をキーとして、ポイント管理サーバ6から所定のタイミング(定期的(例えば、1日毎)、或いは後述する信用承認額の算出の際など)で取得され、決済方法情報データベース82cに格納される。
一方、即時引落決済に対応付けられた利用可能額(即時引落決済の利用可能額)には、ユーザ口座情報に含まれる残高が該当する。即時引落決済に対応付けられた入出金履歴中の入出金日には、利用履歴データに含まれる利用日(出金日)と、振込履歴データに含まれる振込日(入金日)とが該当する。即時引落決済に対応付けられた入出金履歴中の入出金額には、利用履歴データに含まれる利用(出金額)と、振込履歴データに含まれる振込額(入金額)とが該当する。口座の残高、利用履歴データ、及び振込履歴データは、例えばユーザIDまたはデビットカード番号をキーとして、口座管理サーバ7から所定のタイミング(定期的(例えば、1日毎)、或いは後述する信用承認額の算出の際など)で取得され、決済方法情報データベース82cに格納される。
また、図4に示す割振の可否は、ユーザが利用可能な決済方法の情報の一例であり、仮決済された支払金額の割振候補(つまり、仮決済後の実決済に利用する候補)とするか否かを、ユーザが利用可能な決済方法毎に示す。なお、割振の可否は、それぞれのユーザにより任意に選択可能であり、例えばユーザの操作に応じてウォレットサーバ8にアクセスしたユーザ端末1からの設定要求に応じて更新される。また、図4に示す割振の優先順位は、ユーザが利用可能な決済方法の情報の一例であり、仮決済された支払金額の割り振り候補の中で優先して割り振る順番を示す。このような優先順位が高いほど支払金額が優先して割り振られる。なお、割振の優先順位は、それぞれのユーザにより任意に指定可能であり、例えばユーザの操作に応じてウォレットサーバ8にアクセスしたユーザ端末1からの設定要求に応じて更新される。また、図4に示す利用ロック額は、仮決済された支払金額が割り振られた決済方法の利用可能額のうち、割り振られた分の金額を示す。利用ロック額は、支払金額が割り振られた決済方法の利用可能額のうち、仮決済から実決済までの間に利用されること防止する額である。図4の例では、利用ロック額として¥0が格納されているが、支払金額の決済方法への割り振りが行われたときに、その割振額が利用ロック額として格納(更新)されることになる。
システム制御部83(本発明におけるコンピュータの一例)は、CPU(Central Processing Unit)83a(プロセッサ),ROM(Read Only Memory)83b,及びRAM(Random Access Memory)83c等を備え、OS上で決済用プログラム等を実行する。図5は、電子決済システムSの各構成要素の繋がりと、ウォレットサーバ8のシステム制御部83の機能ブロックとを示す図である。システム制御部83(システム制御部83内のプロセッサ)は、決済用プログラムを実行することにより、図5に示すように、ID取得部831、決済方法情報取得部832、信用承認額算出部833、仮決済判定部834、仮決済部835、支払金額割振部836、利用ロック部837、実決済部838、及び利用ロック解除部839等として機能する。なお、ID取得部831は、本発明における第1取得手段の一例である。決済方法情報取得部832は、本発明における第2取得手段の一例である。信用承認額算出部833は、本発明における算出手段の一例である。仮決済判定部834は、本発明における決定手段の一例である。仮決済部835は、本発明における仮決済手段の一例である。支払金額割振部836は、本発明における割振手段の一例である。利用ロック部837は、本発明におけるロック手段の一例である。実決済部838は、本発明における実決済手段の一例である。利用ロック解除部839は、本発明におけるロック解除手段の一例である。
ID取得部831は、取引対象に対する決済を求めるユーザのユーザIDを、例えばユーザ端末1から店舗端末2を介して取得する。なお、ID取得部831は、所定のWebサイト(例えばショッピングモールサイト)において店舗(いわゆる仮想店舗)とユーザとが取引を行う場合、ID取得部831は、当該Webサイトのサーバから、取引対象に対する決済を求めるユーザのユーザIDを取得してもよい。
決済方法情報取得部832は、ユーザ端末1のユーザが利用可能な複数の決済方法であって、ID取得部831により取得されたユーザIDに対応付けられている複数の決済方法のそれぞれの情報(例えば、利用可能額、及び入出金履歴)を決済方法情報データベース82cから取得する。
信用承認額算出部833は、決済方法情報取得部832により取得された、複数の決済方法のそれぞれの情報に基づいて、当該複数の決済方法のうち少なくとも1つの決済方法による実決済の前段階で暫定的に行われる仮決済で許容する信用承認額を算出する。図6は、信用承認額の算出例を示す図である。図6(A)〜(C)の例では、各決済方法の利用可能額から信用根拠額が算出され、算出された各信用根拠額を合計した合計値が信用承認額として算出されている。この信用根拠額は、信用承認額の算出根拠となる金額である。例えば、信用承認額の算出時点から実決済の実行予定日までの間に入出金が予測される金額を利用可能額から増減した金額が信用根拠額として算出される。
ここで、信用承認額の算出時点を2016/1/22とし、実決済の実行予定日を2016/1/31 0:00と仮定したときの信用根拠額について図4を参照して具体的に説明する。図4において、ユーザID“U0001”とクレジット決済に対応付けられた利用履歴から、毎月29日に\3,000が30日に\30,000がそれぞれ利用されていることが特定することができるので、2016/1/22から2016/1/31までの間に\33,000の利用が予測される。このため、信用承認額算出部833は、2016/1/22から2016/1/31までの間の利用額\33,000を、利用せずに残すべき金額(ユーザにとって残しておかなければならない金額)として特定し、図6(A)に示すように、クレジット決済に対応付けられた利用可能額\80,000から当該利用額\33,000を差し引いた残金額\47,000を信用根拠額として算出する。このように、信用承認額算出部833は、決済方法情報取得部832により取得された、決済方法の情報に含まれる決済方法の入出金履歴(この場合、利用履歴)及び利用可能額に基づいて、利用可能額から利用せずに残すべき金額を差し引いた残金額を算出し、当該残金額を信用根拠額として用いて信用承認額を算出することになる。これにより、ユーザの利用履歴から将来的に利用される可能性のある金額を除外して信用承認額を算出するので、より精度の高い(信頼性の高い)適切な信用承認額を算出することができる。すなわち、例えば、電子マネーなどは仮決済の後に、他の用途で利用されることが考えられるし、クレジットカードには携帯キャリア利用料金や公共料金などが毎月引き落とされるように設定されていたり、銀行口座からは毎月の家賃が引落があったりすることが考えられる。このような場合、仮決済時点において複数の決済方法にて支払可能な合計額にて信用承認すると、その後に他の用途で使われた決済により、実決済時には合計額が減っており決済できないことがあり得るが、ユーザの利用履歴から将来的に利用される可能性のある金額を除外して信用承認額を算出すれば実決済できないことを防止することができる。
なお、図4において、ユーザID“U0001”と電子マネー決済に対応付けられた入出金履歴からは、2016/1/22から2016/1/31までの間の出金は予測できない。このため、信用承認額算出部833は、利用せずに残すべき金額は\0となり、図6(A)に示すように、電子マネー決済に対応付けられた利用可能額\13,000を信用根拠額として算出することになる。
一方、図4において、ユーザID“U0001”と即時引落決済に対応付けられた入出金履歴から、毎月25日に\120,000が入金され、29日に\100,000が出金されていることが特定することができるので、2016/1/22から2016/1/31までの間に差引\20,000の入金が予測される。このため、信用承認額算出部833は、2016/1/22から2016/1/31までの間の入金額\20,000を、利用できると予測される金額として特定し、図6(A)に示すように、即時引落決済に対応付けられた利用可能額\0に当該入金額\20,000を加えた見込金額\20,000を信用根拠額として算出する。なお、図6(A)の例では、電子マネー決済及びポイント決済のそれぞれに対応付けられた利用可能額は、そのまま信用根拠額として算出されている。また、図6(B),(C)の例では、各決済方法に対応付けられた利用可能額は、そのまま信用根拠額として算出されている。
ところで、図4において、ユーザID“U0002”と即時引落決済に対応付けられた割振の可否は「否」であるので、当該即時引落決済に対応付けられた利用可能額は、図6(B)に示すように除外されて信用承認額が算出される。すなわち、この場合、信用承認額算出部833は、ユーザbが利用可能な複数の決済方法のうちから実決済に利用する候補として当該ユーザbにより選択された複数の決済方法(つまり、割振の可否が「可」である決済方法)のそれぞれの情報に基づいて、信用承認額を算出することになる。これにより、ユーザの意向に沿った信用承認額を算出することができる。
なお、図6(A)〜(C)の例では、各決済方法の各信用根拠額を合計した合計値が信用承認額として算出されているが、各決済方法の各信用根拠額の合計値の所定割合(例えば、合計値を100%としたときの80%程度)の額が信用承認額として算出されるように構成してもよい。
また、別の例として、信用承認額算出部833は、決済方法情報取得部832により取得された、複数の決済方法のそれぞれの情報から、決済方法全体の過去所定期間における利用可能額の推移(言い換えれば、時間経過に応じた利用可能額の変化)を特定し、当該決済方法全体の利用可能額の推移に基づいて、信用承認額を算出してもよい。図7は、ユーザが利用可能な複数の決済方法全体の過去所定期間における利用可能額の推移に基づいて信用承認額を算出する例を示す概念図である。図7の例では、電子マネー決済、ポイント決済、クレジット決済、及び即時引落決済のぞれぞれの利用可能額の推移と、これらの決済方法全体の利用可能額の推移とが示されている。なお、クレジット決済の利用可能額は月毎に与信限度額まで回復している。信用承認額算出部833は、このような決済方法全体の利用可能額の推移(つまり、当該推移を示すデータ列)から過去所定期間(例えば、3ヶ月〜6ヶ月程度)の推移を特定する。そして、信用承認額算出部833は、特定した過去所定期間における利用可能額の平均値(標準偏差値、最大値、或いは最小値でもよい)を算出し、算出した平均値の所定割合(例えば、平均値等を100%としたときの80%程度)の額を信用承認額として算出する。これにより、実決済の実行予定日に支払可能であると考えられる、より精度の高い適切な信用承認額を算出することができる。
仮決済判定部834は、信用承認額算出部833により算出された信用承認額と、取引対象の支払金額(例えば店舗端末2から取得される支払金額)とに基づいて、取引対象に対する決済を求めるユーザに対して仮決済を許可するかを決定する。例えば、仮決済判定部834は、信用承認額と支払金額と比較して、当該信用承認額が支払金額以上であると判定した場合、当該ユーザに対して仮決済を許可することを決定する。なお、当該信用承認額が支払金額未満であっても、その差が所定値(例えば、\1,000)以下であれば、仮決済を許可することが決定されてもよい。
仮決済部835は、仮決済判定部834により仮決済を許可することが決定された場合、支払金額を仮決済する。すなわち、仮決済部835は、信用承認OKメッセージを店舗端末2へ送信し、取引対象に対する決済を求めるユーザと取引を行う店舗へ当該取引対象の支払金額を立て替えて支払うための処理を実行する。ここで、仮決済とは、信用承認OKメッセージが店舗端末2へ送信されることをいうものであると解釈してもよいし、または、信用承認OKメッセージが店舗端末2受信されることにより当該支払金額の売上が計上されることをいうものであると解釈してもよい。或いは、仮決済とは、当該店舗へ当該支払金額が支払われる(この支払は、電子マネー決済、即時引落決済、クレジット決済のいずれでもよい)ことをいうものであると解釈してもよいし、信用承認OKメッセージが店舗端末2へ送信され、且つ、当該店舗へ当該支払金額が支払われることをいうものであると解釈してもよい。
支払金額割振部836は、仮決済された支払金額を、ユーザにより利用可能な複数の決済方法のうち少なくとも1つの決済方法に割り振る。これにより、仮決済された支払金額をユーザに負担をかけずに割り振りを行うことができる。支払金額は、1つの決済方法に割り振られてもよいし、複数の決済方法に分割されて割り振られてもよい。なお、支払金額の割り振りは、仮決済を許可することが決定された後、仮決済される前に行われてもよい。
図8は、支払金額の割振例を示す図である。図8(A)の例では、各決済方法には割振の優先順位が対応付けられているため、仮決済された支払金額は、ユーザaにより利用可能な複数の決済方法のうち当該ユーザaにより予め指定された優先順位に応じて分割して割り振られている。これにより、仮決済された支払金額をユーザに負担をかけずに、ユーザの意向に沿った割り振りを行うことができる。より具体的には、支払金額\60,000のうち、先ず、割振の優先順位が1位であるクレジット決済に対して割振額\47,000(支払金額\60,000から分割された支払金額)が割り振られている。つまり、支払金額\60,000から分割される金額が、クレジット決済の信用根拠額\47,000以下になるように当該クレジット決済に割り振られている。この信用根拠額\47,000は、クレジット決済の利用可能額から利用せずに残すべき金額を差し引いた残金額に相当する。次に、割振の優先順位が2位であるポイント決済に対して割振額\5,000が割り振られている。つまり、支払金額\60,000から分割される金額が、ポイント決済の信用根拠額\5,000以下になるように当該ポイント決済に割り振られている。最後に、割振の優先順位が3位である電子マネー決済に対して割振額\8,000(残りの支払金額)が割り振られている。つまり、支払金額\60,000から分割される支払金額が、電子マネー決済の信用根拠額\8,000以下になるように当該電子マネー決済に割り振られている。このように、仮決済された支払金額は、ユーザaが利用可能な4つの決済方法のうち3つの決済方法に分割して割り振られる。
一方、図8(B)の例では、各決済方法には割振の優先順位が無い。この場合、仮決済された支払金額は、ユーザbにより利用可能な複数の決済方法(電子マネー決済1、電子マネー決済2、クレジット決済、及び即時引落決済)のうちから実決済に利用する候補としてユーザbにより選択された複数の決済方法(電子マネー決済1、電子マネー決済2、及びクレジット決済)に対して分割して割り振られている。より具体的には、支払金額\40,000が、電子マネー決済1、電子マネー決済2、及びクレジット決済のそれぞれの信用根拠額に応じた割合で\24,000、\8,000、及び\8,000に分割され、分割された割振額\24,000が電子マネー決済1に、分割された割振額\8,000が電子マネー決済2に、分割された割振額\8,000がクレジット決済にそれぞれ割り振られている。このように、仮決済された支払金額が、ユーザbにより選択された3つの決済方法の全部に割り振られる。なお、仮決済された支払金額が、ユーザbにより選択された3つの決済方法の一部(例えば、利用可能額が大きい上位2つの決済方法)に割り振られてもよい。一方、図8(C)の例では、各決済方法には割振の優先順位が対応付けられているが、この場合、支払金額\90,000を割振の優先順位が1位である即時引落決済に対して割り振ると残りの支払金額が\0となる。このため、仮決済された支払金額は、ユーザcが利用可能な2つの決済方法のうち1つの決済方法に分割して割り振られることになる。これにより、仮決済された支払金額をユーザに負担をかけずに、複数の決済方法に分散させて割り振りを行うことができる。
ところで、仮決済された支払金額がストアド型電子マネー決済に割り振られた場合、電子バリューの残高は電子マネーカードの不揮発性メモリに格納されているので、実決済までの間にユーザにより電子バリューが決済に利用されてしまい、割振額が実決済に利用できない場合がある。このため、支払金額割振部836は、上述したウォレット機能により、ストアド型電子マネーの電子バリューのチャージ額が割振額以上管理されている場合に限り、当該ストアド型電子マネー決済に割り振るように構成するとよい。
利用ロック部837は、仮決済された支払金額が割り振られた決済方法の利用可能額のうち、割振額(つまり、実決済される予定の金額)の利用をロックする。これにより、決済方法に割り振られた分の金額が仮決済から実決済までの間に、ユーザにより利用されるのを確実に防止することができる。より具体的には、利用ロック部837は、決済方法への割振額を利用ロック額として決済方法情報データベース82cに格納(更新)する。これにより、利用ロックが解除されるまでの間、信用承認額算出部833は、利用可能額から利用ロック額を差し引いた残金額を信用根拠額として算出することになる。また、利用ロック部837は、割振額が割り振られた決済方法に対応する管理サーバ4〜7の何れかへ、取引対象に対する決済を求めるユーザのユーザID、当該割振額が割り振られた決済方法、及び当該割振額を含む利用ロック要求をネットワークNWを介して送信する。なお、ストアド型電子マネー決済に割振額が割り振られた場合、ウォレット機能により当該ユーザのユーザIDに対応付けられて管理されているチャージ額のうち当該割振額分が電子マネー決済に利用されることを禁止する設定が行われる。
実決済部838は、実決済の実行予定日が到来した場合、仮決済された支払金額(つまり、割振額)を、割り振られた決済方法により実決済する。より具体的には、実決済部838は、割振額が割り振られた決済方法に対応する管理サーバ4〜7の何れかへ、割振額の利用がロックされた対象のユーザのユーザID、当該割振額が割り振られた決済方法、及び当該割振額を含む決済要求をネットワークNWを介して送信する。なお、ストアド型電子マネー決済に割振額が割り振られた場合、ウォレット機能により当該ユーザのユーザIDに対応付けられて管理されているチャージ額から割振額だけ減らす。
利用ロック解除部839は、上記実決済が完了すると、当該実決済された割振額の利用のロックを解除する。より具体的には、利用ロック解除部839は、利用ロック額から当該割振額を差し引いた金額を決済方法情報データベース82cに格納(更新)する。そして、利用ロック解除部839は、利用ロック額がロック中の決済方法に対応する管理サーバ3〜7の何れかへ、割振額の利用がロックされた対象のユーザのユーザID、当該割振額の利用がロックされた決済方法、及び当該割振額を含む利用ロック解除要求をネットワークNWを介して送信する。なお、ストアド型電子マネー決済に支払金額が割り振られた場合、ウォレット機能により当該ユーザのユーザIDに対応付けられて管理されているチャージ額のうち利用ロック額分が電子マネー決済に利用されることを禁止する設定を解除する。
[2.電子決済システムSの動作]
次に、本実施形態に係る電子決済システムSの動作について説明する。
(2−1.割振の可否及び優先順位設定時の動作)
先ず、図9等を参照して、割振の可否及び優先順位設定時の動作について説明する。図9は、割振の可否及び優先順位設定時におけるユーザ端末1及びウォレットサーバ8の処理例を示すシーケンス図である。
例えばユーザaのユーザ端末1においてユーザ側仮決済用プログラムが起動してウォレットサーバ8へアクセスしてログインが完了した後、制御部11は、操作・表示部13に表示されたメニュー(図示せず)から、ユーザaにより設定開始ボタンの指定を受け付けると、取得要求をネットワークNWを介してウォレットサーバ8へ送信する(ステップS1)。この取得要求には、例えばユーザaのユーザIDが含まれる。
次いで、ウォレットサーバ8のシステム制御部83は、ユーザ端末1からの取得要求を受信すると、ユーザaのユーザIDに対応付けられている決済方法毎の割振の可否及び優先順位を決済方法情報データベース82cから取得する(ステップS2)。なお、例えば、割振の可否は、設定前の初期状態では「否」に設定されており、割振の優先順位は、設定前の初期状態では「無」に設定されている。次いで、ウォレットサーバ8のシステム制御部83は、ステップS2で取得した決済方法毎の割振の可否及び優先順位を含むデータをネットワークNWを介してユーザ端末1へ送信する(ステップS3)。
次いで、ユーザ端末1の制御部11は、ウォレットサーバ8からの割振の可否及び優先順位を含むデータを受信すると、割振の可否及び優先順位を記憶し、割振可否設定画面を操作・表示部13に表示する(ステップS4)。図10は、ユーザ端末1における割振可否設定画面の表示例を示す図である。図10に示す割振可否設定画面には、ユーザaが利用可能な決済方法の割振の可否を選択するためのチェックボックス51と、ユーザaが利用可能な決済方法の割振の優先順位を指定するための入力欄52と、設定ボタン53とが設けられている。
このような表示状態で、ユーザaは、チェックボックス51の全部または一部をチェック(選択)することができる。制御部11は、チェックボックス51へのチェックを受け付けると(ステップS5:YES)、チェックされた決済方法の割振を「可」に更新する(ステップS6)。なお、図示しないが、チェックボックス51へのチェックを外すと、その決済方法の割振が「否」に更新される。また、ユーザaは、入力欄52の全部または一部に優先順位(数値)を入力(指定)することができる。制御部11は、入力欄52への入力を受け付けると(ステップS7:YES)、元の優先順位を、入力された優先順位に更新する(ステップS8)。そして、制御部11は、ユーザaによる設定ボタン53の指定を受け付けると(ステップS9:YES)、設定要求をネットワークNWを介してウォレットサーバ8へ送信する(ステップS10)。この設定要求には、上記更新された割振の可否及び優先順位、並びにユーザaのユーザIDが含まれる。
次いで、ウォレットサーバ8のシステム制御部83は、ユーザ端末1からの設定要求を受信すると、受信された設定要求に含まれる割振の可否及び優先順位に基づいて、決済方法情報データベース82cに格納されている割振の可否及び優先順位であってユーザaのユーザIDに対応付けられている決済方法毎の割振の可否及び優先順位を更新(最新に設定)する(ステップS11)。
(2−2.仮決済時の動作)
次に、図11を参照して、仮決済時の動作について説明する。図11は、仮決済時におけるユーザ端末1、店舗端末2、及びウォレットサーバ8の処理例を示すシーケンス図である。例えば、店舗で提供された取引対象に対する決済を求めるユーザaは、当該店舗のレジにおいて、自身が携帯するユーザ端末1のユーザ側仮決済用プログラムが起動させると、ユーザ端末1は、店舗側仮決済用プログラムが起動中の店舗端末2との間で近距離無線通信を開始する(ステップS21)。このとき、上述した割振の可否及び優先順位設定が行われてもよい。次いで、ユーザ端末1の制御部11は、ユーザaによる操作・表示部13からの仮決済指示を受け付けると(ステップS22:YES)、記憶部12からユーザIDを取得する(ステップS23)。次いで、ユーザ端末1の制御部11は、ステップS23で取得されたユーザIDを含む仮決済要求を、近距離無線通信部15を介して店舗端末2へ送信する(ステップS24)。
次いで、店舗端末2の制御部21は、ユーザ端末1からの仮決済要求を受信すると、当該仮決済要求からユーザIDを取得する(ステップS25)。なお、ユーザaは、自身が所持するカードを店舗の店員に提示してもよい。この場合、カードに記憶されているカード番号等の情報がリーダライタRWにより読み取られて店舗端末2により取得される。この場合、ユーザ端末1から送信される仮決済要求には、ユーザIDは含まれなくともよい。また、ユーザ端末1内にカード番号等の情報が記憶されている場合、ユーザ端末1の制御部11は、カード番号等の情報を含む仮決済要求を、近距離無線通信部15を介して店舗端末2へ送信してもよい(この場合、カードの提示は不要である)。
次いで、店舗端末2の制御部21は、店員の操作によって入力された、上記取引対象の支払金額を取得する(ステップS26)。次いで、店舗端末2の制御部21は、記憶部22から店舗IDを取得する(ステップS27)。次いで、店舗端末2の制御部21は、信用承認要求を、通信部24及びネットワークNWを介してウォレットサーバ8へ送信する(ステップS28)。この信用承認要求には、ステップS25で取得されたユーザIDと、ステップS26で取得された支払金額と、ステップS27で取得された店舗IDとが含まれる。
なお、ユーザ端末1またはカードからカード番号等の情報が取得された場合、信用承認要求には、ユーザIDの代わりに当該カード番号等の情報が含まれる。
次いで、ウォレットサーバ8のシステム制御部83(ID取得部831)は、店舗端末2からの信用承認要求を受信すると、当該信用承認要求からユーザID、支払金額、及び店舗IDを取得する(ステップS29)。なお、信用承認要求に、ユーザIDの代わりに当該カード番号等の情報が含まれる場合、システム制御部83は、当該カード番号等の情報をキーとして、ユーザ情報データベース82bから、カード番号等に対応付けられたユーザIDを取得することになる。
次いで、システム制御部83は、決済方法情報データベース82cを参照して、ステップS29で取得されたユーザIDに対応付けられた決済方法のうち割振の可否が「可」である決済方法があるか否かを判定する(ステップS30)。システム制御部83は、割振の可否が「可」である決済方法がないと判定した場合(ステップS30:NO)、処理をステップS35へ進める。ステップS35では、システム制御部83は、信用承認NGメッセージを、通信部81及びネットワークNWを介して店舗端末2へ送信する。
一方、システム制御部83は、割振の可否が「可」である決済方法があると判定した場合(ステップS30:YES)、処理をステップS31に進める。ステップS31では、システム制御部83(決済方法情報取得部832)は、割振の可否が「可」である決済方法の情報(例えば、利用可能額、及び入出金履歴)を決済方法情報データベース82cから取得する。なお、ステップS29で取得されたユーザIDに複数の決済方法が対応付けられている場合、それぞれの決済方法の情報が取得される。次いで、システム制御部83は、実決済の実行予定日を設定する(ステップS32)。例えば、実決済の実行予定日は、現時点から1週間〜3週間以内の日、或いは現時点を含む月の末日に設定される。
次いで、システム制御部83(信用承認額算出部833)は、ステップS31で取得された、割振の可否が「可」である決済方法の情報に基づいて、仮決済で許容する信用承認額を算出する(ステップS33)。例えば、上述したように、システム制御部83(信用承認額算出部833)は、当該信用承認額の算出時点(現時点)から実決済の実行予定日までの間に入出金が予測される金額を、当該決済方法の利用可能額から増減した信用根拠額を算出し、算出された信用根拠額に基づいて信用承認額を算出する。例えば、ステップS31で、複数の決済方法のそれぞれの情報が取得された場合、システム制御部83(信用承認額算出部833)は、各決済方法の信用根拠額を算出し、算出された信用根拠額を合計した合計値(または、合計値の所定割合)を信用承認額として算出する。別の例として、上述したように、システム制御部83(信用承認額算出部833)は、ステップS31で取得された、複数の決済方法のそれぞれの情報から、決済方法全体の過去所定期間(例えば、信用承認額の算出時点から過去4ヶ月前まで)における利用可能額の推移を特定し、当該決済方法全体の利用可能額の推移に基づいて信用承認額を算出してもよい。なお、ステップS31で、1つの決済方法の情報が取得された場合、システム制御部83(信用承認額算出部833)は、当該決済方法の信用根拠額を信用承認額として算出する。
次いで、システム制御部83(仮決済判定部834)は、ステップS29で取得された支払金額と、ステップS33で算出された信用承認額とを比較して、当該信用承認額が支払金額以上であるか否かを判定する(ステップS34)。システム制御部83(仮決済判定部834)は、信用承認額が支払金額以上でないと判定した場合(ステップS34:NO)、処理をステップS35へ進める。システム制御部83(仮決済判定部834)は、信用承認額が支払金額以上であると判定した場合(ステップS34:YES)、ユーザaに対して仮決済を許可することを決定する(ステップS36)。
こうして、仮決済を許可することが決定された場合、システム制御部83(仮決済部835)は、ステップS29で取得されたユーザID(つまり、仮決済が許可されたユーザaのユーザID)と支払金額、利用可能額が信用承認額の算出に利用された決済方法(例えば、決済方法を識別する決済種別ID)、当該決済方法の信用根拠額、当該決済方法の割振の優先順位(設定されている場合に限る)、及びステップS32で設定された実決済の実行予定日を仮決済対象リストに登録する(ステップS37)。次いで、システム制御部83(仮決済部832)は、信用承認OKメッセージを通信部81及びネットワークNWを介して店舗端末2へ送信する(ステップS38)。
次いで、システム制御部83(仮決済部835)は、信用承認OKメッセージの送信から所定時間内(例えば、24時間以内)に、ステップS29で取得された店舗IDの店舗へ当該支払金額を立て替えて支払うための処理を実行する(ステップS39)。例えば、システム制御部83(仮決済部835)は、ステップS29で取得された店舗IDに対応付けられている店舗口座情報を店舗情報データベース82aから取得し、支払金額の移動要求(店舗口座情報、ウォレットサーバ8の運営者により用意された口座の口座番号、及び支払金額等を含む)を口座管理サーバ7または金融機関システム9へ送信する。これにより、当該支払金額がウォレットサーバ8の運営者により用意された口座(口座の残高)から引き落とされて当該店舗の口座に振り込まれる。
一方、店舗端末2の制御部21は、ウォレットサーバ8からの信用承認OKメッセージを受信すると、信用承認OKを操作・表示部13に表示し、当該取引対象の支払金額についての売上を計上する処理を行う(ステップS40)。こうしてユーザaと店舗との取引が完了する。
(2−3.支払金額割振時の動作)
次に、図12を参照して、支払金額割振時の動作について説明する。図12は、支払金額割振時におけるウォレットサーバ8、及び管理サーバ4〜7の処理例を示すシーケンス図である。例えば、上記ステップS39の処理後ただちに、或いは上記ステップS39の処理から実決済の実行予定日までの間の何れかの日に、システム制御部83は、上記仮決済対象リストから、ユーザID、決済方法、信用根拠額、割振の優先順位(設定されている場合に限る)、支払金額、及び実決済の実行予定日を含むレコード(1レコード)を1つ取得する(ステップS41)。なお、システム制御部83は、上記仮決済対象リストから取得されたユーザIDをキーとして、決済方法情報データベース82cから決済方法、利用可能額、入出金履歴、及び割振の優先順位(設定されている場合に限る)を取得してもよい。この場合、システム制御部83は、利用可能額、及び入出金履歴から信用根拠額を算出する。
次いで、システム制御部83は、ステップS41で、決済方法の割振の優先順位が取得されたか否かを判定する(ステップS42)。システム制御部83は、決済方法の割振の優先順位が取得されたと判定した場合(ステップS42:YES)、処理をステップS43に進める。一方、システム制御部83は、決済方法の割振の優先順位が取得されていないと判定した場合(ステップS42:NO)、処理をステップS44に進める。
ステップS43では、上述したように、システム制御部83(支払金額割振部836)は、ステップS41で取得された支払金額(つまり、仮決済された支払金額)をステップS41で取得された各決済方法の割振の優先順位に応じて少なくとも1つの決済方法に割り振る。一方、ステップS44では、上述したように、システム制御部83(支払金額割振部836)は、ステップS41で取得された支払金額をステップS41で取得された決済方法に割り振る(決済方法が複数ある場合、当該支払金額をそれぞれの決済方法の信用根拠額に応じた割合で分割して当該決済方法に割り振る)。
次いで、システム制御部83は、ステップS41で取得されたユーザID、ステップS43またはS44で割り振られた決済方法、当該決済方法に割り振られた割振額、及びステップS41取得された実決済の実行予定日を実決済対象リストに登録する(ステップS45)。次いで、システム制御部83(利用ロック部837)は、実決済対象リストに登録された決済方法への割振額を、ステップS41で取得されたユーザIDに対応付けて利用ロック額として決済方法情報データベース82cに格納し(ステップS46)、当該割振額が割り振られた決済方法に対応する管理サーバ(図12の例では、管理サーバ4〜7)へ利用ロック要求(ステップS41で取得されたユーザID及び割振額を含む)をネットワークNWを介して送信する(ステップS47)。このとき、上記仮決済対象リストからステップS41で取得されたユーザIDを含むレコードが削除される。また、仮決済対象リストにユーザIDを含む別のレコードが登録されている場合、当該レコードについてステップS41以降の処理が行われる。
第2電子マネー管理サーバ4は、ウォレットサーバ8からの利用ロック要求を受信すると、当該利用ロック要求に含まれるユーザIDに対応付けて、割振額を利用ロック額として記憶し、当該ユーザIDに対応付けられた電子バリューの残高のうち当該利用ロック額分がサーバ型電子マネー決済に利用されることを禁止する設定(利用ロック額の禁止設定)を行う(ステップS48)。次いで、第2電子マネー管理サーバ4は、利用ロック完了メッセージをウォレットサーバ8へ返信し(ステップS49)、ウォレットサーバ8は、当該利用ロック完了メッセージを受信する。
一方、クレジットカード管理サーバ5は、ウォレットサーバ8からの利用ロック要求を受信すると、当該利用ロック要求に含まれるユーザIDに対応付けて、割振額を利用ロック額として記憶し、当該ユーザIDに対応付けられた利用可能額のうち利用ロック額分がクレジット決済に利用されることを禁止する設定(利用ロック額の禁止設定)を行う(ステップS50)。つまり、クレジットカード管理サーバ5は、利用可能額から利用ロック額を差し引いた金額を超える支払金額の与信照会を承認しない。次いで、クレジットカード管理サーバ5は、利用ロック完了メッセージをウォレットサーバ8へ返信し(ステップS51)、ウォレットサーバ8は、当該利用ロック完了メッセージを受信する。
一方、ポイント管理サーバ6は、ウォレットサーバ8からの利用ロック要求を受信すると、当該利用ロック要求に含まれるユーザIDに対応付けて、割振額を利用ロック額として記憶し、当該ユーザIDに対応付けられた残りポイント数のうち利用ロック額に対応するポイント分がポイント決済に利用されることを禁止する設定(利用ロック額の禁止設定)を行う(ステップS52)。次いで、ポイント管理サーバ6は、利用ロック完了メッセージをウォレットサーバ8へ返信し(ステップS53)、ウォレットサーバ8は、当該利用ロック完了メッセージを受信する。
一方、口座管理サーバ7は、ウォレットサーバ8からの利用ロック要求を受信すると、当該利用ロック要求に含まれるユーザIDに対応付けて、割振額を利用ロック額として記憶し、当該ユーザIDに対応付けられた口座の残高のうち利用ロック額分が即時引落決済に利用されることを禁止する設定(利用ロック額の禁止設定)を行う(ステップS54)。次いで、口座管理サーバ7は、利用ロック完了メッセージをウォレットサーバ8へ返信し(ステップS55)、ウォレットサーバ8は、当該利用ロック完了メッセージを受信する。
(2−4.実決済時の動作)
次に、図13を参照して、実決済時の動作について説明する。図13は、実決済時におけるウォレットサーバ8、及び管理サーバ4〜7の処理例を示すシーケンス図である。例えば、予め設定された時刻(例えば、毎日午前0時)になると、システム制御部83は、実決済の実行予定日が到来したユーザIDを含むレコードが実決済対象リストに登録されているか否かを判定する(ステップS61)。システム制御部83は、実決済の実行予定日が到来したユーザIDを含むレコードが実決済対象リストに登録されていると判定した場合(ステップS61:YES)、ステップS62へ処理を進める。一方、システム制御部83は、実決済の実行予定日が到来したユーザIDを含むレコードが実決済対象リストに登録されていないと判定した場合(ステップS61:NO)、処理を終了する。
ステップS62では、システム制御部83は、実決済の実行予定日が到来したユーザID、決済方法、及び割振額を含むレコードを実決済対象リストから1つ取得する。次いで、システム制御部83(実決済部838)は、ステップS62で取得された決済方法に対応する管理サーバ(図13の例では、管理サーバ4〜7)へ決済要求(ステップS62で取得されたユーザID及び割振額を含む)をネットワークNWを介して送信する(ステップS63)。
第2電子マネー管理サーバ4は、ウォレットサーバ8からの決済要求を受信すると、当該決済要求に含まれるユーザIDに対応付けられた電子バリューの残高が、割振額以上である場合(なお、電子バリューの残高が割振額未満である場合、サーバ型電子マネー決済は行われない)、当該電子バリューの残高を割振額だけ減らす処理(決済処理)を行う(ステップS64)。次いで、第2電子マネー管理サーバ4は、決済完了メッセージをウォレットサーバ8へ返信し(ステップS65)、ウォレットサーバ8は、当該決済完了メッセージを受信する。
一方、クレジットカード管理サーバ5は、ウォレットサーバ8からの決済要求を受信すると、クレジット決済が可能であるか否かの与信照会を行い(ステップS66)、例えば有効期限が過ぎておらず、且つ当該決済要求に含まれる割振額が、当該決済要求に含まれるユーザIDに対応付けられた利用可能額を超えていない場合(なお、割振額が利用可能額を超えている場合、クレジット決済は行われない)に、与信承認OKメッセージ(完了メッセージに相当)をウォレットサーバ8へ返信し(ステップS67)、ウォレットサーバ8は、当該与信承認OKメッセージを受信する。そして、与信承認OKメッセージが受信された場合、クレジット決済が行われる。すなわち、割振額を請求する請求データ(ステップS62で取得されたユーザID、ウォレットサーバ8の運営者により用意された口座の口座番号、及び割振額を含む)がクレジットカード管理サーバ5へ送信され、さらに、クレジットカード管理サーバ5から金融機関システム9へ資金移動要求が送信される。これにより、当該割振額が立替払取次業者(例えば、クレジットカード会社)の口座(口座の預金残高)から引き落とされてウォレットサーバ8の運営者(立替払取次業者と同一の場合もある)により用意された口座に振り込まれる。その後、当該割振額及び手数料が当該ユーザの口座から引き落とされる。
一方、ポイント管理サーバ6は、ウォレットサーバ8からの決済要求を受信すると、当該決済要求に含まれるユーザIDに対応付けられた残りポイント数が、割振額を所定の換算率で換算したポイント数以上である場合(なお、当該残りポイント数が当該ポイント数未満である場合、ポイント決済は行われない)、当該残りポイント数を減らす(つまり、割振額を所定の換算率で換算したポイント分だけ減らす)処理(決済処理)を行う(ステップS68)。次いで、ポイント管理サーバ6は、決済完了メッセージをウォレットサーバ8へ返信し(ステップS69)、ウォレットサーバ8は、当該決済完了メッセージを受信する。
一方、口座管理サーバ7は、ウォレットサーバ8からの決済要求を受信すると、当該決済要求に含まれるユーザIDに対応付けられたユーザの口座の残高が、割振額以上である場合(当該残高が割振額未満である場合、即時引落決済は行われない)、当該割振額の移動要求(当該決済要求に含まれるユーザID、ウォレットサーバ8の運営者により用意された口座の口座番号、及び割振額を含む)を金融機関システム9へ送信する(ステップS70)。これにより、当該割振額がユーザの口座(口座の残高)から引き落とされてウォレットサーバ8の運営者により用意された口座に振り込まれる。次いで、口座管理サーバ7は、決済完了メッセージをウォレットサーバ8へ返信し(ステップS71)、ウォレットサーバ8は、当該決済完了メッセージを受信する。
以上のように、ウォレットサーバ8が上記決済要求の送信先となった全ての管理サーバ(図13の例では、管理サーバ4〜7)から上記決済完了メッセージを受信した場合に、実決済が完了する(ステップS72)。そして、システム制御部83(利用ロック解除部839)は、ステップS62で取得されたユーザID及び決済方法に対応付けられている利用ロック額(決済方法情報データベース82cに登録中)から、ステップS62で取得された割振額を差し引いた金額を決済方法情報データベース82cに格納する。次いで、システム制御部83(利用ロック解除部839)は、ステップS62で取得された決済方法に対応する管理サーバ(図13の例では、管理サーバ4〜7)へ利用ロック解除要求(ステップS62で取得されたユーザID及び割振額を含む)をネットワークNWを介して送信する(ステップS73)。なお、利用ロック解除要求の送信は、決済要求の送信と同時に行われてもよい。
第2電子マネー管理サーバ4は、ウォレットサーバ8からの利用ロック解除要求を受信すると、当該利用ロック解除要求に含まれるユーザIDに対応付けられた利用ロック額から当該割振額を減額し、当該ユーザIDに対応付けられた電子バリューの残高のうち当該割振額分がサーバ型電子マネー決済に利用されることを禁止する設定を解除(利用ロック額の禁止設定解除)する(ステップS74)。次いで、第2電子マネー管理サーバ4は、利用ロック解除完了メッセージをウォレットサーバ8へ返信し(ステップS75)、ウォレットサーバ8は、当該利用ロック解除完了メッセージを受信する。
一方、クレジットカード管理サーバ5は、ウォレットサーバ8からの利用ロック解除要求を受信すると、当該利用ロック解除要求に含まれるユーザIDに対応付けられた利用ロック額から当該割振額を減額し、当該ユーザIDに対応付けられた利用可能額のうち当該割振額分がクレジット決済に利用されることを禁止する設定を解除(利用ロック額の禁止設定解除)する(ステップS76)。次いで、クレジットカード管理サーバ5は、利用ロック解除完了メッセージをウォレットサーバ8へ返信し(ステップS77)、ウォレットサーバ8は、当該利用ロック解除完了メッセージを受信する。
一方、ポイント管理サーバ6は、ウォレットサーバ8からの利用ロック解除要求を受信すると、当該利用ロック解除要求に含まれるユーザIDに対応付けられた利用ロック額から当該割振額を減額し、当該ユーザIDに対応付けられた残りポイント数のうち当該割振額に対応するポイント分がポイント決済に利用されることを禁止する設定を解除(利用ロック額の禁止設定解除)する(ステップS78)。次いで、ポイント管理サーバ6は、利用ロック解除完了メッセージをウォレットサーバ8へ返信し(ステップS79)、ウォレットサーバ8は、当該利用ロック解除完了メッセージを受信する。
一方、口座管理サーバ7は、ウォレットサーバ8からの利用ロック解除要求を受信すると、当該利用ロック解除要求に含まれるユーザIDに対応付けられた利用ロック額から当該割振額を減額し、当該ユーザIDに対応付けられた口座の残高のうち当該割振額分が即時引落決済に利用されることを禁止する設定を解除(利用ロック額の禁止設定解除)する(ステップS80)。次いで、口座管理サーバ7は、利用ロック解除完了メッセージをウォレットサーバ8へ返信し(ステップS81)、ウォレットサーバ8は、当該利用ロック解除完了メッセージを受信する。
以上のように、ウォレットサーバ8が上記利用ロック解除要求の送信先となった全ての管理サーバ(図13の例では、管理サーバ4〜7)から上記利用ロック解除メッセージを受信した場合、上記実決済対象リストからステップS62で取得されたユーザIDを含むレコードが削除され、上記実決済対象リストに、実決済の実行予定日が到来したユーザIDを含む別のレコードが登録されている場合、当該別のレコードについてステップS62以降の処理が行われる。
以上説明したように、上記実施形態によれば、システム制御部83は、取引対象に対する決済を求めるユーザが利用可能な複数の決済方法のそれぞれの情報を取得し、当該複数の決済方法のそれぞれの情報に基づいて仮決済で許容する信用承認額を算出し、当該信用承認額と当該取引対象の支払金額とに基づいて当該ユーザに対して仮決済を許可するかを決定するように構成したので、当該ユーザが利用可能な複数の決済方法による全体的な支払い能力を考慮することができ、より実質的なユーザの支払能力に応じた信用承認を行うことができる。その結果、ユーザの利便性を高め、店舗の販売機会の損失を回避することができる。
なお、上記実施形態においては、ウォレットサーバ8のシステム制御部83が決済用プログラムを実行することにより、ID取得部831、決済方法情報取得部832、信用承認額算出部833、仮決済判定部834、仮決済部835、支払金額割振部836、利用ロック部837、実決済部838、及び利用ロック解除部839として機能するように構成した。しかし、ユーザ端末1の制御部11が、ID取得部831、決済方法情報取得部832、信用承認額算出部833、仮決済判定部834、仮決済部835、及び支払金額割振部836のうちの全部または一部として機能するように構成してもよい。例えば、ユーザ端末1の制御部11は、取引対象に対する決済を求めるユーザのユーザID及び当該取引対象の支払金額を取得し、取得したユーザIDに付けられている複数の決済方法のそれぞれの情報(例えば、利用可能額、及び入出金履歴)をウォレットサーバ8からネットワークNWを介して取得する。ユーザ端末1の制御部11は、取得された複数の決済方法のそれぞれの情報に基づいて、上述したように、仮決済で許容する信用承認額を算出し、算出された信用承認額と、当該取引対象の支払金額とに基づいて当該仮決済を許可するかを決定する。そして、ユーザ端末1の制御部11は、仮決済を許可することを決定した場合、信用承認OKメッセージをウォレットサーバ8へ送信する。或いは、ユーザ端末1の制御部11は、取得された複数の決済方法のそれぞれの情報に基づいて仮決済で許容する信用承認額を算出し、算出された信用承認額及び支払金額をウォレットサーバ8へ送信してもよい。この場合、ウォレットサーバ8が信用承認額と支払金額とに基づいて当該仮決済を許可するかを決定し、仮決済を許可することを決定した場合、仮決済を行う。
或いは、店舗端末2の制御部21が、ID取得部831、決済方法情報取得部832、信用承認額算出部833、仮決済判定部834、仮決済部835、及び支払金額割振部836のうちの全部または一部として機能するように構成してもよい。例えば、店舗端末2の制御部21は、取引対象に対する決済を求めるユーザのユーザID及び当該取引対象の支払金額を取得し、取得したユーザIDに付けられている複数の決済方法のそれぞれの情報(例えば、利用可能額、及び入出金履歴)をウォレットサーバ8からネットワークNWを介して取得する。店舗端末2の制御部21は、取得された複数の決済方法のそれぞれの情報に基づいて、仮決済で許容する信用承認額を算出し、算出された信用承認額と、当該取引対象の支払金額とに基づいて当該仮決済を許可するかを決定する。そして、店舗端末2の制御部21は、仮決済を許可することを決定した場合、信用承認OKメッセージをウォレットサーバ8へ送信する。或いは、店舗端末2の制御部21は、取得された複数の決済方法のそれぞれの情報に基づいて仮決済で許容する信用承認額を算出し、算出された信用承認額及び支払金額をウォレットサーバ8へ送信してもよい。この場合、ウォレットサーバ8が信用承認額と支払金額とに基づいて当該仮決済を許可するかを決定し、仮決済を許可することを決定した場合、仮決済を行う。