JP6491372B1 - 決済処理システム、決済処理方法及び決済処理プログラム - Google Patents

Abstract

【課題】ユーザ端末を利用して、効率的に取引を行なうための決済処理システム、決済処理方法及び決済処理プログラムを提供する。
【解決手段】決済処理システムのユーザ端末１０は、銀行サーバ４０の停止中の支払を支援する支払支援部１１１と、利用者の口座残高を管理する銀行サーバ４０及び店頭端末２０に接続される決済処理部１１２とを備える。そして、支払支援部１１１は、銀行サーバ４０の停止前に、口座残高に基づいて、デビットカードの代替手段における支払準備を行なう。そして、決済処理部１１２は、銀行サーバ４０の停止中に、店頭端末２０に対するデビットカードを用いての支払指示を取得した場合、代替手段を用いて支払を行ない、銀行サーバ４０が再開した場合に、代替手段を用いて支払われた金額を口座残高に反映させる。
【選択図】図１

Description

本発明は、ユーザ端末を利用して、決済を行なうための決済処理システム、決済処理方法及び決済処理プログラムに関する。

今日、利用者が所持するユーザ端末を用いて、商品購入時等の決済を行なうための技術が検討されている（例えば、特許文献１，２参照）。特許文献１に記載された技術においては、ユーザ端末は、店舗端末から商品購入代金を取得し、クレジット決済を要求する。クレジットサーバは、クレジット決済を行ない、クレジット決済金額の電子マネーの発行を電子マネーサーバに指示する。電子マネーサーバは、ユーザ端末にクレジット決済金額の電子マネーを送信する。そして、クレジット決済金額の電子マネーを受信したユーザ端末は、店舗端末に出力する。

また、特許文献２に記載された技術においては、商品購入の際に自身の顧客端末上で専用アプリを起動しておき、店舗のレジのＰＯＳ端末に購入金額を入力すると、ＰＯＳ端末は、顧客端末に登録されたカード情報を読み取り、カード情報と、購入情報をカード決済管理サーバに送信する。

一方、デビットカードを用いた取引においては、金融機関のホストシステムにオンラインで接続される。この場合、ホストシステムが稼働していない時間帯では取引ができない。このため、取引時間外に、現金自動預払機で出金取引を行なうための技術も検討されている（例えば、特許文献３参照）。この特許文献３に記載された技術では、ホストコンピュータの稼働を停止させた時間帯に取引を行う時間外取引の予約を端末機から受け付け、予約成立時には、予約取引番号を採番して予約管理ファイルに記録する。現金自動預払機からの取引の要求により、予約管理ファイルに記憶した予約取引番号の取引を実行する。

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

上記特許文献１に記載された技術においては、クレジットカードの利用を前提としている。しかしながら、利用者によっては、クレジットカードを保有していない場合もある。この場合には、ユーザ端末を利用した決済を行なうことができない。また、特許文献２においても、デビットカードへの適用が示唆されているが、銀行口座を用いる金融機関のホストシステムの稼働が前提となる。また、特許文献３に記載された技術では、予約が必要であり、店舗等における商品購入においては速やかな決済ができない。

上記課題を解決する決済処理システムは、利用者の口座残高を管理するホストシステム及び店頭端末に接続される決済処理部と、ホストシステムの停止中の支払を支援する支払支援部を備える。そして、前記決済処理部は、前記ホストシステムの稼働中に、前記店頭端末に対するデビットカードを用いての支払指示を取得した場合、前記ホストシステムの口座残高を用いて支払を行なう第１処理を実行し、前記支払支援部は、前記ホストシステムの停止前に、前記ホストシステムの口座残高を取得し、前記口座残高に基づいて、前記デビットカードの代替手段における支払準備を行なう先行処理と、前記ホストシステムの停止中に、前記店頭端末に対するデビットカードを用いての支払指示を取得した場合、前記代替手段による支払を行なう第２処理と、前記ホストシステムが再開した場合に、前記代替手段により支払われた金額を口座残高に反映させる後続処理とを実行する。

本発明によれば、ユーザ端末を利用して、効率的に決済を行なうことができる。

第１の実施形態の決済処理システムの説明図。 第１の実施形態の処理手順の説明図。 第１の実施形態の処理手順の説明図。 第２の実施形態の決済処理システムの説明図。 第２の実施形態の処理手順の説明図。 第２の実施形態の処理手順の説明図。 第３の実施形態の決済処理システムの説明図。 第３の実施形態の処理手順の説明図。 第３の実施形態の処理手順の説明図。

（第１の実施形態）
以下、図１〜図３に従って、決済処理システム、決済処理方法及び決済処理プログラムを具体化した第１の実施形態を説明する。本実施形態では、金融機関の顧客（利用者）に対して、ユーザ端末を利用して決済を行なうためのウォレット（電子的な決済媒体）の管理を想定する。このウォレットには、複数の決済媒体を記録することが可能である。決済媒体としては、電子マネー、キャッシュカード（デビットカード）、クレジットカード等を用いることができる。

ここでは、図１に示すように、ネットワークを介して接続されたユーザ端末１０、店舗端末２０、中継サーバ３０、銀行サーバ４０、ＡＰＩサーバ５０を用いる。
ユーザ端末１０は、金融機関に口座を開設した利用者が用いるコンピュータ端末である。ユーザ端末１０は、無線通信を介して、店舗端末２０と接続する。この無線通信には、例えば、ＮＦＣ（Near field radio communication）方式を用いることができる。このユーザ端末１０は、制御部１１、情報記憶部１２、タッチパネルディスプレイ１５を備える。

制御部１１は、制御手段（ＣＰＵ、ＲＡＭ、ＲＯＭ等）を備え、後述する処理（決済処理段階、支払支援段階等の各処理等）を行なう。そのため、ユーザ端末１０には、決済処理アプリケーションが格納されている。決済処理アプリケーションを起動することにより、制御部１１は、支払支援部１１１、決済処理部１１２として機能する。

支払支援部１１１は、デビットカードを用いた決済時に、銀行サーバ４０を利用できない場合に、決済を支援するための処理を実行する。この支払支援部１１１は、代替手段を用いての決済を許容する金額（必要額）に関するデータを記憶させておく。この必要額は、銀行サーバ４０の停止期間中に使用された金額の統計値や、使用される可能性がある金額の予測値、利用者によって指定された金額等を用いる。

更に、支払支援部１１１は、銀行サーバ４０の停止期間（停止予定日時、再開予定日時）に関するデータを保持している。
更に、支払支援部１１１は、後述するＡＰＩサーバ５０にアクセスし、銀行口座の残高を取得したり、振替依頼を送信したりする。

決済処理部１１２は、利用者が取引を行なう場合の代金支払い等の決済処理を実行する。この決済には、ウォレットに格納された決済媒体を選択して用いる。

情報記憶部１２には、ウォレット情報記憶領域１２２、決済履歴情報記憶領域１２３が設けられている。
ウォレット情報記憶領域１２２には、決済媒体管理レコードが記録される。この決済媒体管理レコードは、利用者が利用可能な決済媒体が登録された場合に記録される。決済媒体レコードは、媒体種別、発行者、媒体コード、残高に関するデータを含んで構成される。

媒体種別データ領域には、決済媒体の種類を特定するための識別子に関するデータが記録される。決済媒体としては、例えば、電子マネー、キャッシュカード、クレジットカード等が記録される。

発行者データ領域には、この決済媒体の発行者を特定するための識別子に関するデータが記録される。例えば、電子マネーの発行者や、銀行名、クレジット会社名等が記録される。

媒体コードデータ領域には、決済媒体を特定するための識別子に関するデータが記録される。例えば、電子マネーの場合には、利用者固有情報、キャッシュカードの場合には口座番号、クレジットカードの場合には、カード番号等が記録される。
残高データ領域には、プリペイド方式の決済媒体については、そのチャージ残高に関するデータが記録される。

決済履歴情報記憶領域１２３には、決済履歴管理レコードが記録される。この決済履歴管理レコードは、取引における決済が完了した場合に記録される。決済履歴管理レコードは、決済番号、媒体コード、店舗コード、決済日時、金額に関するデータを含んで構成される。

決済番号データ領域には、各決済を特定するための識別子に関するデータが記録される。
媒体コードデータ領域には、この決済に用いられた決済媒体を特定するための識別子に関するデータが記録される。

店舗コードデータ領域には、この決済を行なった店舗を特定するための識別子に関するデータが記録される。
決済日時データ領域には、決済を完了した年月日及び時刻に関するデータが記録される。
金額データ領域には、取引における決済金額に関するデータが記録される。

タッチパネルディスプレイ１５は、画面上に情報を出力する出力部、タッチ操作等による情報を入力する入力部として機能する。

店舗端末２０は、ユーザ端末１０と無線通信を行ない、取引（例えば、商品購入）の決済に必要な情報を取得する。そして、店舗端末２０は、ユーザ端末１０から、決済媒体に関するトークンを取得する。

中継サーバ３０は、店舗端末２０と、銀行サーバ４０やクレジット会社サーバ等の金融機関サーバとの間の通信を中継するコンピュータシステムである。例えば、「Credit And Finance Information Switching system（ＣＡＦＩＳ）」（登録商標）を用いる。決済時にキャッシュカードを用いる場合、中継サーバ３０は、店舗端末２０から取得したトークンに基づいて、利用者の口座を特定し、決済要求を銀行サーバ４０に送信する。そして、銀行サーバ４０で口座引落（決済）が行なわれた場合には、中継サーバ３０は、銀行サーバ４０から決済結果を取得し、決済番号を付与した取引結果を蓄積する。この取引結果には、決済番号、取引日時、店舗コード、取引金額、金融機関コードに関するデータを含める。そして、中継サーバ３０は、店舗端末２０に取引結果通知を返信する。

銀行サーバ４０は、顧客の銀行口座を管理する銀行のホストシステム（金融機関サーバ）である。
この銀行サーバ４０は、利用者の銀行口座毎に、口座残高、入出金履歴を記憶する口座情報記憶部４２を備える。

銀行口座データ領域には、利用者の銀行口座を特定する識別子（口座番号）に関するデータが記録される。
口座残高データ領域には、この銀行口座の残高に関するデータが記録される。
入出金履歴データ領域には、入出金日時、入出金額、摘要に関するデータが記録される。

銀行サーバ４０は、中継サーバ３０から取得した決済要求に基づいて、利用者の銀行口座から決済代金を引き落とす。そして、銀行サーバ４０は、決済結果を、中継サーバ３０に提供する。中継サーバ３０は、決済結果を、店舗端末２０に転送する。

ＡＰＩサーバ５０は、インターネット等のネットワークを介してユーザ端末１０に接続される。このＡＰＩサーバ５０は、残高照会ＡＰＩ５１、振替処理ＡＰＩ５２を備える。
残高照会ＡＰＩ５１は、ユーザ端末１０に対して、銀行サーバ４０に開設された銀行口座の残高に関する情報を提供する。
振替処理ＡＰＩ５２は、ユーザ端末１０から取得した振替指示に基づいて、銀行サーバ４０に対して、利用者口座から振替先口座への振替処理を指示する。

（停止対応処理）
図２を用いて、停止対応処理を説明する。この処理は、定期的に実行される。
まず、ユーザ端末１０の制御部１１は、停止前かどうかについての判定処理を実行する（ステップＳ１−１）。具体的には、制御部１１の支払支援部１１１は、ユーザ端末１０内のシステムタイマから現在日時を取得する。そして、支払支援部１１１は、銀行サーバ４０の停止予定日時と比較する。停止予定日時の所定時間前に達している場合には、銀行サーバ４０の停止前と判定する。

停止予定日時の所定時間前に達しておらず、停止前でないと判定した場合（ステップＳ１−１において「ＮＯ」の場合）、ユーザ端末１０の制御部１１は、所定時間後に、停止前かどうかについての判定処理（ステップＳ１−１）を繰り返す。

一方、銀行サーバ４０の停止時刻の所定時間前に達して、停止前と判定した場合（ステップＳ１−１において「ＹＥＳ」の場合）、ユーザ端末１０の制御部１１は、残高取得処理を実行する（ステップＳ１−２）。具体的には、制御部１１の支払支援部１１１は、ネットワークを介して、ＡＰＩサーバ５０にアクセスする。そして、支払支援部１１１は、残高照会ＡＰＩ５１を介して、デビットカードの銀行口座の残高を取得する。

次に、ユーザ端末１０の制御部１１は、口座引落処理を実行する（ステップＳ１−３）。具体的には、制御部１１の支払支援部１１１は、残高と必要額とを比較する。そして、必要額以上の残高がある場合には、支払支援部１１１は、ＡＰＩサーバ５０の振替処理ＡＰＩ５２を介して、口座から必要額の引落指示を送信する。一方、残高が必要額未満の場合には、支払支援部１１１は、ＡＰＩサーバ５０の振替処理ＡＰＩ５２を介して、すべての残高をチャージする引落指示を送信する。

次に、ユーザ端末１０の制御部１１は、電子マネーのチャージ処理を実行する（ステップＳ１−４）。具体的には、制御部１１の支払支援部１１１は、ＡＰＩサーバ５０を介して、銀行サーバ４０から電子マネーのチャージ指示を取得する。ここでは、口座残高から引き落とした金額（必要額、残高の低い方の金額）のチャージ指示を取得する。この場合、支払支援部１１１は、チャージ指示の金額を、情報記憶部１２のウォレット情報記憶領域１２２の電子マネー残高に加算する。

次に、ユーザ端末１０の制御部１１は、停止終了かどうかについての判定処理を実行する（ステップＳ１−５）。具体的には、制御部１１の支払支援部１１１は、ユーザ端末１０内のシステムタイマから現在日時を取得する。そして、支払支援部１１１は、銀行サーバ４０の再開予定日時と比較する。再開予定日時を経過している場合には、銀行サーバ４０の停止終了と判定する。

再開予定日時を経過しておらず、停止終了でないと判定した場合（ステップＳ１−５において「ＮＯ」の場合）、ユーザ端末１０の制御部１１は、所定時間後に、停止終了かどうかについての判定処理（ステップＳ１−５）を繰り返す。

一方、再開予定日時を経過し、停止終了と判定した場合（ステップＳ１−５において「ＹＥＳ」の場合）、ユーザ端末１０の制御部１１は、利用額の算出処理を実行する（ステップＳ１−６）。具体的には、制御部１１の支払支援部１１１は、今回の銀行サーバ４０の停止期間中に、デビットカードの代わりに使用された電子マネーの金額（代替金額）を、情報記憶部１２の決済履歴情報記憶領域１２３から取得する。

次に、ユーザ端末１０の制御部１１は、電子マネーの返却処理を実行する（ステップＳ１−７）。具体的には、制御部１１の支払支援部１１１は、銀行サーバ４０の停止前にチャージした金額（必要額、残高の低い方の金額）から代替金額を差し引いて、返却金額を算出する。そして、支払支援部１１１は、情報記憶部１２のウォレット情報記憶領域１２２の電子マネー残高から返却金額を差し引く。更に、支払支援部１１１は、ＡＰＩサーバ５０の振替処理ＡＰＩ５２を介して、返却金額の銀行口座への振替指示を送信する。この場合、銀行サーバ４０は、振替指示に基づいて、利用者の銀行口座に返却金額を入金する。

（決済時処理）
図３を用いて、決済時処理を説明する。ユーザ端末１０のデジタルウォレットを用いて決済を行なう場合、ウォレットアプリケーションを起動する。

まず、ユーザ端末１０の制御部１１は、決済媒体の選択処理を実行する（ステップＳ２−１）。具体的には、制御部１１の決済処理部１１２は、情報記憶部１２のウォレット情報記憶領域１２２に記録されている決済媒体管理レコードの媒体種別をタッチパネルディスプレイ１５に出力する。そして、決済処理部１１２は、タッチパネルディスプレイ１５において選択された媒体種別を、決済媒体として特定する。本実施形態では、媒体種別としてデビットカードを選択する場合を想定する。

次に、ユーザ端末１０の制御部１１は、停止期間中かどうかについての判定処理を実行する（ステップＳ２−２）。具体的には、制御部１１の決済処理部１１２は、システムタイマから現在日時を取得する。そして、決済処理部１１２は、現在日時と停止期間とを比較する。現在日時が停止期間に含まれる場合には、停止期間中と判定する。

停止期間中でないと判定した場合（ステップＳ２−２において「ＮＯ」の場合）、ユーザ端末１０の制御部１１は、取引要求処理を実行する（ステップＳ２−３）。具体的には、制御部１１の決済処理部１１２は、無線通信を利用して、店舗端末２０に取引要求を送信する。この取引要求には、選択された決済媒体（キャッシュカード）の媒体コード（口座番号）を含めたトークンを含める。この場合、店舗端末２０は、決済要求を中継サーバ３０に送信する。この決済要求には、店舗における取引金額、店舗コード、ユーザ端末１０から取得したトークンを含める。この場合、中継サーバ３０は、トークンから口座番号を取得する。そして、中継サーバ３０は、銀行サーバ４０に対して、決済要求を送信する。この決済要求には、口座番号及び取引金額に関するデータを含める。

中継サーバ３０から決済要求を取得した銀行サーバ４０は、口座残高の取得処理を実行する（ステップＳ２−４）。具体的には、銀行サーバ４０は、決済要求に含まれる口座番号の口座の残高情報を取得する。

次に、銀行サーバ４０は、銀行口座引落処理を実行する（ステップＳ２−５）。銀行サーバ４０は、取引金額と口座残高とを比較する。取引金額以上の口座残高があり、決済可能と判定した場合、銀行サーバ４０は、利用者の口座残高から取引金額を引き落とし、別段口座に入金する。そして、銀行サーバ４０は、中継サーバ３０からの指示に応じて、別段口座に入金された資金を店舗コードに対応した口座に入金する。なお、口座残高が取引金額未満で、決済不可と判定した場合、銀行サーバ４０は、口座引落を行なわない。

そして、銀行サーバ４０は、決済結果の返信処理を実行する（ステップＳ２−６）。具体的には、銀行サーバ４０は、中継サーバ３０に決済結果を送信する。口座引落を行なった場合には、この決済結果に決済完了フラグを含める。一方、口座引落ができなかった場合には、この決済結果に決済未了フラグを含める。決済完了フラグを含む決済結果を取得した中継サーバ３０は、決済番号を付与し、店舗コード、取引金額を記録する。そして、中継サーバ３０は、決済番号を付与し、決済完了通知を店舗端末２０に送信する。この決済完了通知には、決済番号、店舗コード、取引日時、取引金額を含める。一方、決済未了フラグを含む決済結果を取得した中継サーバ３０は、エラー通知を店舗端末２０に送信する。店舗端末２０は、決済完了通知又はエラー通知をユーザ端末１０に転送する。

ユーザ端末１０の制御部１１は、決済結果の取得処理を実行する（ステップＳ２−７）。具体的には、制御部１１の決済処理部１１２は、中継サーバ３０から取得した決済結果（決済完了通知又はエラー通知）を、タッチパネルディスプレイ１５に表示する。

次に、ユーザ端末１０の制御部１１は、決済完了かどうかについての判定処理を実行する（ステップＳ２−８）。具体的には、制御部１１の決済処理部１１２は、決済完了通知を取得した場合、決済完了と判定する。

決済完了と判定した場合（ステップＳ２−８において「ＹＥＳ」の場合）、ユーザ端末１０の制御部１１は、決済履歴の記録処理を実行する（ステップＳ２−９）。具体的には、制御部１１の決済処理部１１２は、決済番号、店舗コード、取引金額、取引日時を記録した決済履歴レコードを生成し、決済履歴情報記憶領域１２３に記録する。

一方、エラー通知を取得し、決済完了でないと判定した場合（ステップＳ２−８において「ＮＯ」の場合）、ユーザ端末１０の制御部１１は、エラー処理を実行する（ステップＳ２−１０）。具体的には、制御部１１の決済処理部１１２は、タッチパネルディスプレイ１５にエラーメッセージを出力する。この場合、決済処理部１１２は、他の決済媒体の利用を推奨するメッセージを出力する。

一方、停止期間中と判定した場合（ステップＳ２−２において「ＹＥＳ」の場合）、ユーザ端末１０の制御部１１は、電子マネーで対応可能かどうかについての判定処理を実行する（ステップＳ２−１１）。具体的には、制御部１１の決済処理部１１２は、情報記憶部１２のウォレット情報記憶領域１２２に記録された電子マネーの残高情報を取得する。取引金額以上の電子マネー残高があり、決済可能と判定した場合、対応可能と判定する。

電子マネーで対応可能と判定した場合（ステップＳ２−１１において「ＹＥＳ」の場合）、ユーザ端末１０の制御部１１は、電子マネーによる支払処理を実行する（ステップＳ２−１２）。具体的には、制御部１１の決済処理部１１２は、情報記憶部１２のウォレット情報記憶領域１２２に記録された電子マネーを用いての支払指示を、店舗端末２０に対して出力する。そして、決済処理部１１２は、取引金額について、電子マネー残高を減額する。

そして、ユーザ端末１０の制御部１１は、決済履歴の記録処理を実行する（ステップＳ２−９）。具体的には、制御部１１の決済処理部１１２は、決済番号、店舗コード、取引金額、取引日時を記録した決済履歴レコードを生成し、決済履歴情報記憶領域１２３に記録する。この場合、デビットカードの代わりの電子マネーで支払ったことを示す代替フラグを記録する。

一方、電子マネーで対応可能でないと判定した場合（ステップＳ２−１１において「ＮＯ」の場合）、ユーザ端末１０の制御部１１は、エラー処理を実行する（ステップＳ２−１０）。

以上、本実施形態によれば、以下に示す効果を得ることができる。
（１−１）本実施形態では、銀行サーバ４０の停止前と判定した場合（ステップＳ１−１において「ＹＥＳ」の場合）、ユーザ端末１０の制御部１１は、残高取得処理（ステップＳ１−２）、口座引落処理（ステップＳ１−３）、電子マネーのチャージ処理（ステップＳ１−４）を実行する。これにより、銀行サーバ４０の停止期間中に対応するための電子マネーをチャージしておくことができる。

（１−２）本実施形態では、再開予定日時を経過し、停止終了と判定した場合（ステップＳ１−５において「ＹＥＳ」の場合）、ユーザ端末１０の制御部１１は、利用額の算出処理（ステップＳ１−６）、電子マネーの返却処理（ステップＳ１−７）を実行する。これにより、銀行サーバ４０の停止期間中のためにチャージした電子マネーを、利用者口座に戻すことができる。

（１−３）本実施形態では、停止期間中でないと判定した場合（ステップＳ２−２において「ＮＯ」の場合）、ユーザ端末１０の制御部１１は、取引要求処理を実行する（ステップＳ２−３）。これにより、銀行サーバ４０の稼働期間中であれば、利用者口座を用いて、決済を行なうことができる。

（１−４）本実施形態では、電子マネーで対応可能と判定した場合（ステップＳ２−１１において「ＹＥＳ」の場合）、ユーザ端末１０の制御部１１は、電子マネーによる支払処理を実行する（ステップＳ２−１２）。これにより、銀行サーバ４０を利用できない場合にも、電子マネーを用いて決済を行なうことができる。

（１−５）本実施形態では、ユーザ端末１０の制御部１１は、決済履歴の記録処理を実行する（ステップＳ２−９）。これにより、デビットカードによる支払のみならず、デビットカードに代えて電子マネーによる支払の履歴を把握することができる。

（第２の実施形態）
次に、第２の実施形態を図４〜図６に従って説明する。上記第１の実施形態では、停止期間中には、銀行口座の代わりに、電子マネーを用いて決済を行なう。代替手段は、銀行サーバ４０の停止中にも決済可能な手段であれば、電子マネーに限定されるものではない。第２の実施形態においては、デビットカードの代替手段として仮想口座を用いて決済を行なうように変更したのみの構成である。このため、上記第１実施形態と同様の部分については、同一の符号を付し、その詳細な説明を省略する。
ここでは、上記第１実施形態と異なり、ユーザ端末１０の制御部１１に、支払支援部１１１は不要である。

本実施形態では、銀行サーバ４０に接続された決済支援サーバ６０を設ける。この決済支援サーバ６０は、決済支援部６１、仮想口座情報記憶部６２を備える。
決済支援部６１は、銀行サーバ４０の停止期間中の決済を支援するための停止対応処理を実行する。

仮想口座情報記憶部６２には、仮想口座番号毎に、銀行サーバ４０で管理される銀行口座、仮想口座残高に関するデータを含む仮想口座管理レコードが記録される。
仮想口座番号データ領域には、代替手段としての仮想口座を特定する識別子（口座番号）に関するデータが記録される。
銀行口座データ領域には、利用者の銀行口座を特定する識別子（口座番号）に関するデータが記録される。
仮想口座残高データ領域には、この仮想口座の残高に関するデータが記録される。

（停止対応処理）
次に、図５を用いて、停止対応処理を説明する。
まず、決済支援サーバ６０の決済支援部６１は、ステップＳ１−１と同様に、停止前かどうかについての判定処理を実行する（ステップＳ３−１）。

停止前でないと判定した場合（ステップＳ３−１において「ＮＯ」の場合）、決済支援サーバ６０の決済支援部６１は、所定時間後に、停止前かどうかについての判定処理（ステップＳ３−１）を繰り返す。

一方、停止前と判定した場合（ステップＳ３−１において「ＹＥＳ」の場合）、決済支援サーバ６０の決済支援部６１は、利用者毎に以下の処理を繰り返す。
ここでは、決済支援サーバ６０の決済支援部６１は、残高取得処理を実行する（ステップＳ３−２）。具体的には、決済支援部６１は、仮想口座情報記憶部６２において、処理対象利用者の口座番号を特定する。そして、決済支援部６１は、銀行サーバ４０にアクセスし、口座情報記憶部４２から利用者の銀行口座の口座残高を取得する。

次に、決済支援サーバ６０の決済支援部６１は、銀行口座引落処理を実行する（ステップＳ３−３）。具体的には、決済支援部６１は、残高と必要額とを比較する。そして、必要額以上の残高がある場合には、決済支援部６１は、銀行口座から必要額の引落指示を送信する。一方、残高が必要額未満の場合には、決済支援部６１は、すべての残高の引落指示を送信する。

次に、決済支援サーバ６０の決済支援部６１は、仮想口座入金処理を実行する（ステップＳ３−４）。具体的には、決済支援部６１は、仮想口座情報記憶部６２において、口座残高から引き落とした金額を仮想口座に入金する。
以上の処理を、利用者毎に繰り返す。

次に、決済支援サーバ６０の決済支援部６１は、ステップＳ１−５と同様に、停止終了かどうかについての判定処理を実行する（ステップＳ３−５）。

再開予定日時を経過しておらず、停止終了でないと判定した場合（ステップＳ３−５において「ＮＯ」の場合）、決済支援サーバ６０の決済支援部６１は、所定時間後に、停止終了かどうかについての判定処理（ステップＳ３−５）を繰り返す。

一方、再開予定日時を経過し、停止終了と判定した場合（ステップＳ３−５において「ＹＥＳ」の場合）、決済支援サーバ６０の決済支援部６１は、利用者毎に、仮想口座残高の返却処理を実行する（ステップＳ３−６）。具体的には、決済支援部６１は、仮想口座のすべての残高を銀行サーバ４０の口座に送金する。この処理を、利用者毎に繰り返す。

（決済時処理）
次に、図６を用いて、決済時処理を説明する。
まず、ユーザ端末１０の制御部１１は、ステップＳ２−１，Ｓ２−３と同様に、決済媒体の選択処理（ステップＳ４−１）、取引要求処理（ステップＳ４−２）を実行する。

この場合、決済支援サーバ６０の決済支援部６１は、取引要求の取得処理を実行する（ステップＳ４−３）。具体的には、決済支援部６１は、ユーザ端末１０から、店舗端末２０，中継サーバ３０を介して、取引要求を取得する。

次に、決済支援サーバ６０の決済支援部６１は、停止期間中かどうかについての判定処理を実行する（ステップＳ４−４）。具体的には、決済支援部６１は、システムタイマから現在日時を取得し、現在日時と停止期間とを比較する。

停止期間中でないと判定した場合（ステップＳ４−４において「ＮＯ」の場合）、決済支援サーバ６０の決済支援部６１は、取引要求の転送処理を実行する（ステップＳ４−５）。具体的には、決済支援部６１は、取引要求を銀行サーバ４０に転送する。

この場合、銀行サーバ４０は、ステップＳ２−４〜Ｓ２−６と同様に、口座残高の取得処理（ステップＳ４−６）、銀行口座引落処理（ステップＳ４−７）、決済結果の返信処理（ステップＳ４−８）を実行する。
一方、停止期間中と判定した場合（ステップＳ４−４において「ＹＥＳ」の場合）、決済支援サーバ６０の決済支援部６１は、仮想口座残高の取得処理を実行する（ステップＳ４−９）。具体的には、決済支援部６１は、決済要求に含まれる銀行口座の口座番号に関連付けられた仮想口座の残高情報を仮想口座情報記憶部６２から取得する。

次に、決済支援サーバ６０の決済支援部６１は、仮想口座で対応可能かどうかについての判定処理を実行する（ステップＳ４−１０）。具体的には、決済支援部６１は、取引金額と仮想口座残高とを比較する。

取引金額以上の仮想口座残高があり、仮想口座で対応可能と判定した場合（ステップＳ４−１０において「ＹＥＳ」の場合）、決済支援サーバ６０の決済支援部６１は、仮想口座引落処理を実行する（ステップＳ４−１１）。具体的には、決済支援部６１は、仮想口座残高から取引金額を引き落とし、決済支援サーバ６０の別段口座に入金する。そして、銀行サーバ４０の稼働時に、この別段口座に入金された資金を、銀行サーバ４０の稼働時に、店舗コードに対応した銀行口座に入金する処理を行なう。

一方、仮想口座残高が取引金額未満で、仮想口座で対応不可と判定した場合（ステップＳ４−１０において「ＮＯ」の場合）、決済支援サーバ６０の決済支援部６１は、仮想口座引落処理（ステップＳ４−１１）をスキップし、決済結果の返信処理（ステップＳ４−８）を実行する。

この場合、ユーザ端末１０の制御部１１は、ステップＳ２−７〜Ｓ２−９と同様に、決済結果の取得処理（ステップＳ４−１２）、決済完了かどうかについての判定処理（ステップＳ４−１３）、決済履歴の記録処理（ステップＳ４−１４）を実行する。

なお、エラー通知を取得し、決済完了でないと判定した場合（ステップＳ４−１３において「ＮＯ」の場合）、ユーザ端末１０の制御部１１は、ステップＳ２−１０と同様に、エラー処理を実行する（ステップＳ４−１５）。

以上、第２の実施形態によれば、以下に示す効果を得ることができる。
（２−１）本実施形態では、決済支援サーバ６０の決済支援部６１は、残高取得処理（ステップＳ３−２）、銀行口座引落処理（ステップＳ３−３）、仮想口座入金処理（ステップＳ３−４）を実行する。これにより、銀行サーバ４０の停止期間中の取引に対応するために、仮想口座の残高を確保しておくことができる。

（２−２）本実施形態では、決済支援サーバ６０の決済支援部６１は、仮想口座残高の返却処理を実行する（ステップＳ３−６）。これにより、銀行サーバ４０の停止期間中のために確保した仮想口座の残高を、利用者口座に返還することができる。

（２−３）本実施形態では、停止期間中と判定した場合（ステップＳ４−４において「ＹＥＳ」の場合）、決済支援サーバ６０の決済支援部６１は、仮想口座残高の取得処理を実行する（ステップＳ４−９）。仮想口座で対応可能と判定した場合（ステップＳ４−１０において「ＹＥＳ」の場合）、決済支援サーバ６０の決済支援部６１は、仮想口座引落処理を実行する（ステップＳ４−１１）。これにより、銀行サーバ４０の停止期間中には、仮想口座の残高を用いて決済を行なうことができる。

（第３の実施形態）
次に、第３の実施形態を図７〜図９に従って説明する。上記第２の実施形態では、停止期間中には、銀行口座の代わりに、仮想口座を用いて決済を行なう。代替手段は、利用者口座の残高に応じた仮想口座に限定されるものではない。第３の実施形態においては、デビットカードの代替手段として与信を用いて決済を行なうように変更したのみの構成であるため、同様の部分についてはその詳細な説明を省略する。

本実施形態では、決済支援サーバ６０（第２実施形態）の代わりに、銀行サーバ４０に接続された決済支援サーバ７０を設ける。この決済支援サーバ７０は、与信処理部７１、利用者情報記憶部７２を備える。
与信処理部７１は、銀行サーバ４０の口座情報記憶部４２に記録された入出金履歴に基づいて、信用レベルのスコアリングを行なう。ここでは、銀行サーバ４０の停止期間中のリスクを考慮してスコアリングを行なう。そして、与信処理部７１は、このスコアリングに基づいて、与信可能枠（与信可能額）を決定するためのスコアリングモデルを保持している。

利用者情報記憶部７２には、本サービスの利用者の銀行口座毎に、与信枠、利用額に関するデータを含む利用者管理レコードが記録される。
銀行口座データ領域には、利用者の銀行口座を特定する識別子（口座番号）に関するデータが記録される。

与信枠データ領域には、銀行サーバ４０の停止期間中に与信により利用可能な金額に関するデータが記録される。
利用額データ領域には、銀行サーバ４０の停止期間中に利用された金額に関するデータが記録される。

（停止対応処理）
次に、図８を用いて、停止対応処理を説明する。
まず、決済支援サーバ７０の与信処理部７１は、ステップＳ３−１と同様に、停止前かどうかについての判定処理を実行する（ステップＳ５−１）。

停止前でないと判定した場合（ステップＳ５−１において「ＮＯ」の場合）、決済支援サーバ７０の与信処理部７１は、所定時間後に、停止前かどうかについての判定処理（ステップＳ５−１）を繰り返す。

一方、停止前と判定した場合（ステップＳ５−１において「ＹＥＳ」の場合）、決済支援サーバ７０の与信処理部７１は、利用者毎に以下の処理を繰り返す。
まず、決済支援サーバ７０の与信処理部７１は、与信枠の算出処理を実行する（ステップＳ５−２）。具体的には、与信処理部７１は、利用者情報記憶部７２において、処理対象利用者の口座番号を特定する。そして、与信処理部７１は、銀行サーバ４０の口座情報記憶部４２から利用者口座の口座残高や入出金履歴を取得する。そして、与信処理部７１は、取得した口座残高や入出金履歴をスコアリングモデルに適用して、与信上限枠を算出する。この与信上限枠内で、必要額（与信枠）を決定する。

次に、決済支援サーバ７０の与信処理部７１は、与信枠の設定処理を実行する（ステップＳ５−３）。具体的には、与信処理部７１は、算出した与信枠を銀行口座の口座番号に関連付けて、利用者情報記憶部７２に記録する。
以上の処理を、利用者毎に繰り返す。

次に、決済支援サーバ７０の与信処理部７１は、ステップＳ３−５と同様に、停止終了かどうかについての判定処理を実行する（ステップＳ５−４）。

再開予定日時を経過しておらず、停止終了でないと判定した場合（ステップＳ５−４において「ＮＯ」の場合）、決済支援サーバ７０の与信処理部７１は、所定時間後に、停止終了かどうかについての判定処理（ステップＳ５−４）を繰り返す。

一方、再開予定日時を経過し、停止終了と判定した場合（ステップＳ５−４において「ＹＥＳ」の場合）、決済支援サーバ７０の与信処理部７１は、利用者毎に以下の処理を繰り返す。

ここでは、決済支援サーバ７０の与信処理部７１は、利用額の引落処理を実行する（ステップＳ５−５）。具体的には、与信処理部７１は、利用者情報記憶部７２に記録されている利用額を取得する。そして、与信処理部７１は、銀行サーバ４０に対して、利用額について、利用者口座から店舗口座に送金する指示を送信する。

次に、決済支援サーバ７０の与信処理部７１は、利用額のリセット処理を実行する（ステップＳ５−６）。具体的には、与信処理部７１は、利用者情報記憶部７２に記録されている利用額をリセットする。
以上の処理を、利用者毎に繰り返す。

（決済時処理）
次に、図９を用いて、決済時処理を説明する。
まず、ユーザ端末１０の制御部１１は、ステップＳ４−１，Ｓ４−２と同様に、決済媒体の選択処理（ステップＳ６−１）、取引要求処理（ステップＳ６−２）を実行する。

この場合、決済支援サーバ７０の与信処理部７１は、取引要求の取得処理を実行する（ステップＳ６−３）。具体的には、与信処理部７１は、ユーザ端末１０から、店舗端末２０，中継サーバ３０を介して、取引要求を取得する。

次に、決済支援サーバ７０の与信処理部７１は、停止期間中かどうかについての判定処理を実行する（ステップＳ６−４）。具体的には、与信処理部７１は、システムタイマから現在日時を取得する。そして、与信処理部７１は、現在日時と停止期間とを比較する。

停止期間中でないと判定した場合（ステップＳ６−４において「ＮＯ」の場合）、決済支援サーバ７０の与信処理部７１は、ステップＳ４−５と同様に、取引要求の転送処理を実行する（ステップＳ６−５）。

この場合、銀行サーバ４０は、ステップＳ４−６〜Ｓ４−８と同様に、口座残高の取得処理（ステップＳ６−６）、銀行口座引落処理（ステップＳ６−７）、決済結果の返信処理（ステップＳ６−８）を実行する。
一方、停止期間中と判定した場合（ステップＳ６−４において「ＹＥＳ」の場合）、決済支援サーバ７０の与信処理部７１は、与信枠において利用可能額の算出処理を実行する（ステップＳ６−９）。具体的には、与信処理部７１は、決済要求に含まれる口座番号を含む利用者管理レコードを利用者情報記憶部７２から取得する。次に、与信処理部７１は、利用者管理レコードの与信枠から利用額を差し引いて利用可能額を算出する。

次に、決済支援サーバ７０の与信処理部７１は、与信枠で対応可能かどうかについての判定処理を実行する（ステップＳ６−１０）。具体的には、与信処理部７１は、取引金額と利用可能額とを比較する。

利用可能額が取引金額以上であり、与信枠で対応可能と判定した場合（ステップＳ６−１０において「ＹＥＳ」の場合）、決済支援サーバ７０の与信処理部７１は、貸付処理を実行する（ステップＳ６−１１）。具体的には、与信処理部７１は、利用者管理レコードの利用額データ領域に取引金額を加算する。そして、与信処理部７１は、取引日時、店舗コード、取引金額を記録した取引管理レコードを生成し、取引情報記憶部に記録する。そして、与信処理部７１は、中継サーバ３０からの指示に応じて、別段口座に入金された資金を店舗コードに対応した口座に入金する。

一方、利用可能額が取引金額未満であり、与信枠で対応不可と判定した場合（ステップＳ６−１０において「ＮＯ」の場合）、決済支援サーバ７０の与信処理部７１は、貸付処理（ステップＳ６−１１）をスキップし、決済結果の返信処理（ステップＳ６−８）を実行する。

この場合、ユーザ端末１０の制御部１１は、ステップＳ４−１２〜Ｓ４−１４と同様に、決済結果の取得処理（ステップＳ６−１２）、決済完了かどうかについての判定処理（ステップＳ６−１３）、決済履歴の記録処理（ステップＳ６−１４）を実行する。

なお、エラー通知を取得し、決済完了でないと判定した場合（ステップＳ６−１３において「ＮＯ」の場合）、ユーザ端末１０の制御部１１は、ステップＳ４−１５と同様に、エラー処理を実行する（ステップＳ６−１５）。

以上、第３の実施形態によれば、以下に示す効果を得ることができる。
（３−１）本実施形態では、決済支援サーバ７０の与信処理部７１は、与信枠の算出処理を実行する（ステップＳ５−２）。これにより、銀行サーバ４０の停止期間中の取引に対応するための与信枠を利用者毎に設定することができる。

（３−２）本実施形態では、決済支援サーバ７０の与信処理部７１は、利用額の引落処理（ステップＳ５−５）、利用額のリセット処理（ステップＳ５−６）を実行する。これにより、銀行サーバ４０の停止期間中に利用した金額を、銀行口座を用いて支払うことができる。

（３−３）本実施形態では、停止期間中と判定した場合（ステップＳ６−４において「ＹＥＳ」の場合）、決済支援サーバ７０の与信処理部７１は、与信枠において利用可能額の算出処理を実行する（ステップＳ６−９）。与信枠で対応可能と判定した場合（ステップＳ６−１０において「ＹＥＳ」の場合）、決済支援サーバ７０の与信処理部７１は、貸付処理を実行する（ステップＳ６−１１）。これにより、銀行サーバ４０の停止期間中には、与信枠を用いて決済を行なうことができる。

本実施形態は、以下のように変更して実施することができる。本実施形態及び以下の変更例は、技術的に矛盾しない範囲で互いに組み合わせて実施することができる。
・上記第１の実施形態では、ユーザ端末１０の制御部１１は、口座引落処理（ステップＳ１−３）、電子マネーのチャージ処理（ステップＳ１−４）を実行する。ここでは、必要額のチャージを行なう。この必要額は、利用履歴に基づいて算出するようにしてもよい。この場合には、利用者毎に、デビットカードの利用履歴を取得する。そして、利用履歴における金額が高い程、高い必要額を設定する。
また、停止期間の長さに応じて金額を決定してもよい。ここでは、停止期間が長いほど、高い必要額を設定する。

・上記第１の実施形態では、ユーザ端末１０の制御部１１は、口座引落処理（ステップＳ１−３）、電子マネーのチャージ処理（ステップＳ１−４）を実行する。ここでは、電子マネー残高に応じて処理を変更してもよい。例えば、支払支援部１１１が、銀行サーバ４０の停止前に、情報記憶部１２のウォレット情報記憶領域１２２に記録された電子マネー残高を取得し、電子マネー残高が必要額未満の場合のみ、口座引落処理（ステップＳ１−３）、電子マネーのチャージ処理（ステップＳ１−４）を実行する。

・上記第１の実施形態では、ユーザ端末１０の制御部１１は、電子マネーの返却処理を実行する（ステップＳ１−７）。ここで、電子マネー残高に応じて処理を変更してもよい。例えば、支払支援部１１１が、銀行サーバ４０の停止終了後に、情報記憶部１２のウォレット情報記憶領域１２２に記録された電子マネー残高を取得し、電子マネー残高が基準額以上の場合のみ、電子マネーの返却処理（ステップＳ１−７）を実行する。

・上記第１の実施形態では、ユーザ端末１０の制御部１１は、口座引落処理（ステップＳ１−３）、電子マネーのチャージ処理（ステップＳ１−４）を実行する。ここで、情報記憶部１２のウォレット情報記憶領域１２２の電子マネー残高に応じて、口座引落処理の要否を判定するようにしてもよい。具体的には、必要額以上の電子マネー残高がある場合には、新たなチャージを行なわない。一方、電子マネー残高が必要額未満の場合には、不足分のみをチャージする。

・上記第２の実施形態では、決済支援サーバ６０の与信処理部７１は、残高取得処理を実行する（ステップＳ３−２）。残高の取得方法は、銀行サーバ４０に直接、アクセスする場合に限定されるものではない。例えば、決済支援部６１は、ＡＰＩサーバ５０の残高照会ＡＰＩ５１を介して、口座残高を取得するようにしてもよい。

・上記第３の実施形態では、決済支援サーバ７０の与信処理部７１は、与信枠の算出処理を実行する（ステップＳ５−２）。この与信枠の算出のタイミングは、銀行サーバ４０の停止前に限定されるものではない。例えば、定期的に与信枠を算出するようにしてもよい。

・上記第２、第３の実施形態では、中継サーバ３０と銀行サーバ４０との間に、決済支援サーバ６０，７０を設けた。ハードウェア構成はこれに限定されるものではない。例えば、決済支援サーバ６０，７０を中継サーバ３０に設けてもよい。

１０…ユーザ端末、１１…制御部、１１１…支払支援部、１１２…決済処理部、１２…情報記憶部、１５…タッチパネルディスプレイ、３０…中継サーバ、４０…銀行サーバ、４２…口座情報記憶部、５０…ＡＰＩサーバ、５１…残高照会ＡＰＩ、５２…振替処理ＡＰＩ、６０…決済支援サーバ、６１…決済支援部、６２…仮想口座情報記憶部、７０…決済支援サーバ、７１…与信処理部、７２…利用者情報記憶部。

Claims (8)

1. 利用者の口座残高を管理するホストシステム及び店頭端末に接続される決済処理部と、
   ホストシステムの停止中の支払を支援する支払支援部を備えた決済処理システムであって、
   前記決済処理部は、前記ホストシステムの稼働中に、前記店頭端末に対するデビットカードを用いての支払指示を取得した場合、前記ホストシステムの口座残高を用いて支払を行なう第１処理を実行し、
   前記支払支援部は、前記ホストシステムの停止前に、前記ホストシステムの口座残高を取得し、前記口座残高から必要額を引き落として、前記デビットカードの代替手段としての電子マネーをチャージする支払準備を行なう先行処理と、
   前記ホストシステムの停止中に、前記店頭端末に対するデビットカードを用いての支払指示を取得した場合、前記電子マネーによる支払を行なう第２処理と、
   前記ホストシステムが再開した場合に、前記停止前にチャージされた電子マネーの必要額の残りの残高を前記ホストシステムの口座残高に還元する後続処理とを実行することを特徴とする決済処理システム。
2. 利用者の口座残高を管理するホストシステム及び店頭端末に接続される決済処理部と、
   ホストシステムの停止中の支払を支援する支払支援部を備えた決済処理システムであって、
   前記決済処理部は、前記ホストシステムの稼働中に、前記店頭端末に対するデビットカードを用いての支払指示を取得した場合、前記ホストシステムの口座残高を用いて支払を行なう第１処理を実行し、
   前記支払支援部は、前記ホストシステムの停止前に、前記ホストシステムの口座残高を取得し、前記口座残高に基づいて、前記デビットカードの代替手段としての必要額に応じた与信枠を算出する支払準備を行なう先行処理と、
   前記ホストシステムの停止中に、前記店頭端末に対するデビットカードを用いての支払指示を取得した場合、前記与信枠を用いて支払を行なう第２処理と、
   前記ホストシステムが再開した場合に、前記与信枠において支払われた金額を前記ホストシステムの口座残高から引き落とす後続処理とを実行することを特徴とする決済処理シ
   ステム。
3. 前記先行処理において、前記支払支援部は、前記ホストシステムの停止前に、前記ホストシステムの口座残高から必要額を引き落として、前記代替手段としての仮想口座に入金し、
   前記第２処理において、前記デビットカードを用いての支払指示を取得した場合、前記仮想口座に口座残高がある場合には、前記仮想口座を用いて支払を行ない、
   前記後続処理において、前記ホストシステムが再開した場合に、前記停止前に仮想口座の口座残高を前記ホストシステムの口座残高に還元する処理を更に実行することを特徴とする請求項１又は２に記載の決済処理システム。
4. 前記支払支援部は、前記必要額を、利用者の出金状況に応じて算出することを特徴とする請求項１〜３の何れか一項に記載の決済処理システム。
5. 利用者の口座残高を管理するホストシステム及び店頭端末に接続される決済処理部と、
   ホストシステムの停止中の支払を支援する支払支援部を備えた決済処理システムを用いて、決済支援を行なうための方法であって、
   前記決済処理部は、前記ホストシステムの稼働中に、前記店頭端末に対するデビットカードを用いての支払指示を取得した場合、前記ホストシステムの口座残高を用いて支払を行なう第１処理を実行し、
   前記支払支援部は、前記ホストシステムの停止前に、前記ホストシステムの口座残高を取得し、前記口座残高から必要額を引き落として、前記デビットカードの代替手段としての電子マネーをチャージする支払準備を行なう先行処理と、
   前記ホストシステムの停止中に、前記店頭端末に対するデビットカードを用いての支払指示を取得した場合、前記電子マネーによる支払を行なう第２処理と、
   前記ホストシステムが再開した場合に、前記停止前にチャージされた電子マネーの必要額の残りの残高を前記ホストシステムの口座残高に還元する後続処理とを実行することを特徴とする決済処理方法。
6. 利用者の口座残高を管理するホストシステム及び店頭端末に接続される決済処理部と、
   ホストシステムの停止中の支払を支援する支払支援部を備えた決済処理システムを用いて、決済支援を行なうための方法であって、
   前記決済処理部は、前記ホストシステムの稼働中に、前記店頭端末に対するデビットカードを用いての支払指示を取得した場合、前記ホストシステムの口座残高を用いて支払を行なう第１処理を実行し、
   前記支払支援部は、前記ホストシステムの停止前に、前記ホストシステムの口座残高を取得し、前記口座残高に基づいて、前記デビットカードの代替手段としての必要額に応じた与信枠を算出する支払準備を行なう先行処理と、
   前記ホストシステムの停止中に、前記店頭端末に対するデビットカードを用いての支払指示を取得した場合、前記与信枠を用いて支払を行なう第２処理と、
   前記ホストシステムが再開した場合に、前記与信枠において支払われた金額を前記ホストシステムの口座残高から引き落とす後続処理とを実行することを特徴とする決済処理方法。
7. 利用者の口座残高を管理するホストシステム及び店頭端末に接続される決済処理部と、
   ホストシステムの停止中の支払を支援する支払支援部として機能するコンピュータを備えた決済処理システムを用いて、決済支援を行なうためのプログラムであって、
   前記コンピュータを、
   前記ホストシステムの稼働中に、前記店頭端末に対するデビットカードを用いての支払指示を取得した場合、前記ホストシステムの口座残高を用いて支払を行なう第１処理を実
   行する手段、
   前記ホストシステムの停止前に、前記ホストシステムの口座残高を取得し、前記口座残高から必要額を引き落として、前記デビットカードの代替手段としての電子マネーをチャージする支払準備を行なう先行処理と、
   前記ホストシステムの停止中に、前記店頭端末に対するデビットカードを用いての支払指示を取得した場合、前記電子マネーによる支払を行なう第２処理と、
   前記ホストシステムが再開した場合に、前記停止前にチャージされた電子マネーの必要額の残りの残高を前記ホストシステムの口座残高に還元する後続処理とを実行する手段として機能させることを特徴とする決済処理プログラム。
8. 利用者の口座残高を管理するホストシステム及び店頭端末に接続される決済処理部と、
   ホストシステムの停止中の支払を支援する支払支援部として機能するコンピュータを備えた決済処理システムを用いて、決済支援を行なうためのプログラムであって、
   前記コンピュータを、
   前記ホストシステムの稼働中に、前記店頭端末に対するデビットカードを用いての支払指示を取得した場合、前記ホストシステムの口座残高を用いて支払を行なう第１処理を実行する手段、
   前記ホストシステムの停止前に、前記ホストシステムの口座残高を取得し、前記口座残高に基づいて、前記デビットカードの代替手段としての必要額に応じた与信枠を算出する支払準備を行なう先行処理と、
   前記ホストシステムの停止中に、前記店頭端末に対するデビットカードを用いての支払指示を取得した場合、前記与信枠を用いて支払を行なう第２処理と、
   前記ホストシステムが再開した場合に、前記与信枠において支払われた金額を前記ホストシステムの口座残高から引き落とす後続処理とを実行する手段として機能させることを特徴とする決済処理プログラム。

Images