特許 7569417 決済処理装置、支払処理方法、及びプログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B1)

(11)【特許番号】

(24)【登録日】2024-10-08

(45)【発行日】2024-10-17

(54)【発明の名称】決済処理装置、支払処理方法、及びプログラム

(51)【国際特許分類】

   G06Q 20/24 20120101AFI20241009BHJP

【ＦＩ】

G06Q20/24

【請求項の数】 4

(21)【出願番号】P 2023119393

(22)【出願日】2023-07-21

【審査請求日】2023-07-21

【新規性喪失の例外の表示】特許法第３０条第２項適用 発行者名 株式会社三井住友銀行 刊行物名 「ｉＢ－ｔｌｅ」請求企業向けチラシ 発行日 令和５年４月２４日

(73)【特許権者】

【識別番号】397077955

【氏名又は名称】株式会社三井住友銀行

(74)【代理人】

【識別番号】110001243

【氏名又は名称】弁理士法人谷・阿部特許事務所

(72)【発明者】

【氏名】太田 裕行

(72)【発明者】

【氏名】木村 陽介

(72)【発明者】

【氏名】平井 正和

【審査官】深津 始

(56)【参考文献】

【文献】特開２０１２－０１４４１０（ＪＰ，Ａ）

【文献】特開２００１－３３１７４９（ＪＰ，Ａ）

【文献】特開２０２０－１７７３３２（ＪＰ，Ａ）

【文献】特開２００５－３２６９０２（ＪＰ，Ａ）

【文献】日専連ライフサービス，ショッピング「あとからリボ」「あとから分割」「あとからスキップ」 [online]，2023年05月30日，[検索日2024.04.17], Internet<URL:https://web.archive.org/web/20230530211125/https://www.nissenren-sendai.or.jp/use/shiharaihenkou/shiharaihenkou_shoppping.html>

【文献】Pick up Topics (9) ＲＯＢＯＴ ＰＡＹＭＥＮＴ，ＣａｒｄＷａｖｅ，日本，株式会社インフキュリオンコンサルティング，2022年12月25日，第35巻, 第6号，第50-51ページ

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｑ １０／００ －Ｇ０６Ｑ ９９／００

(57)【特許請求の範囲】

【請求項1】

外部ネットワークと通信するための通信部、記憶部、及び制御部を備えた決済処理装置であって、
前記記憶部は、第１のユーザ及び第２のユーザ間の取引結果を示す請求データ及び請求明細データを格納しており、
前記制御部は、
第２のユーザの端末からの要求に応答して、前記第２のユーザに関連付けられる、そのステータスが口座振替依頼待ちの請求明細データを前記通信部を介して前記第２のユーザの端末に提供することと、
提供された前記請求明細データのうちの第２のユーザによって選択された支払先延ばしを希望する請求明細データの情報と前記第２のユーザの希望支払日の情報とを含む支払先延ばし依頼を前記通信部を介して前記第２のユーザの端末から受信したことに応答して、前記支払先延ばし依頼に基づく試算依頼を前記通信部を介してファイナンスシステムに送信し、前記ファイナンスシステムから受信した前記試算依頼の試算結果を前記通信部を介して前記第２のユーザの端末に提供することであって、前記試算依頼は、支払先延ばしを希望する請求明細データの情報と前記第２のユーザの希望支払日の情報とを含み、前記試算結果は、前記支払先延ばし依頼に対する審査承認の情報を示す、ことと、
カード払いに関連付けられるファイナンス申込であって、前記支払先延ばしを希望する請求明細データの情報と前記第２のユーザの希望支払日の情報とを含むファイナンス申込を前記通信部を介して前記第２のユーザの端末から受信することと、
前記ファイナンス申込を受信したことに応答して、前記ファイナンス申込に関連付けられる前記支払先延ばしを希望する請求明細データに基づいて、前記支払先延ばしを希望する請求明細データに元々登録されていた支払予定日に前記第１のユーザの口座に対して入金処理を行うための入金依頼を生成し、入金処理システムに送信することと、
前記ファイナンス申込に関連付けられる、銀行による保証を受けるための保証申込を生成し、生成した前記保証申込を前記ファイナンスシステムに送信することと、
オーソリゼーションデータを生成することなく、前記ファイナンス申込に関連付けられる前記支払先延ばしを希望する請求明細データの請求金額と、前記ファイナンス申込に関連付けられる前記希望支払日に口座振替処理が実行される日付を売上日とするカード売上データを生成し、生成したカード売上データを入金処理システムに送信することと、
を実行する決済処理装置。

【請求項2】

前記制御部は、前記第２のユーザに関連付けられるカードの支払日に基づく複数の候補を前記通信部を介して前記第２のユーザの端末に提供し、
前記希望支払日は、前記複数の候補の中から第２のユーザによって選択された支払日である、
請求項１の決済処理装置。

【請求項3】

決済処理装置によって実行される方法であって、
前記決済処理装置は、外部ネットワークと通信するための通信部、記憶部、及び制御部を備え、
前記記憶部は、第１のユーザ及び第２のユーザ間の取引結果を示す請求データ及び請求明細データを格納しており、
前記方法は、
第２のユーザの端末からの要求に応答して、前記第２のユーザに関連付けられる、そのステータスが口座振替依頼待ちの請求明細データを前記通信部を介して前記第２のユーザの端末に提供することと、
提供された前記請求明細データのうちの第２のユーザによって選択された支払先延ばしを希望する請求明細データの情報と前記第２のユーザの希望支払日の情報とを含む支払先延ばし依頼を前記通信部を介して前記第２のユーザの端末から受信したことに応答して、前記支払先延ばし依頼に基づく試算依頼を前記通信部を介してファイナンスシステムに送信し、前記ファイナンスシステムから受信した前記試算依頼の試算結果を前記通信部を介して前記第２のユーザの端末に提供することであって、前記試算依頼は、支払先延ばしを希望する請求明細データの情報と前記第２のユーザの希望支払日の情報とを含み、前記試算結果は、前記支払先延ばし依頼に対する審査承認の情報を示す、ことと、
カード払いに関連付けられるファイナンス申込であって、前記支払先延ばしを希望する請求明細データの情報と前記第２のユーザの希望支払日の情報とを含むファイナンス申込を前記通信部を介して前記第２のユーザの端末から受信することと、
前記ファイナンス申込を受信したことに応答して、前記ファイナンス申込に関連付けられる前記支払先延ばしを希望する請求明細データに基づいて、前記支払先延ばしを希望する請求明細データに元々登録されていた支払予定日に前記第１のユーザの口座に対して入金処理を行うための入金依頼を生成し、入金処理システムに送信することと、
前記ファイナンス申込に関連付けられる、銀行による保証を受けるための保証申込を生成し、生成した前記保証申込を前記ファイナンスシステムに送信することと、
オーソリゼーションデータを生成することなく、前記ファイナンス申込に関連付けられる前記支払先延ばしを希望する請求明細データの請求金額と、前記ファイナンス申込に関連付けられる前記希望支払日に口座振替処理が実行される日付を売上日とするカード売上データを生成し、生成したカード売上データを入金処理システムに送信することと、
を備える方法。

【請求項4】

請求項３に記載の方法をコンピュータに実行させるためのプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、決済処理装置、支払処理方法、及びプログラムに関する。

【背景技術】

【0002】

企業間取引（ＢｔｏＢ：Business to Business）の分野において、バイヤー（債務者）からサプライヤー（債権者）に対する支払手段は、振込、口座振替、クレジットカード払いなどが知られており、近年、法人間の支払でもクレジットカードを利用することが増えてきつつある。

【0003】

企業間取引では、サプライヤーとバイヤーの間で締結された契約により、例えば、毎月月末払いなどの支払日が決められている。会社の経営状態によっては、サプライヤーは早期に資金を得たい場合があり、一方、バイヤーは予め決められた支払日を先延ばししたい場合があるが、そのような場合には、相手方の企業に相談して一定の制約条件のもとで早期資金化を行い、及び／または支払先延ばしを行っていた。

【先行技術文献】

【特許文献】

【0004】

【文献】特許５８６６４１８号公報

【発明の概要】

【発明が解決しようとする課題】

【0005】

従来のクレジットカードの機能では、カード会社の審査に応じた与信額を上限としており、決済金額が大きくなりがちな企業間取引では上限額を超えることもあり、クレジットカード払いをできる取引は限定されていてカード払いを使用しづらかった。クレジットカードの立替期間も約１ヵ月程度と短く、数か月単位での立替は利用できず不便であった。特許文献１は、カード会社の口座に対して事前に振込を行うことでカード上限額を引き上げることを提案しているが、この手法では事前に多額の資金を必要とするため、支払を数カ月単位で引き伸ばしたいユーザにとっては利用し辛かった。

【0006】

従来の早期資金化の申込では、例えば手形や電子記録債権を受領した場合には、サプライヤーは、通常の期日通りの代金回収かウィズリコースのみの早期資金化の選択、カード加盟店での代金回収では全件ウィズアウトリコースのみの早期資金化しかできず、状況に応じて通常の期日通りの回収、ウィズリコース／ウィズアウトリコースの早期資金化を選択することはできず、柔軟性に欠けていた。一方、バイヤーは、支払先延ばしをしたいと思っていても簡単には実現できなかった。

【0007】

本発明は、このような課題を解決するためになされたものであり、従来の口座振替の支払手段以外にも、保証機能を組み合わせたカード払いの支払手段をバイヤーに提供する決済処理装置、支払処理方法、及びプログラムを提供することを目的とする。

【0008】

また、本発明は、従来の支払予定日通りの口座振替による支払以外に、早期資金化の申込と合わせてウィズリコース（自社保証）及びウィズアウトリコース（銀行保証）の一つを選択可能とする決済処理装置、支払処理方法、及びプログラムを提供することを目的とする。

【課題を解決するための手段】

【0009】

上記の課題を解決するために、本発明の決済処理装置は、外部ネットワークと通信するための通信部、記憶部、及び制御部を備えた決済処理装置であって、
前記記憶部は、第１のユーザ及び第２のユーザ間の取引結果を示す請求データ及び請求明細データを格納しており、
前記制御部は、
カード払いに関連付けられるファイナンス申込を前記通信部を介して第２のユーザ端末から受信することと、
前記ファイナンス申込に関連付けられる第１の請求明細データに登録されていた支払予定日に前記第１のユーザの口座に対して入金処理を行うための入金依頼を生成することと、
前記ファイナンス申込に関連付けられる保証申込を生成することと、
前記ファイナンス申込に関連付けられる希望支払日に前記第１の請求明細データに基づく口座振替処理が実行されるような売上日を設定したカード売上データを生成することと
を実行する。

【発明の効果】

【0010】

本発明によれば、バイヤーは、決済処理装置が許容する保証限度額まで支払先延ばし（金融機関による立替払）を申込むことが可能となり、カード会社の与信額よりも高額の支払が可能となり、保証がつけられる限りはカード会社の与信リスクを外すことができるため数か月単位での立替が可能となる。

【0011】

本発明によれば、サプライヤーは、決済処理装置で３つの資金回収方法を選択することができるようになり、自社の資金繰りや与信管理の状況に応じて、入金日の早期化や与信リスクヘッジを柔軟に使い分けることが可能となる。すなわち、サプライヤーは、資金回収の選択肢として、バイヤーとの決済条件に基づいた入金予定日に収納代行による通常の代金回収、ウィズリコースでの早期資金化、及びウィズアウトリコースでの早期資金化のうちの１つを選択することが可能になる。

【図面の簡単な説明】

【0012】

本明細書において開示される実施形態の詳細な理解は、添付図面に関連して例示される以下の説明から得ることができる。

【図1】決済処理装置１０を含むシステム全体の構成図である。

【図2】決済処理装置１０のシステム構成図である。

【図3】ユーザマスタ１０６のデータ構造の一例を示す図である。

【図4】契約／決済情報１０７のデータ構造の一例を示す図である。

【図5】請求データ１０８のデータ構造の一例を示す図である。

【図6】請求明細データ１０９のデータ構造の一例を示す図である。

【図7】口座振替及び振込によりサプライヤー及びバイヤー間で資金移動を行う処理フローを説明する図である。

【図8】サプライヤーにとってのファイナンス処理を説明するフロー図である。

【図9】バイヤーにとってのファイナンス処理を説明するフロー図である。

【図10】早期資金化依頼画面１０００の一例を説明する図である。

【図11】試算結果表示画面１１００の一例を説明する図である。

【図12】支払先延ばし依頼画面１２００の一例を説明する図である。

【図13】試算結果表示画面１３００の一例を説明する図である。

【発明を実施するための形態】

【0013】

（全体構成）
図１は、本発明の実施形態に係る決済処理装置１０、サプライヤー端末１１、バイヤー端末１２、口座振替システム１３、ファイナンスシステム１４、入金処理システム１５、第１の銀行システム１６、及び第２の銀行システム１７を含むシステム全体の構成図である。

【0014】

決済処理装置１０は、インターネットなどの第１のネットワーク２１を介してサプライヤー端末１１及びバイヤー端末１２と相互に通信可能に接続されている。決済処理装置１０は、インターネットあるいはＬＡＮやＷＡＮなどの第２のネットワーク２２を介して口座振替システム１３、ファイナンスシステム１４、入金処理システム１５、第１の銀行システム１６、及び第２の銀行システム１７と相互に通信可能に接続されている。

【0015】

本明細書では、決済処理装置１０を１つのシステムあるいは装置として説明するが、決済処理装置１０によって実行される様々な処理を複数のシステムあるいは装置で分散して実行するように構成してもよい。図１では、説明の簡便化のため、サプライヤー端末１１及びバイヤー端末１２は１つずつしか示されていないが、これらは複数存在し得る。

【0016】

サプライヤー端末１１は、企業間取引におけるサプライヤーによって使用される端末である。サプライヤー端末１１は、通信機能やＷｅｂブラウザによるデータ編集・閲覧機能を備えたパーソナルコンピュータ（ＰＣ）やタブレット型端末などのコンピュータとすることができるが、特定の装置やデバイスに限定されることはない。

【0017】

バイヤー端末１２は、企業間取引におけるバイヤーによって使用される端末である。バイヤー端末１２は、通信機能やＷｅｂブラウザによるデータ編集・閲覧機能を備えたパーソナルコンピュータ（ＰＣ）やタブレット型端末などのコンピュータとすることができるが、特定の装置やデバイスに限定されることはない。

【0018】

口座振替システム１３、ファイナンスシステム１４、及び入金処理システム１５は、所定の処理を実行するためのシステムであり、金融機関の外部システムまたはサブシステムであってよく、後述するような機能を提供する。

【0019】

第１の銀行システム１６及び第２の銀行システム１７は、金融機関によって制御される勘定系システムなどの銀行システムである。第１の銀行システム１６は、サプライヤー取引銀行のシステムであり、第２の銀行システム１７は、バイヤー取引銀行のシステムである。サプライヤー取引銀行及びバイヤー取引銀行が同一金融機関となる場合には、第１の銀行システム１６及び第２の銀行システム１７は同一のシステムである。

【0020】

決済処理装置１０は、企業間取引の決済関連処理のために使用される装置であり、本願明細書で説明するような、基盤データの登録処理、決済処理、ファイナンス処理、保証処理、入金処理などをサポートする様々な機能を、ウェブベースの統一されたインターフェースを介してサプライヤー端末１１及びバイヤー端末１２に提供する。以下、決済処理装置１０によって提供される様々な機能を説明する。

【0021】

（基盤データの登録処理）
本明細書において「基盤データ」は、サプライヤー及びバイヤーに関連するユーザ情報及び企業間取引の契約情報、並びに企業間取引の実態を示す情報（例えば、売上データ）を指す。決済処理装置１０は、サプライヤー及びバイヤーのそれぞれに対してＩＤを発行し、サプライヤー及びバイヤーに関連する情報を受信してユーザ情報として記憶する。決済処理装置１０は、締日、売上データ登録日、支払日などの決済関連の契約情報をサプライヤー端末１１から受信して記憶する。

【0022】

決済処理装置１０は、サプライヤー端末１１から受信した売上データと、ユーザ情報及び契約情報とに基づいて予め定められたタイミングで未承認請求データを生成してサプライヤー端末１１に提供する。決済処理装置１０は、未承認請求データがサプライヤー端末１１によって承認されたことに応答して、当該未承認請求データをバイヤー端末１２に提供する。バイヤーは、当該未承認請求データの内容を確認してバイヤー端末１２を介して承認すると、当該データは、承認済請求データとして決済処理装置１０によって扱われる。承認済の請求データは、サプライヤー及びバイヤーの決済口座、サプライヤー及びバイヤー間の契約情報に基づく支払日などの情報を含んでいる。このため、バイヤーは、実際に支払を行う前に、支払額及び支払日を事前に確認することができる。以下の記載では、承認済請求データのことを単に「請求データ」あるいは「請求明細データ」と呼び、承認されていない請求データのことを「未承認請求データ」あるいは「未承認請求明細データ」と呼ぶこととする。

【0023】

（決済処理）
決済処理装置１０は、請求データ及び請求明細データの金額情報とサプライヤー及びバイヤーの口座情報とに基づいて口座振替請求データを生成する。決済処理装置１０は、口座振替請求データを口座振替請求データによって示される引落日に処理が行われるように口座振替システム１３に送信する。口座振替請求データは、引落日、引落口座、入金口座、引落金額などの情報を含んでおり、口座振替システム１３は、口座振替請求データを受信すると即座に（引落日は当日あるいは翌営業日にセット）、口座振替電文を生成して第２の銀行システム１７に対して送信する。

【0024】

第２の銀行システム１７は、口座振替処理を実行し、資金は、口座振替システム１３を管理する決済代行業者の口座に送金される。決済処理装置１０は、口座振替請求データのサプライヤー口座の情報に基づいて、決済代行業者の口座からサプライヤー口座への資金移動を示す振込電文を生成し、第１の銀行システム１６に送信する。その後、第１の銀行システム１６がサプライヤー口座に対する入金処理を実行する。

【0025】

（ファイナンス処理、入金処理、保証処理）
ファイナンスとは、金融機関による立替払のことであり、ファイナンスの種類として、サプライヤー（債権者）にとっての早期資金化、及びバイヤー（債務者）にとっての支払先延ばしがある。

【0026】

ファイナンスの一形態である早期資金化に関して、決済処理装置１０は、支払日が到来していない請求データ及び請求明細データを、決済処理装置１０が提供する画面インターフェース上でサプライヤー端末１１に提供する。決済処理装置１０は、サプライヤー端末１１によって選択された請求明細データについてファイナンス希望の旨をサプライヤー端末１１から受信すると、当該請求明細データに基づいて試算依頼データを生成してファイナンスシステム１４に送信する。ファイナンス希望は、それぞれの明細データについて銀行保証（ウィズアウトリコース）及び自社保証（ウィズリコース）のいずれかの選択情報を含む。ファイナンスシステム１４は、請求明細データの内容及び保証の情報に基づいて早期資金化の試算を行い、試算結果を決済処理装置１０に送信する。決済処理装置１０は、試算結果を別の画面インターフェース上でサプライヤー端末１１に提供する。

【0027】

決済処理装置１０は、試算結果を提供後にサプライヤー端末１１から早期資金化申込データを受信すると、当該申込データに基づいて入金依頼データを生成し、入金処理システム１５に送信する。入金処理システム１５は、入金依頼データに基づいて振込電文を生成して第１の銀行システム１６に送信する。第１の銀行システム１６は、振込電文に基づいてサプライヤー口座に対して入金処理を行う。また、決済処理装置１０は、当該申込データに基づいて口座振替請求データを生成し、口座振替システム１３に送信する。その後、上述したように、元々の支払予定日に口座振替処理が行われる。口座振替処理後には、サプライヤー口座宛の入金処理は行われない。

【0028】

ファイナンスの他の形態である支払先延ばしに関して、決済処理装置１０は、支払日が到来していない請求データ及び請求明細データを、決済処理装置１０が提供する画面インターフェース上でバイヤー端末１２に提供する。決済処理装置１０は、バイヤー端末１２によって選択された請求明細データ及び希望支払日についてのファイナンス希望の旨をバイヤー端末１２から受信すると、当該請求明細データ及び希望支払日に基づいて試算依頼データを生成してファイナンスシステム１４に送信する。ファイナンスシステム１４は、請求明細データの内容及び希望支払日の情報に基づいて支払先延ばしの試算を行い、試算結果を決済処理装置１０に送信する。決済処理装置１０は、試算結果を別の画面インターフェース上でバイヤー端末１２に提供する。

【0029】

決済処理装置１０は、試算結果を提供後にバイヤー端末１２から支払先延ばし申込データを受信すると、当該申込データに基づいて入金依頼データを生成し、入金処理システム１５に送信する。入金処理システム１５は、入金依頼データに基づいて振込電文を生成して第１の銀行システム１６に送信する。第１の銀行システム１６は、振込電文に基づいてサプライヤー口座に対して入金処理を行う。この入金は、元々の支払予定日に行われる。また、決済処理装置１０は、当該申込データに関連付けられる請求明細データに基づいて口座振替請求データを生成し、口座振替請求データによって示される引落日に処理が行われるように口座振替システム１３に送信する。この引落日は、バイヤーが設定した希望支払日である。口座振替処理後には、サプライヤー口座宛の入金処理は行われない。

【0030】

なお、ファイナンス処理における振込電文の振込元口座は、入金処理システム１５を管理する事業者の銀行の口座であり、口座振替処理における入金口座は、決済代行業者の口座である。

【0031】

さらに、決済処理装置１０は、早期資金化申込データまたは支払先延ばし申込データを受信すると、それぞれの申込に対応する保証申込データを生成してファイナンスシステム１４に送信する。ファイナンスシステム１４は、保証申込データに基づいて早期資金化あるいは支払先延ばしについての保証取組の処理を実行する。

【0032】

（金融機関の外部システムまたはサブシステムの機能）
口座振替システム１３は、受信した口座振替請求データに基づいて、バイヤー口座を有する金融機関の第２の銀行システム１７に対してバイヤー口座から資金を引き落とす口座振替処理を依頼し、第２の銀行システム１７は、引き落とした資金を所定の口座に資金移動する。受信した口座振替請求データは、契約情報に含まれる支払予定日、すなわち、口座振替請求データを受信した当日（あるいは翌営業日）、またはバイヤー希望のファイナンス（立替払）依頼の際に指定した希望支払日に口座振替が実行されることを示してもよい。

【0033】

ファイナンスシステム１４は、ファイナンス希望のあった請求明細データ及び保証の情報に基づいて試算を行い、早期資金化に対する試算結果を決済処理装置１０に提供する。ファイナンスシステム１４は、ファイナンス希望のあった請求明細データ、保証の情報及びバイヤーが指定した希望支払日に基づいて試算を行い、支払い先延ばしに対する試算結果を決済処理装置１０に提供する。ファイナンスシステム１４は、保証申込データに基づいて保証取組の処理を実行する。

【0034】

入金処理システム１５は、決済処理装置１０から受信した入金依頼データに基づいて振込電文を生成し、入金依頼データに含まれる振込先口座に対応する金融機関のシステム、例えば、サプライヤー口座を有する第１の銀行システム１６に振込電文を送信して入金処理を実行する。

【0035】

（決済処理装置１０のシステム構成）
次に、決済処理装置１０のシステム構成を説明する。図２は、本発明の実施形態に係る決済処理装置１０のシステム構成図である。図２に示すように、決済処理装置１０は、一般的なコンピュータと同様に、バス１２０などによって相互に接続された制御部１０１、主記憶部１０２、補助記憶部１０３、ＩＦ部１０４、及び出力部１０５を備える。補助記憶部１０３は、決済処理装置１０の各機能を実装するプログラム、及び当該プログラムで取り扱うデータを格納する。補助記憶部１０３は、ファイル／データベースなどの形式で、ユーザマスタ１０６、契約／決済情報１０７、請求データ１０８、及び請求明細データ１０９を備える。決済処理装置１０は、ユーザマスタ１０６、契約／決済情報１０７、請求データ１０８、及び請求明細データ１０９に格納されている情報を読み出し、編集し、あるいは更新できる。補助記憶部１０３に格納されている各種プログラムは、決済処理装置１０によって実行される。

【0036】

制御部１０１は、中央処理装置（ＣＰＵ）とも呼ばれ、決済処理装置１０の各構成要素の制御やデータの演算を行い、また、補助記憶部１０３に格納されている各種プログラムを主記憶部１０２に読み出して実行する。主記憶部１０２は、メインメモリとも呼ばれ、受信した各種データ、コンピュータ実行可能な命令及び当該命令による演算処理後のデータなどを記憶する。補助記憶部１０３は、ハードディスク（ＨＤＤ）などに代表される記憶装置であり、データやプログラムを長期的に保存する際に使用される。

【0037】

図２の実施形態は、制御部１０１、主記憶部１０２及び補助記憶部１０３を同一のコンピュータの内部に設ける実施形態について説明するが、他の実施形態として、決済処理装置１０は、制御部１０１、主記憶部１０２及び補助記憶部１０３を複数個使用することにより、複数のコンピュータによる並列分散処理を実現するように構成することもできる。他の実施形態として、決済処理装置１０のための複数のサーバを設置し、複数サーバが一つの補助記憶部１０３を共有する実施形態にすることも可能である。

【0038】

ＩＦ部１０４は、他のシステムや装置との間でデータを送受信する際のインターフェース（ＩＦ）の役割を果たし、また、システムオペレータから各種コマンドや入力データ（各種マスタ、テーブルなど）を受け付けるインターフェースを提供する。出力部１０５は、処理されたデータを表示する表示画面や当該データを印刷するための印刷手段などを提供する。

【0039】

ユーザマスタ１０６は、本発明に係る決済処理装置１０を利用するサプライヤー及びバイヤーなどのユーザの情報を格納する。図３は、本発明の実施形態に係るユーザマスタ１０６のデータ構造の一例を示す図である。ユーザマスタ１０６は、ユーザＩＤ３０１、ユーザ名称３０２、及びユーザ情報３０３を含むことができるが、これらのデータ項目に限定されることはなく他のデータ項目も含むことができる。

【0040】

ユーザＩＤ３０１は、本発明に係る決済処理装置１０を利用するユーザ（企業、企業内の任意の部署など）を識別する識別子である。ユーザは、企業間取引においてサプライヤーにもなり得るし、バイヤーにもなり得る。ユーザ名称３０２は、ユーザの名称（企業名、企業内の部署名など）を示す。ユーザ情報３０３は、ユーザの連絡先（電子メールアドレス、電話番号、住所など）、決済口座、決裁者、及び決裁ルートなどのユーザの各種情報を示す。決済口座は、入出金処理の際に使用される銀行口座の情報を示す。決裁者は、未承認請求データに対してサプライヤーやバイヤーにおいて承認を行う者を示し、承認を行う者は、ユーザにおける部署であってよい。決裁ルートは、決裁者が複数いる場合の決裁順序のルートを示す。

【0041】

図２に戻って説明すると、契約／決済情報１０７は、企業間取引におけるサプライヤー及びバイヤー間の取引に関する契約情報及び決済情報を格納する。サプライヤーは、決済処理装置１０によって提供される契約／決済情報登録画面（不図示）を介して、契約情報及び決済情報を登録する。図４は、本発明の実施形態に係る契約／決済情報１０７のデータ構造の一例を示す図である。契約／決済情報１０７は、サプライヤーＩＤ４０１、バイヤーＩＤ４０２、決済条件４０３、及び与信状況４０４を含むことができるが、これらのデータ項目に限定されることはなく他のデータ項目も含むことができる。

【0042】

サプライヤーＩＤ４０１は、企業間取引におけるサプライヤーを示す識別子である。バイヤーＩＤ４０２は、企業間取引におけるバイヤーを示す識別子である。サプライヤーＩＤ４０１及びバイヤーＩＤ４０２として設定される識別子は、ユーザＩＤ３０１であってよい。決済条件４０３は、サプライヤーとバイヤーの間で予め取り交わされている決済条件を示す。決済条件は、締日、売上データ登録期限、及び支払日（例えば、月末）などであってよい。与信状況４０４は、サプライヤーがバイヤーに対して設定した債権の枠（上限額）及び現在残高を示す。

【0043】

図２に戻って説明すると、請求データ１０８は、サプライヤーによってアップロードされた売上データのサマリー情報を格納する。サマリー情報は、未承認請求データまたは請求データを示す。図５は、本発明の実施形態に係る請求データ１０８のデータ構造の一例を示す図である。請求データ１０８は、サプライヤーＩＤ４０１、バイヤーＩＤ４０２、ファイルＩＤ５０１、ファイル名５０２、作成日５０３、データ件数５０４，合計金額５０５、支払日５０６、変更前支払予定日５０７、支払方法５０８、及びステータス５０９を含むことができるが、これらのデータ項目に限定されることはなく他のデータ項目も含むことができる。

【0044】

サプライヤーＩＤ４０１は、請求データにおけるサプライヤーを示す識別子である。バイヤーＩＤ４０２は、請求データにおけるバイヤーを示す識別子である。ファイルＩＤ５０１は、サプライヤーによってアップロードされた売上データファイルを識別する識別子である。売上データファイルには、１または複数の未承認請求明細データが含まれている。ファイル名５０２は、アップロードされた売上データファイルに付された名称である。作成日５０３は、売上データファイルの作成日である。データ件数５０４は、売上データファイルに含まれる明細データのデータ件数である。合計金額５０５は、売上データファイルに含まれる請求明細の合計請求額を示す。

【0045】

支払日５０６は、支払が行われる予定日を示す。変更前支払予定日５０７は、支払日が変更された場合の以前の支払予定日を示す。支払方法５０８は、バイヤーからサプライヤーに対する支払が行われる方法（例えば、口座振替、振込、カード払いなど）を示す。ステータス５０９は、未承認請求データまたは請求データの状態を示す。この状態は、例えば、サプライヤー承認待ち、バイヤー承認待ち、口座振替依頼待ち、カード払い、入金待ち、入金済などを示し、通常、請求明細データ１０９の対応するデータ群のステータスと同期する。

【0046】

図２に戻って説明すると、請求明細データ１０９は、未承認請求データに関連付けられる未承認請求明細データまたは請求データに関連付けられる請求明細データを格納する。図６は、本発明の実施形態に係る請求明細データ１０９のデータ構造の一例を示す図である。請求明細データ１０９は、サプライヤーＩＤ４０１、バイヤーＩＤ４０２、ファイルＩＤ５０１、支払日５０６、請求番号６０１、請求内容６０２、請求金額６０３、支払予定日６０４、ステータス６０５、ファイナンスフラグ６０６、保証フラグ６０７、入金口座６０８、及び出金口座６０９を含むことができるが、これらのデータ項目に限定されることはなく他のデータ項目も含むことができる。

【0047】

サプライヤーＩＤ４０１は、請求明細データにおけるサプライヤーを示す識別子である。バイヤーＩＤ４０２は、請求明細データにおけるバイヤーを示す識別子である。ファイルＩＤ５０１は、それぞれの請求明細データに関連付けられる売上ファイルの識別子である。支払日５０６は、請求明細データに関連付けられる請求データの支払日を示し、サプライヤー及びバイヤー間の１つ以上の明細データをまとめる単位となる。請求番号６０１は、請求明細データを識別する識別子である。請求内容６０２は、請求の内容（例えば、物品代、サービス代）を示す。請求金額６０３は、請求明細データによって示される請求金額を示す。支払予定日６０４は、個々の請求に対して支払が予定される日を示す。

【0048】

ステータス６０５は、請求明細データの状態を示す。請求明細データの状態は、例えば、サプライヤー承認待ち、バイヤー承認待ち、口座振替依頼待ち、カード払い、入金待ち、入金済などを示す。ファイナンスフラグ６０６は、サプライヤー及びバイヤーの間で予め取り決めた支払サイトよりも早期に資金化する希望があるかどうか、あるいはバイヤーが支払先延ばしを希望しているかどうかを示すフラグである。保証フラグ６０７は、銀行保証または自社保証が選択されているかどうかを示す。入金口座６０８は、入金口座、例えば、サプライヤー口座を示す。出金口座６０９は、出金口座、例えば、バイヤー口座を示す。

【0049】

（各種フローについての説明）
図７～図９を参照しながら、決済処理装置１０によって実行される様々な処理、すなわち、口座振替及び振込による資金移動の処理フロー、サプライヤーの依頼による早期資金化の処理フロー、バイヤーの依頼によるカード払いを使用した支払先延ばしの処理フローを説明する。これらの処理フローを説明する前提として、サプライヤー及びバイヤーとなり得るユーザは、決済処理装置１０によってユーザＩＤが割り当てられており、ユーザ関連の各種情報はユーザマスタ１０６に登録されており、企業間取引におけるサプライヤー及びバイヤー間の取引に関する契約情報及び決済情報は、契約／決済情報１０７に登録されており、サプライヤー及びバイヤー間の取引に基づく請求データ及び請求明細データは請求データ１０８及び請求明細データ１０９に格納されているものとする。

【0050】

（処理フロー：口座振替及び振込による資金移動）
図７は、口座振替及び振込によりサプライヤー及びバイヤー間で資金移動を行う処理フローを説明する図である。より詳細に言えば、決済処理装置１０が、支払予定日が到来する請求明細データに基づいて口座振替依頼データを生成し、口座振替システム１３に口座振替依頼データ送信して資金移動を実行する処理フローを説明する。

【0051】

Ｓ７０１にて、決済処理装置１０は、ステータス６０５が「口座振替依頼待ち」を示す請求明細データを請求明細データ１０９から読み出す。

【0052】

Ｓ７０２にて、決済処理装置１０は、読み出した請求明細データに含まれる支払予定日６０４、請求金額６０３、入金口座６０８，及び出金口座６０９の情報に基づいて口座振替依頼データを生成するとともに、読み出した請求明細データと当該請求明細データに関連付けられる請求データのステータス５０９、６０５をそれぞれ「入金待ち」に更新する。口座振替依頼データの入金口座は、サプライヤー口座あるいは口座振替システム１３を管理する決済代行業者の口座であってよい。

【0053】

決済処理装置１０は、口座振替依頼データを口座振替システム１３に送信する。口座振替システム１３は、口座振替依頼データに基づいて所定フォーマットに基づく口座振替依頼電文を生成し、口座振替依頼データに含まれるバイヤー口座に対応する金融機関の第２の銀行システム１７に口座振替依頼電文を送信する。第２の銀行システム１７は、口座振替処理の結果データを口座振替システム１３を介して決済処理装置１０に送信する。また、第２の銀行システム１７は、バイヤー口座から資金を引き落とし、決済代行業者の口座を有する銀行に送金する。当該銀行は、決済代行業者の口座に対して入金処理を行う。

【0054】

Ｓ７０３にて、決済処理装置１０は、口座振替処理の結果データを第２の銀行システム１７から受信したことに応答して、口座振替依頼データに対応する入金依頼データを生成する。入金依頼データは、決済代行業者の口座を出金口座として、サプライヤー口座を入金口座とする入金依頼データであってよい。決済処理装置１０は、入金依頼データを口座振替システム１３に送信し、口座振替システム１３が入金依頼データに基づいて振込電文を生成し、第１の銀行システム１６に送信する。第１の銀行システム１６は、振込電文に基づいてサプライヤー口座に対して入金処理を実行する。

【0055】

Ｓ７０４にて、決済処理装置１０は、口座振替処理の結果データに基づいて、口座振替処理に関連付けられる請求明細データのステータス６０５を「入金済」に更新するとともに、当該請求明細データに関連付けられる請求データのステータス５０９を「入金済」に更新する。

【0056】

これらの処理により、サプライヤーは、請求金額及び支払期日を管理する事務作業を大幅に削減することができるようになる。また、Ｓ７０４の更新処理により、請求データ及び請求明細データのステータスが「入金済」と表示されることにより、それぞれの請求に対する入金消込の事務作業を従来よりも簡便に行うことができるようになる。サプライヤー端末１１は、ステータスが「入金済」の請求データ及び請求明細データを取得できるので、サプライヤーは、入金消込の確認が簡単に行えるようになる。

【0057】

（処理フロー：ファイナンス及び保証取組）
ファイナンスとは、金融機関による立替払のことであり、ファイナンスの種類として、サプライヤー（債権者）にとっての早期資金化、及びバイヤー（債務者）にとっての支払先延ばしがある。図８は、サプライヤーにとってのファイナンス処理を説明するフロー図であり、図９は、バイヤーにとってのファイナンス処理を説明するフロー図である。

【0058】

図８を参照しながら、決済処理装置１０が、サプライヤーからのファイナンス依頼（早期資金化依頼）を受信したことに応答して試算を行った結果をサプライヤーに提供し、サプライヤーからファイナンス申込を受信したことに応答して入金依頼データを生成するとともに、保証申込データを生成する処理フローを説明する。

【0059】

Ｓ８０１にて、決済処理装置１０は、サプライヤー端末１１からの要求に応答して、口座振替依頼データを生成していない請求明細データ、すなわち、ステータス６０５が「口座振替依頼待ち」の請求明細データを、それらに関連付けられる売上データファイル単位で早期資金化依頼画面１０００を介してサプライヤー端末１１に提供する。

【0060】

図１０は、早期資金化依頼画面１０００の一例を説明する図である。早期資金化依頼画面１０００は、請求データ概要１００１、早期資金化依頼概要１００２、請求明細データ選択欄１００３、及び登録ボタン１００４を含む。請求データ概要１００１は、１以上の請求明細データに関連付けられる売上データファイルのサマリー情報を示す。早期資金化依頼概要１００２は、サプライヤーが行う依頼内容の概要を示す。依頼内容の概要は、早期資金化を希望するかどうか、銀行保証の早期資金化の内容、及び自社保証の早期資金化の内容を含む。請求明細データ選択欄１００３は、売上データファイルに関連付けられる請求明細データのそれぞれを表示する。登録ボタン１００４は、サプライヤーによって入力された早期資金化依頼の内容を登録するためのボタンである。

【0061】

サプライヤーが早期資金化依頼概要１００２において「希望しない」を選択した場合、請求明細データに格納されている支払予定日通りに口座振替処理が行われることになる。一方、サプライヤーが早期資金化依頼概要１００２において「希望する」を選択した場合、サプライヤーは、請求明細データ選択欄１００３に表示されている請求明細データのうち早期資金化を希望する明細データを選択し、さらに銀行保証及び自社保証のいずれか一方を選択する。早期資金化の手段としては、銀行保証（ウィズアウトリコース）及び自社保証（ウィズリコース）がある。銀行保証（ウィズアウトリコース）は、バイヤー（債務者）が支払期日になっても支払を行えず、債務不履行になったとしても早期入金した資金がサプライヤーから振込元の金融機関に戻されることはないことを意味しており、債務不履行時のリスクを金融機関が負うことを意味している。一方、自社保証（ウィズリコース）は、債務不履行時に早期入金した資金がサプライヤーから振込元の金融機関に戻されることを意味しており、債務不履行時のリスクをサプライヤー自身が負うことを意味している。

【0062】

サプライヤーが登録ボタン１００４を押下すると、決済処理装置１０は、選択された請求明細データについての早期資金化依頼を受信する。受信した請求明細データのファイナンスフラグ６０６には所定の値がセットされる。例えば、銀行保証が選択されている請求明細データのファイナンスフラグ６０６には第１の値がセットされ、一方、自社保証が選択されている請求明細データのファイナンスフラグ６０６には第２の値がセットされる。

【0063】

Ｓ８０２にて、決済処理装置１０は、早期資金化依頼された請求明細データの内容及び保証の情報（例えば、第１の値、第２の値）に基づいて早期資金化するための試算依頼をファイナンスシステム１４に送信する。ファイナンスシステム１４は、受信した請求明細データの内容及び保証の情報に基づいて試算を行い、試算結果を決済処理装置１０に送信する。ファイナンスシステム１４は、支払予定日までの日数によって試算結果が変わることを示してもよい。

【0064】

Ｓ８０３にて、決済処理装置１０は、ファイナンスシステム１４から試算結果を受信したことに応答して、試算結果表示画面１１００を介してサプライヤー端末１１に試算結果を提供する。

【0065】

図１１は、試算結果表示画面１１００の一例を説明する図である。試算結果表示画面１１００は、早期入金対象明細情報１１０１、試算結果１１０２、申込ボタン１１０３、及び取下ボタン１１０４を含む。早期入金対象明細情報１１０１は、試算を行った１以上の請求明細データと、それぞれの請求明細データに対する試算結果とを示す。試算結果１１０２は、１以上の請求明細データに対して行われた試算結果のサマリーを示す。申込ボタン１１０３は、試算結果に従って早期資金化を正式に申し込むためのボタンである。取下ボタン１１０４は、試算結果を承諾しない場合に依頼を取り下げるためのボタンであり、このボタンが押下された場合には、決済処理装置１０は、取下対象の請求明細データのファイナンスフラグ６０６にＮｕｌｌ値をセットする。

【0066】

試算結果が許容可能なものであれば、サプライヤーは、サプライヤー端末１１を介して申込ボタン１１０３を押下し、試算結果に基づく早期資金化を正式に申し込む。決済処理装置１０は、サプライヤー端末１１から早期資金化申込を受信する。

【0067】

Ｓ８０４にて、決済処理装置１０は、早期資金化申込を受信すると、ユーザマスタ１０６に問い合わせを行ってサプライヤーの決済口座の情報を取得し、サプライヤー口座に対する入金処理を行うための入金依頼データを生成して入金処理システム１５に送信する。入金処理システム１５は、入金依頼データに基づいて第１の銀行システム１６に振込電文を送信し、第１の銀行システム１６は、サプライヤー口座に対して入金処理を行う。

【0068】

Ｓ８０５にて、決済処理装置１０は、早期資金化申込を受信すると、銀行による保証を受けるための保証申込データを生成し、生成した保証申込データをファイナンスシステム１４に送信する。ファイナンスシステム１４は、保証申込データに基づいて保証取組の処理を実行する。

【0069】

上述の処理により、サプライヤーは、入金予定日よりも早期に債権を資金化することができるようになる。決済処理装置１０は、早期資金化を行った請求明細データについては支払予定日に口座振替処理を行う。口座振替処理は、図７を参照しながら説明した処理に従って行われる。口座振替の結果、バイヤー口座から引き落とされた資金は、決済代行業者の口座に入金され、その後、振込電文の出金元口座に入金される。

【0070】

次に、図９を参照しながら、決済処理装置１０が、バイヤーからのファイナンス依頼（カード利用による支払先延ばし依頼）を受信したことに応答して、請求明細データと希望支払日に基づいて試算を行った結果をバイヤーに提供し、バイヤーから正式なファイナンス申込を受信したことに応答してカード売上データ及び入金依頼データを生成するとともに、保証申込データを生成する処理フローを説明する。

【0071】

Ｓ９０１にて、決済処理装置１０は、バイヤー端末１２からの要求に応答して、口座振替依頼データを生成していない請求明細データ、すなわち、ステータス６０５が「口座振替依頼待ち」の請求明細データを、それらに関連付けられる売上データファイル単位で支払先延ばし依頼画面１２００を介してバイヤー端末１２に提供する。

【0072】

図１２は、支払先延ばし依頼画面１２００の一例を説明する図である。支払先延ばし依頼画面１２００は、請求データ概要１２０１、支払先延ばし依頼概要１２０２、請求明細データ選択欄１２０３、及び登録ボタン１２０４を含む。請求データ概要１２０１は、１以上の請求明細データに関連付けられる売上データファイルのサマリー情報を示す。支払先延ばし依頼概要１２０２は、バイヤーが行う依頼内容の概要を示す。支払先延ばし依頼概要１２０２に含まれる支払希望日は、バイヤーが保有するクレジットカードの支払日に基づく複数の候補から選択されるように構成されてよい。例えば、クレジットカードの支払日が「月末払い」であった場合、複数の候補は、翌月末、翌々月末、３カ月後の月末・・・などであってよく、バイヤーが「３カ月後の月末」を選択した場合には、その日が希望支払日となる。請求明細データ選択欄１２０３は、売上データファイルに関連付けられる請求明細データのそれぞれを表示する。登録ボタン１２０４は、バイヤーによって入力された支払先延ばし依頼の内容を登録するためのボタンである。

【0073】

バイヤーは、請求明細データ選択欄１２０３に表示されている請求明細データのうち支払先延ばしを希望するデータを選択する。バイヤーが登録ボタン１２０４を押下すると、決済処理装置１０は、選択された請求明細データについての支払先延ばし依頼を受信し、依頼された請求明細データのファイナンスフラグ６０６に所定の値（例えば、支払先延ばしを示す「第３の値」）をセットする。支払先延ばし依頼は、選択された請求明細データと希望支払日の情報を含む。

【0074】

Ｓ９０２にて、決済処理装置１０は、カード払いによる支払先延ばしを依頼された請求明細データの内容と希望支払日を含む試算依頼をファイナンスシステム１４に送信する。ファイナンスシステム１４は、受信した請求明細データの内容と希望支払日に基づいて試算を行い、試算結果を決済処理装置１０に送信する。

【0075】

Ｓ９０３にて、決済処理装置１０は、ファイナンスシステム１４から試算結果を受信したことに応答して、試算結果表示画面１３００を介してバイヤー端末１２に試算結果を提供する。

【0076】

図１３は、試算結果表示画面１３００の一例を説明する図である。試算結果表示画面１３００は、支払先延ばし対象明細情報１３０１、試算結果１３０２、申込ボタン１３０３、及び取下ボタン１３０４を含む。支払先延ばし対象明細情報１３０１は、試算を行った１以上の請求明細データと、それぞれの請求明細データに対する試算結果とを示す。試算結果１３０２は、１以上の請求明細データに対して行われた試算結果のサマリーを示す。申込ボタン１３０３は、試算結果に従って支払先延ばしのための処理を正式に申し込むためのボタンである。取下ボタン１３０４は、試算結果を承諾しない場合に依頼を取り下げるためのボタンであり、このボタンが押下された場合には、決済処理装置１０は、取下対象の請求明細データのファイナンスフラグ６０６にＮｕｌｌ値をセットする。

【0077】

試算結果が許容可能なものであれば、バイヤーは、バイヤー端末１２を介して支払先延ばし申込を登録する。決済処理装置１０は、バイヤー端末１２から試算結果に基づくカード払いによる支払先延ばし申込を受信する。この申込は、支払先延ばしを行いたい請求明細データの情報とバイヤーの希望支払日とを含む。

【0078】

Ｓ９０４にて、決済処理装置１０は、カード払いによる支払先延ばし申込を受信すると、請求明細データに元々登録されていた支払予定日に入金処理を行うための入金依頼データを生成して入金処理システム１５に送信する。入金処理システム１５は、入金依頼データに基づいて第１の銀行システム１６に振込電文を送信し、第１の銀行システム１６は、サプライヤー口座に対して入金処理を行う。

【0079】

Ｓ９０５にて、決済処理装置１０は、カード払いによる支払先延ばし申込を受信すると、銀行による保証を受けるための保証申込データを生成し、生成した保証申込データをファイナンスシステム１４に送信する。ファイナンスシステム１４は、保証申込データに基づいて保証取組の処理を実行する。

【0080】

Ｓ９０６にて、決済処理装置１０は、カード払いによる支払先延ばし申込を行った請求明細データの請求金額６０３の金額を決済額とし、及び希望支払日に口座引落が実行されるような日付を売上日とするカード売上データを生成し、入金処理システム１５に送信する。通常、カード決済は、カード事業会社のシステムがカード番号、決裁金額、及びカード保有者の与信情報などの情報に基づいて決済可否を判断するオーソリゼーションと呼ばれる処理を実行するが、本発明では、このようなオーソリゼーション処理は行われない。そのため、決済処理装置１０は、オーソリゼーションデータを生成せず、請求明細データ及び希望支払日に基づいて売上データを生成するように構成される。

【0081】

また、通常のカード決済では、売上日に従って口座振替により口座引落が行われる日が決定される。通常のケースでは、最短で約１カ月、最長でも約２カ月後に口座引落が実行される。本発明では、決済処理装置１０は、バイヤーの希望支払日であって、かつ保証が付けられる限りの日付に口座引落が実行されるように、売上日を設定したカード売上データを生成する。

【0082】

決済処理装置１０は、カード売上データに関連付けられる請求明細データのステータス６０５及び当該請求明細データに関連付けられる請求データのステータス５０９を「カード払い」に変更する。ステータスが「カード払い」となっている請求データ及び請求明細データについては、図７を参照しながら説明したような口座振替処理は実行されず、クレジットカードの支払日、すなわち、希望支払日に決済額がバイヤーの口座から引き落とされる。

【0083】

上述の処理により、入金処理システム１５を管理しているクレジットカード事業会社がサプライヤーに対する立替払いを行うため、サプライヤーは、当初の入金予定日に資金を受け取ることができ、一方、バイヤーは、クレジットカード払いを選択することにより当初の支払予定日を希望支払日に先延ばしすることができるようになる。

【0084】

以上、例示的な実施形態を参照しながら本発明の原理を説明したが、本発明の要旨を逸脱することなく、構成及び細部において変更する様々な実施形態を実現可能であることを当業者は理解するだろう。すなわち、本発明は、例えば、システム、装置、方法、プログラム若しくは記憶媒体等としての実施態様を採ることが可能である。

【符号の説明】

【0085】

１０ 決済処理装置
１１ サプライヤー端末
１２ バイヤー端末
１３ 口座振替システム
１４ ファイナンスシステム
１５ 入金処理システム
１６ 第１の銀行システム
１７ 第２の銀行システム
２１ 第１のネットワーク
２２ 第２のネットワーク
１０１ 制御部
１０２ 主記憶部
１０３ 補助記憶部
１０４ インターフェース（ＩＦ）部
１０５ 出力部
１０６ ユーザマスタ
１０７ 契約／決済情報
１０８ 請求データ
１０９ 請求明細データ
１０００ 早期資金化依頼画面
１１００、１３００ 試算結果表示画面
１２００ 支払先延ばし依頼画面

【要約】

【課題】保証機能を組み合わせたカード払いの支払手段を提供する。
【解決手段】決済処理装置は、第１のユーザ及び第２のユーザ間の取引結果を示す請求データ及び請求明細データを格納している。決済処理装置は、カード払いに関連付けられるファイナンス申込を受信することと、ファイナンス申込に関連付けられる第１の請求明細データに登録されていた支払予定日に第１のユーザの口座に対して入金処理を行うための入金依頼を生成することと、ファイナンス申込に関連付けられる保証申込を生成することと、ファイナンス申込に関連付けられる希望支払日に第１の請求明細データに基づく口座振替処理が実行されるような売上日を設定したカード売上データを生成することを実行する。
【選択図】図９

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】