JP7143253B2 - 決済サーバ、決済サーバの決済方法及びプログラム - Google Patents

Description

本発明は、決済サーバ、決済サーバの決済方法及びプログラムに関する。

従来、商品等の購入代金を店舗へ支払う方法として、顧客の口座から購入代金を引き落とすキャッシュレス決済が知られている（例えば、特許文献１－５）。

特許第６３６８４４６号公報 特開２００４－７８５０２号公報 特開２００３－２８１４５８号公報 特開２００６－９９４８５号公報 特開２００４－７０８３３号公報

キャッシュレス決済においては、複数の口座から決済用の口座を選択したり、取引後に任意のタイミングで決済したり、複数取引をまとめて決済したりしたい等の要望が顧客側にある。しかしながら、顧客側の要望通り、複数の口座からの決済用の口座の選択や取引後における決済が可能になると、キャッシュレス決済サービスの提供機関は、取引時に決済用の口座を特定できず、後日の決済時に決済用の口座の残高が支払い金額未満であると当該支払い金額を回収できなくなる虞がある。顧客側の要望のみを満たし、決済サービスの提供機関のリスクを低減できないキャッシュレス決済は、普及され難くなる。

本発明は、上記課題に鑑みてなされたものであり、顧客側の要望を満たしつつ、決済サービスの提供機関のリスクを低減できる技術を提供することを課題とする。

上記課題を解決するため、本発明では、取引時に顧客の代表口座の残高に基づいて決済条件を決定することとした。

詳細には、本発明は、決済サーバであって、取引前に銀行サーバと通信を行って顧客の複数口座における口座状況を取得し、前記口座状況に基づいて決済サービスの利用可否を判定する判定部と、前記複数口座から代表口座を特定する特定部と、取引時に支払い金額及び前記代表口座の残高に基づいて決済条件を決定する決定部と、取引後に決済用の口座を顧客が設定する条件に基づいて特定し、前記決済用の口座から前記決済条件に基づいて決済を行う決済部と、を備える。

ここで、顧客は複数口座を有しており、決済サーバは銀行サーバと通信を行うことで複数口座における口座状況を取得する。なお、決済サーバが通信可能な銀行サーバは複数であってもよい。このような決済サーバによれば、決済サービス利用可否が複数の口座における口座状況に基づいて判定されるため、例えば、顧客は、取引時に一つの口座の残高が支払い金額未満であっても取引前の全口座における口座状況によっては決済サービスを利用することができ、更に、複数の口座から任意の口座を決済用の口座に選択して支払いができる。また、決済サーバによれば、決済サービス利用可否を複数の口座における口座状況に基づいて判定しつつ、取引時に代表口座の残高の情報を取得し当該残高に基づいて決
済条件を決定する二段階の判定を行うことで、決済サービスの提供機関が支払い金額を回収できない場合のリスクに備えることができる。

上記決済サーバにおいて、前記口座状況は、前記複数口座の合計残高を含み、前記判定部は、前記合計残高が所定金額以上である場合に前記決済サービスの利用を前記顧客に対して許可してもよい。

上記決済サーバにおいて、前記判定部は、所定の日数経過毎に前記口座状況を取得し、前記決済サービスの利用可否を判定してもよい。

上記決済サーバにおいて、前記判定部は、顧客が設定する条件に基づいて前記口座状況を取得し、前記決済サービスの利用可否を判定してもよい。

上記決済サーバにおいて、前記特定部は、前記複数口座のうち残高が最も高い口座を前記代表口座として特定してもよい。

上記決済サーバにおいて、前記特定部は、顧客が設定する条件に基づいて前記代表口座を特定してもよい。

上記決済サーバにおいて、前記決定部は、前記代表口座の残高が支払い金額未満である場合に前記決済条件として前記顧客に対して不利な条件を決定してもよい。

また、本発明は、方法またはプログラムの側面から捉えることもできる。例えば、本発明は、決済方法であって、取引前に銀行サーバと通信を行って顧客の複数口座における口座状況を取得し、前記口座状況に基づいて決済サービスの利用可否を判定するステップと、前記複数口座から代表口座を特定するステップと、取引時に支払い金額及び前記代表口座の残高に基づいて決済条件を決定するステップと、取引後に決済用の口座を顧客が設定する条件に基づいて特定し、前記決済用の口座から前記決済条件に基づいて決済を行うステップと、を備えていてもよい。

上記の決済サーバ、決済方法及びプログラムであれば、顧客側の要望を満たしつつ、決済サービスの提供機関のリスクを低減できる。

図１は、実施形態に係る決済システムの構成図である。 図２は、実施形態に係る決済システムの決済サーバにおいて実現される機能ブロックを示した図である。 図３は、実施形態に係る決済システムの決済サーバにおける取引前の処理フローの一例を示した図である。 図４は、実施形態に係る決済システムの決済サーバにおける取引時の処理フローの一例を示した図である。 図５は、実施形態に係る決済システムの決済サーバにおける取引後の処理フローの一例を示した図である。

以下、実施形態について説明する。以下に示す実施形態は、単なる例示であり、本開示の技術的範囲を以下の態様に限定するものではない。

図１は、実施形態に係る決済システムの構成図である。決済システムは、決済サーバ１
と、小売店等の店舗に配置された店舗端末２と、顧客が利用する顧客端末３と、銀行サーバ５ａ～５ｃと、を備える。決済サーバ１と、店舗端末２及び顧客端末３とは、通信網４を介して相互に通信可能に接続されている。また、決済サーバ１は、銀行サーバ５ａ～５ｃと専用回線を介して相互に通信可能に接続されている。決済システムは、決済サーバ１、店舗端末２、顧客端末３、銀行サーバ５ａ～５ｃが協働することによって、顧客が店舗等に購入金額等を支払うキャッシュレスの決済サービス（以下、単に「決済サービス」と称する）を実現する。

決済サーバ１は、決済サービスの提供機関が管理するサーバであり、当該機関を利用する顧客が商品等を購入した際の決済に係る処理を行う。店舗端末２は、実店舗（例えば、スーパーマーケット、コンビニエンスストア、飲食店）や、インターネット上で営業する仮想店舗又はその他の各種の店舗で営業を行う事業者が使用する端末であり、当該事業者の店舗で行われた支払いに係る決済データを決済サーバ１へ送信する。店舗端末２は、店舗に設置された精算機自体であってもよいし、仮想店舗の場合であれば仮想商店街を運営する運営者が管理するデータセンタのサーバであってもよい。

本実施形態に係る決済システムでは、各事業者の店舗において、店舗端末２を通じて顧客端末３の支払い用アプリケーションを用いた支払い、顧客が店員に提示した会員カードの情報を店員が端末に入力することによって行われる支払い等、各種の電子的手段を用いた顧客の支払いが行われると、当該支払いに係る決済データが店舗端末２から通信網４を介して決済サーバ１へ送信される。決済データには、顧客情報、支払い金額、購入品名、購入店舗、購入日時等が含まれる。そして、決済サーバ１では、店舗端末２から送られた決済データを基に、各事業者の口座への入金処理や顧客の口座からの出金処理が行われる。なお、決済データは、店舗端末２の代わりに顧客端末３から通信網４を介して決済サーバ１へ送られてもよい。

決済サーバ１は、ＣＰＵやメモリ、通信インタフェース、ＨＤＤ（Hard Disk Drive）
やＳＳＤ（Solid State Drive）等のストレージを有する情報処理装置である。決済サー
バ１では、電磁的手段を使って行われる決済に係るコンピュータプログラムや、銀行の顧客の口座を管理するコンピュータプログラムが実行される。

顧客端末３は、決済サーバ１にアクセスする顧客が操作する情報処理装置であり、例えば、パーソナルコンピュータ（ＰＣ）やタブレットＰＣ、スマートフォン等の各種装置が挙げられる。

店舗端末２は、ＣＰＵやメモリ、通信インタフェース等を有する情報処理装置である。店舗端末２では、決済サービスに係るコンピュータプログラムが実行されることにより、顧客端末３から顧客情報を取得する処理や、顧客情報と当該顧客が購入した商品等の情報を決済サーバ１へ通知する処理が実現される。なお、本実施形態では、店舗端末２は顧客端末３が表示する二次元コードを読み取ることによって顧客情報を取得する。なお、店舗端末２は、顧客端末３と近距離無線通信を行って顧客情報を取得してもよい。また、店舗端末２は、電気的な接点が接触する接触式のＩＣカードを読み取る端末であってもよいし、磁気カードの情報を読み取る端末であってもよく、顧客端末３に代えてＩＣカードや磁気カードを読み取ることによって顧客情報を取得してもよい。

通信網４は、主に公衆通信回線で形成されている。通信網４は、有線と無線の何れの通信回線であってもよい。通信網４を使って店舗端末２と決済サーバ１及び顧客端末３と決済サーバ１との間で取り交わされるデータは、通信内容が傍受されるのを防ぐために暗号化される。

銀行サーバ５ａ～５ｃは、ＣＰＵやメモリ、通信インタフェース、ＨＤＤ（Hard Disk Drive）やＳＳＤ（Solid State Drive）等のストレージを有する情報処理装置である。銀行サーバ５ａ～５ｃでは、決済サービスに係るコンピュータプログラムや、銀行の顧客の口座を管理するコンピュータプログラムが実行される。

銀行サーバ５ａは、Ａ銀行の口座情報が記憶されたサーバであり、銀行サーバ５ｂは、Ｂ銀行の口座情報が記憶されたサーバであり、銀行サーバ５ｃは、Ｃ銀行の口座情報が記憶されたサーバである。本実施形態に係る決済システムにおいて、顧客は複数の銀行に口座を有しており、決済サーバ１には、複数の銀行における口座情報を取得する。口座情報には、口座名義人、口座のある支店名や支店番号、口座番号等が含まれる。なお、顧客は一つの銀行に複数の口座を有しており、決済サーバ１は、当該一つの銀行における複数の口座情報を取得してもよい。

図２は、決済サーバ１において実現される機能ブロックを示した図である。決済サーバ１のメモリに記憶されているコンピュータプログラムを決済サーバ１のＣＰＵが実行することにより、決済サーバ１では、図２に示すように、通信部１０、判定部１１、特定部１２、決定部１３、決済部１４が実現される。また、決済サーバ１には、データベース１５が設けられている。通信部１０は、店舗端末２、顧客端末３及び銀行サーバ５ａ～５ｃとのデータ通信を行う。判定部１１は、取引前に銀行サーバ５ａ～５ｃと通信を行って顧客の複数口座における口座状況を取得し、口座状況に基づいて決済サービスの利用可否を判定する。特定部１２は、顧客の複数口座から代表口座を特定する。決定部１３は、取引時に支払い金額及び代表口座の残高に基づいて決済条件を決定する。決済部１４は、取引後に決済用の口座を顧客が設定する条件に基づいて特定し、決済用の口座から決済条件に基づいて決済を行う。データベース１５は、顧客の氏名や住所、メールアドレス等の顧客情報及び顧客情報に紐づけられた顧客の複数の口座情報が記憶されている。

図３は、本実施形態に係る決済システムの決済サーバ１による取引前の処理フローの一例を示している。まず、決済サーバ１は、顧客の全口座の口座状況を取得する（ステップＳ１０１）。決済サーバ１のデータベース１５には、顧客が予め登録した口座情報が記憶されており、決済サーバ１は、この口座情報に基づいて銀行サーバ５ａ～５ｃと通信を行って顧客によって予め登録された全口座の口座状況を取得する。この全口座の口座状況取得には、公知のスクレイピングや、銀行ＡＰＩ等の技術が用いられる。口座状況には、普通預金における合計残高や、普通預金及び定期預金の合計残高、貸越サービスの利用申し込み有無や各銀行におけるその他のサービス利用申し込み有無等が含まれている。

ステップＳ１０１の次のステップＳ１０２では、決済サーバ１は、ステップＳ１０１で取得した口座状況に基づいて決済サービスの利用可否を判定する。例えば、決済サーバ１は、全口座における合計残高が所定金額以上である場合に決済サービスの利用を顧客に対して許可し、当該合計残高が所定金額未満である場合に決済サービスの利用を顧客に対して許可しない。なお、当該合計残高は、普通預金における合計残高又は普通預金及び定期預金の合計残高であってもよい。また、決済サーバ１は、全口座のうち最も残高が高い口座の残高が所定金額以上である場合に決済サービスの利用を顧客に対して許可し、当該残高が所定金額未満である場合に決済サービスの利用を顧客に対して許可しなくてもよい。所定金額には、例えば、本例の決済サービスでの一回の取引における上限金額が設定されていてもよい。本例では、この上限金額は、例えば、３５，０００円に設定されている。また、決済サーバ１は、全口座のうち貸越サービスの利用申し込み又は各銀行におけるその他のサービス利用申し込みがされている場合に決済サービスの利用を顧客に対して許可し、いずれも申し込まれていない場合に決済サービスの利用を前記顧客に対して許可しなくてもよい。

決済サーバ１は、ステップＳ１０２において決済サービスの利用を顧客に対して許可すると判定すると（ステップＳ１０２のＹＥＳ）、ステップＳ１０３の処理に移行する。ステップＳ１０３では、決済サーバ１は、顧客に対して決済サービスの利用を許可する設定を行う。例えば、決済サーバ１は、顧客情報に紐づけて決済サービスが利用可能であることをデータベース１５に記憶する。

一方、決済サーバ１は、ステップＳ１０２において決済サービスの利用を顧客に対して許可しないと判定すると（ステップＳ１０２のＮＯ）、ステップＳ１０４の処理に移行する。ステップＳ１０４では、決済サーバ１は、顧客に対して決済サービスの利用を不可とする設定を行う。例えば、決済サーバ１は、データベース１５に顧客情報に紐づけて決済サービスが利用不可能であることを記憶する。

決済サーバ１は、ステップＳ１０３又はステップＳ１０４の処理を終了すると取引前の処理を終了する。

このように、決済サーバ１は、全口座における口座状況に基づいて決済サービスの利用可否を判定する。

また、決済サーバ１は、図３に示す取引前の処理を所定の日数（例えば、１０日）経過毎に実行する。すなわち、決済サーバ１は、所定の日数経過毎に預金情報を取得し、決済サービスの利用可否を判定する。また、決済サーバ１は、顧客が設定する条件に基づいて図３に示す取引前の処理を実行してもよい。例えば、決済サーバ１は、顧客端末３から取引前の処理を実行する指令が送信された場合に当該処理を実行してもよい。これにより、顧客は、任意のタイミングで、決済サービスの利用可否を判定させることができる。例えば、顧客は、自身の口座に入金があったタイミングで、決済サービスの利用可否を判定させることができる。

図４は、本実施形態に係る決済システムの決済サーバ１による取引時の処理フローの一例を示している。決済サーバ１は、店舗端末２や顧客端末３から決済データを受信した場合に取引時の処理を実行する。

まず、決済サーバ１は、顧客が決済サービスを利用可能であるか否かを判定する（ステップＳ２０１）。決済サーバ１は、図３に示すステップＳ１０３又はステップＳ１０４においてデータベース１５に顧客情報に紐付けて記憶した決済サービス利用可否情報に基づいて決済サービス利用可否を判定する。

決済サーバ１は、ステップＳ２０１において決済サービス利用可能であると判定すると（ステップＳ２０１のＹＥＳ）、ステップＳ２０２の処理に移行する。ステップＳ２０２では、決済サーバ１は、顧客の複数口座から代表口座を特定する。例えば、代表口座は予め顧客によって設定されていてもよいし、複数口座のうち最も残高の高い口座が代表口座に特定されてもよい。本実施形態では、代表口座を特定する処理（ステップＳ２０２）は取引時に実行されているが、代表口座を特定する処理は取引前に実行されてもよい。例えば、代表口座を特定する処理は、図３に示すステップＳ１０３の次に実行されてもよいし、図３に示す取引前の処理とは別に所定の日数（例えば、１０日）経過毎に実行されてもよいし、顧客端末３から取引前の処理を実行する指令が送信された場合等の顧客が設定する条件に基づいて実行されてもよい。すなわち、代表口座を特定する処理は、取引前又は取引時のいずれのタイミングで実行されてもよい。

一方、決済サーバ１は、ステップＳ２０１において決済サービス利用不可能であると判定すると（ステップＳ２０１のＮＯ）、ステップＳ２０８の処理に移行する。ステップＳ
２０８では、決済サーバ１は、顧客に対して決済サービスが利用不可能である旨を通知する。この通知は、メールや専用アプリによって顧客端末３に通知される。

また、ステップＳ２０２の次のステップＳ２０３では、決済サーバ１は、代表口座の残高を取得する。決済サーバ１は、代表口座のある銀行の銀行サーバ５ａ～５ｃのいずれかと通信を行い、代表口座の残高を取得する。

ステップＳ２０３の次のステップＳ２０４では、決済サーバ１は、代表口座の残高が取引において顧客が店舗等に支払う支払い金額以上であるか否かを判定する。

決済サーバ１は、ステップＳ２０４において代表口座の残高が支払い金額以上であると判定すると（ステップＳ２０４のＹＥＳ）、ステップＳ２０５の処理に移行する。ステップＳ２０５では、決済サーバ１は、決済手数料をなしに決定する。

一方、決済サーバ１は、ステップＳ２０４において代表口座の残高が支払い金額未満であると判定すると（ステップＳ２０４のＮＯ）、ステップＳ２０６の処理に移行する。ステップＳ２０６では、決済サーバ１は、決済手数料（例えば、２０円）をありに決定する。

ステップＳ２０５またはステップＳ２０６の次のステップＳ２０７では、決済サーバ１は、決済金額を通知する。この通知は、メールや専用アプリによって顧客端末３に通知される。決済金額には、支払い金額と決済手数料が含まれる。

決済サーバ１は、ステップＳ２０７又はステップＳ２０８の処理を終了すると取引時の処理を終了する。

本実施形態では、決済サーバ１は、支払い金額及び代表口座の残高に基づいて決済条件を決定する。決済サーバ１は、代表口座の残高が支払い金額以上である場合に決済条件として顧客に対して有利な条件を決定する。本例の有利な条件は決済手数料なしである。なお、有利な条件は、決済サービスで利用可能なポイントの付与、決済金額の割引、顧客へのキャッシュバック等であってもよい。一方、決済サーバ１は、代表口座の残高が支払い金額未満である場合に決済条件として顧客に対して不利な条件を決定する。本例の不利な条件は決済手数料ありである。なお、不利な条件は、決済サービスの提供機関の設置したＡＴＭ利用手数料の無料回数の制限や、当該提供機関と契約中のローンの金利ペナルティ等であってもよい。また、決済サーバ１は、代表口座の残高に応じて又は代表口座の残高から支払い金額を引いた不足分の金額に応じて、顧客に対して決定する不利な決済条件の程度を決定してもよい。例えば、決済サーバ１は、代表口座の残高が所定金額（例えば、予め決済サービスの提供機関や顧客によって設定される金額）未満である場合や代表口座の残高から支払い金額を引いた不足金額分に応じて不利な決済条件を決定する。決済サーバ１は、代表口座の残高や当該不足金額が大きいほど、決済手数料を高く設定したり、決済サービスの提供機関の設置したＡＴＭ利用手数料の無料回数を少なくしたり、当該提供機関と契約中のローンの金利を高くしたりしてもよい。

また、本実施形態では、決済サーバ１は、ステップＳ２０４において、代表口座の残高が支払い金額未満である場合にステップＳ２０６の処理に移行しているが、代表口座の残高に応じて又は代表口座の残高から支払い金額を引いた不足分の金額に応じて、ステップＳ２０６の処理に移行することを決定してもよい。例えば、決済サーバ１は、代表口座の残高が所定金額（例えば、予め決済サービスの提供機関や顧客によって設定される金額）未満である場合や代表口座の残高から支払い金額を引いた不足分が所定金額（例えば、代表口座以外の口座における残高）以上である場合にステップＳ２０６の処理に移行しても
よい。

図５は、本実施形態に係る決済システムの決済サーバ１による取引後の処理フローの一例を示している。決済サーバ１は、取引後の処理により決済金額を顧客の口座から出金し、決済金額のうち支払い金額を取引が行われた店舗の口座に入金し、決済手数料を決済サービスの提供機関の口座に入金する処理を行う。この取引後の処理は、決済サービスの提供機関が定める毎月決まった日時に実行されてもよいし、顧客によって設定された毎月決まった日時に実行されてもよいし、顧客が設定する任意のタイミングで実行されてもよい。

図５に示すように、まず、決済サーバ１は、決済用の口座を特定する（ステップＳ３０１）。決済用の口座は、取引後に顧客が設定する条件に基づいて特定される。例えば、顧客は、取引後に顧客端末３から決済サーバ１に決済用の口座情報を送信したり、取引後の処理が実行される前日に顧客端末３から決済サーバ１に決済用の口座情報を送信したりすることで、決済用の口座を設定することができる。また、取引後に顧客が決済用の口座を特定するための設定を行わない場合には、決済サーバ１は代表口座又は顧客が取引前に予め設定した所定の口座を決済用の口座として特定してもよい。

ステップＳ３０１の次のステップＳ３０２では、決済サーバ１は、決済処理を行う。決済サーバ１は、決済処理において、決済金額を顧客の決済用の口座から出金し、決済金額のうち支払い金額を取引が行われた店舗の口座に入金し、決済手数料を決済サービスの提供機関の口座に入金する処理を行う。

決済サーバ１は、ステップＳ３０２の処理を終了すると取引後の処理を終了する。

以上説明した本実施形態に係る決済システムによれば、顧客は取引後に複数の口座から任意の口座を決済用の口座に選択して支払ができるため、決済用途に応じて複数の口座を使い分けたり、決済金額に応じて決済用の口座を変更したりすることができる。また、顧客は、取引後に支払いを行うため、任意のタイミングで決済したり、複数取引をまとめて決済したりすることもできる。また、顧客は、取引時に一つの口座の残高が支払い金額を下回っていても、取引前に全口座の合計残高が所定金額以上であれば決済サービスを利用することができ、顧客の利便性を高めることができる。

また、本実施形態に係る決済システムによれば、顧客の代表口座の残高が支払い金額未満であって、支払い金額を回収できない場合の損失に備え、決済手数料収入を得ることができる。また、決済システムにおいて、全口座の残高取得（図３におけるステップＳ１０１）は、取引前に決済サービスの提供機関の都合で実行可能であり、取引時は代表口座のみの残高を取得処理（図４におけるステップＳ２０３）を行うため、取引時に全口座の残高を取得する場合と比較して決済サーバ１のシステム負荷を軽減できる。また、決済システムにおいて、決済サーバ１が取引時に顧客の代表口座の残高を取得することで、少なくとも取引時に代表口座からの決済金額の出金が可能であるかを確認できる。また、決済サーバ１が取引時に顧客の代表口座の残高を取得することで、少なくとも取引時に代表口座からの決済金額の支払いが可能な状況であるかを確認し支払金額を回収できない場合のリスクを低減できる。

また、本実施形態に係る決済システムによれば、決済サービス利用可否が複数の口座における口座状況に基づいて判定されるため（図３のステップＳ１０２）、取引時に一つの口座の残高が支払い金額未満であっても、取引前に全口座の合計残高が所定金額以上であれば決済サービスを利用することができ、更に、複数の口座から任意の口座を決済用の口座に選択して支払いができる。このように、本実施形態に係る決済システムは、顧客の利
便性を高めることができる。また、本実施形態に係る決済システムによれば、決済サーバ１が決済サービス利用可否を複数の口座における口座状況に基づいて判定し（図３のステップＳ１０２）、取引時に代表口座の残高の情報を取得し当該残高に基づいて決済条件を決定する（図４のステップＳ２０４）二段階の判定を行うことで、決済サービスの提供機関が支払い金額を回収できない場合のリスクに備えることができる。

以上の通り、本実施形態に係る決済システムによれば、顧客側の要望を満たしつつ、決済サービスの提供機関のリスクを低減できる。

１・・決済サーバ
２・・店舗端末
３・・顧客端末
４・・通信網
５ａ、５ｂ、５ｃ・・銀行サーバ
１０・・通信部
１１・・判定部
１２・・特定部
１３・・決定部
１４・・決済部
１５・・データベース

Claims (8)

1. 取引前に銀行サーバと通信を行って顧客の複数口座における口座状況を取得し、前記口座状況に基づいて決済サービスの利用可否を判定する判定部と、
   前記複数口座から代表口座を特定する特定部と、
   取引時に支払い金額及び前記代表口座の残高に基づいて、前記残高が前記支払い金額以上である場合に前記顧客にとって経済的利益となる決済条件を決定し、前記残高が前記支払い金額未満である場合に前記顧客にとって経済的不利益となる決済条件を決定する決定部と、
   取引後に決済用の口座を顧客が設定する条件に基づいて特定し、前記決済用の口座から前記決済条件に基づいて決済を行う決済部と、
   を備える、決済サーバ。
2. 前記口座状況は、前記複数口座の合計残高を含み、
   前記判定部は、前記合計残高が所定金額以上である場合に前記決済サービスの利用を前記顧客に対して許可する、
   請求項１に記載の決済サーバ。
3. 前記判定部は、所定の日数経過毎に前記口座状況を取得し、前記決済サービスの利用可否を判定する、
   請求項１又は２に記載の決済サーバ。
4. 前記判定部は、顧客が設定する条件に基づいて前記口座状況を取得し、前記決済サービスの利用可否を判定する、
   請求項１又は２に記載の決済サーバ。
5. 前記特定部は、前記複数口座のうち残高が最も高い口座を前記代表口座として特定する、
   請求項１から４のいずれか一項に記載の決済サーバ。
6. 前記特定部は、顧客が設定する条件に基づいて前記代表口座を特定する、
   請求項１から４のいずれか一項に記載の決済サーバ。
7. 取引前に銀行サーバと通信を行って顧客の複数口座における口座状況を取得し、前記口座状況に基づいて決済サービスの利用可否を判定するステップと、
   前記複数口座から代表口座を特定するステップと、
   取引時に支払い金額及び前記代表口座の残高に基づいて、前記残高が前記支払い金額以上である場合に前記顧客にとって経済的利益となる決済条件を決定し、前記残高が前記支払い金額未満である場合に前記顧客にとって経済的不利益となる決済条件を決定するステップと、
   取引後に決済用の口座を顧客が設定する条件に基づいて特定し、前記決済用の口座から前記決済条件に基づいて決済を行うステップと、
   を備える、決済サーバの決済方法。
8. 決済サーバのコンピュータに、
   取引前に銀行サーバと通信を行って顧客の複数口座における口座状況を取得し、前記口座状況に基づいて決済サービスの利用可否を判定させ、
   前記複数口座から代表口座を特定させ、
   取引時に支払い金額及び前記代表口座の残高に基づいて、前記残高が前記支払い金額以上である場合に前記顧客にとって経済的利益となる決済条件を決定させ、前記残高が前記支払い金額未満である場合に前記顧客にとって経済的不利益となる決済条件を決定させ、
   取引後に決済用の口座を顧客が設定する条件に基づいて特定させ、前記決済用の口座から前記決済条件に基づいて決済を行わせる、
   プログラム。

Images