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

決済処理システム、決済処理方法及び決済処理プログラム Download PDF

Info

Publication number
JP6491372B1
JP6491372B1 JP2018017946A JP2018017946A JP6491372B1 JP 6491372 B1 JP6491372 B1 JP 6491372B1 JP 2018017946 A JP2018017946 A JP 2018017946A JP 2018017946 A JP2018017946 A JP 2018017946A JP 6491372 B1 JP6491372 B1 JP 6491372B1
Authority
JP
Japan
Prior art keywords
payment
host system
account balance
settlement
account
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2018017946A
Other languages
English (en)
Other versions
JP2019135575A (ja
Inventor
聡 西本
聡 西本
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Mizuho Bank Ltd
Original Assignee
Mizuho Bank Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Mizuho Bank Ltd filed Critical Mizuho Bank Ltd
Priority to JP2018017946A priority Critical patent/JP6491372B1/ja
Application granted granted Critical
Publication of JP6491372B1 publication Critical patent/JP6491372B1/ja
Publication of JP2019135575A publication Critical patent/JP2019135575A/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

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

Description

本発明は、ユーザ端末を利用して、決済を行なうための決済処理システム、決済処理方法及び決済処理プログラムに関する。
今日、利用者が所持するユーザ端末を用いて、商品購入時等の決済を行なうための技術が検討されている(例えば、特許文献1,2参照)。特許文献1に記載された技術においては、ユーザ端末は、店舗端末から商品購入代金を取得し、クレジット決済を要求する。クレジットサーバは、クレジット決済を行ない、クレジット決済金額の電子マネーの発行を電子マネーサーバに指示する。電子マネーサーバは、ユーザ端末にクレジット決済金額の電子マネーを送信する。そして、クレジット決済金額の電子マネーを受信したユーザ端末は、店舗端末に出力する。
また、特許文献2に記載された技術においては、商品購入の際に自身の顧客端末上で専用アプリを起動しておき、店舗のレジのPOS端末に購入金額を入力すると、POS端末は、顧客端末に登録されたカード情報を読み取り、カード情報と、購入情報をカード決済管理サーバに送信する。
一方、デビットカードを用いた取引においては、金融機関のホストシステムにオンラインで接続される。この場合、ホストシステムが稼働していない時間帯では取引ができない。このため、取引時間外に、現金自動預払機で出金取引を行なうための技術も検討されている(例えば、特許文献3参照)。この特許文献3に記載された技術では、ホストコンピュータの稼働を停止させた時間帯に取引を行う時間外取引の予約を端末機から受け付け、予約成立時には、予約取引番号を採番して予約管理ファイルに記録する。現金自動預払機からの取引の要求により、予約管理ファイルに記憶した予約取引番号の取引を実行する。
特開2013−80356号公報 特開2017−130092号公報 特開2010−92316号公報
上記特許文献1に記載された技術においては、クレジットカードの利用を前提としている。しかしながら、利用者によっては、クレジットカードを保有していない場合もある。この場合には、ユーザ端末を利用した決済を行なうことができない。また、特許文献2においても、デビットカードへの適用が示唆されているが、銀行口座を用いる金融機関のホストシステムの稼働が前提となる。また、特許文献3に記載された技術では、予約が必要であり、店舗等における商品購入においては速やかな決済ができない。
上記課題を解決する決済処理システムは、利用者の口座残高を管理するホストシステム及び店頭端末に接続される決済処理部と、ホストシステムの停止中の支払を支援する支払支援部を備える。そして、前記決済処理部は、前記ホストシステムの稼働中に、前記店頭端末に対するデビットカードを用いての支払指示を取得した場合、前記ホストシステムの口座残高を用いて支払を行なう第1処理を実行し、前記支払支援部は、前記ホストシステムの停止前に、前記ホストシステムの口座残高を取得し、前記口座残高に基づいて、前記デビットカードの代替手段における支払準備を行なう先行処理と、前記ホストシステムの停止中に、前記店頭端末に対するデビットカードを用いての支払指示を取得した場合、前記代替手段による支払を行なう第2処理と、前記ホストシステムが再開した場合に、前記代替手段により支払われた金額を口座残高に反映させる後続処理とを実行する。
本発明によれば、ユーザ端末を利用して、効率的に決済を行なうことができる。
第1の実施形態の決済処理システムの説明図。 第1の実施形態の処理手順の説明図。 第1の実施形態の処理手順の説明図。 第2の実施形態の決済処理システムの説明図。 第2の実施形態の処理手順の説明図。 第2の実施形態の処理手順の説明図。 第3の実施形態の決済処理システムの説明図。 第3の実施形態の処理手順の説明図。 第3の実施形態の処理手順の説明図。
(第1の実施形態)
以下、図1〜図3に従って、決済処理システム、決済処理方法及び決済処理プログラムを具体化した第1の実施形態を説明する。本実施形態では、金融機関の顧客(利用者)に対して、ユーザ端末を利用して決済を行なうためのウォレット(電子的な決済媒体)の管理を想定する。このウォレットには、複数の決済媒体を記録することが可能である。決済媒体としては、電子マネー、キャッシュカード(デビットカード)、クレジットカード等を用いることができる。
ここでは、図1に示すように、ネットワークを介して接続されたユーザ端末10、店舗端末20、中継サーバ30、銀行サーバ40、APIサーバ50を用いる。
ユーザ端末10は、金融機関に口座を開設した利用者が用いるコンピュータ端末である。ユーザ端末10は、無線通信を介して、店舗端末20と接続する。この無線通信には、例えば、NFC(Near field radio communication)方式を用いることができる。このユーザ端末10は、制御部11、情報記憶部12、タッチパネルディスプレイ15を備える。
制御部11は、制御手段(CPU、RAM、ROM等)を備え、後述する処理(決済処理段階、支払支援段階等の各処理等)を行なう。そのため、ユーザ端末10には、決済処理アプリケーションが格納されている。決済処理アプリケーションを起動することにより、制御部11は、支払支援部111、決済処理部112として機能する。
支払支援部111は、デビットカードを用いた決済時に、銀行サーバ40を利用できない場合に、決済を支援するための処理を実行する。この支払支援部111は、代替手段を用いての決済を許容する金額(必要額)に関するデータを記憶させておく。この必要額は、銀行サーバ40の停止期間中に使用された金額の統計値や、使用される可能性がある金額の予測値、利用者によって指定された金額等を用いる。
更に、支払支援部111は、銀行サーバ40の停止期間(停止予定日時、再開予定日時)に関するデータを保持している。
更に、支払支援部111は、後述するAPIサーバ50にアクセスし、銀行口座の残高を取得したり、振替依頼を送信したりする。
決済処理部112は、利用者が取引を行なう場合の代金支払い等の決済処理を実行する。この決済には、ウォレットに格納された決済媒体を選択して用いる。
情報記憶部12には、ウォレット情報記憶領域122、決済履歴情報記憶領域123が設けられている。
ウォレット情報記憶領域122には、決済媒体管理レコードが記録される。この決済媒体管理レコードは、利用者が利用可能な決済媒体が登録された場合に記録される。決済媒体レコードは、媒体種別、発行者、媒体コード、残高に関するデータを含んで構成される。
媒体種別データ領域には、決済媒体の種類を特定するための識別子に関するデータが記録される。決済媒体としては、例えば、電子マネー、キャッシュカード、クレジットカード等が記録される。
発行者データ領域には、この決済媒体の発行者を特定するための識別子に関するデータが記録される。例えば、電子マネーの発行者や、銀行名、クレジット会社名等が記録される。
媒体コードデータ領域には、決済媒体を特定するための識別子に関するデータが記録される。例えば、電子マネーの場合には、利用者固有情報、キャッシュカードの場合には口座番号、クレジットカードの場合には、カード番号等が記録される。
残高データ領域には、プリペイド方式の決済媒体については、そのチャージ残高に関するデータが記録される。
決済履歴情報記憶領域123には、決済履歴管理レコードが記録される。この決済履歴管理レコードは、取引における決済が完了した場合に記録される。決済履歴管理レコードは、決済番号、媒体コード、店舗コード、決済日時、金額に関するデータを含んで構成される。
決済番号データ領域には、各決済を特定するための識別子に関するデータが記録される。
媒体コードデータ領域には、この決済に用いられた決済媒体を特定するための識別子に関するデータが記録される。
店舗コードデータ領域には、この決済を行なった店舗を特定するための識別子に関するデータが記録される。
決済日時データ領域には、決済を完了した年月日及び時刻に関するデータが記録される。
金額データ領域には、取引における決済金額に関するデータが記録される。
タッチパネルディスプレイ15は、画面上に情報を出力する出力部、タッチ操作等による情報を入力する入力部として機能する。
店舗端末20は、ユーザ端末10と無線通信を行ない、取引(例えば、商品購入)の決済に必要な情報を取得する。そして、店舗端末20は、ユーザ端末10から、決済媒体に関するトークンを取得する。
中継サーバ30は、店舗端末20と、銀行サーバ40やクレジット会社サーバ等の金融機関サーバとの間の通信を中継するコンピュータシステムである。例えば、「Credit And Finance Information Switching system(CAFIS)」(登録商標)を用いる。決済時にキャッシュカードを用いる場合、中継サーバ30は、店舗端末20から取得したトークンに基づいて、利用者の口座を特定し、決済要求を銀行サーバ40に送信する。そして、銀行サーバ40で口座引落(決済)が行なわれた場合には、中継サーバ30は、銀行サーバ40から決済結果を取得し、決済番号を付与した取引結果を蓄積する。この取引結果には、決済番号、取引日時、店舗コード、取引金額、金融機関コードに関するデータを含める。そして、中継サーバ30は、店舗端末20に取引結果通知を返信する。
銀行サーバ40は、顧客の銀行口座を管理する銀行のホストシステム(金融機関サーバ)である。
この銀行サーバ40は、利用者の銀行口座毎に、口座残高、入出金履歴を記憶する口座情報記憶部42を備える。
銀行口座データ領域には、利用者の銀行口座を特定する識別子(口座番号)に関するデータが記録される。
口座残高データ領域には、この銀行口座の残高に関するデータが記録される。
入出金履歴データ領域には、入出金日時、入出金額、摘要に関するデータが記録される。
銀行サーバ40は、中継サーバ30から取得した決済要求に基づいて、利用者の銀行口座から決済代金を引き落とす。そして、銀行サーバ40は、決済結果を、中継サーバ30に提供する。中継サーバ30は、決済結果を、店舗端末20に転送する。
APIサーバ50は、インターネット等のネットワークを介してユーザ端末10に接続される。このAPIサーバ50は、残高照会API51、振替処理API52を備える。
残高照会API51は、ユーザ端末10に対して、銀行サーバ40に開設された銀行口座の残高に関する情報を提供する。
振替処理API52は、ユーザ端末10から取得した振替指示に基づいて、銀行サーバ40に対して、利用者口座から振替先口座への振替処理を指示する。
(停止対応処理)
図2を用いて、停止対応処理を説明する。この処理は、定期的に実行される。
まず、ユーザ端末10の制御部11は、停止前かどうかについての判定処理を実行する(ステップS1−1)。具体的には、制御部11の支払支援部111は、ユーザ端末10内のシステムタイマから現在日時を取得する。そして、支払支援部111は、銀行サーバ40の停止予定日時と比較する。停止予定日時の所定時間前に達している場合には、銀行サーバ40の停止前と判定する。
停止予定日時の所定時間前に達しておらず、停止前でないと判定した場合(ステップS1−1において「NO」の場合)、ユーザ端末10の制御部11は、所定時間後に、停止前かどうかについての判定処理(ステップS1−1)を繰り返す。
一方、銀行サーバ40の停止時刻の所定時間前に達して、停止前と判定した場合(ステップS1−1において「YES」の場合)、ユーザ端末10の制御部11は、残高取得処理を実行する(ステップS1−2)。具体的には、制御部11の支払支援部111は、ネットワークを介して、APIサーバ50にアクセスする。そして、支払支援部111は、残高照会API51を介して、デビットカードの銀行口座の残高を取得する。
次に、ユーザ端末10の制御部11は、口座引落処理を実行する(ステップS1−3)。具体的には、制御部11の支払支援部111は、残高と必要額とを比較する。そして、必要額以上の残高がある場合には、支払支援部111は、APIサーバ50の振替処理API52を介して、口座から必要額の引落指示を送信する。一方、残高が必要額未満の場合には、支払支援部111は、APIサーバ50の振替処理API52を介して、すべての残高をチャージする引落指示を送信する。
次に、ユーザ端末10の制御部11は、電子マネーのチャージ処理を実行する(ステップS1−4)。具体的には、制御部11の支払支援部111は、APIサーバ50を介して、銀行サーバ40から電子マネーのチャージ指示を取得する。ここでは、口座残高から引き落とした金額(必要額、残高の低い方の金額)のチャージ指示を取得する。この場合、支払支援部111は、チャージ指示の金額を、情報記憶部12のウォレット情報記憶領域122の電子マネー残高に加算する。
次に、ユーザ端末10の制御部11は、停止終了かどうかについての判定処理を実行する(ステップS1−5)。具体的には、制御部11の支払支援部111は、ユーザ端末10内のシステムタイマから現在日時を取得する。そして、支払支援部111は、銀行サーバ40の再開予定日時と比較する。再開予定日時を経過している場合には、銀行サーバ40の停止終了と判定する。
再開予定日時を経過しておらず、停止終了でないと判定した場合(ステップS1−5において「NO」の場合)、ユーザ端末10の制御部11は、所定時間後に、停止終了かどうかについての判定処理(ステップS1−5)を繰り返す。
一方、再開予定日時を経過し、停止終了と判定した場合(ステップS1−5において「YES」の場合)、ユーザ端末10の制御部11は、利用額の算出処理を実行する(ステップS1−6)。具体的には、制御部11の支払支援部111は、今回の銀行サーバ40の停止期間中に、デビットカードの代わりに使用された電子マネーの金額(代替金額)を、情報記憶部12の決済履歴情報記憶領域123から取得する。
次に、ユーザ端末10の制御部11は、電子マネーの返却処理を実行する(ステップS1−7)。具体的には、制御部11の支払支援部111は、銀行サーバ40の停止前にチャージした金額(必要額、残高の低い方の金額)から代替金額を差し引いて、返却金額を算出する。そして、支払支援部111は、情報記憶部12のウォレット情報記憶領域122の電子マネー残高から返却金額を差し引く。更に、支払支援部111は、APIサーバ50の振替処理API52を介して、返却金額の銀行口座への振替指示を送信する。この場合、銀行サーバ40は、振替指示に基づいて、利用者の銀行口座に返却金額を入金する。
(決済時処理)
図3を用いて、決済時処理を説明する。ユーザ端末10のデジタルウォレットを用いて決済を行なう場合、ウォレットアプリケーションを起動する。
まず、ユーザ端末10の制御部11は、決済媒体の選択処理を実行する(ステップS2−1)。具体的には、制御部11の決済処理部112は、情報記憶部12のウォレット情報記憶領域122に記録されている決済媒体管理レコードの媒体種別をタッチパネルディスプレイ15に出力する。そして、決済処理部112は、タッチパネルディスプレイ15において選択された媒体種別を、決済媒体として特定する。本実施形態では、媒体種別としてデビットカードを選択する場合を想定する。
次に、ユーザ端末10の制御部11は、停止期間中かどうかについての判定処理を実行する(ステップS2−2)。具体的には、制御部11の決済処理部112は、システムタイマから現在日時を取得する。そして、決済処理部112は、現在日時と停止期間とを比較する。現在日時が停止期間に含まれる場合には、停止期間中と判定する。
停止期間中でないと判定した場合(ステップS2−2において「NO」の場合)、ユーザ端末10の制御部11は、取引要求処理を実行する(ステップS2−3)。具体的には、制御部11の決済処理部112は、無線通信を利用して、店舗端末20に取引要求を送信する。この取引要求には、選択された決済媒体(キャッシュカード)の媒体コード(口座番号)を含めたトークンを含める。この場合、店舗端末20は、決済要求を中継サーバ30に送信する。この決済要求には、店舗における取引金額、店舗コード、ユーザ端末10から取得したトークンを含める。この場合、中継サーバ30は、トークンから口座番号を取得する。そして、中継サーバ30は、銀行サーバ40に対して、決済要求を送信する。この決済要求には、口座番号及び取引金額に関するデータを含める。
中継サーバ30から決済要求を取得した銀行サーバ40は、口座残高の取得処理を実行する(ステップS2−4)。具体的には、銀行サーバ40は、決済要求に含まれる口座番号の口座の残高情報を取得する。
次に、銀行サーバ40は、銀行口座引落処理を実行する(ステップS2−5)。銀行サーバ40は、取引金額と口座残高とを比較する。取引金額以上の口座残高があり、決済可能と判定した場合、銀行サーバ40は、利用者の口座残高から取引金額を引き落とし、別段口座に入金する。そして、銀行サーバ40は、中継サーバ30からの指示に応じて、別段口座に入金された資金を店舗コードに対応した口座に入金する。なお、口座残高が取引金額未満で、決済不可と判定した場合、銀行サーバ40は、口座引落を行なわない。
そして、銀行サーバ40は、決済結果の返信処理を実行する(ステップS2−6)。具体的には、銀行サーバ40は、中継サーバ30に決済結果を送信する。口座引落を行なった場合には、この決済結果に決済完了フラグを含める。一方、口座引落ができなかった場合には、この決済結果に決済未了フラグを含める。決済完了フラグを含む決済結果を取得した中継サーバ30は、決済番号を付与し、店舗コード、取引金額を記録する。そして、中継サーバ30は、決済番号を付与し、決済完了通知を店舗端末20に送信する。この決済完了通知には、決済番号、店舗コード、取引日時、取引金額を含める。一方、決済未了フラグを含む決済結果を取得した中継サーバ30は、エラー通知を店舗端末20に送信する。店舗端末20は、決済完了通知又はエラー通知をユーザ端末10に転送する。
ユーザ端末10の制御部11は、決済結果の取得処理を実行する(ステップS2−7)。具体的には、制御部11の決済処理部112は、中継サーバ30から取得した決済結果(決済完了通知又はエラー通知)を、タッチパネルディスプレイ15に表示する。
次に、ユーザ端末10の制御部11は、決済完了かどうかについての判定処理を実行する(ステップS2−8)。具体的には、制御部11の決済処理部112は、決済完了通知を取得した場合、決済完了と判定する。
決済完了と判定した場合(ステップS2−8において「YES」の場合)、ユーザ端末10の制御部11は、決済履歴の記録処理を実行する(ステップS2−9)。具体的には、制御部11の決済処理部112は、決済番号、店舗コード、取引金額、取引日時を記録した決済履歴レコードを生成し、決済履歴情報記憶領域123に記録する。
一方、エラー通知を取得し、決済完了でないと判定した場合(ステップS2−8において「NO」の場合)、ユーザ端末10の制御部11は、エラー処理を実行する(ステップS2−10)。具体的には、制御部11の決済処理部112は、タッチパネルディスプレイ15にエラーメッセージを出力する。この場合、決済処理部112は、他の決済媒体の利用を推奨するメッセージを出力する。
一方、停止期間中と判定した場合(ステップS2−2において「YES」の場合)、ユーザ端末10の制御部11は、電子マネーで対応可能かどうかについての判定処理を実行する(ステップS2−11)。具体的には、制御部11の決済処理部112は、情報記憶部12のウォレット情報記憶領域122に記録された電子マネーの残高情報を取得する。取引金額以上の電子マネー残高があり、決済可能と判定した場合、対応可能と判定する。
電子マネーで対応可能と判定した場合(ステップS2−11において「YES」の場合)、ユーザ端末10の制御部11は、電子マネーによる支払処理を実行する(ステップS2−12)。具体的には、制御部11の決済処理部112は、情報記憶部12のウォレット情報記憶領域122に記録された電子マネーを用いての支払指示を、店舗端末20に対して出力する。そして、決済処理部112は、取引金額について、電子マネー残高を減額する。
そして、ユーザ端末10の制御部11は、決済履歴の記録処理を実行する(ステップS2−9)。具体的には、制御部11の決済処理部112は、決済番号、店舗コード、取引金額、取引日時を記録した決済履歴レコードを生成し、決済履歴情報記憶領域123に記録する。この場合、デビットカードの代わりの電子マネーで支払ったことを示す代替フラグを記録する。
一方、電子マネーで対応可能でないと判定した場合(ステップS2−11において「NO」の場合)、ユーザ端末10の制御部11は、エラー処理を実行する(ステップS2−10)。
以上、本実施形態によれば、以下に示す効果を得ることができる。
(1−1)本実施形態では、銀行サーバ40の停止前と判定した場合(ステップS1−1において「YES」の場合)、ユーザ端末10の制御部11は、残高取得処理(ステップS1−2)、口座引落処理(ステップS1−3)、電子マネーのチャージ処理(ステップS1−4)を実行する。これにより、銀行サーバ40の停止期間中に対応するための電子マネーをチャージしておくことができる。
(1−2)本実施形態では、再開予定日時を経過し、停止終了と判定した場合(ステップS1−5において「YES」の場合)、ユーザ端末10の制御部11は、利用額の算出処理(ステップS1−6)、電子マネーの返却処理(ステップS1−7)を実行する。これにより、銀行サーバ40の停止期間中のためにチャージした電子マネーを、利用者口座に戻すことができる。
(1−3)本実施形態では、停止期間中でないと判定した場合(ステップS2−2において「NO」の場合)、ユーザ端末10の制御部11は、取引要求処理を実行する(ステップS2−3)。これにより、銀行サーバ40の稼働期間中であれば、利用者口座を用いて、決済を行なうことができる。
(1−4)本実施形態では、電子マネーで対応可能と判定した場合(ステップS2−11において「YES」の場合)、ユーザ端末10の制御部11は、電子マネーによる支払処理を実行する(ステップS2−12)。これにより、銀行サーバ40を利用できない場合にも、電子マネーを用いて決済を行なうことができる。
(1−5)本実施形態では、ユーザ端末10の制御部11は、決済履歴の記録処理を実行する(ステップS2−9)。これにより、デビットカードによる支払のみならず、デビットカードに代えて電子マネーによる支払の履歴を把握することができる。
(第2の実施形態)
次に、第2の実施形態を図4〜図6に従って説明する。上記第1の実施形態では、停止期間中には、銀行口座の代わりに、電子マネーを用いて決済を行なう。代替手段は、銀行サーバ40の停止中にも決済可能な手段であれば、電子マネーに限定されるものではない。第2の実施形態においては、デビットカードの代替手段として仮想口座を用いて決済を行なうように変更したのみの構成である。このため、上記第1実施形態と同様の部分については、同一の符号を付し、その詳細な説明を省略する。
ここでは、上記第1実施形態と異なり、ユーザ端末10の制御部11に、支払支援部111は不要である。
本実施形態では、銀行サーバ40に接続された決済支援サーバ60を設ける。この決済支援サーバ60は、決済支援部61、仮想口座情報記憶部62を備える。
決済支援部61は、銀行サーバ40の停止期間中の決済を支援するための停止対応処理を実行する。
仮想口座情報記憶部62には、仮想口座番号毎に、銀行サーバ40で管理される銀行口座、仮想口座残高に関するデータを含む仮想口座管理レコードが記録される。
仮想口座番号データ領域には、代替手段としての仮想口座を特定する識別子(口座番号)に関するデータが記録される。
銀行口座データ領域には、利用者の銀行口座を特定する識別子(口座番号)に関するデータが記録される。
仮想口座残高データ領域には、この仮想口座の残高に関するデータが記録される。
(停止対応処理)
次に、図5を用いて、停止対応処理を説明する。
まず、決済支援サーバ60の決済支援部61は、ステップS1−1と同様に、停止前かどうかについての判定処理を実行する(ステップS3−1)。
停止前でないと判定した場合(ステップS3−1において「NO」の場合)、決済支援サーバ60の決済支援部61は、所定時間後に、停止前かどうかについての判定処理(ステップS3−1)を繰り返す。
一方、停止前と判定した場合(ステップS3−1において「YES」の場合)、決済支援サーバ60の決済支援部61は、利用者毎に以下の処理を繰り返す。
ここでは、決済支援サーバ60の決済支援部61は、残高取得処理を実行する(ステップS3−2)。具体的には、決済支援部61は、仮想口座情報記憶部62において、処理対象利用者の口座番号を特定する。そして、決済支援部61は、銀行サーバ40にアクセスし、口座情報記憶部42から利用者の銀行口座の口座残高を取得する。
次に、決済支援サーバ60の決済支援部61は、銀行口座引落処理を実行する(ステップS3−3)。具体的には、決済支援部61は、残高と必要額とを比較する。そして、必要額以上の残高がある場合には、決済支援部61は、銀行口座から必要額の引落指示を送信する。一方、残高が必要額未満の場合には、決済支援部61は、すべての残高の引落指示を送信する。
次に、決済支援サーバ60の決済支援部61は、仮想口座入金処理を実行する(ステップS3−4)。具体的には、決済支援部61は、仮想口座情報記憶部62において、口座残高から引き落とした金額を仮想口座に入金する。
以上の処理を、利用者毎に繰り返す。
次に、決済支援サーバ60の決済支援部61は、ステップS1−5と同様に、停止終了かどうかについての判定処理を実行する(ステップS3−5)。
再開予定日時を経過しておらず、停止終了でないと判定した場合(ステップS3−5において「NO」の場合)、決済支援サーバ60の決済支援部61は、所定時間後に、停止終了かどうかについての判定処理(ステップS3−5)を繰り返す。
一方、再開予定日時を経過し、停止終了と判定した場合(ステップS3−5において「YES」の場合)、決済支援サーバ60の決済支援部61は、利用者毎に、仮想口座残高の返却処理を実行する(ステップS3−6)。具体的には、決済支援部61は、仮想口座のすべての残高を銀行サーバ40の口座に送金する。この処理を、利用者毎に繰り返す。
(決済時処理)
次に、図6を用いて、決済時処理を説明する。
まず、ユーザ端末10の制御部11は、ステップS2−1,S2−3と同様に、決済媒体の選択処理(ステップS4−1)、取引要求処理(ステップS4−2)を実行する。
この場合、決済支援サーバ60の決済支援部61は、取引要求の取得処理を実行する(ステップS4−3)。具体的には、決済支援部61は、ユーザ端末10から、店舗端末20,中継サーバ30を介して、取引要求を取得する。
次に、決済支援サーバ60の決済支援部61は、停止期間中かどうかについての判定処理を実行する(ステップS4−4)。具体的には、決済支援部61は、システムタイマから現在日時を取得し、現在日時と停止期間とを比較する。
停止期間中でないと判定した場合(ステップS4−4において「NO」の場合)、決済支援サーバ60の決済支援部61は、取引要求の転送処理を実行する(ステップS4−5)。具体的には、決済支援部61は、取引要求を銀行サーバ40に転送する。
この場合、銀行サーバ40は、ステップS2−4〜S2−6と同様に、口座残高の取得処理(ステップS4−6)、銀行口座引落処理(ステップS4−7)、決済結果の返信処理(ステップS4−8)を実行する。
一方、停止期間中と判定した場合(ステップS4−4において「YES」の場合)、決済支援サーバ60の決済支援部61は、仮想口座残高の取得処理を実行する(ステップS4−9)。具体的には、決済支援部61は、決済要求に含まれる銀行口座の口座番号に関連付けられた仮想口座の残高情報を仮想口座情報記憶部62から取得する。
次に、決済支援サーバ60の決済支援部61は、仮想口座で対応可能かどうかについての判定処理を実行する(ステップS4−10)。具体的には、決済支援部61は、取引金額と仮想口座残高とを比較する。
取引金額以上の仮想口座残高があり、仮想口座で対応可能と判定した場合(ステップS4−10において「YES」の場合)、決済支援サーバ60の決済支援部61は、仮想口座引落処理を実行する(ステップS4−11)。具体的には、決済支援部61は、仮想口座残高から取引金額を引き落とし、決済支援サーバ60の別段口座に入金する。そして、銀行サーバ40の稼働時に、この別段口座に入金された資金を、銀行サーバ40の稼働時に、店舗コードに対応した銀行口座に入金する処理を行なう。
一方、仮想口座残高が取引金額未満で、仮想口座で対応不可と判定した場合(ステップS4−10において「NO」の場合)、決済支援サーバ60の決済支援部61は、仮想口座引落処理(ステップS4−11)をスキップし、決済結果の返信処理(ステップS4−8)を実行する。
この場合、ユーザ端末10の制御部11は、ステップS2−7〜S2−9と同様に、決済結果の取得処理(ステップS4−12)、決済完了かどうかについての判定処理(ステップS4−13)、決済履歴の記録処理(ステップS4−14)を実行する。
なお、エラー通知を取得し、決済完了でないと判定した場合(ステップS4−13において「NO」の場合)、ユーザ端末10の制御部11は、ステップS2−10と同様に、エラー処理を実行する(ステップS4−15)。
以上、第2の実施形態によれば、以下に示す効果を得ることができる。
(2−1)本実施形態では、決済支援サーバ60の決済支援部61は、残高取得処理(ステップS3−2)、銀行口座引落処理(ステップS3−3)、仮想口座入金処理(ステップS3−4)を実行する。これにより、銀行サーバ40の停止期間中の取引に対応するために、仮想口座の残高を確保しておくことができる。
(2−2)本実施形態では、決済支援サーバ60の決済支援部61は、仮想口座残高の返却処理を実行する(ステップS3−6)。これにより、銀行サーバ40の停止期間中のために確保した仮想口座の残高を、利用者口座に返還することができる。
(2−3)本実施形態では、停止期間中と判定した場合(ステップS4−4において「YES」の場合)、決済支援サーバ60の決済支援部61は、仮想口座残高の取得処理を実行する(ステップS4−9)。仮想口座で対応可能と判定した場合(ステップS4−10において「YES」の場合)、決済支援サーバ60の決済支援部61は、仮想口座引落処理を実行する(ステップS4−11)。これにより、銀行サーバ40の停止期間中には、仮想口座の残高を用いて決済を行なうことができる。
(第3の実施形態)
次に、第3の実施形態を図7〜図9に従って説明する。上記第2の実施形態では、停止期間中には、銀行口座の代わりに、仮想口座を用いて決済を行なう。代替手段は、利用者口座の残高に応じた仮想口座に限定されるものではない。第3の実施形態においては、デビットカードの代替手段として与信を用いて決済を行なうように変更したのみの構成であるため、同様の部分についてはその詳細な説明を省略する。
本実施形態では、決済支援サーバ60(第2実施形態)の代わりに、銀行サーバ40に接続された決済支援サーバ70を設ける。この決済支援サーバ70は、与信処理部71、利用者情報記憶部72を備える。
与信処理部71は、銀行サーバ40の口座情報記憶部42に記録された入出金履歴に基づいて、信用レベルのスコアリングを行なう。ここでは、銀行サーバ40の停止期間中のリスクを考慮してスコアリングを行なう。そして、与信処理部71は、このスコアリングに基づいて、与信可能枠(与信可能額)を決定するためのスコアリングモデルを保持している。
利用者情報記憶部72には、本サービスの利用者の銀行口座毎に、与信枠、利用額に関するデータを含む利用者管理レコードが記録される。
銀行口座データ領域には、利用者の銀行口座を特定する識別子(口座番号)に関するデータが記録される。
与信枠データ領域には、銀行サーバ40の停止期間中に与信により利用可能な金額に関するデータが記録される。
利用額データ領域には、銀行サーバ40の停止期間中に利用された金額に関するデータが記録される。
(停止対応処理)
次に、図8を用いて、停止対応処理を説明する。
まず、決済支援サーバ70の与信処理部71は、ステップS3−1と同様に、停止前かどうかについての判定処理を実行する(ステップS5−1)。
停止前でないと判定した場合(ステップS5−1において「NO」の場合)、決済支援サーバ70の与信処理部71は、所定時間後に、停止前かどうかについての判定処理(ステップS5−1)を繰り返す。
一方、停止前と判定した場合(ステップS5−1において「YES」の場合)、決済支援サーバ70の与信処理部71は、利用者毎に以下の処理を繰り返す。
まず、決済支援サーバ70の与信処理部71は、与信枠の算出処理を実行する(ステップS5−2)。具体的には、与信処理部71は、利用者情報記憶部72において、処理対象利用者の口座番号を特定する。そして、与信処理部71は、銀行サーバ40の口座情報記憶部42から利用者口座の口座残高や入出金履歴を取得する。そして、与信処理部71は、取得した口座残高や入出金履歴をスコアリングモデルに適用して、与信上限枠を算出する。この与信上限枠内で、必要額(与信枠)を決定する。
次に、決済支援サーバ70の与信処理部71は、与信枠の設定処理を実行する(ステップS5−3)。具体的には、与信処理部71は、算出した与信枠を銀行口座の口座番号に関連付けて、利用者情報記憶部72に記録する。
以上の処理を、利用者毎に繰り返す。
次に、決済支援サーバ70の与信処理部71は、ステップS3−5と同様に、停止終了かどうかについての判定処理を実行する(ステップS5−4)。
再開予定日時を経過しておらず、停止終了でないと判定した場合(ステップS5−4において「NO」の場合)、決済支援サーバ70の与信処理部71は、所定時間後に、停止終了かどうかについての判定処理(ステップS5−4)を繰り返す。
一方、再開予定日時を経過し、停止終了と判定した場合(ステップS5−4において「YES」の場合)、決済支援サーバ70の与信処理部71は、利用者毎に以下の処理を繰り返す。
ここでは、決済支援サーバ70の与信処理部71は、利用額の引落処理を実行する(ステップS5−5)。具体的には、与信処理部71は、利用者情報記憶部72に記録されている利用額を取得する。そして、与信処理部71は、銀行サーバ40に対して、利用額について、利用者口座から店舗口座に送金する指示を送信する。
次に、決済支援サーバ70の与信処理部71は、利用額のリセット処理を実行する(ステップS5−6)。具体的には、与信処理部71は、利用者情報記憶部72に記録されている利用額をリセットする。
以上の処理を、利用者毎に繰り返す。
(決済時処理)
次に、図9を用いて、決済時処理を説明する。
まず、ユーザ端末10の制御部11は、ステップS4−1,S4−2と同様に、決済媒体の選択処理(ステップS6−1)、取引要求処理(ステップS6−2)を実行する。
この場合、決済支援サーバ70の与信処理部71は、取引要求の取得処理を実行する(ステップS6−3)。具体的には、与信処理部71は、ユーザ端末10から、店舗端末20,中継サーバ30を介して、取引要求を取得する。
次に、決済支援サーバ70の与信処理部71は、停止期間中かどうかについての判定処理を実行する(ステップS6−4)。具体的には、与信処理部71は、システムタイマから現在日時を取得する。そして、与信処理部71は、現在日時と停止期間とを比較する。
停止期間中でないと判定した場合(ステップS6−4において「NO」の場合)、決済支援サーバ70の与信処理部71は、ステップS4−5と同様に、取引要求の転送処理を実行する(ステップS6−5)。
この場合、銀行サーバ40は、ステップS4−6〜S4−8と同様に、口座残高の取得処理(ステップS6−6)、銀行口座引落処理(ステップS6−7)、決済結果の返信処理(ステップS6−8)を実行する。
一方、停止期間中と判定した場合(ステップS6−4において「YES」の場合)、決済支援サーバ70の与信処理部71は、与信枠において利用可能額の算出処理を実行する(ステップS6−9)。具体的には、与信処理部71は、決済要求に含まれる口座番号を含む利用者管理レコードを利用者情報記憶部72から取得する。次に、与信処理部71は、利用者管理レコードの与信枠から利用額を差し引いて利用可能額を算出する。
次に、決済支援サーバ70の与信処理部71は、与信枠で対応可能かどうかについての判定処理を実行する(ステップS6−10)。具体的には、与信処理部71は、取引金額と利用可能額とを比較する。
利用可能額が取引金額以上であり、与信枠で対応可能と判定した場合(ステップS6−10において「YES」の場合)、決済支援サーバ70の与信処理部71は、貸付処理を実行する(ステップS6−11)。具体的には、与信処理部71は、利用者管理レコードの利用額データ領域に取引金額を加算する。そして、与信処理部71は、取引日時、店舗コード、取引金額を記録した取引管理レコードを生成し、取引情報記憶部に記録する。そして、与信処理部71は、中継サーバ30からの指示に応じて、別段口座に入金された資金を店舗コードに対応した口座に入金する。
一方、利用可能額が取引金額未満であり、与信枠で対応不可と判定した場合(ステップS6−10において「NO」の場合)、決済支援サーバ70の与信処理部71は、貸付処理(ステップS6−11)をスキップし、決済結果の返信処理(ステップS6−8)を実行する。
この場合、ユーザ端末10の制御部11は、ステップS4−12〜S4−14と同様に、決済結果の取得処理(ステップS6−12)、決済完了かどうかについての判定処理(ステップS6−13)、決済履歴の記録処理(ステップS6−14)を実行する。
なお、エラー通知を取得し、決済完了でないと判定した場合(ステップS6−13において「NO」の場合)、ユーザ端末10の制御部11は、ステップS4−15と同様に、エラー処理を実行する(ステップS6−15)。
以上、第3の実施形態によれば、以下に示す効果を得ることができる。
(3−1)本実施形態では、決済支援サーバ70の与信処理部71は、与信枠の算出処理を実行する(ステップS5−2)。これにより、銀行サーバ40の停止期間中の取引に対応するための与信枠を利用者毎に設定することができる。
(3−2)本実施形態では、決済支援サーバ70の与信処理部71は、利用額の引落処理(ステップS5−5)、利用額のリセット処理(ステップS5−6)を実行する。これにより、銀行サーバ40の停止期間中に利用した金額を、銀行口座を用いて支払うことができる。
(3−3)本実施形態では、停止期間中と判定した場合(ステップS6−4において「YES」の場合)、決済支援サーバ70の与信処理部71は、与信枠において利用可能額の算出処理を実行する(ステップS6−9)。与信枠で対応可能と判定した場合(ステップS6−10において「YES」の場合)、決済支援サーバ70の与信処理部71は、貸付処理を実行する(ステップS6−11)。これにより、銀行サーバ40の停止期間中には、与信枠を用いて決済を行なうことができる。
本実施形態は、以下のように変更して実施することができる。本実施形態及び以下の変更例は、技術的に矛盾しない範囲で互いに組み合わせて実施することができる。
・上記第1の実施形態では、ユーザ端末10の制御部11は、口座引落処理(ステップS1−3)、電子マネーのチャージ処理(ステップS1−4)を実行する。ここでは、必要額のチャージを行なう。この必要額は、利用履歴に基づいて算出するようにしてもよい。この場合には、利用者毎に、デビットカードの利用履歴を取得する。そして、利用履歴における金額が高い程、高い必要額を設定する。
また、停止期間の長さに応じて金額を決定してもよい。ここでは、停止期間が長いほど、高い必要額を設定する。
・上記第1の実施形態では、ユーザ端末10の制御部11は、口座引落処理(ステップS1−3)、電子マネーのチャージ処理(ステップS1−4)を実行する。ここでは、電子マネー残高に応じて処理を変更してもよい。例えば、支払支援部111が、銀行サーバ40の停止前に、情報記憶部12のウォレット情報記憶領域122に記録された電子マネー残高を取得し、電子マネー残高が必要額未満の場合のみ、口座引落処理(ステップS1−3)、電子マネーのチャージ処理(ステップS1−4)を実行する。
・上記第1の実施形態では、ユーザ端末10の制御部11は、電子マネーの返却処理を実行する(ステップS1−7)。ここで、電子マネー残高に応じて処理を変更してもよい。例えば、支払支援部111が、銀行サーバ40の停止終了後に、情報記憶部12のウォレット情報記憶領域122に記録された電子マネー残高を取得し、電子マネー残高が基準額以上の場合のみ、電子マネーの返却処理(ステップS1−7)を実行する。
・上記第1の実施形態では、ユーザ端末10の制御部11は、口座引落処理(ステップS1−3)、電子マネーのチャージ処理(ステップS1−4)を実行する。ここで、情報記憶部12のウォレット情報記憶領域122の電子マネー残高に応じて、口座引落処理の要否を判定するようにしてもよい。具体的には、必要額以上の電子マネー残高がある場合には、新たなチャージを行なわない。一方、電子マネー残高が必要額未満の場合には、不足分のみをチャージする。
・上記第2の実施形態では、決済支援サーバ60の与信処理部71は、残高取得処理を実行する(ステップS3−2)。残高の取得方法は、銀行サーバ40に直接、アクセスする場合に限定されるものではない。例えば、決済支援部61は、APIサーバ50の残高照会API51を介して、口座残高を取得するようにしてもよい。
・上記第3の実施形態では、決済支援サーバ70の与信処理部71は、与信枠の算出処理を実行する(ステップS5−2)。この与信枠の算出のタイミングは、銀行サーバ40の停止前に限定されるものではない。例えば、定期的に与信枠を算出するようにしてもよい。
・上記第2、第3の実施形態では、中継サーバ30と銀行サーバ40との間に、決済支援サーバ60,70を設けた。ハードウェア構成はこれに限定されるものではない。例えば、決済支援サーバ60,70を中継サーバ30に設けてもよい。
10…ユーザ端末、11…制御部、111…支払支援部、112…決済処理部、12…情報記憶部、15…タッチパネルディスプレイ、30…中継サーバ、40…銀行サーバ、42…口座情報記憶部、50…APIサーバ、51…残高照会API、52…振替処理API、60…決済支援サーバ、61…決済支援部、62…仮想口座情報記憶部、70…決済支援サーバ、71…与信処理部、72…利用者情報記憶部。

Claims (8)

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

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2018017946A JP6491372B1 (ja) 2018-02-05 2018-02-05 決済処理システム、決済処理方法及び決済処理プログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2018017946A JP6491372B1 (ja) 2018-02-05 2018-02-05 決済処理システム、決済処理方法及び決済処理プログラム

Publications (2)

Publication Number Publication Date
JP6491372B1 true JP6491372B1 (ja) 2019-03-27
JP2019135575A JP2019135575A (ja) 2019-08-15

Family

ID=65895322

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2018017946A Active JP6491372B1 (ja) 2018-02-05 2018-02-05 決済処理システム、決済処理方法及び決済処理プログラム

Country Status (1)

Country Link
JP (1) JP6491372B1 (ja)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113409042A (zh) * 2020-03-16 2021-09-17 丰田自动车株式会社 便携终端、记录了钱包程序的记录介质以及钱包系统
CN113470200A (zh) * 2020-03-31 2021-10-01 丰田自动车株式会社 结算系统、终端装置以及记录介质
JP7058834B1 (ja) 2021-02-05 2022-04-25 クーパン コーポレイション アイテム販売情報処理のための電子装置およびその方法

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2021140712A (ja) * 2020-02-29 2021-09-16 Assest株式会社 融資先信用度判定プログラム
JP2022060657A (ja) * 2020-10-05 2022-04-15 株式会社三菱Ufj銀行 資金決済装置及び資金決済方法
JP7453438B1 (ja) 2023-01-26 2024-03-19 PayPay株式会社 情報管理装置、口座管理サーバ、情報管理方法、およびプログラム

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH11134417A (ja) * 1997-10-30 1999-05-21 The Sumitomo Bank Ltd 国際キャッシュカードのネットワークにおける代行処理システム、事故対応システムおよびその制御方法並びに代行処理制御プログラム、事故対応制御プログラムを記録した記録媒体
JP2002007918A (ja) * 2000-06-23 2002-01-11 Akesesu:Kk 決済処理方法
JP2003108780A (ja) * 2001-09-27 2003-04-11 Glory Ltd 取引決済方法およびシステム並びに装置、記録媒体
JP2004139293A (ja) * 2002-10-17 2004-05-13 Hitachi Ltd 電子商取引方法
JP2004355486A (ja) * 2003-05-30 2004-12-16 Bank Of Tokyo-Mitsubishi Ltd 多機能icカード及びicカード端末
JP2011070604A (ja) * 2009-09-28 2011-04-07 Tis Kk 決済支援装置、および決済支援用プログラム

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH11134417A (ja) * 1997-10-30 1999-05-21 The Sumitomo Bank Ltd 国際キャッシュカードのネットワークにおける代行処理システム、事故対応システムおよびその制御方法並びに代行処理制御プログラム、事故対応制御プログラムを記録した記録媒体
JP2002007918A (ja) * 2000-06-23 2002-01-11 Akesesu:Kk 決済処理方法
JP2003108780A (ja) * 2001-09-27 2003-04-11 Glory Ltd 取引決済方法およびシステム並びに装置、記録媒体
JP2004139293A (ja) * 2002-10-17 2004-05-13 Hitachi Ltd 電子商取引方法
JP2004355486A (ja) * 2003-05-30 2004-12-16 Bank Of Tokyo-Mitsubishi Ltd 多機能icカード及びicカード端末
JP2011070604A (ja) * 2009-09-28 2011-04-07 Tis Kk 決済支援装置、および決済支援用プログラム

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113409042A (zh) * 2020-03-16 2021-09-17 丰田自动车株式会社 便携终端、记录了钱包程序的记录介质以及钱包系统
CN113409042B (zh) * 2020-03-16 2024-04-16 丰田自动车株式会社 便携终端、记录了钱包程序的记录介质以及钱包系统
CN113470200A (zh) * 2020-03-31 2021-10-01 丰田自动车株式会社 结算系统、终端装置以及记录介质
JP7058834B1 (ja) 2021-02-05 2022-04-25 クーパン コーポレイション アイテム販売情報処理のための電子装置およびその方法
JP2022120761A (ja) * 2021-02-05 2022-08-18 クーパン コーポレイション アイテム販売情報処理のための電子装置およびその方法

Also Published As

Publication number Publication date
JP2019135575A (ja) 2019-08-15

Similar Documents

Publication Publication Date Title
JP6491372B1 (ja) 決済処理システム、決済処理方法及び決済処理プログラム
US8682784B2 (en) Method and system to process credit card payment transactions initiated by a merchant
US8423453B1 (en) Systems and methods for processing a transaction
JP2007531123A (ja) 複数のリワードプログラムの一元管理方法およびシステム
US20150248669A1 (en) Systems and methods for managing gift cards
JP2018060300A (ja) 購買管理システム
WO2017107870A1 (zh) 一种脱机消费的方法及装置
US20170357974A1 (en) Payment processing
JP2021002139A (ja) 決済サーバ、決済方法及びプログラム
Nagasubramanian et al. Payment gateway-innovation in multiple payments
WO2006019368A2 (en) Method and system to process credit card payment transactions initiated by a merchant
US10977659B2 (en) Real-time monitoring system
TWM613595U (zh) 保險商品保費折抵系統及保險公司端伺服器
JP7148852B1 (ja) 支払いを処理するためのシステム、方法、及びプログラム
CA3116976A1 (en) Process flow management
JP7510466B2 (ja) サービス提供装置、サービス提供方法、およびプログラム
WO2020047676A1 (en) System and method for managing resource consumption for electronic transaction data processes
JP7206430B1 (ja) 情報処理装置、情報処理方法、およびプログラム
US20180082370A1 (en) Credit card product with dynamic interest rate based on balance/spending in merchant categories
JP7331284B1 (ja) 情報提供装置、情報提供方法、およびプログラム
JP7456037B1 (ja) カード情報管理装置、カード情報管理方法、およびプログラム
KR20140038654A (ko) 가맹점에 대한 결제 정보 제공 시스템
JP7414206B1 (ja) 情報処理システム、及び情報処理方法
JP7502529B1 (ja) 決済処理装置、支払処理方法、及びプログラム
JP7278451B1 (ja) サービス提供システムおよびサービス提供方法

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20180205

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20181016

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20181217

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20190129

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20190228

R150 Certificate of patent or registration of utility model

Ref document number: 6491372

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250