JP2022103842A - 情報処理装置、方法及びプログラム - Google Patents

Abstract

【課題】決済の可否判定に照会システム用いる場合に生じ得る不便を低減させる決済サーバを提供する。【解決手段】決済サーバ１は、決済要求受信部２１と、問合せ部２２と、結果取得部２４と、充当部２９と、を備える。決済要求受信部２１は、決済要求を受信する。問合せ部２２は、決済要求に係る決済の可否を、第一の決済手段を用いた決済の可否判定を担う照会システムに問い合わせる。結果取得部２４は、照会システムによる可否判定の結果を取得する。充当部２９は、照会システムからの可否判定の結果を取得する前に、第二の決済手段を用いて、決済要求に係る決済に充当する。【選択図】図３

Description

本開示は、決済の可否判定を伴う決済技術に関する。

従来、ユーザシステムの代行処理制御装置が、サーバ装置からの異常を検知すると、リモート保守センタに異常通知を送信し、異常通知を受信した保守センタの代行処理制御装置が、異常内容から代行可能と判定すると、代行処理制御装置を介して処理要求を受け取り、対応する処理プログラムを記憶装置から読み出して、代行サーバ装置で実施する、代行処理方法が提案されている（特許文献１を参照）。

特開２００２－１６９７０４号公報

従来、決済の可否判定を照会システムに問い合わせ、照会システムから得られた結果に応じて決済を実行又は拒否するシステムが用いられている。しかし、照会システムからの可否判定の取得には不具合（例えば、障害や遅延等）が生じる可能性があり、このような場合に、照会システムによって可否判定される決済手段を用いた決済に不便が生じることがあった。

本開示は、上記した問題に鑑み、決済の可否判定に照会システム用いる場合に生じ得る不便を低減させることを課題とする。

本開示の一例は、決済要求を受信する決済要求受信手段と、前記決済要求に係る決済の可否を、第一の決済手段を用いた決済の可否判定を担う照会システムに問い合わせる問合せ手段と、前記照会システムによる前記可否判定の結果を取得する結果取得手段と、前記照会システムからの前記可否判定の結果を取得する前に、第二の決済手段を用いて、前記決済要求に係る決済に充当する充当手段と、を備える情報処理装置である。

本開示は、情報処理装置、システム、コンピュータによって実行される方法又はコンピュータに実行させるプログラムとして把握することが可能である。また、本開示は、そのようなプログラムをコンピュータその他の装置、機械等が読み取り可能な記録媒体に記録したものとしても把握できる。ここで、コンピュータ等が読み取り可能な記録媒体とは、データやプログラム等の情報を電気的、磁気的、光学的、機械的又は化学的作用によって蓄積し、コンピュータ等から読み取ることができる記録媒体をいう。

本開示によれば、決済の可否判定に照会システム用いる場合に生じ得る不便を低減させることが可能となる。

実施形態に係るシステムの構成を示す概略図である。 実施形態に係るシステムのハードウェア構成の概略を示す図である。 実施形態に係る決済サーバの機能構成の概略を示す図である。 実施形態に係る、ＰＯＳシステム毎の決済確認の送信タイミングを示す図である。 実施形態に係る決済処理の概要を示すフローチャートである。 実施形態に係る充当管理処理の概要を示すフローチャートである。 バリエーションに係る決済処理の概要を示すフローチャートである。 バリエーションに係る決済処理の概要を示すフローチャートである。

以下、本開示に係る情報処理システム、情報処理装置、方法及びプログラムの実施の形態を、図面に基づいて説明する。但し、以下に説明する実施の形態は、実施形態を例示するものであって、本開示に係る情報処理システム、情報処理装置、方法及びプログラムを以下に説明する具体的構成に限定するものではない。実施にあたっては、実施の態様に応じた具体的構成が適宜採用され、また、種々の改良や変形が行われてよい。

本実施形態では、本開示に係る情報処理システム、情報処理装置、方法及びプログラムを、所定の決済手段（例えば、クレジットカード決済）と対応づけたコード決済を行うためのシステムにおいて実施した場合の実施の形態について説明する。但し、本開示に係る情報処理システム、情報処理装置、方法及びプログラムは、決済を提供するための技術について広く用いることが可能であり、本開示の適用対象は、実施形態において示した例に限定されない。

＜システムの構成＞
図１は、本実施形態に係るシステムの構成を示す概略図である。本実施形態に係るシステムは、ネットワークに接続されることで互いに通信可能なコード決済提供サーバ（以下、「決済サーバ」）１と、１又は複数のＰＯＳ（ｐｏｉｎｔ ｏｆ ｓａｌｅ）端末５と、アカウント管理サーバ７と、１又は複数のユーザ端末９とを備え、外部照会システムに接続されている。

一般に、コード決済において、ＰＯＳ端末等の店舗端末から決済要求を受け付けた決済サーバは、当該決済要求が示す決済の可否判定（コード決済に紐づけられた第一の決済手段がクレジットカードである場合、ユーザの信用照会）を外部照会システム（例えば、クレジットカード会社の信用照会システム）に依頼し、その結果に応じて決済を実行又は拒否する。具体的には、決済サーバは、外部照会システムへの信用照会の結果、支払可との応答が得られた場合には決済を実行し、支払不可との応答が得られた場合には決済を実行しない（拒否する）。

ここで、外部照会システムからの決済可否判定の取得には、不具合（障害や遅延等）が生じる場合がある。外部照会システムからの決済可否判定の取得に不具合が生じる場合としては、例えば、決済サーバと外部照会システムとの間における通信に異常が発生した、外部照会システムにおける処理負荷が過大となった、外部照会システムにおいてシステムエラーが発生した、等様々であり、信用照会要求に対する回答が一定時間を経過しても返ってこない等の状況が生じ得る。このため、従来、外部照会システムからの決済可否判定の取得に不具合が生じた場合にも決済が正常に運用できるようにするための対策がとられている。例えば、外部照会システムからの決済可否判定の取得に不具合が生じている場合に、決済サーバが外部照会システムに代わって、決済可否判定を行う、という対策を採用することが可能である。

しかし、このような対策を採用した結果、決済サーバ側で代行して行った判定と、外部照会システムで行った判定とが相違した場合（例えば、決済サーバによる判定：決済可、外部照会システムによる判定：決済不可）、決済手段を提供する会社（例えば、クレジットカード会社）からユーザに対する請求及び決済サーバの提供事業者（コード決済事業者）に対する精算は行われず、決済サーバの提供事業者が店舗に対する支払を肩代わりすることとなる。

そこで、本実施形態に係るシステムでは、前述のような代行処理の結果として、決済サーバが代行して行った判定と、外部照会システムが行った判定とが相違した場合、第二の決済手段（例えば、同一ユーザのポイント／電子マネー／銀行預金等を用いた決済手段）を用いて、当該決済に充当することとした。

また、大量の決済要求が発生した場合や外部照会システムからの回答に時間がかかった場合等にＰＯＳ端末からのメッセージ（例えば、処理状況を確認するための決済確認）等で決済サーバのメモリ（キュー）が溢れてしまうことを防ぐために、ＰＯＳ端末と決済サーバとの間の処理に非同期処理を採用することが出来る。ここでは、決済サーバが、決済要求単位で処理用のメモリを確保して当該決済要求に係るＰＯＳ端末と決済サーバとの間の通信及び決済完了までの処理を管理する処理態様を同期処理と称し、これに対して、決済サーバが、ＰＯＳ端末からのメッセージ（決済要求や決済確認等）が受信される毎にメッセージ処理用のメモリを確保してメッセージに対応する処理を実行し、メッセージへの応答後には当該メッセージ処理用メモリを解放する処理態様を非同期処理と称する。即ち、非同期処理を採用すれば、大量の決済要求が発生した場合や外部照会システムからの回答に時間がかかった場合等であっても、決済要求の処理のために決済サーバのメモリが大量に占有されることなく、決済要求に対応することが可能となる。

しかし、このような非同期処理を採用した場合、ＰＯＳ端末からの決済確認を受信しないと決済サーバでの判定代行等の代替処理のための処理が起動されず、また、ＰＯＳ端末が決済確認を送信するタイミングは店舗側のシステムの仕様に依存するため、決済サーバ側で任意に設定したタイミングで代替処理を開始することが困難である。その結果、目標時間（後述する第二の所定の時間）内に代替処理を伴う決済を完了させることが困難となったり、店舗側のシステムの仕様に依存して代替処理を伴う決済が完了するまでの時間がバラついたりする場合がある。

そこで、本実施形態に係るシステムでは、ＰＯＳ端末から送信される決済要求に含まれる店舗ＩＤに基づいて、当該店舗のＰＯＳ端末からの決済確認が受信されるタイミングを参照し、代替処理の開始トリガーに適した決済確認を対象の店舗側システムの仕様に応じて特定し、代替処理の実行を開始させることとした。なお、本開示に係る、代替処理の開始トリガーに適した決済確認を特定する技術は、上記説明した非同期処理を採用するシステムにおいてより高い効果を奏するが、本開示に係る技術を採用可能なシステムは、上記説明した非同期処理を採用するシステムに限定されない。本開示に係る技術は、同期処理を採用するシステムにおいても採用可能である。

図２は、本実施形態に係るシステムのハードウェア構成の概略を示す図である。決済サーバ１は、ユーザに対してコード決済サービスを提供するためのサーバである。決済サーバ１は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１１、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）１２、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）１３、ＥＥＰＲＯＭ（Ｅｌｅｃｔｒｉｃａｌｌｙ Ｅｒａｓａｂｌｅ ａｎｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）やＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）等の記憶装置１４、ＮＩＣ（Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ Ｃａｒｄ）等の通信ユニット１５、等を備えるコンピュータである。但し、決済サーバ１の具体的なハードウェア構成に関しては、実施の態様に応じて適宜省略や置換、追加が可能である。また、決済サーバ１は、単一の筐体からなる装置に限定されない。決済サーバ１は、所謂クラウドや分散コンピューティングの技術等を用いた、複数の装置によって実現されてよい。

ＰＯＳ端末５は、店舗等の、ユーザが商品やサービスを購入する場所に設定されて、商品／サービスが購入される際の支払等を行うための端末装置である。ＰＯＳ端末５は、ＣＰＵ、ＲＯＭ、ＲＡＭ、記憶装置、通信ユニット、入力装置、出力装置等（図示は省略する）を備えるコンピュータである。ここで、ＰＯＳ端末５は、入力装置として、キーボードやタッチパネルの他に、光学コードリーダやＲＦＩＤリーダ、磁気リーダ等の、ユーザ識別情報を読み取るための装置を備える。但し、ＰＯＳ端末５の具体的なハードウェア構成に関しては、実施の態様に応じて適宜省略や置換、追加が可能である。例えば、ＰＯＳ端末５として、従来のＰＯＳレジスター端末に代えて、入出力装置としてタッチパネルディスプレイを備え、ユーザが所望のアプリケーションをインストールし実行可能な所謂スマートフォンが用いられてもよく、ＰＯＳ端末５として用いることができる機器の種類は限定されない。また、ＰＯＳ端末５は、単一の筐体からなる装置に限定されない。ＰＯＳ端末５は、所謂クラウドや分散コンピューティングの技術等を用いた、複数の装置によって実現されてよい。

アカウント管理サーバ７は、ユーザアカウントを管理するためのサーバである。アカウント管理サーバ７は、ＣＰＵ、ＲＯＭ、ＲＡＭ、記憶装置、通信ユニット等（図示は省略する）を備えるコンピュータである。また、アカウント管理サーバ７は、単一の筐体からなる装置に限定されない。アカウント管理サーバ７は、所謂クラウドや分散コンピューティングの技術等を用いた、複数の装置によって実現されてよい。決済サーバ１は、アカウント管理サーバ７にアクセスすることで、ユーザＩＤに紐づけられたユーザの会員状態、ポイント残高、電子マネー残高、銀行預金残高等の、ユーザに関する情報を取得する。また、アカウント管理サーバ７は、ユーザ端末９に対して、ユーザＩＤに紐づけられた、コード決済のための決済コードを発行する。このため、決済サーバ１は、アカウント管理サーバ７に問い合わせることで、決済コード及びユーザＩＤの何れによっても、ユーザを特定することが可能である。なお、本システムにおいて、決済サーバ１とアカウント管理サーバ７とは、これらの両方の機能を有する１のサーバとして構築されてもよい。

ユーザ端末９は、ユーザによって使用される端末装置である。ユーザ端末９は、ＣＰＵ、ＲＯＭ、ＲＡＭ、記憶装置、通信ユニット、入力装置、出力装置等（図示は省略する）を備えるコンピュータである。また、ユーザ端末９は、単一の筐体からなる装置に限定されない。ユーザ端末９は、所謂クラウドや分散コンピューティングの技術等を用いた、複数の装置によって実現されてよい。ユーザは、これらのユーザ端末９を介して、アカウント管理サーバ７からコード決済のための決済コードを取得し、決済サーバ１によって提供される各種サービスを利用する。

図３は、本実施形態に係る決済サーバ１の機能構成の概略を示す図である。決済サーバ１は、記憶装置１４に記録されているプログラムが、ＲＡＭ１３に読み出され、ＣＰＵ１１によって実行されて、決済サーバ１に備えられた各ハードウェアが制御されることで、決済要求受信部２１、問合せ部２２、決済確認受信部２３、結果取得部２４、タイミング記憶部２５、代替処理開始部２６、判定代行部２７、決済要求処理部２８及び充当部２９を備える情報処理装置として機能する。なお、本実施形態及び後述する他の実施形態では、決済サーバ１の備える各機能は、汎用プロセッサであるＣＰＵ１１によって実行されるが、これらの機能の一部又は全部は、１又は複数の専用プロセッサによって実行されてもよい。

決済要求受信部２１は、決済要求を受信する。本実施形態では、コード決済のための決済要求として、アカウント管理サーバ７によって発行された決済コード、店舗ＩＤ及び決済額を含む決済要求が受信される。但し、決済要求に含まれるユーザを識別するための情報には、例えばユーザＩＤ自体等、その他の識別情報が用いられてもよい。

問合せ部２２は、決済要求に係る決済の可否を、第一の決済手段を用いた決済の可否判定を担う外部照会システムに問い合わせる。なお、本実施形態では、第一の決済手段としてクレジットカード決済を用いる態様について説明し、問合せ部２２は、クレジットカード会社の信用照会システムに対して決済の可否を問い合わせる。但し、第一の決済手段として採用可能な決済手段は限定されない。例えば、第一の決済手段として、ポイント、電子マネー及び銀行預金等の何れかを用いた決済手段が採用されてもよい。

決済確認受信部２３は、外部照会システムによる可否判定の結果を待つ間に、決済要求の発行元（本実施形態では、ＰＯＳ端末５）から、決済要求に係る決済結果を問い合わせる決済確認を受信する。この際、決済確認受信部２３は、１の決済に関して、決済確認を複数回受信可能である。

結果取得部２４は、外部照会システムによる可否判定の結果を取得する。

タイミング記憶部２５は、決済要求の発行元に応じて異なる決済確認の送受信タイミングを予め記憶する。本実施形態に係るシステムにおいて、決済確認の送受信タイミングは、決済要求の発行元に応じて異なる。これは、店舗が導入しているＰＯＳシステム毎に、決済要求に対する決済結果が得られない場合に決済確認を送信するタイミングが異なるためである。

図４は、本実施形態に係る、ＰＯＳシステム毎の決済確認の送信タイミングを示す図である。タイミング記憶部２５は、決済の際に店舗側の相手方となるＰＯＳシステムの種類毎に、決済確認の送信タイミングを記憶する。本実施形態では、例えば、ＰＯＳシステムＰ１は、決済要求（Ｓｅｔメッセージ）に対する決済サーバ１からの応答メッセージが受信された直後に最初の決済確認（Ｇｅｔメッセージ）を送信し、その後は６秒毎に決済確認を送信する。一方、ＰＯＳシステムＰ２は、応答メッセージの受信から１秒後に決済確認を送信し、その後は応答メッセージが受信されてから２．５秒毎に決済確認を送信する。また、ＰＯＳシステムＰ３は、決済要求の１秒後に最初の決済確認を送信し、その後は応答メッセージが受信されてから１秒毎に決済確認を送信する。但し、本実施形態において示した決済確認の送受信タイミングは例示であり、決済確認の送受信タイミングは、ここで挙げた例に限定されない。

代替処理開始部２６は、決済要求を基準に決定される第一の時点Ｔ１までに受信される決済確認のうち最後の決済確認が受信されたタイミングで、決済確認が受信されたことを契機として、第一の決済手段の代替処理を開始させる。ここで、第一の時点Ｔ１は、外部照会システムへの問合せに係る所定の時点を起点として予め設定された第二の時点Ｔ２よりも、代替処理の処理時間に基づいて決定された代替処理用時間以上手前のタイミングである。代替処理に必要な時間がｎ秒である場合、第一の時点Ｔ１を、第二の時点Ｔ２よりもｎ秒以上前の時点とすることで、第二の時点Ｔ２までに、ＰＯＳ端末５に対して判定結果を返すことが可能となる。

代替処理開始部２６は、タイミング記憶部２５から取得される、決済要求の発行元に係る送受信タイミングに基づいて、最後の決済確認を特定する。決済要求の発行元は、店舗ＩＤに基づいて特定可能である。具体的な例を挙げると、第二の時点Ｔ２として決済要求の受信から８秒が設定されており、代替処理に必要な時間が１秒未満である場合、第一の時点Ｔ１を決済要求の受信から７秒とすることで、第二の時点Ｔ２までに、店舗に対して判定結果を返すことが可能となる。図４に示された例に基づくと、メッセージ送受信の遅延等によって変動し得るものの、概ね、以下の決済確認が、「第一の時点Ｔ１までに受信される決済確認のうち最後の決済確認」として特定される。
ＰＯＳシステムＰ１からの決済要求について：決済サーバ１からの応答メッセージが受信されてから約６秒後に送信された決済確認。
ＰＯＳシステムＰ２からの決済要求について：決済サーバ１からの応答メッセージが受信されてから約５秒後に送信された決済確認。
ＰＯＳシステムＰ３からの決済要求について：決済サーバ１からの応答メッセージが受信されてから約６秒後に送信された決済確認。

また、代替処理開始部２６は、代替処理として、後述する充当部２９による充当のための処理を開始させる。本実施形態では、充当部２９による充当のための処理として、後述する判定代行部２７による判定代行処理が開始される。但し、実施の形態によっては、判定代行部２７による判定代行処理が省略され、充当部２９による充当処理が開始されてもよい。

判定代行部２７は、外部照会システムからの可否判定の取得に不具合がある場合に、外部照会システムに代わって、外部照会システムとは異なる独自の方法／基準に基づいて、決済要求に係る決済の可否を判定する。本実施形態において、外部照会システムからの可否判定の取得に不具合がある場合とは、外部照会システムに対して問合せを送れない場合、又は外部照会システムから問合せ結果が所定時間以上得られない場合、等であり、このような場合に、判定代行部２７は、外部照会システムからの可否判定の結果を取得する前に、外部照会システムに代わって、決済要求に係る決済の可否を判定する。

例えば、判定代行部２７は、外部照会システムとは異なる独自の方法／基準として、後述する第二の決済手段による充当可能性に基づいて、決済要求に係る決済の可否を判定する。より具体的には、例えば、判定代行部２７は、以下に示す複数の基準のうち少なくとも１以上の基準が満たされているか否かを判定することで、決済の可否を判定することが出来る。
１）決済コード／ユーザＩＤに基づいてアカウント管理サーバ７から取得された当該ユーザが第二の決済手段で充当可能な決済額の上限と、決済要求に含まれる決済額とを比較し、決済額が上限以下であるか否かを判定する。
２）決済要求に含まれる店舗ＩＤに基づいて当該店舗が第二の決済手段による充当を許可しているか否かを判定する。

なお、ユーザが第二の決済手段で充当可能な決済額の上限としては、当該ユーザについて予め設定された上限額が参照されてもよいし、当該ユーザが所有するバリュー（ポイント、電子マネー又は銀行預金等）の残高が参照されてもよい。また、当該ユーザについて当該バリューのマイナス残高が許容されている場合には、バリューの残高にマイナス可能枠を加算した額を上限として判定が行われてもよい。

決済要求処理部２８は、結果取得部２４によって取得された可否判定の結果、又は判定代行部２７による判定の結果（代替処理の結果）に基づいて、決済要求を処理する。なお、決済の実行は、決済サーバ１によって管理される台帳ファイル（図示は省略する）への記録をもって行われる。本実施形態に係る決済は、クレジットカードと対応づけたコード決済であるため、決済の実行後、台帳ファイルに記録された決済内容に応じた決済額相当のバリューが、決済サーバ１の提供事業者から店舗へ、クレジットカード会社から決済サーバ１の提供事業者へ、店舗で商品等を購入したユーザからクレジットカード会社へ、夫々支払われる。また、決済要求処理部２８は、決済要求を基準に決定される第二の時点Ｔ２（例えば、決済要求が受信されてから８秒後のタイミング）を経過するまでに外部照会システムによる可否判定の結果が取得されなかった場合に、決済要求に係る決済をエラー終了させる。

充当部２９は、外部照会システムからの可否判定の取得に不具合があり判定代行部２７によって決済可と判定された決済要求に係る決済について、外部照会システムから決済不可の結果が取得された場合に、第二の決済手段を用いて、決済要求に係る決済に充当する。但し、充当部２９は、外部照会システムからの可否判定の取得に不具合がある場合に、判定代行部２７による判定又は外部照会システムによる判定結果の取得を経ることなく、第二の決済手段を用いて、決済要求に係る決済に充当してもよい（「不具合がある場合」の具体例については、上記判定代行部２７の説明を参照）。なお、本実施形態において、決済サーバ１又はアカウント管理サーバ７は、ユーザ毎に、第二の決済手段を用いた充当を行うことについてユーザから同意が得られているか否かを示す情報をユーザＩＤに関連付けて保持しており、充当部２９は、当該情報を参照することで、対象の決済要求について、第二の決済手段による充当を行うか否かを決定する。

ここで、第二の決済手段は、決済要求に係る第一の決済手段と同一のユーザに係る決済手段であり、例えば、第一の決済手段と同一のユーザが所有するポイント、電子マネー及び銀行預金等の何れかを用いた決済手段である。充当部２９は、ユーザＩＤ等をキーとしてアカウント管理サーバ７に問い合わせることで、決済要求に係る第一の決済手段と同一のユーザに係る第二の決済手段を特定し、特定された第二の決済手段を用いて、決済要求に係る決済を実行する。

より具体的には、第二の決済手段としてポイント支払を用いる場合、充当部２９は、決済要求に含まれる決済コード／ユーザＩＤに基づいて当該ユーザのポイントアカウントを特定し、特定されたポイントアカウントの残高から、決済額に相当するポイントを減ずる。なお、ポイントの残高が決済額未満である場合には、ポイント残高をマイナスとしてもよい（例えば、ポイント残高：３００ポイント、決済額：５００円のとき、ユーザのポイント残高をマイナス２００ポイントに更新する）。また、第二の決済手段として電子マネー支払を用いる場合、充当部２９は、決済要求に含まれる決済コード／ユーザＩＤに基づいて当該ユーザの電子マネーアカウントを特定し、特定された電子マネーアカウントの残高から、決済額に相当する電子マネーを減ずる。なお、電子マネーとしては、ストアドバリュー型電子マネーが用いられてもよいし、サーバ型電子マネーが用いられてもよい。また、第二の決済手段として銀行預金からの支払を用いる場合、充当部２９は、決済要求に含まれる決済コード／ユーザＩＤに基づいて当該ユーザの銀行口座を特定し、特定された銀行口座に対して、決済額に相当する請求を行う。

＜処理の流れ＞
次に、本実施形態に係る情報処理システムによって実行される処理の流れを説明する。なお、以下に説明する処理の具体的な内容及び処理順序は、本開示を実施するための一例である。具体的な処理内容及び処理順序は、本開示の実施の形態に応じて適宜選択されてよい。

図５は、本実施形態に係る、決済サーバ１によって実行される決済処理の概要を示すフローチャートである。ユーザは、決済サーバ１によって提供される決済サービスによる決済（本実施形態では、コード決済）を要望する場合、ユーザ端末９によってアカウント管理サーバ７から取得された決済コードを示して、当該決済コードを店舗のＰＯＳ端末５に読み取らせる。そして、本フローチャートに示された処理は、決済のための情報を含む決済要求（例えば、アカウント管理サーバ７によって発行された決済コード、店舗ＩＤ及び決済額を含む）を、店舗のＰＯＳ端末５から決済サーバ１が受信したことを契機として実行される。なお、本実施形態では、決済要求に含まれるユーザを識別するための情報として、アカウント管理サーバ７から取得された決済コードを用いる例について説明しているが、ユーザを識別するための情報には、例えばユーザＩＤ等、その他の識別情報が用いられてもよい。

ステップＳ１０１及びステップＳ１０２では、受信された決済要求に従って、外部照会システムへの決済可否の問合せが行われる。決済要求受信部２１が、ＰＯＳ端末５によって送信された決済要求（本実施形態では、決済サーバ１の提供事業者が提供するコード決済の要求）を受信すると（ステップＳ１０１）、決済サーバ１は、ＰＯＳ端末５に対して決済要求が受け付けられたことを通知するための応答メッセージを送信する。そして、問合せ部２２は、当該決済要求に対応づけられた第一の決済手段（本実施形態では、クレジットカード決済）を特定し、特定された第一の決済手段を用いた決済の可否判定を担う外部照会システムに対して、当該決済要求に係る決済の可否を問い合わせる（ステップＳ１０２）。問合せ部２２は、決済要求に含まれる決済コードに基づいて、対象ユーザのユーザＩＤ及びクレジットカード情報をアカウント管理サーバ７から取得し、決済の可否判定のために必要な情報（例えば、アカウント管理サーバ７から取得されたクレジットカード情報、及び決済要求に含まれる決済額）を外部照会システムに対して送信することで、決済の可否を問い合わせる。その後、処理はステップＳ１０３へ進む。

ステップＳ１０３からステップＳ１０６では、外部照会システムからの決済可否の判定結果が待機される。決済サーバ１は、
１）外部照会システムによる決済可否の判定結果が受信される（ステップＳ１０３のＹＥＳ）、
２）第一の時点Ｔ１（本実施形態では、決済要求が受信されてから７秒が経過する時点）が経過する前の最後の決済確認が受信される（ステップＳ１０６のＹＥＳ）、及び
３）第二の時点Ｔ２（本実施形態では、決済要求が受信されてから８秒が経過する時点）が経過する（ステップＳ１０４のＹＥＳ）、
の何れかの条件が満たされるまで、ステップＳ１０３からステップＳ１０６の処理を繰り返し実行し、外部照会システムからの決済可否の判定結果を待機する。なお、この間、決済確認受信部２３によって、外部照会システムからの決済可否の判定結果が受信されていない状態で受信された決済確認であって、且つ第一の時点Ｔ１が経過する前の最後の決済確認ではない（ステップＳ１０６のＮＯ）決済確認が受信された場合、決済サーバ１は、処理中であることを通知する応答メッセージをＰＯＳ端末５に対して送信することで対応する。なお、上述の通り、決済要求の発行元に応じて、第一の時点Ｔ１が経過する前の最後の決済確認が送受信されるタイミングは異なる。このため、代替処理開始部２６は、タイミング記憶部２５から取得される、決済要求の発行元に係る送受信タイミングに基づいて、受信された決済確認が、第一の時点Ｔ１が経過する前の最後の決済確認であるか否かを判定する。

外部照会システムによる決済可否の判定結果が受信された場合（ステップＳ１０３のＹＥＳ）、処理はステップＳ１０８へ進む。また、第一の時点Ｔ１が経過する前の最後の決済確認が受信された場合（ステップＳ１０６のＹＥＳ）、処理はステップＳ１１２へ進む。一方、第二の時点Ｔ２が経過した場合（ステップＳ１０４のＹＥＳ）、処理はステップＳ１０７へ進む。

ステップＳ１０７では、決済要求がエラー終了される。第二の時点Ｔ２が経過した場合（ステップＳ１０４のＹＥＳ）、決済サーバ１は、決済要求をエラー終了させ、決済要求の送信元のＰＯＳ端末５に対して、決済要求に係る決済に失敗したこと（決済不成立）を、ＰＯＳ端末５からの決済確認への応答メッセージとして通知する。その後、本フローチャートに示された処理は終了する。

ステップＳ１０８からステップＳ１１１では、外部照会システムによる可否判定の結果に基づいて、決済要求が処理される。外部照会システムによる決済可否の判定結果が受信された場合（ステップＳ１０３のＹＥＳ）、決済要求処理部２８は、結果取得部２４によって受信された判定結果の内容を確認する（ステップＳ１０８）。受信された判定結果が決済不可である場合、決済要求処理部２８は、決済要求に係る決済をエラー終了させ、決済要求が拒否されたこと（決済不成立）を、ＰＯＳ端末５からの決済確認への応答メッセージとしてＰＯＳ端末５に対して通知する（ステップＳ１０９）。一方、受信された判定結果が決済可である場合、決済要求処理部２８は、ＰＯＳ端末５からの決済確認に応じて決済要求に係る決済を実行し（ステップＳ１１０）、決済要求の送信元のＰＯＳ端末５に対して、決済成立を、ＰＯＳ端末５からの決済確認への応答メッセージとして通知する。また、決済サーバ１は、外部照会システムに対して、決済が実行されたことを通知する（ステップＳ１１１）。その後、本フローチャートに示された処理は終了する。

ステップＳ１１２からステップＳ１１５では、代替処理が行われる。第一の時点Ｔ１が経過する前の最後の決済確認が受信された場合（ステップＳ１０６のＹＥＳ）、判定代行部２７は、外部照会システムからの可否判定の取得に不具合があると判断し、外部照会システムに代わって、決済要求に係る決済の可否を判定する（ステップＳ１１２）。判定代行部２７による判定結果が決済不可である場合（ステップＳ１１３のＮＯ）、決済要求処理部２８は、決済要求に係る決済をエラー終了させ、決済要求が拒否されたこと（決済不成立）を、ＰＯＳ端末５からの決済確認への応答メッセージとしてＰＯＳ端末５に対して通知する（ステップＳ１１４）。一方、判定代行部２７による判定結果が決済可である場合（ステップＳ１１３のＹＥＳ）、決済要求処理部２８は、決済要求に係る決済を実行し（ステップＳ１１５）、決済要求の送信元のＰＯＳ端末５に対して、決済成立を、ＰＯＳ端末５からの決済確認への応答メッセージとして通知する。その後、本フローチャートに示された処理は終了する。

なお、本実施形態において、決済サーバ１は、判定代行部２７による判定代行（図５のステップＳ１１２を参照）が実行された後も、外部照会システムによる決済可否の判定結果の受信を待ち続ける。但し、問合せ部２２は、判定代行部２７による判定が行われた後、ステップＳ１０２において行われた問合せを一旦キャンセルし、判定代行部２７による判定代行が実行された決済要求に係る決済の可否を、外部照会システムに対して再度問い合わせてもよい。

図６は、本実施形態に係る、決済サーバ１によって実行される充当管理処理の概要を示すフローチャートである。本フローチャートに示された処理は、上記説明した決済処理において判定代行部２７による判定代行（図５のステップＳ１１２を参照）が実行された決済要求毎に、外部照会システムによる決済可否の判定結果が受信されたことを契機として実行される。但し、本フローチャートに示された処理が実行されるタイミングは、ここで説明される例に限定されない。ＰＯＳ端末５から受信した決済要求に対応する処理は既に完了しているため、本フローチャートに示された処理が実行されるタイミングは、判定代行がなされた直後であってもよいし、判定代行がなされてから一定時間が経過した後であってもよい。

外部照会システムによる決済可否の判定結果が受信されると、決済要求処理部２８は、受信された判定結果の内容を確認する（ステップＳ２０１）。受信された判定結果が決済可である場合、決済要求処理部２８は、外部照会システムに対して、上記説明した決済処理におけるステップＳ１１５で実行された決済の内容を通知する（ステップＳ２０２）。一方、受信された判定結果が決済不可である場合、当該決済要求に係る決済が実行済み（図５のステップＳ１１５を参照）であるか否かが判定され（ステップＳ２０３）、決済が実行済みである場合、充当部２９は、第二の決済手段を用いて、決済要求に係る決済に充当する（ステップＳ２０４）。その後、本フローチャートに示された処理は終了する。

上記説明した本実施形態に係るシステムによれば、決済サーバ１が外部照会システムに代わって決済可否判定を行い決済可能と判定されて実行された決済が、後で外部照会システムによって決済不可と判定された場合に、当該決済相当額を対象ユーザの他の決済手段（ポイント／電子マネー／銀行預金等を用いた決済手段）を用いて充当することで、決済サーバ１の提供事業者の負担を軽減することが可能となる。

更に、本実施形態に係るシステムによれば、決済サーバ１が外部照会システムに代わって決済可否判定を行う際、決済要求の送信元であるＰＯＳ端末５に係る店舗を示す情報に基づいて、判定代行を開始するトリガーとなる決済確認を特定することで、所定時間内の決済を実現（ユーザの機会損失を防止）しながら、可能な限り正確な（本来的な）判定を行うことが可能となる。

＜バリエーション＞
上記説明した実施形態では、決済処理において、外部照会システムからの決済可否の判定結果を待機する際に、代替処理を開始するトリガーとなる決済確認を特定する処理（ステップＳ１０３からステップＳ１０６を参照）が実行される例について説明した。しかし、代替処理を開始するトリガーとなる決済確認を特定する処理は省略されてもよい。

図７は、バリエーションに係る、決済サーバ１によって実行される決済処理の概要を示すフローチャートである。本フローチャートに示された処理のうち、ステップＳ３０１及びステップＳ３０２に示された処理の内容は、図５を参照して説明したステップＳ１０１及びステップＳ１０２の処理と概略同様であるため、説明を省略する。

ステップＳ３０３及びステップＳ３０６では、外部照会システムからの決済可否の判定結果が待機される。決済サーバ１は、外部照会システムによる決済可否の判定結果が受信される（ステップＳ３０３のＹＥＳ）、及び第一の時点Ｔ１（本実施形態では、決済要求が受信されてから７秒が経過する時点）が経過する（ステップＳ３０６のＹＥＳ）、の何れかの条件が満たされるまで、ステップＳ３０３及びステップＳ３０６の処理を繰り返し実行し、外部照会システムからの決済可否の判定結果を待機する。なお、この間、決済確認受信部２３によって、外部照会システムからの決済可否の判定結果が受信されていない状態で決済確認が受信された場合、決済サーバ１は、処理中であることを通知する応答メッセージをＰＯＳ端末５に対して送信することで対応する。

外部照会システムによる決済可否の判定結果が受信された場合（ステップＳ３０３のＹＥＳ）、処理はステップＳ３０８へ進む。また、第一の時点Ｔ１が経過した場合（ステップＳ３０６のＹＥＳ）、処理はステップＳ３１２へ進む。ステップＳ３０８以降に示された処理の内容は、図５を参照して説明したステップＳ１０８以降の処理と概略同様であるため、説明を省略する。

また、上記説明した実施形態では、所定の時間内に外部照会システムからの回答が得られない場合に、判定代行による決済可否の判定が行われる例について説明した。しかし、所定の時間内に外部照会システムからの回答が得られない場合に、判定代行による決済可否の判定を省略し、決済要求に係る決済を、第二の決済手段を用いて一律実行することとしてもよい。

図８は、バリエーションに係る、決済サーバ１によって実行される決済処理の概要を示すフローチャートである。本フローチャートに示された処理のうち、ステップＳ４０１及びステップＳ４０２に示された処理の内容は、図５を参照して説明したステップＳ１０１及びステップＳ１０２の処理と概略同様であるため、説明を省略する。また、ステップＳ４０３及びステップＳ４０６に示された処理の内容は、図７を参照して説明したステップＳ３０３及びステップＳ３０６の処理と概略同様であるため、説明を省略する。

外部照会システムによる決済可否の判定結果が受信された場合（ステップＳ４０３のＹＥＳ）、処理はステップＳ４０８へ進む。ステップＳ４０８からステップＳ４１１に示された処理の内容は、図５を参照して説明したステップＳ１０８からステップＳ１１１の処理と概略同様であるため、説明を省略する。

また、第一の時点Ｔ１が経過した場合（ステップＳ４０６のＹＥＳ）、処理はステップＳ４１５へ進む。決済要求処理部２８は、決済要求に係る決済を実行し（ステップＳ４１５）、決済要求の送信元のＰＯＳ端末５に対して、決済成立を、ＰＯＳ端末５からの決済確認への応答メッセージとして通知する。そして、充当部２９は、第二の決済手段を用いて、決済要求に係る決済に充当する（ステップＳ４１６）。即ち、本実施形態では、図５を参照して説明した処理のうち、ステップＳ１１２からステップＳ１１４の判定代行処理が省略され、所定の時間内に外部照会システムからの回答が得られなかった決済要求に係る決済が、第二の決済手段を用いて一律実行される。その後、本フローチャートに示された処理は終了する。

なお、図８を参照して説明したバリエーションでは、判定代行処理を省略しているため、充当管理処理（図６を参照）は省略されてよい。

１ 決済サーバ
５ ＰＯＳ端末
９ ユーザ端末

Claims (10)

1. 決済要求を受信する決済要求受信手段と、
   前記決済要求に係る決済の可否を、第一の決済手段を用いた決済の可否判定を担う照会システムに問い合わせる問合せ手段と、
   前記照会システムによる前記可否判定の結果を取得する結果取得手段と、
   前記照会システムから前記可否判定の結果を取得する前に、第二の決済手段を用いて、前記決済要求に係る決済に充当する充当手段と、
   を備える情報処理装置。
2. 前記照会システムからの前記可否判定の結果を取得する前に、前記照会システムに代わって、前記決済要求に係る決済の可否を判定する判定代行手段を更に備え、
   前記充当手段は、前記判定代行手段によって決済可と判定された前記決済要求に係る決済について、前記照会システムから決済不可の結果が取得された場合に、第二の決済手段を用いて、前記決済要求に係る決済に充当する、
   請求項１に記載の情報処理装置。
3. 前記結果取得手段によって取得された前記可否判定の結果、又は前記判定代行手段による前記判定の結果に基づいて、前記決済要求を処理する決済要求処理手段を更に備える、
   請求項２に記載の情報処理装置。
4. 前記第二の決済手段は、前記第一の決済手段と同一のユーザに係る決済手段であり、
   前記判定代行手段は、前記第二の決済手段による充当可能性に基づいて、前記決済要求に係る決済の可否を判定する、
   請求項２又は３に記載の情報処理装置。
5. 前記第二の決済手段は、前記第一の決済手段と同一のユーザが所有するポイント、電子マネー、及び銀行預金の何れかを用いた決済手段である、
   請求項４に記載の情報処理装置。
6. 前記充当手段は、前記照会システムからの前記可否判定の取得に不具合がある場合に、第二の決済手段を用いて、前記決済要求に係る決済に充当する、
   請求項１から５の何れか一項に記載の情報処理装置。
7. 前記判定代行手段は、前記照会システムからの前記可否判定の取得に不具合がある場合に、前記照会システムに代わって、前記決済要求に係る決済の可否を判定する、
   請求項２から５の何れか一項に記載の情報処理装置。
8. 前記照会システムからの前記可否判定の取得に不具合がある場合とは、前記照会システムに対して前記問合せを送れない場合、又は前記照会システムから前記問合せ結果が所定時間以上得られない場合である、
   請求項６又は７に記載の情報処理装置。
9. コンピュータが、
   決済要求を受信する決済要求受信ステップと、
   前記決済要求に係る決済の可否を、第一の決済手段を用いた決済の可否判定を担う照会システムに問い合わせる問合せステップと、
   前記照会システムによる前記可否判定の結果を取得する結果取得ステップと、
   前記照会システムからの前記可否判定の結果を取得する前に、第二の決済手段を用いて、前記決済要求に係る決済に充当する充当ステップと、
   を実行する方法。
10. コンピュータを、
    決済要求を受信する決済要求受信手段と、
    前記決済要求に係る決済の可否を、第一の決済手段を用いた決済の可否判定を担う照会システムに問い合わせる問合せ手段と、
    前記照会システムによる前記可否判定の結果を取得する結果取得手段と、
    前記照会システムからの前記可否判定の結果を取得する前に、第二の決済手段を用いて、前記決済要求に係る決済に充当する充当手段と、
    として機能させるためのプログラム。
    
    

Images