JP2020035370A - 支払代行装置、決済システム、決済方法、及びプログラム - Google Patents

Abstract

【課題】企業間のカード決済取引の利用を増加させる。【解決手段】支払代行装置は、売り手と買い手との間の取引の支払い代行を申請する支払代行申請を取得する申請取得部と、前記支払代行申請に含まれる取引金額に応じた取引手数料を、買い手負担分と売り手負担分とに分配して設定する手数料分配部と、前記申請取得部が取得した前記支払代行申請に応じて、前記買い手から前記売り手への前記取引金額の支払いを代行する支払代行処理部であって、前記取引金額から前記売り手負担分を減額した支払金額を前記売り手の口座に振り込む立替払い処理を実行し、前記取引金額に前記買い手負担分を加算した集金金額を前記買い手の口座から回収する回収処理を実行する支払代行処理部とを備える。【選択図】図１

Description

本発明は、支払代行装置、決済システム、決済方法、及びプログラムに関する。

近年、クレジットカードなどの決済カードを利用して取引を行うカード決済が広く利用されている。従来のクレジット決済などのカード決済を利用した決済システムでは、売り手（サプライヤ）からの依頼により売り手へ立替え払いが行われ、買い手（バイヤ）は後支払いで決済が行われる。売り手は、カード決済を利用するために、決済手数料をカード会社に負担する仕組みであった（例えば、特許文献１を参照）。

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

しかしながら、従来の決済システムでは、上述したように、売り手側の一方のみが取引手数料を負担する仕組みであり、カード決済を利用した企業間の取引が普及しない要因になっている。

本発明は、上記問題を解決すべくなされたもので、その目的は、企業間のカード決済取引の利用を増加させることができる支払代行装置、決済システム、決済方法、及びプログラムを提供することにある。

上記問題を解決するために、本発明の一態様は、売り手と買い手との間の取引の支払い代行を申請する支払代行申請を取得する申請取得部と、前記支払代行申請に含まれる取引金額に応じた決済手数料を、買い手負担分と売り手負担分とに分配して設定する手数料分配部と、前記申請取得部が取得した前記支払代行申請に応じて、前記買い手から前記売り手への前記取引金額の支払いを代行する支払代行処理部であって、前記取引金額から前記売り手負担分を減額した支払金額を前記売り手の口座に振り込む立替払い処理を実行し、前記取引金額に前記買い手負担分を加算した集金金額を前記買い手の口座から回収する回収処理を実行する支払代行処理部とを備えることを特徴とする支払代行装置である。

また、本発明の一態様は、上記の支払代行装置において、前記取引金額と、前記決済手数料を示す手数料情報とを対応付けて記憶する決済手数料記憶部から、前記取引金額に対応する前記手数料情報を取得し、当該手数料情報に基づいて前記決済手数料を設定する決済手数料設定部を備え、前記手数料分配部は、前記買い手の端末を示す買手側端末から取得した分配情報に基づいて、前記決済手数料設定部が設定した前記決済手数料を、前記買い手負担分と前記売り手負担分とに分配して設定することを特徴とする。

また、本発明の一態様は、上記の支払代行装置において、前記手数料情報は、前記決済手数料の金額値、又は前記取引金額に対する前記決済手数料の割合であることを特徴とする。

また、本発明の一態様は、上記の支払代行装置において、前記立替払い処理によって、前記売り手に支払われる入金期日の変更に応じて、前記売り手に対して入金手数料を設定する入金手数料設定部を備え、前記支払代行処理部は、前記入金期日が変更された場合に、前記立替払い処理において、前記取引金額と、前記売り手負担分及び前記入金手数料とに基づいて算出された前記支払金額を、変更された前記入金期日に前記売り手の口座に振り込む処理を実行することを特徴とする。

また、本発明の一態様は、上記の支払代行装置において、前記支払代行処理部は、前記回収処理において、決済カードによるカード決済を利用して、前記買い手の口座から前記集金金額を回収する処理を実行し、前記立替払い処理において、前記カード決済を行うカード会社に対して、前記支払金額を前記売り手に立替えて支払う処理依頼を行うことを特徴とする。

また、本発明の一態様は、上記の支払代行装置において、前記決済カードは、クレジットカードであり、前記支払代行処理部は、前記クレジットカードによるカード決済を利用して、前記回収処理を実行することを特徴とする。

また、本発明の一態様は、企業間の電子商取引サービスを提供し、売り手と買い手との間の取引の支払い代行を申請する支払代行申請を生成する取引処理装置と、支払代行装置とを備え、前記支払代行装置は、売り手と買い手との間の取引の支払い代行を申請する支払代行申請を取得する申請取得部と、前記支払代行申請に含まれる取引金額に応じた決済手数料を、買い手負担分と売り手負担分とに分配して設定する手数料分配部と、前記申請取得部が取得した前記支払代行申請に応じて、前記買い手から前記売り手への前記取引金額の支払いを代行する支払代行処理部であって、前記取引金額から前記売り手負担分を減額した支払金額を前記売り手の口座に振り込む立替払い処理を実行し、前記取引金額に前記買い手負担分を加算した集金金額を前記買い手の口座から回収する回収処理を実行する支払代行処理部とを備えることを特徴とする決済システムである。

また、本発明の一態様は、申請取得部が、売り手と買い手との間の取引の支払い代行を申請する支払代行申請を取得する申請取得ステップと、手数料分配部が、前記支払代行申請に含まれる取引金額に応じた決済手数料を、買い手負担分と売り手負担分とに分配して設定する手数料分配ステップと、支払代行処理部が、前記申請取得ステップによって取得された前記支払代行申請に応じて、前記買い手から前記売り手への前記取引金額の支払いを代行する支払代行処理ステップであって、前記取引金額から前記売り手負担分を減額した支払金額を前記売り手の口座に振り込む立替払い処理を実行し、前記取引金額に前記買い手負担分を加算した集金金額を前記買い手の口座から回収する回収処理を実行する支払代行処理ステップとを含むことを特徴とする決済方法である。

また、本発明の一態様は、コンピュータに、売り手と買い手との間の取引の支払い代行を申請する支払代行申請を取得する申請取得ステップと、前記支払代行申請に含まれる取引金額に応じた決済手数料を、買い手負担分と売り手負担分とに分配して設定する手数料分配ステップと、前記申請取得ステップによって取得された前記支払代行申請に応じて、前記買い手から前記売り手への前記取引金額の支払いを代行する支払代行処理ステップであって、前記取引金額から前記売り手負担分を減額した支払金額を前記売り手の口座に振り込む立替払い処理を実行し、前記取引金額に前記買い手負担分を加算した集金金額を前記買い手の口座から回収する回収処理を実行する支払代行処理ステップとを実行させるためのプログラムである。

本発明によれば、企業間のカード決済取引の利用を増加させることができる。

第１の実施形態による決済システムの一例を示すブロック図である。 第１の実施形態における取引情報記憶部が記憶するデータ例を示す図である。 第１の実施形態における利用料記憶部が記憶するデータ例を示す図である。 第１の実施形態における決済手数料記憶部が記憶するデータ例を示す図である。 第１の実施形態における月額利用料記憶部が記憶するデータ例を示す図である。 第１の実施形態における早期入金手数料記憶部が記憶するデータ例を示す図である。 第１の実施形態による決済システムの支払代行処理の動作の一例を説明する図である。 第１の実施形態による支払代行サーバの支払代行の申請処理の一例を説明する図である。 第１の実施形態による支払代行申請におけるＦＢデータのアップロード画面の一例を示す図である。 第１の実施形態による支払代行の申請画面の一例を示す図である。 第１の実施形態による支払代行サーバの支払代行処理の一例をフローチャートである。 第１の実施形態による支払代行サーバの支払代行処理の動作の一例を説明する図である。 第２の実施形態による決済システムの一例を示すブロック図である。 第２の実施形態による決済システムの支払代行処理の動作の一例を説明する図である。 第３の実施形態による決済システムの一例を示すブロック図である。 第３の実施形態による決済システムの支払代行処理の動作の一例を説明する図である。 第４の実施形態による決済システムの一例を示すブロック図である。 第４の実施形態による決済システムの支払代行処理の動作の一例を説明する図である。

以下、本発明の一実施形態による支払代行装置、及び決済システムについて図面を参照して説明する。

［第１の実施形態］
図１は、第１の実施形態による決済システム１００の一例を示すブロック図である。
この図に示すように、本実施形態による決済システム１００は、支払代行サーバ１と、バイヤ端末２と、サプライヤ端末３と、カード会社サーバ４と、取引処理サーバ５とを備えている。支払代行サーバ１と、バイヤ端末２と、サプライヤ端末３と、カード会社サーバ４と、取引処理サーバ５とは、ネットワークＮＷ１を介して、互いに接続可能である。

なお、図１に示す例では、説明上、図示を省略するが、決済システム１００は、バイヤ端末２と、サプライヤ端末３とのそれぞれを、複数備えることが可能である。
また、本実施形態では、例えば、クレジットカード（パーチェシングカードを含む）、デビットカード、プリペイドカード等のカード取引、及び、カード取引の仕組みを利用した仮想決済番号による取引に用いられる決済カードの一例として、クレジットカードを利用した決済システム１００について説明する。

バイヤ端末２（買手側端末の一例）は、企業間の取引において、買い手であるバイヤが所有する端末装置である。バイヤ端末２は、バイヤの操作により、例えば、取引処理サーバ５及び支払代行サーバ１にネットワークＮＷ１を介して接続し、バイヤとサプライヤとの間の取引の契約や支払代行の依頼（支払代行申請）などを行う。また、バイヤ端末２は、入力部２１と、表示部２２とを備えている。
なお、本実施形態において、サプライヤは、商品等を販売している売り手のことであり、バイヤは、商品等を購入する買い手のことである。また、バイヤは、決済カードによるカード決済を行うカード会社と契約した支払代行サービスにおける会員である。

入力部２１は、例えば、キーボードやマウスなどであり、バイヤ端末２の使用者（バイヤ）から必要な各種情報を受け付ける。
表示部２２（出力部の一例）は、例えば、液晶ディスプレイなどの表示装置であり、各種情報を表示する。表示部２２は、例えば、取引処理サーバ５を利用した電子商取引サービスにおける各種表示画面、及び支払代行サーバ１を利用した支払代行サービスにおける各種表示画面などを表示する。

サプライヤ端末３（売手端末の一例）は、企業間の取引において、売り手であるサプライヤが所有する端末装置である。サプライヤ端末３は、サプライヤの操作により、例えば、取引処理サーバ５及び支払代行サーバ１にネットワークＮＷ１を介して接続し、バイヤとサプライヤとの間の取引の契約や支払代行の承認などを行う。また、サプライヤ端末３は、入力部３１と、表示部３２とを備えている。

入力部３１は、例えば、キーボードやマウスなどであり、サプライヤ端末３の使用者（サプライヤ）から必要な各種情報を受け付ける。
表示部３２（出力部の一例）は、例えば、液晶ディスプレイなどの表示装置であり、各種情報を表示する。表示部３２は、例えば、取引処理サーバ５を利用した電子商取引サービスにおける各種表示画面、及び支払代行サーバ１を利用した支払代行サービスにおける各種表示画面などを表示する。

カード会社サーバ４は、クレジットカードを発行するとともに、クレジットカードの利用限度額などを管理するカード会社が所有するサーバ装置であり、発行したクレジットカードを管理する。ここで、カード会社は、クレジットカード（決済カード）によるカード決済を行う会社であり、例えば、カード発行会社（イシュア）及び加盟店管理会社（アクワイアラ）である。カード会社サーバ４は、例えば、各クレジットカードの利用限度額を管理し、クレジットカードの与信を利用した決済が可能であるか否かを確認する与信確認依頼を受け付けて、確認結果を依頼元に送信する。

また、カード会社サーバ４は、支払代行サーバ１からの依頼により、サプライヤへの立替払いのための振込処理、及び、バイヤからの回収のためのクレジット決済処理などを行う。また、カード会社サーバ４は、例えば、カード管理記憶部４１を備えている。
カード管理記憶部４１は、例えば、カード契約情報を記憶している。ここで、カード契約情報は、カード発行会社が発行しているクレジットカードの契約情報であり、カード発行会社に予め登録されている情報である。カード管理記憶部４１は、例えば、カード番号と、カード契約情報とを対応付けて記憶している。また、カード契約情報には、例えば、カード有効期限年月、法人名、所属部署、及び使用者名などの情報が含まれる。

取引処理サーバ５（取引処理装置の一例）は、企業間の電子商取引サービスを提供するプラットフォーマであり、バイヤとサプライヤとの間の取引を支援する。取引処理サーバ５は、例えば、売買契約記憶部５１を備えている。
売買契約記憶部５１は、バイヤとサプライヤとの間の取引における売買契約情報を記憶する。売買契約情報には、例えば、取引日、バイヤ情報、サプライヤ情報、取引金額、支払期日（入金期日）などが含まれる。

支払代行サーバ１（支払代行装置の一例）は、バイヤとサプライヤとの間の売買契約に基づく支払代行を行う支払代行サービスを提供する。また、支払代行サーバ１は、クレジットカードを利用したカード決済を利用して支払代行を行う。また、支払代行サーバ１は、ＮＷ（ネットワーク）通信部１１と、記憶部１２と、制御部１３とを備えている。

ＮＷ通信部１１は、ネットワークＮＷ１と接続して、各種通信を行う。
記憶部１２は、支払代行サーバ１の各種処理に利用する情報を記憶する。記憶部１２は、アカウント記憶部１２１と、サプライヤ情報記憶部１２２と、バイヤ情報記憶部１２３と、取引情報記憶部１２４と、利用料記憶部１２５と、決済手数料記憶部１２６と、月額利用料記憶部１２７と、早期入金手数料記憶部１２８とを備えている。

アカウント記憶部１２１は、支払代行サーバ１に接続するためのログインＩＤやパスワードなどのログイン情報を記憶する。ログイン情報は、バイヤ又はサプライヤが、支払代行サービスに会員登録する際に、アカウント記憶部１２１に記憶される。

サプライヤ情報記憶部１２２は、支払代行サーバ１が提供する支払代行サービスに会員登録しているサプライヤに関する情報であるサプライヤ情報を記憶する。サプライヤ情報記憶部１２２は、例えば、企業情報（企業名、法人番号、業種など）、担当者情報（所属部署名、ユーザ氏名、メールアドレス、電話番号など）、口座情報（金融機関名、支店名、口座番号、口座名義など）、等をサプライヤ情報として記憶している。なお、サプライヤが、加盟店に加盟している場合には、加盟店番号を記憶してもよい。サプライヤ情報は、サプライヤが支払代行サービスに会員登録する際に、サプライヤ情報記憶部１２２に記憶される。

バイヤ情報記憶部１２３は、支払代行サーバ１が提供する支払代行サービスに会員登録しているバイヤに関する情報であるバイヤ情報を記憶する。バイヤ情報記憶部１２３は、例えば、企業情報（企業名、法人番号、業種など）、担当者情報（所属部署名、ユーザ氏名、メールアドレス、電話番号など）、口座情報（金融機関名、支店名、口座番号、口座名義など）、クレジットカードのカード番号、等をバイヤ情報として記憶している。バイヤ情報は、バイヤが支払代行サービスに会員登録する際に、バイヤ情報記憶部１２３に記憶される。

取引情報記憶部１２４は、支払代行を行った取引情報（支払代行申請の情報）を記憶する。取引情報記憶部１２４は、例えば、図２に示すように、売買契約情報、支払方法、決済手数料及び入金期日の変更によって生じる入金手数料などを記憶する。
図２は、本実施形態における取引情報記憶部１２４が記憶するデータ例を示す図である。図２に示すように、取引情報記憶部１２４は、「取引日」と、「取引ＩＤ」と、「バイヤ」及び「サプライヤ」と、「取引金額」と、「支払期日」と、「支払方法」と、「決済手数料」と、「入金手数料」とを対応付けて記憶する。

なお、「決済手数料」には、「手数料合計」と、「バイヤ負担分」と、「サプライヤ負担分」とが含まれている。また、「入金手数料」には、サプライヤへの入金期日（振込期日）のより前に入金を前倒した場合の早期入金手数料である。

例えば、図２に示す例では、「取引日」が“２０１８／４／１”の「取引ＩＤ」が“ＸＸＸＸＸ１”に対応する支払代行（取引）は、「バイヤ」が“Ａ社”であり、「サプライヤ」が“Ｂ社”であり、「取引金額」が“１０００万円”であることを示している。また、この支払代行のサプライヤへの「支払期日」が“２０１８／４／３０”であり、「支払方法」が“アカウント決済”であることを示している。ここで、アカウント決済は、バイヤ情報に紐付いて設定されたクレジットカードによる決済を利用した決済方法であり、例えば、取引金額に応じて決済手数料が変動し、手数料負担者及び負担金額が設定可能な決済方法である。また、この支払代行の「決済手数料」は、「手数料合計」が“１０万円”、「バイヤ負担分」が“６万円”、「サプライヤ負担分」が“４万円”であることを示し、「入金手数料」が“１万円”（早期入金手数料）であることを示している。

図１の説明に戻り、利用料記憶部１２５は、支払代行サービスの利用料金に関する情報を記憶する。利用料記憶部１２５は、例えば、図３に示すように、「導入費用」、「決済手数料」、「月額利用料」、「システム利用料」、「ユーザＩＤ利用料」、「入金手数料」などの項目の利用料の設定情報を記憶する。
図３は、本実施形態における利用料記憶部１２５が記憶するデータ例を示す図である。
図３において、「決済手数料」、「月額利用料」、及び「入金手数料」は、利用条件により変動するため、利用料記憶部１２５は、これらの各項目の設定テーブルを示す情報を記憶する。

再び図１の説明に戻り、決済手数料記憶部１２６は、支払代行の決済ごとに発生する手数料を設定する設定テーブル（決済手数料マスタ）を記憶する。決済手数料記憶部１２６は、取引金額と、手数料情報とを対応付けた設定テーブルを記憶する。ここで、図４を参照して、決済手数料記憶部１２６が記憶するデータ例について説明する。

図４は、本実施形態における決済手数料記憶部１２６が記憶するデータ例を示す図である。図４に示すように、決済手数料記憶部１２６は、「取引金額」と、「手数料情報」とを対応付けて記憶する。ここで、「手数料情報」は、決済手数料を示す情報であり、例えば、取引金額に対する決済手数料の割合（料率）を示している。
例えば、図４に示す例では、「取引金額」が“３０万円未満”である場合に、「手数料情報」が“Ｘ．Ｘ％”であることを示している。なお、図４に示す例では、「手数料情報」に決済手数料の割合（料率）を用いる例を説明しているが、決済手数料の金額値を用いてもよい。

再び図１の説明に戻り、月額利用料記憶部１２７は、支払代行サービスを受ける場合の月額の利用料を設定する設定テーブル（月額利用料マスタ）を記憶する。月額利用料記憶部１２７は、１カ月の取引総金額と、利用料情報とを対応付けた設定テーブルを記憶する。ここで、図５を参照して、月額利用料記憶部１２７が記憶するデータ例について説明する。

図５は、本実施形態における月額利用料記憶部１２７が記憶するデータ例を示す図である。図５に示すように、月額利用料記憶部１２７は、「前月の取引総金額」と、「利用料情報」とを対応付けて記憶する。ここで、「利用料情報」は、月額利用料を示す情報であり、例えば、１カ月の取引総金額に対する月額利用料の金額値を示している。
例えば、図５に示す例では、「前月の取引総金額」が“５００万円未満”である場合に、「利用料情報」が“ＸＸＸＸＸ円”であることを示している。なお、図５に示す例では、「利用料情報」に月額利用料の金額値を用いる例を説明しているが、月額利用料の割合（料率）を用いてもよい。

再び図１の説明に戻り、早期入金手数料記憶部１２８は、サプライヤへの入金期日の前倒しを希望する場合の入金手数料を設定する設定テーブル（早期入金手数料マスタ）を記憶する。早期入金手数料記憶部１２８は、入金期日の入金短縮日数（前倒しされた日数）と、早期入金手数料情報とを対応付けた設定テーブルを記憶する。ここで、図６を参照して、早期入金手数料記憶部１２８が記憶するデータ例について説明する。

図６は、本実施形態における早期入金手数料記憶部１２８が記憶するデータ例を示す図である。図６に示すように、早期入金手数料記憶部１２８は、「入金短縮日数」と、「早期入金手数料情報」とを対応付けて記憶する。ここで、「早期入金手数料情報」は、早期入金手数料を示す情報であり、例えば、取引金額に対する早期入金手数料の割合（料率）を示している。
例えば、図６に示す例では、「入金短縮日数」が“１営業日以上１０営業日以下”である場合に、「早期入金手数料情報」が“Ｘ．Ｘ％”であることを示している。なお、図６に示す例では、「早期入金手数料情報」に早期入金手数料の割合（料率）を用いる例を説明しているが、早期入金手数料の金額値を用いてもよい。

再び図１の説明に戻り、制御部１３は、例えば、ＣＰＵ（Central Processing Unit）などを含むプロセッサであり、支払代行サーバ１を統括的に制御する。制御部１３は、ＮＷ通信部１１を介して、上述したバイヤ端末２、サプライヤ端末３、カード会社サーバ４、及び取引処理サーバ５と情報の送受信を行い、各種処理を実行する。制御部１３は、例えば、支払代行サービスの会員登録処理、各種手数料・利用料の設定処理、及び支払代行処理などの各種処理を実行する。
制御部１３は、バイヤ登録部１３１と、サプライヤ登録部１３２と、申請取得部１３３と、支払代行処理部１３４と、決済手数料設定部１３５と、手数料分配部１３６と、入金手数料設定部１３７とを備える。

バイヤ登録部１３１は、バイヤ端末２からのバイヤの登録申請に応じて、バイヤ情報を受け付け、当該バイヤ情報をバイヤ情報記憶部１２３に記憶させる。バイヤ登録部１３１は、ＮＷ通信部１１を介して、バイヤ端末２の入力部２１などから受け付けたバイヤ情報を取得して、当該バイヤ情報をバイヤ情報記憶部１２３に記憶させる。

サプライヤ登録部１３２は、サプライヤ端末３からのサプライヤの登録申請に応じて、サプライヤ情報を受け付け、当該サプライヤ情報をサプライヤ情報記憶部１２２に記憶させる。サプライヤ登録部１３２は、ＮＷ通信部１１を介して、サプライヤ端末３の入力部３１などから受け付けたサプライヤ情報を取得して、当該サプライヤ情報をサプライヤ情報記憶部１２２に記憶させる。

申請取得部１３３は、バイヤからの支払い代行の申請を示す支払代行申請を取得する。ここで、支払代行申請には、サプライヤとバイヤとの間の売買契約を示す売買契約情報が含まれるものとする。また、本実施形態では、申請取得部１３３は、取引処理サーバ５から取得されたＦＢデータ（ファームバンキングデータ）を売買契約情報として含む支払代行申請を、バイヤ端末２から取得する。ここで、ＦＢデータとは、金融機関を利用して振込処理を行うためのデータであり、例えば、取引処理サーバ５によって、バイヤとサプライヤとの間で契約された売買契約に基づくデータ（売買契約情報）である。

申請取得部１３３は、例えば、バイヤ端末２からの操作により、ＦＢデータを読み込み、ＦＢデータに含まれる取引データが選択され、決済手数料の分配などの設定を受け付けた後に、支払代行申請を受け付ける。すなわち、申請取得部１３３は、受け付けた支払代行申請を取得する。また、申請取得部１３３は、支払代行申請に含まれる情報を、取引情報記憶部１２４に記憶させる。

決済手数料設定部１３５は、支払代行申請の売買契約情報に含まれる取引金額に応じて、決済手数料を設定する。決済手数料設定部１３５は、例えば、決済手数料記憶部１２６が記憶する設定テーブル（決済手数料マスタ）を参照して、取引金額に対応する決済手数料情報を取得し、当該決済手数料情報に基づいて、当該取引の決済手数料を設定する。また、決済手数料設定部１３５は、設定した決済手数料を取引情報記憶部１２４に記憶させる。

手数料分配部１３６は、決済手数料をバイヤ負担分とサプライヤ負担分とに分配して設定する。手数料分配部１３６は、例えば、バイヤ端末２からのバイヤの操作によって、決済手数料設定部１３５が設定した決済手数料を、バイヤ負担分とサプライヤ負担分との分配情報を受け付け、サプライヤ端末３からのサプライヤの承認が得られた場合に、バイヤ端末２から受け付けたバイヤ負担分とサプライヤ負担分とを設定する。また、手数料分配部１３６は、設定したバイヤ負担分とサプライヤ負担分とを取引情報記憶部１２４に記憶させる。

このように、手数料分配部１３６は、バイヤ端末２から取得した分配情報に基づいて、決済手数料設定部１３５が設定した決済手数料を、バイヤ負担分とサプライヤ負担分とに分配して設定する。なお、分配情報は、バイヤ負担分及びサプライヤ負担分の金額値であってもよいし、決済手数料に対するバイヤ負担分及びサプライヤ負担分の割合であってもよい。

入金手数料設定部１３７は、後述する立替払い処理によって、サプライヤに支払われる入金期日の変更に応じて、サプライヤに対して入金手数料を設定する。入金手数料設定部１３７は、入金期日が前倒しされた場合に、前倒しされた日数に応じて、早期入金手数料を入金手数料として設定する。入金手数料設定部１３７は、例えば、早期入金手数料記憶部１２８が記憶する設定テーブル（早期入金手数料マスタ）を参照して、前倒しされた日数（入金短縮日数）に対応する早期入金手数料情報を取得し、当該早期入金手数料情報に基づいて、早期入金手数料を設定（生成）する。

支払代行処理部１３４は、申請取得部１３３が取得した支払代行申請に応じて、売買契約に対応した支払金額をサプライヤの口座（図７のサプライヤ口座６３）に立替えて支払をする立替払い処理を実行する。また、支払代行処理部１３４は、支払代行申請を取得後の所定の期日に、売買契約に対応した集金金額をバイヤの口座（図７のバイヤ口座６２）から回収する回収処理を実行する。すなわち、支払代行処理部１３４は、ＦＢデータが示す売買契約に対応した立替払い処理及び回収処理を実行する。ここで、支払金額は、取引金額に基づいてサプライヤに支払う金額を示し、集金金額は、取引金額に基づいてバイヤから集金（回収）する金額を示す。

支払代行処理部１３４は、決済カードによるカード決済を行うカード会社の加盟店に相当する仮想加盟店として機能し、回収処理において、仮想加盟店として、カード会社を経由してカード決済を用いて、集金金額をバイヤ口座６２から回収する処理を実行する。ここで、仮想加盟店として機能させるために、支払代行サーバ１の運営者、又はカード会社は、予め支払代行サーバ１用の仮想加盟店として、支払代行サーバ１用の加盟店番号を取得しているものとする。支払代行処理部１３４は、回収処理において、クレジットカードを用いたクレジット決済により、バイヤから仮想加盟店としての支払代行サーバ１に集金金額を回収する。

また、支払代行処理部１３４は、立替払い処理において、カード会社に対して、支払金額をサプライヤ口座６３に立替えて支払う処理依頼を行う。支払代行処理部１３４は、例えば、支払金額を、カード会社サーバ４を経由して、サプライヤ口座６３に振り込ませる。

また、支払代行処理部１３４は、売買契約の取引金額に応じた決済手数料と取引金額とに基づいて、集金金額を算出する。支払代行処理部１３４は、決済手数料設定部１３５が取引金額に基づいて設定した決済手数料と取引金額とに基づいて、集金金額を算出する。さらに、支払代行処理部１３４は、決済手数料を手数料分配部１３６が分配したバイヤ負担分を、取引金額に加算して集金金額を算出する。すなわち、支払代行処理部１３４は、回収処理において、取引金額にバイヤ負担分を加算した集金金額をバイヤ口座６２から回収する処理を実行する。

なお、支払代行処理部１３４は、集金金額を以下の式（１）により算出する。

集金金額＝取引金額＋決済手数料のバイヤ負担分 … （１）

また、支払代行処理部１３４は、決済手数料を手数料分配部１３６が分配したサプライヤ負担分を、取引金額から減算して支払金額を算出する。すなわち、支払代行処理部１３４は、立替払い処理において、取引金額からサプライヤ負担分を減額した支払金額をサプライヤ口座６３に振り込む処理を実行する。

また、支払代行処理部１３４は、入金期日が変更された場合に、立替払い処理において、売買契約の取引金額と入金手数料とに基づいて算出された支払金額を、変更された入金期日にサプライヤ口座６３に振り込む処理を実行する。例えば、支払代行処理部１３４は、入金期日が前倒しされた場合に、立替払い処理において、取引金額から早期入金手数料を減額した支払金額を、サプライヤ口座６３に振り込む処理を実行する。すなわち、この場合、支払代行処理部１３４は、入金手数料設定部１３７が設定した早期入金手数料と、上述したサプライヤ負担分とを取引金額から減算した支払金額をサプライヤ口座６３に振り込む処理を実行する。

なお、支払代行処理部１３４は、支払金額を以下の式（２）により算出する。

支払金額＝取引金額−決済手数料のサプライヤ負担分−早期入金手数料 … （２）

また、支払代行処理部１３４は、毎月の所定の期日に、支払代行サービスを利用した月単位又は所定期間内の利用料の合計を算出し、当該利用料の合計を、バイヤから回収する処理を実行する。支払代行処理部１３４は、例えば、取引情報記憶部１２４が記憶する取引情報に基づいて、先月分の取引総金額を算出し、月額利用料記憶部１２７が記憶する設定テーブル（月額利用料マスタ）を参照して、先月分の取引総金額に対応する月額利用料情報を取得し、当該月額利用料情報に基づいて、月額利用料を算出する。支払代行処理部１３４は、さらに、算出した当該月額利用料と、利用料記憶部１２５が記憶する月額利用料以外の固定の利用項目の情報に基づいて、先月分の利用料の合計を算出する。

次に、図面を参照して、本実施形態による決済システム１００の動作について説明する。
図７は、本実施形態による決済システム１００の支払代行処理の動作の一例を説明する図である。

なお、図７に示す金融機関サーバ６は、決済処理を行うための口座を有しており、例えば、支払代行口座６１と、バイヤ口座６２と、サプライヤ口座６３とを有している。
支払代行口座６１は、支払代行サービスのために、運営者、又はカード会社が開設した口座であり、バイヤ口座６２は、バイヤが所有する口座であり、サプライヤ口座６３は、サプライヤが所有する口座である。

図７に示すように、バイヤ端末２は、まず、取引処理サーバ５を利用して、バイヤとサプライヤとの間で、商品等の取引契約（売買契約）を行う（ステップＳ１０１）。バイヤ端末２は、バイヤの入力部２１の操作によって、取引処理サーバ５にログインし、サプライヤの商品等の取引契約（売買契約）を行う。取引処理サーバ５は、取引契約（売買契約）の情報を、売買契約記憶部５１に記憶させる。

次に、バイヤ端末２は、ＦＢデータ（売買契約情報）を取引処理サーバ５からダウンロードする（ステップＳ１０２）。
次に、バイヤ端末２は、支払代行申請及び承認を支払代行サーバ１に対して行う（ステップＳ１０３）。バイヤ端末２は、バイヤの入力部２１の操作によって、支払代行サーバ１にログインして、売買契約情報であるＦＢデータを支払代行サーバ１に送付して支払代行申請を行うとともに、支払代行申請の承認を行う。なお、バイヤ端末２は、決済手数料の分担などを設定して、支払代行申請を行う。

次に、サプライヤ端末３が、支払代行申請の承認を行う（ステップＳ１０４）。支払代行サーバ１は、バイヤ端末２からの支払代行申請の承認に応じて、例えば、サプライヤにメールなどで、支払代行申請の承認依頼を行い、この承認依頼に応じて、サプライヤ端末３が、支払代行申請の承認を行う。

次に、支払代行サーバ１が、カード会社サーバ４に集金金額の回収依頼を行う（ステップＳ１０５）。支払代行サーバ１の支払代行処理部１３４は、仮想加盟店として、クレジット決済を利用して、支払代行サーバ１用の加盟店番号に対応する支払代行口座６１に、集金金額を回収する依頼を、カード会社サーバ４に行う。

次に、カード会社サーバ４は、集金金額の回収依頼に応じて、仮想加盟店への立替払い依頼を、金融機関サーバ６に対して行う（ステップＳ１０６）。これにより、金融機関サーバ６において、カード会社から支払代行口座６１に集金金額（＝取引金額＋バイヤ負担分）が振り込まれる（立替払いされる）。

また、支払代行サーバ１は、カード会社サーバ４を介して、支払金額の支払い依頼を金融機関サーバ６に対して行う（ステップＳ１０７）。これにより、金融機関サーバ６において、支払代行口座６１から支払金額（＝取引金額−サプライヤ負担分−入金手数料）がサプライヤ口座６３に振り込まれる。ここで、入金手数料は、早期入金手数料である。

また、カード会社サーバ４は、所定の引落期日になったら、バイヤ口座６２からカード会社に債権（集金金額）を回収する債権回収依頼を金融機関サーバ６に対して行う（ステップＳ１０８）。これにより、金融機関サーバ６において、バイヤ口座６２からカード会社に、集金金額が引き落とされ、結果として、バイヤ口座６２から支払代行口座６１に集金金額（＝取引金額＋バイヤ負担分）が回収されたことになる。
これにより、決済システム１００による支払代行処理が完了する。

次に、図８〜図１０を参照して、本実施形態の支払代行サーバ１による支払代行申請の受け付け処理について説明する。
図８は、本実施形態による支払代行サーバ１の支払代行の申請処理の一例を説明する図である。また、図９は、本実施形態による支払代行申請におけるＦＢデータのアップロード画面の一例を示す図である。また、図１０は、本実施形態による支払代行の申請画面の一例を示す図である。

図８において、支払代行サーバ１は、まず、ＦＢデータを取得する（ステップＳ２０１）。支払代行サーバ１の申請取得部１３３は、バイヤ端末２の表示部２２に、図９に示す画面Ｇ１のような表示画面を表示させ、入力枠Ｗ１に入力部２１によりＦＢデータのファイル名を入力させることで、ＦＢデータを取得する。ＦＢデータが取得されると、支払代行サーバ１は、図９の画面Ｇ１に示すような取引データ（売買契約）の一覧を表示させる。バイヤ端末２の入力部２１によって、画面Ｇ１において、例えば、取引データＤ１の“詳細”ボタンＢＴ１が押下されると、申請取得部１３３は、図１０（ａ）の画面Ｇ２及び図１０（ｂ）の画面Ｇ３のような支払代行申請の情報を入力する表示画面を、バイヤ端末２に表示させる。

次に、申請取得部１３３は、サプライヤの口座情報に対応する企業情報を取得する（ステップＳ２０２）。申請取得部１３３は、選択された取引データ（売買契約）のサプライヤの口座情報に対応する企業情報を、サプライヤ情報記憶部１２２から取得する。申請取得部１３３は、企業情報の取得に成功した場合に、図１０（ａ）の画面Ｇ２に示すように、「取引先企業情報」及び「担当者情報」としてバイヤ端末２に表示させる。

また、申請取得部１３３は、サプライヤが支払代行サービスの会員であるか否かを判定する（ステップＳ２０３）。申請取得部１３３は、サプライヤ情報記憶部１２２に、上述したサプライヤの口座情報及び企業情報があるか否かに応じて、サプライヤが支払代行サービスの会員であるか否かを判定する。申請取得部１３３は、サプライヤが支払代行サービスの会員である場合（ステップＳ２０３：ＹＥＳ）に、処理をステップＳ２０４に進める。また、申請取得部１３３は、サプライヤが支払代行サービスの会員でない場合（ステップＳ２０３：ＮＯ）に、処理をステップＳ２０８に進める。

ステップＳ２０４において、申請取得部１３３は、請求書情報及び支払方法を取得する。申請取得部１３３は、選択された取引データ（売買契約）から請求書情報（請求書番号、取引金額、支払期日など）、及び支払方法（アカウント決済など）を取得する。

次に、申請取得部１３３は、バイヤに対応する手数料情報を取得する（ステップＳ２０５）。申請取得部１３３は、決済手数料設定部１３５が、バイヤが選択した支払方法、及び取引金額に基づく決済手数料を取得し、図１０（ｃ）の画面Ｇ４に示すように、バイヤ端末２に表示させる。

次に、支払代行サーバ１の手数料分配部１３６は、決済手数料の分担及び負担金額を受け付ける（ステップＳ２０６）。手数料分配部１３６は、図１０（ｃ）の画面Ｇ４の入力枠Ｗ２において、バイヤ端末２の入力部２１によりバイヤ負担分及びサプライヤ負担分の負担金額を受け付ける。

次に、申請取得部１３３は、支払代行申請を受け付ける（ステップＳ２０７）。申請取得部１３３は、図１０（ｃ）に示す画面Ｇ４において、バイヤ端末２の入力部２１によって、“支払代行申請”のボタンＢＴ２が押下されると、支払代行申請を受け付ける。これにより、申請取得部１３３は、図１０（ｄ）の画面Ｇ５を、バイヤ端末２に表示させる。なお、申請取得部１３３は、“支払代行申請”のボタンＢＴ２が押下された後に、バイヤ端末２から送信された正式な支払代行申請を取得し、取得した支払代行申請を取引情報として、取引情報記憶部１２４に記憶させる。このように、申請取得部１３３は、上述した一連の処理により、ＦＢデータを売買契約情報として含む支払代行申請を取得する。ステップＳ２０７の処理後に、支払代行の申請処理を終了する。

また、ステップＳ２０８において、申請取得部１３３は、サプライヤが、不適合企業であるか否かを判定する。申請取得部１３３は、例えば、外部の企業データベースなどを利用して、サプライヤが***的勢力の関連企業であるか否か、過去の取引において不適合な事例がある企業であるか否かなどを判定することにより、不適合企業であるか否かを判定する。申請取得部１３３は、サプライヤが、不適合企業である場合（ステップＳ２０８：ＹＥＳ）に、処理をステップＳ２１１に進める。また、申請取得部１３３は、サプライヤが、不適合企業でない場合（ステップＳ２０８：ＮＯ）に、処理をステップＳ２０９に進める。

ステップＳ２０９において、申請取得部１３３は、請求書情報及び支払方法を取得する。申請取得部１３３は、選択された取引データ（売買契約）から請求書情報（請求書番号、取引金額、支払期日など）、及び支払方法（アカウント決済など）を取得する。

次に、申請取得部１３３は、バイヤに対応する手数料情報を取得する（ステップＳ２１０）。申請取得部１３３は、決済手数料設定部１３５が、バイヤが選択した支払方法、及び取引金額に基づく決済手数料を取得し、図１０（ｃ）の画面Ｇ４に示すように、バイヤ端末２に表示させる。なお、この場合、サプライヤが会員でないため、申請取得部１３３は、決済手数料の分担、及び負担金額の受け付け処理を行わずに、処理をステップＳ２０７に進める。

また、ステップＳ２１１において、申請取得部１３３は、支払代行申請の受け付けを不可として、支払代行の申請処理を終了する。

次に、図１１及び図１２を参照して、本実施形態による支払代行サーバ１の支払代行処理の詳細について説明する。
図１１は、本実施形態による支払代行サーバ１の支払代行処理の一例をフローチャートである。また、図１２は、本実施形態による支払代行サーバ１の支払代行処理の動作の一例を説明する図である。

図１１に示すように、支払代行サーバ１の申請取得部１３３は、まず、支払代行申請の受け付け及びバイヤの承認を受領する（ステップＳ３０１）。申請取得部１３３は、上述した図８の支払代行の申請処理により、支払代行申請を受け付ける。そして、申請取得部１３３は、例えば、バイヤにメールなどで、支払代行申請の承認依頼を行い、この承認依頼に応じて、バイヤ端末２が、支払代行申請の承認を行う。

なお、ステップＳ３０１の処理が、申請取得部１３３による支払代行申請を取得する処理に対応する。ここで、支払代行申請は、一例として、図１１（ａ）に示す内容であるものとする。すなわち、図１１（ａ）に示す例では、Ｂ社からＡ社に取引金額１０００万円を支払う支払代行処理を行う場合であり、決済手数料の合計が、１０万円であり、その内の６万円をバイヤが負担し、４万円をサプライヤが負担する。また、早期入金手数料が１万円である。

次に、支払代行サーバ１の支払代行処理部１３４が、申請取得部１３３が取得した支払代行申請に基づいて、オーソリ処理を実行する（ステップＳ３０２）。ここで、オーソリ処理とは、カード会社に対して、与信確認を行うことであり、支払代行処理部１３４は、図１２（ｂ）に示すように、取引金額の１０００万円と、決済手数料の合計金額の１０万円のオーソリ処理をカード会社サーバ４に対して行う。支払代行処理部１３４は、オーソリ処理において、バイヤ（Ａ社）のカード番号を利用したカード決済により、支払代行処理部１３４の仮想加盟店に支払を行うオーソリ処理を、カード会社サーバ４に対して行う。

これに対して、カード会社サーバ４は、カード管理記憶部４１に記憶されている情報に基づいて、バイヤ（Ａ社）のカード番号の与信確認を行い、オーソリ結果を支払代行サーバ１に送信する。ここでは、オーソリ結果が問題ない（与信ＯＫである）ものとして以降の処理を説明する。
なお、決済手数料のサプライヤ負担分（Ｂ社負担分）の承認がまだ得られていないため、支払代行処理部１３４は、一旦、決済手数料の合計金額の１０万円によりオーソリ処理を行う。

次に、支払代行処理部１３４は、サプライヤの承認依頼及びサプライヤの承認受領を行う（ステップＳ３０３）。支払代行処理部１３４は、オーソリ結果が問題ない場合に、サプライヤ（Ｂ社）にメールなどで、支払代行申請の承認依頼を行う。サプライヤ（Ｂ社）は、サプライヤ端末３の入力部３１を使用して、早期入金申請及び支払代行申請の承認を入力し、支払代行サーバ１に承認結果を送信する。支払代行処理部１３４は、当該支払代行申請の承認結果を受領する。これにより、決済手数料のサプライヤ負担分（Ｂ社負担分）及び早期入金手数料が確定される。

次に、支払代行処理部１３４は、決済手数料のサプライヤ負担分があるか否かを判定する（ステップＳ３０４）。支払代行処理部１３４は、決済手数料のサプライヤ負担分がある場合（ステップＳ３０４：ＹＥＳ）に、処理をステップＳ３０５に進める。また、支払代行処理部１３４は、決済手数料のサプライヤ負担分がない場合（ステップＳ３０４：ＮＯ）に、処理をステップＳ３０６に進める。

ステップＳ３０５において、支払代行処理部１３４は、決済手数料のオーソリ取消、及びバイヤ負担分のオーソリ処理を実行する。支払代行処理部１３４は、例えば、図１２（ｃ）に示すように、上述した決済手数料の合計金額の１０万円のオーソリ取消をカード会社サーバ４に対して行うとともに、バイヤ負担分の６万円のオーソリ処理をカード会社サーバ４に対して行う。なお、ステップＳ３０２において、決済手数料の合計金額の１０万円のオーソリ処理ではなく、バイヤ負担分の６万円のオーソリ処理をカード会社サーバ４に対して行うことで、本ステップをスキップすることも可能とする。

次に、ステップＳ３０６において、支払代行処理部１３４は、売上確定処理を実行する。支払代行処理部１３４は、例えば、図１２（ｃ）に示すように、取引金額の１０００万円とバイヤ負担分の６万円との売上確定処理を、カード会社サーバ４に対して行う。すなわち、支払代行処理部１３４は、集金金額１００６万円（＝１０００万円＋６万円）の回収依頼をカード会社サーバ４に対して行う。これにより、カード会社サーバ４は、集金金額１００６万円を支払代行口座６１に振り込む処理を金融機関サーバ６に対して行う。これにより、支払代行口座６１に集金金額１００６万円がカード会社から振り込まれる。

また、カード会社サーバ４は、クレジット決済により定められた後日の引き落とし期日に、バイヤ口座６２（Ａ社の口座）から集金金額１００６万円を引き落とす処理を金融機関サーバ６に対して行う。これにより、後日の引き落とし日に、バイヤ口座６２（Ａ社の口座）から集金金額１００６万円が引き落とされる（回収される）。

次に、支払代行処理部１３４は、サプライヤ精算処理日になったか否かを判定する（ステップＳ３０７）。支払代行処理部１３４は、サプライヤへの入金期日に入金するためのサプライヤ精算処理日になったか否かを判定し、サプライヤ精算処理日である場合（ステップＳ３０７：ＹＥＳ）に処理をステップＳ３０８に進める。また、支払代行処理部１３４は、サプライヤ精算処理日でない場合（ステップＳ３０７：ＮＯ）に処理をステップＳ３０７に戻す。

ステップＳ３０８において、支払代行処理部１３４は、サプライヤへの振込処理を実行する。支払代行処理部１３４は、例えば、図１２（ｄ）に示すような、支払代行口座６１からサプライヤ口座６３（Ｂ社の口座）に支払金額９９５万円（＝１０００万円−4万円−１万円）を振り込むＦＢデータを生成する。支払代行処理部１３４は、生成したＦＢデータにより、サプライヤ（Ｂ社）に支払金額９９５万円を支払う支払い依頼を、カード会社サーバ４を経由して金融機関サーバ６に対して行う。これにより、支払代行口座６１からサプライヤ口座６３（Ｂ社の口座）に支払金額９９５万円が振り込まれる。ステップＳ３０８の処理後に、支払代行処理部１３４は、支払代行処理を終了する。

なお、上述したバイヤ口座６２（Ａ社の口座）から集金金額１００６万円が引き落とされる（回収される）処理は、ステップＳ３０８による支払代行口座６１からサプライヤ口座６３（Ｂ社の口座）に支払金額９９５万円が振り込まれる処理よりも後日に実行される。

なお、上述した処理では、支払代行処理部１３４は、ＦＢデータを利用して、支払代行口座６１からサプライヤ口座６３（Ｂ社の口座）に支払金額を振り込む処理を行っているが、サプライヤ（Ｂ社）がカード会社の加盟店である場合には、クレジット決済を利用して支払金額を振り込むようにしてもよい。
また、上述した処理では、支払代行処理部１３４は、ＦＢデータにより、サプライヤ（Ｂ社）に支払金額９９５万円を支払う支払い依頼を、カード会社サーバ４を経由して行う一例を説明したが、金融機関サーバ６に直接依頼するようにしてもよい。

以上説明したように、本実施形態による支払代行サーバ１（支払代行装置）は、申請取得部１３３と、支払代行処理部１３４とを備える。申請取得部１３３は、サプライヤ（売り手）とバイヤ（買い手）との間の売買契約を示す売買契約情報を含む支払代行申請であって、バイヤからの支払い代行の申請を示す支払代行申請を取得する。支払代行処理部１３４は、申請取得部１３３が取得した支払代行申請に応じて、売買契約に対応した支払金額をサプライヤに立替えて支払をする立替払い処理を実行し、支払代行申請を取得後の所定の期日に、売買契約に対応した集金金額をバイヤ口座６２（バイヤの口座）から回収する回収処理を実行する。

これにより、本実施形態による支払代行サーバ１は、売買契約に基づいてバイヤからの依頼により支払代行を行うため、例えば、資金決済法による貸金又は資金移動と見なされることを回避することができる。そのため、本実施形態による支払代行サーバ１は、１回の送金上限額が１００万円を超える取引に対応することができ、取引金額の制限を広げることができる。よって、本実施形態による支払代行サーバ１は、バイヤ側からの支払依頼により後支払いでの決済を実現することができ、企業間のカード決済取引の利用を増加させることができる。

また、本実施形態では、申請取得部１３３は、企業間の電子商取引サービスを提供する取引処理サーバ５（取引処理装置）から取得されたＦＢデータ（ファームバンキングデータ）を売買契約情報として含む支払代行申請を、バイヤの端末であるバイヤ端末２（買手側端末）から取得する。支払代行処理部１３４は、ＦＢデータが示す売買契約に対応した立替払い処理及び回収処理を実行する。
これにより、本実施形態による支払代行サーバ１は、取引処理サーバ５から取得されたＦＢデータにより容易に支払代行と売買契約とを紐付けることが可能になり、利便性を向上しつつ、取引金額の制限を広げることができる。

また、本実施形態では、支払代行処理部１３４は、決済カードによるカード決済を行うカード会社の加盟店に相当する仮想加盟店として機能し、回収処理において、仮想加盟店として、カード会社を経由してカード決済を用いて、集金金額をバイヤ口座６２から回収する処理を実行する。
これにより、本実施形態による支払代行サーバ１は、例えば、サプライヤが加盟店に加盟していない場合であっても、適切に支払代行に対応することができる。すなわち、本実施形態による支払代行サーバ１では、加盟店に加盟していないサプライヤに取引相手を広げることができ、企業間のカード決済取引の利用を増加させることができる。

また、本実施形態では、決済カードは、クレジットカードであり、支払代行処理部１３４は、クレジットカードによるカード決済を利用して、回収処理を実行する。
これにより、本実施形態による支払代行サーバ１は、バイヤの与信判断をクレジットカードによるカード決済の仕組みで行うことができるため、バイヤの与信判断を容易に行うことが可能になる。

また、本実施形態では、支払代行処理部１３４は、立替払い処理において、カード会社に対して、支払金額をサプライヤ口座６３（サプライヤの口座）に立替えて支払う処理依頼を行う。
これにより、本実施形態による支払代行サーバ１は、支払金額のサプライヤへの支払いに対してもカード会社を利用できるため、利便性を向上させることができる。

また、本実施形態では、支払代行処理部１３４は、売買契約の取引金額に応じた決済手数料と取引金額とに基づいて、集金金額を算出する。
これにより、本実施形態による支払代行サーバ１は、バイヤが決済手数料を負担することが可能になるため、企業間取引の幅を広げることができる。

また、本実施形態による支払代行サーバ１は、決済手数料をバイヤ負担分（買い手負担分）とサプライヤ負担分（売り手負担分）とに分配して設定する手数料分配部１３６を備える。支払代行処理部１３４は、立替払い処理において、取引金額からサプライヤ負担分を減額した支払金額をサプライヤ口座６３に振り込む処理を実行し、回収処理において、取引金額にバイヤ負担分を加算した集金金額をバイヤ口座６２から回収する処理を実行する。
これにより、本実施形態による支払代行サーバ１は、バイヤとサプライヤとの間で決済手数料を柔軟に設定することが可能になり、企業間取引の幅をさらに広げることができる。

また、本実施形態による支払代行サーバ１は、立替払い処理によって、サプライヤに支払われる入金期日の変更に応じて、サプライヤに対して入金手数料（例えば、早期入金手数料）を設定する入金手数料設定部１３７を備える。支払代行処理部１３４は、入金期日が変更された場合に、立替払い処理において、売買契約の取引金額と入金手数料とに基づいて算出された支払金額を、変更された入金期日にサプライヤ口座６３に振り込む処理を実行する。
これにより、本実施形態による支払代行サーバ１は、入金期日の変更に応じて、サプライヤに対して入金手数料（例えば、早期入金手数料）を設定することができる。本実施形態による支払代行サーバ１は、サプライヤが、入金期日を柔軟に指定することができ、入金期日を指定する選択肢が増えるため、さらに利便性を向上させることができる。

また、本実施形態では、入金手数料設定部１３７は、入金期日が前倒しされた場合に、前倒しされた日数に応じて、早期入金手数料を入金手数料として設定する。支払代行処理部１３４は、入金期日が前倒しされた場合に、立替払い処理において、取引金額から早期入金手数料を減額した支払金額を、サプライヤ口座６３に振り込む処理を実行する。
これにより、本実施形態による支払代行サーバ１では、サプライヤは、早期入金手数料を支払うことで、支払金額を早期に得ることができる。そのため、本実施形態による支払代行サーバ１は、さらに利便性を向上させることができる。

また、本実施形態による支払代行サーバ１は、取引金額と、決済手数料を示す手数料情報とを対応付けて記憶する決済手数料記憶部１２６から、取引金額に対応する手数料情報を取得し、当該手数料情報に基づいて決済手数料を設定する決済手数料設定部１３５を備える。手数料分配部１３６は、バイヤの端末を示すバイヤ端末２（買手側端末）から取得した分配情報に基づいて、決済手数料を、バイヤ負担分とサプライヤ負担分とに分配して設定する。また、手数料情報は、決済手数料の金額値、又は取引金額に対する決済手数料の割合である。
これにより、本実施形態による支払代行サーバ１は、簡易な手法により、決済手数料と、バイヤ負担分及びサプライヤ負担分を適切に設定することができる。

また、本実施形態による決済システム１００は、企業間の電子商取引サービスを提供する取引処理サーバ５（取引処理装置）と、支払代行サーバ１とを備える。支払代行サーバ１は、申請取得部１３３と、支払代行処理部１３４とを備える。申請取得部１３３は、取引処理サーバ５によって契約されたサプライヤとバイヤとの間の売買契約を示す売買契約情報を含む支払代行申請であって、バイヤからの支払い代行の申請を示す支払代行申請を取得する。支払代行処理部１３４は、申請取得部１３３が取得した支払代行申請に応じて、売買契約に対応した支払金額をサプライヤに立替えて支払をする立替払い処理を実行し、支払代行申請を取得後の所定の期日に、売買契約に対応した集金金額をバイヤ口座６２から回収する回収処理を実行する。
これにより、本実施形態による決済システム１００は、上述した支払代行サーバ１と同様の効果を奏し、バイヤ側からの支払依頼により後支払いでの決済を実現することができ、企業間のカード決済取引の利用を増加させることができる。

また、本実施形態による決済方法は、申請取得ステップと、支払代行処理ステップとを含む。申請取得ステップにおいて、申請取得部１３３が、サプライヤとバイヤとの間の売買契約を示す売買契約情報を含む支払代行申請であって、バイヤからの支払い代行の申請を示す支払代行申請を取得する。支払代行処理ステップにおいて、支払代行処理部１３４が、申請取得ステップによって取得された支払代行申請に応じて、売買契約に対応した支払金額をサプライヤに立替えて支払をする立替払い処理を実行し、支払代行申請を取得後の所定の期日に、売買契約に対応した集金金額をバイヤ口座６２から回収する回収処理を実行する。
これにより、本実施形態による決済方法は、上述した支払代行サーバ１と同様の効果を奏し、バイヤ側からの支払依頼により後支払いでの決済を実現することができ、企業間のカード決済取引の利用を増加させることができる。

［第２の実施形態］
次に、図面を参照して、第２の実施形態による支払代行サーバ１ａ及び決済システム１００ａについて説明する。

図１３は、本実施形態による決済システム１００ａの一例を示すブロック図である。
この図に示すように、本実施形態による決済システム１００ａは、支払代行サーバ１ａと、バイヤ端末２と、サプライヤ端末３と、カード会社サーバ４と、取引処理サーバ５とを備えている。支払代行サーバ１ａと、バイヤ端末２と、サプライヤ端末３と、カード会社サーバ４と、取引処理サーバ５とは、ネットワークＮＷ１を介して、互いに接続可能である。

なお、この図において、図１に示す構成と同一の構成については同一の符号を付し、その説明を省略する。
本実施形態では、取引処理サーバ５と連携して、売買契約情報を取引処理サーバ５から取得する変形例について説明する。

支払代行サーバ１ａ（支払代行装置の一例）は、バイヤとサプライヤとの間の売買契約に基づく支払代行を行う支払代行サービスを提供する。また、支払代行サーバ１ａは、クレジットカードを利用したカード決済を利用して支払代行を行う。また、支払代行サーバ１ａは、ＮＷ通信部１１と、記憶部１２と、制御部１３ａとを備えている。

制御部１３ａは、例えば、ＣＰＵなどを含むプロセッサであり、支払代行サーバ１ａを統括的に制御する。制御部１３ａは、売買契約情報の取得方法が異なる点を除いて、基本的な機能は、第１の実施形態と同様である。
制御部１３ａは、バイヤ登録部１３１と、サプライヤ登録部１３２と、申請取得部１３３ａと、支払代行処理部１３４と、決済手数料設定部１３５と、手数料分配部１３６と、入金手数料設定部１３７とを備える。

申請取得部１３３ａは、企業間の電子商取引サービスを提供する取引処理サーバ５から取得されたサプライヤとバイヤとの間の取引情報を売買契約情報として含む支払代行申請を取得する。なお、申請取得部１３３ａは、売買契約情報として含む支払代行申請を取引処理サーバ５から直接取得するようにしてもよいし、支払代行申請の大部分を、第１の実施形態と同様に、バイヤ端末２から取得し、取引処理サーバ５から売買契約情報を取得するようにしてもよい。

また、本実施形態による支払代行処理部１３４の機能は、第１の実施形態と同様であるため、ここではその説明を省略する。

次に、図面を参照して、本実施形態による決済システム１００ａの動作について説明する。
図１４は、本実施形態による決済システム１００ａの支払代行処理の動作の一例を説明する図である。

図１４に示すように、バイヤ端末２は、まず、取引処理サーバ５を利用して、バイヤとサプライヤとの間で、商品等の取引契約（売買契約）を行う（ステップＳ４０１）。
次に、バイヤ端末２は、取引情報（売買契約情報）を取引処理サーバ５から支払代行サーバ１ａに転送させる。（ステップＳ４０２）。

次に、バイヤ端末２は、支払代行申請及び承認を支払代行サーバ１ａに対して行う（ステップＳ４０３）。このステップＳ４０３の処理は、ＦＢデータを用いない点を除いて、図７に示すステップＳ１０３の処理と同様であるため、ここではその説明を省略する。

また、続く、ステップＳ４０４からステップＳ４０８までの処理は、図７に示すステップＳ１０４からステップＳ１０８までの処理と同様であるため、ここではその説明を省略する。

なお、本実施形態の支払代行サーバ１ａによる支払代行申請の受け付け処理は、図８に示すステップＳ２０１の処理が、ＦＢデータから、取引処理サーバ５から取得された取引情報（売買契約情報）に置き換わる点を除いて、図８に示す処理と同様であるためここではその説明を省略する。
また、本実施形態による支払代行サーバ１ａの支払代行処理の詳細については、上述した図１１及び図１２に示す第１の実施形態の処理と同様であるため、ここではその説明を省略する。

以上説明したように、本実施形態では、申請取得部１３３ａは、企業間の電子商取引サービスを提供する取引処理サーバ５から取得されたサプライヤとバイヤとの間の取引情報を売買契約情報として含む支払代行申請を取得する。
これにより、本実施形態による支払代行サーバ１ａ及び決済システム１００ａは、取引処理サーバ５を利用して、さらに容易に支払代行と売買契約とを紐付けることが可能になり、利便性を向上しつつ、取引金額の制限を広げることができる。

［第３の実施形態］
次に、図面を参照して、第３の実施形態による支払代行サーバ１ｂ及び決済システム１００ｂについて説明する。

図１５は、本実施形態による決済システム１００ｂの一例を示すブロック図である。
この図に示すように、本実施形態による決済システム１００ｂは、支払代行サーバ１ｂと、バイヤ端末２と、サプライヤ端末３と、カード会社サーバ４とを備えている。支払代行サーバ１ｂと、バイヤ端末２と、サプライヤ端末３と、カード会社サーバ４とは、ネットワークＮＷ１を介して、互いに接続可能である。なお、本実施形態では、決済システム１００ｂが、取引処理サーバ５を備えていない点が、第１の実施形態と異なる。

なお、この図において、図１に示す構成と同一の構成については同一の符号を付し、その説明を省略する。
本実施形態では、上述した取引処理サーバ５を用いずに、売買契約情報を含む支払代行申請を取得する変形例について説明する。

支払代行サーバ１ｂ（支払代行装置の一例）は、バイヤとサプライヤとの間の売買契約に基づく支払代行を行う支払代行サービスを提供する。また、支払代行サーバ１ｂは、クレジットカードを利用したカード決済を利用して支払代行を行う。また、支払代行サーバ１ｂは、ＮＷ通信部１１と、記憶部１２と、制御部１３ｂとを備えている。

制御部１３ｂは、例えば、ＣＰＵなどを含むプロセッサであり、支払代行サーバ１ｂを統括的に制御する。制御部１３ｂは、売買契約情報の取得方法が異なる点を除いて、基本的な機能は、第１の実施形態と同様である。
制御部１３ｂは、バイヤ登録部１３１と、サプライヤ登録部１３２と、申請取得部１３３ｂと、支払代行処理部１３４と、決済手数料設定部１３５と、手数料分配部１３６と、入金手数料設定部１３７とを備える。

申請取得部１３３ｂは、売買契約を示す画像データを売買契約情報として含む支払代行申請を、バイヤ端末２から取得する。ここで、画像データは、例えば、売買の契約書、請求書、見積書、発注伝票などの売買契約の証拠に成り得る文書や書類を撮像（又はスキャン）した画像データである。

なお、本実施形態では、申請取得部１３３ｂは、支払代行申請に含まれる各種情報を、バイヤ端末２からバイヤによる入力部２１の手入力（マニュアル入力）により取得する。
また、本実施形態の支払代行処理部１３４は、画像データが示す売買契約に対応した立替払い処理及び回収処理を実行する。支払代行処理部１３４のその他の機能は、第１の実施形態と同様であるため、ここではその説明を省略する。

次に、図面を参照して、本実施形態による決済システム１００ｂの動作について説明する。
図１６は、本実施形態による決済システム１００ｂの支払代行処理の動作の一例を説明する図である。

図１６に示すように、バイヤ端末２は、まず、バイヤとサプライヤとの間で、商品等の取引契約（売買契約）を行う（ステップＳ５０１）。ここでは、取引処理サーバ５を用いないものとする。

次に、バイヤ端末２は、支払代行申請、及び承認を支払代行サーバ１に対して行う（ステップＳ５０２）。バイヤ端末２は、バイヤの入力部２１の操作によって、支払代行サーバ１にログインして、支払代行申請に必要な各種情報を送付するとともに、売買契約情報として、売買契約の画像データを支払代行サーバ１に送付して、支払代行申請を行う。また、バイヤ端末２は、支払代行申請の承認を行う。なお、バイヤ端末２は、決済手数料の分担などを設定して、支払代行申請を行う。

また、続く、ステップＳ５０３からステップＳ５０７までの処理は、図７に示すステップＳ１０４からステップＳ１０８までの処理と同様であるため、ここではその説明を省略する。

なお、本実施形態の支払代行サーバ１ｂによる支払代行申請の受け付け処理は、図８における取得情報をバイヤの入力部２１の操作によって取得する点を除いて、図８に示す処理と同様であるためここではその説明を省略する。
また、本実施形態による支払代行サーバ１ｂの支払代行処理の詳細については、上述した図１１及び図１２に示す第１の実施形態の処理と同様であるため、ここではその説明を省略する。

以上説明したように、本実施形態では、申請取得部１３３ｂは、売買契約を示す画像データを売買契約情報として含む支払代行申請を、バイヤの端末であるバイヤ端末２から取得する。支払代行処理部１３４は、画像データが示す売買契約に対応した立替払い処理及び回収処理を実行する。
これにより、本実施形態による支払代行サーバ１ｂ及び決済システム１００ｂは、取引処理サーバ５を利用せずに、容易に支払代行と売買契約とを紐付けることが可能になり、利便性を向上しつつ、取引金額の制限を広げることができる。

［第４の実施形態］
次に、図面を参照して、第４の実施形態による支払代行サーバ１ｃ及び決済システム１００ｃについて説明する。

図１７は、本実施形態による決済システム１００ｃの一例を示すブロック図である。
この図に示すように、本実施形態による決済システム１００ｃは、支払代行サーバ１ｃと、バイヤ端末２と、サプライヤ端末３と、カード会社サーバ４と、取引処理サーバ５とを備えている。支払代行サーバ１ｃと、バイヤ端末２と、サプライヤ端末３と、カード会社サーバ４と、取引処理サーバ５とは、ネットワークＮＷ１を介して、互いに接続可能である。

なお、この図において、図１に示す構成と同一の構成については同一の符号を付し、その説明を省略する。
本実施形態では、サプライヤから支払代行申請を行う場合の変形例について説明する。

支払代行サーバ１ｃ（支払代行装置の一例）は、サプライヤからの依頼により、バイヤからサプライヤへの支払の代行を行う支払代行サービスを提供する。また、支払代行サーバ１ｃは、クレジットカードを利用したカード決済を利用して支払代行を行う。また、支払代行サーバ１ｃは、ＮＷ通信部１１と、記憶部１２と、制御部１３ｃとを備えている。

制御部１３ｃは、例えば、ＣＰＵなどを含むプロセッサであり、支払代行サーバ１ｃを統括的に制御する。制御部１３ｃは、支払代行申請の取得方法が異なる点を除いて、基本的な機能は、第１の実施形態と同様である。
制御部１３ｃは、バイヤ登録部１３１と、サプライヤ登録部１３２と、申請取得部１３３ｃと、支払代行処理部１３４と、決済手数料設定部１３５と、手数料分配部１３６と、入金手数料設定部１３７とを備える。

申請取得部１３３ｃは、サプライヤの依頼に基づいて、企業間の電子商取引サービスを提供する取引処理サーバ５から取得されたサプライヤとバイヤとの間の取引情報を売買契約情報として含む支払代行申請を取得する。
また、本実施形態による支払代行処理部１３４の機能は、第１の実施形態と同様であるため、ここではその説明を省略する。

次に、図面を参照して、本実施形態による決済システム１００ｃの動作について説明する。
図１８は、本実施形態による決済システム１００ｃの支払代行処理の動作の一例を説明する図である。

図１８に示すように、バイヤ端末２は、まず、取引処理サーバ５を利用して、バイヤとサプライヤとの間で、商品等の取引契約（売買契約）を行う（ステップＳ６０１）。
次に、サプライヤ端末３は、売買契約に基づく決済処理を支払代行にて行う支払代行申請を、取引処理サーバ５から支払代行サーバ１ｃに転送させる。（ステップＳ６０２）。これにより、支払代行サーバ１ｃは、支払代行申請に基づく、支払代行処理を実行する。

続く、ステップＳ６０３からステップＳ６０６までの処理は、図７に示すステップＳ１０４からステップＳ１０８までの処理と同様であるため、ここではその説明を省略する。
なお、本実施形態による支払代行サーバ１ｃの支払代行処理の詳細については、上述した図１１及び図１２に示す第１の実施形態の処理と同様であるため、ここではその説明を省略する。

なお、本実施形態による支払代行サーバ１ｃは、申請取得部１３３ｃと、支払代行処理部１３４とを備える。申請取得部１３３ｃは、サプライヤとバイヤとの間の取引の支払い代行を申請する支払代行申請を取得する。支払代行処理部１３４は、申請取得部１３３が取得した支払代行申請に応じて、支払代行申請に含まれる取引金額に対応した支払金額をサプライヤに立替えて支払をする立替払い処理を実行し、取引金額に対応した集金金額を、決済カードによるカード決済を利用して、バイヤ口座６２から回収する回収処理を実行する。さらに、支払代行処理部１３４は、カード決済を行うカード会社の加盟店に相当する仮想加盟店として機能し、回収処理において、仮想加盟店としてカード決済を利用して、集金金額をバイヤ口座６２から回収する処理を実行する。

これにより、本実施形態による支払代行サーバ１ｃは、例えば、サプライヤが加盟店に加盟していない場合であっても、適切に支払代行に対応することができる。すなわち、本実施形態による支払代行サーバ１ｃでは、加盟店に加盟していないサプライヤに取引相手を広げることができ、企業間のカード決済取引の利用を増加させることができる。

また、本実施形態では、申請取得部１３３ｃは、企業間の電子商取引サービスを提供する取引処理サーバ５から支払代行申請を取得する。
これにより、本実施形態による支払代行サーバ１ｃでは、取引処理サーバ５を利用して支払代行申請を行うことができるため、利便性を向上させることができる。

また、本実施形態による決済システム１００ｃは、企業間の電子商取引サービスを提供し、サプライヤとバイヤとの間の取引の支払い代行を申請する支払代行申請を生成する取引処理サーバ５と、上述した支払代行サーバ１ｃとを備える。
これにより、本実施形態による決済システム１００ｃは、支払代行サーバ１ｃと同様の効果を奏し、企業間のカード決済取引の利用を増加させることができる。

また、本実施形態による決済方法は、申請取得ステップと、支払代行処理ステップとを含む。申請取得ステップにおいて、申請取得部１３３ｃが、サプライヤとバイヤとの間の取引の支払い代行を申請する支払代行申請を取得する。支払代行処理ステップにおいて、支払代行処理部１３４が、カード決済を行うカード会社の加盟店に相当する仮想加盟店として機能し、回収処理において、仮想加盟店としてカード決済を利用して、集金金額をバイヤ口座６２から回収する処理を実行するようにしてもよい。
これにより、本実施形態による決済方法は、支払代行サーバ１ｃと同様の効果を奏し、企業間のカード決済取引の利用を増加させることができる。

また、本実施形態による支払代行サーバ１ｃは、申請取得部１３３ｃと、手数料分配部１３６と、支払代行処理部１３４とを備える。手数料分配部１３６は、支払代行申請に含まれる取引金額に応じた決済手数料を、バイヤ負担分とサプライヤ負担分とに分配して設定する。支払代行処理部１３４は、申請取得部１３３ｃが取得した支払代行申請に応じて、バイヤからサプライヤへの取引金額の支払いを代行する支払代行処理部１３４であって、取引金額からサプライヤ負担分を減額した支払金額をサプライヤに振り込む立替払い処理を実行し、取引金額にバイヤ負担分を加算した集金金額をバイヤ口座６２から回収する回収処理を実行する。
これにより、本実施形態による支払代行サーバ１ｃは、バイヤとサプライヤとの間で決済手数料を柔軟に設定することが可能になり、企業間取引の幅をさらに広げることができる。

また、本実施形態による決済方法は、申請取得ステップと、手数料分配ステップと、支払代行処理ステップとを含む。手数料分配ステップにおいて、手数料分配部１３６が、支払代行申請に含まれる取引金額に応じた決済手数料を、バイヤ負担分とサプライヤ負担分とに分配して設定する。支払代行処理ステップにおいて、支払代行処理部１３４が、申請取得ステップによって取得された支払代行申請に応じて、バイヤからサプライヤへの取引金額の支払いを代行し、取引金額からサプライヤ負担分を減額した支払金額をサプライヤに振り込む立替払い処理を実行し、取引金額にバイヤ負担分を加算した集金金額をバイヤ口座６２から回収する回収処理を実行する。
これにより、本実施形態による決済方法は、上述した支払代行サーバ１ｃと同様の効果を奏し、バイヤとサプライヤとの間で決済手数料を柔軟に設定することが可能になり、企業間取引の幅をさらに広げることができる。

なお、本発明は、上記の各実施形態に限定されるものではなく、本発明の趣旨を逸脱しない範囲で変更可能である。
例えば、上記の各実施形態において、支払代行サーバ１（１ａ〜１ｃ）は、取引処理サーバ５とは異なる装置として説明したが、支払代行サーバ１（１ａ〜１ｃ）は、取引処理サーバ５の機能を含むようにしてもよい。

また、上記の各実施形態において、支払代行サーバ１（１ａ〜１ｃ）は、１つの装置として説明したが、複数の装置により構成されてもよい。また、支払代行サーバ１（１ａ〜１ｃ）が、記憶部１２を備える例を説明したが、記憶部１２の一部又は全部は、支払代行サーバ１（１ａ〜１ｃ）の外部に備えるようにしてもよい。例えば、記憶部１２の一部又は全部は、ネットワークＮＷ１に接続された外部記憶装置であってもよい。

また、上記の第１〜第３の実施形態において、支払代行サーバ１（１ａ、１ｂ）が、異なる手法により、売買契約情報を含む支払代行申請を取得する例を説明したが、これらの複数の手法により支払代行申請を備え、これらの複数の手法を切り替えて使用するようにしてもよい。

また、上記の各実施形態において、支払代行処理部１３４は、サプライヤへの振込処理を、ＦＢデータを用いて行う例を説明したが、これに限定されるものではなく、例えば、クレジット決済を用いて、サプライヤへの振込処理を行ってもよい。
また、上記の各実施形態において、決済カードの一例として、クレジットカードを用いる例を説明したが、これに限定されるものではなく、他の決済カード、又は、他の振込や送金等に利用される仮想決済番号等を適用するようにしてもよい。

また、上記の各実施形態において、サプライヤへの支払いは、サプライヤ口座６３に支払金額を振り込む例を説明したが、電子マネーや仮想通貨などで、サプライヤのＩＣカードや端末、ハードウェアウォレットなどに支払金額を直接振り込む、等、サプライヤ口座６３以外に振り込むようにしてもよい。
また、上記の各実施形態において、加盟店には、カード会社との契約、その他の契約、又は申込み形態も含まれ、仮想加盟店は、カード会社と加盟店契約を結ぶ形態でなくてもよい。

なお、上述した決済システム１００（１００ａ〜１００ｃ）及び支払代行サーバ１（１ａ〜１ｃ）が備える各構成は、内部に、コンピュータシステムを有している。そして、上述した決済システム１００（１００ａ〜１００ｃ）及び支払代行サーバ１（１ａ〜１ｃ）が備える各構成の機能を実現するためのプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することにより上述した決済システム１００（１００ａ〜１００ｃ）及び支払代行サーバ１（１ａ〜１ｃ）が備える各構成における処理を行ってもよい。ここで、「記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行する」とは、コンピュータシステムにプログラムをインストールすることを含む。ここでいう「コンピュータシステム」とは、ＯＳや周辺機器等のハードウェアを含むものとする。
また、「コンピュータシステム」は、インターネットやＷＡＮ、ＬＡＮ、専用回線等の通信回線を含むネットワークを介して接続された複数のコンピュータ装置を含んでもよい。また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＣＤ−ＲＯＭ等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。このように、プログラムを記憶した記録媒体は、ＣＤ−ＲＯＭ等の非一過性の記録媒体であってもよい。

また、記録媒体には、当該プログラムを配信するために配信サーバからアクセス可能な内部又は外部に設けられた記録媒体も含まれる。なお、プログラムを複数に分割し、それぞれ異なるタイミングでダウンロードした後に決済システム１００（１００ａ〜１００ｃ）及び支払代行サーバ１（１ａ〜１ｃ）が備える各構成で合体される構成や、分割されたプログラムのそれぞれを配信する配信サーバが異なっていてもよい。さらに「コンピュータ読み取り可能な記録媒体」とは、ネットワークを介してプログラムが送信された場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリ（ＲＡＭ）のように、一定時間プログラムを保持しているものも含むものとする。また、上記プログラムは、上述した機能の一部を実現するためのものであってもよい。さらに、上述した機能をコンピュータシステムに既に記録されているプログラムとの組み合わせで実現できるもの、いわゆる差分ファイル（差分プログラム）であってもよい。

また、上述した機能の一部又は全部を、ＬＳＩ（Large Scale Integration）等の集積回路として実現してもよい。上述した各機能は個別にプロセッサ化してもよいし、一部、又は全部を集積してプロセッサ化してもよい。また、集積回路化の手法はＬＳＩに限らず専用回路、又は汎用プロセッサで実現してもよい。また、半導体技術の進歩によりＬＳＩに代替する集積回路化の技術が出現した場合、当該技術による集積回路を用いてもよい。

１、１ａ、１ｂ、１ｃ 支払代行サーバ
２ バイヤ端末
３ サプライヤ端末
４ カード会社サーバ
５ 取引処理サーバ
６ 金融機関サーバ
１１ ＮＷ通信部
１２ 記憶部
１３、１３ａ、１３ｂ、１３ｃ 制御部
２１、３１ 入力部
２２、３２ 表示部
４１ カード管理記憶部
５１ 売買契約記憶部
６１ 支払代行口座
６２ バイヤ口座
６３ サプライヤ口座
１００、１００ａ、１００ｂ、１００ｃ 決済システム
１２１ アカウント記憶部
１２２ サプライヤ情報記憶部
１２３ バイヤ情報記憶部
１２４ 取引情報記憶部
１２５ 利用料記憶部
１２６ 決済手数料記憶部
１２７ 月額利用料記憶部
１２８ 早期入金手数料記憶部
１３１ バイヤ登録部
１３２ サプライヤ登録部
１３３、１３３ａ、１３３ｂ、１３３ｃ 申請取得部
１３４ 支払代行処理部
１３５ 決済手数料設定部
１３６ 手数料分配部
１３７ 入金手数料設定部

Claims (9)

1. 売り手と買い手との間の取引の支払い代行を申請する支払代行申請を取得する申請取得部と、
   前記支払代行申請に含まれる取引金額に応じた決済手数料を、買い手負担分と売り手負担分とに分配して設定する手数料分配部と、
   前記申請取得部が取得した前記支払代行申請に応じて、前記買い手から前記売り手への前記取引金額の支払いを代行する支払代行処理部であって、前記取引金額から前記売り手負担分を減額した支払金額を前記売り手の口座に振り込む立替払い処理を実行し、前記取引金額に前記買い手負担分を加算した集金金額を前記買い手の口座から回収する回収処理を実行する支払代行処理部と
   を備えることを特徴とする支払代行装置。
2. 前記取引金額と、前記決済手数料を示す手数料情報とを対応付けて記憶する決済手数料記憶部から、前記取引金額に対応する前記手数料情報を取得し、当該手数料情報に基づいて前記決済手数料を設定する決済手数料設定部を備え、
   前記手数料分配部は、
   前記買い手の端末を示す買手側端末から取得した分配情報に基づいて、前記決済手数料設定部が設定した前記決済手数料を、前記買い手負担分と前記売り手負担分とに分配して設定する
   ことを特徴とする請求項１に記載の支払代行装置。
3. 前記手数料情報は、前記決済手数料の金額値、又は前記取引金額に対する前記決済手数料の割合である
   ことを特徴とする請求項２に記載の支払代行装置。
4. 前記立替払い処理によって、前記売り手に支払われる入金期日の変更に応じて、前記売り手に対して入金手数料を設定する入金手数料設定部を備え、
   前記支払代行処理部は、前記入金期日が変更された場合に、前記立替払い処理において、前記取引金額と、前記売り手負担分及び前記入金手数料とに基づいて算出された前記支払金額を、変更された前記入金期日に前記売り手の口座に振り込む処理を実行する
   ことを特徴とする請求項１から請求項３のいずれか一項に記載の支払代行装置。
5. 前記支払代行処理部は、前記回収処理において、決済カードによるカード決済を利用して、前記買い手の口座から前記集金金額を回収する処理を実行し、前記立替払い処理において、前記カード決済を行うカード会社に対して、前記支払金額を前記売り手に立替えて支払う処理依頼を行う
   ことを特徴とする請求項１から請求項４のいずれか一項に記載の支払代行装置。
6. 前記決済カードは、クレジットカードであり、
   前記支払代行処理部は、
   前記クレジットカードによるカード決済を利用して、前記回収処理を実行する
   ことを特徴とする請求項５に記載の支払代行装置。
7. 企業間の電子商取引サービスを提供し、売り手と買い手との間の取引の支払い代行を申請する支払代行申請を生成する取引処理装置と、支払代行装置とを備え、
   前記支払代行装置は、
   売り手と買い手との間の取引の支払い代行を申請する支払代行申請を取得する申請取得部と、
   前記支払代行申請に含まれる取引金額に応じた決済手数料を、買い手負担分と売り手負担分とに分配して設定する手数料分配部と、
   前記申請取得部が取得した前記支払代行申請に応じて、前記買い手から前記売り手への前記取引金額の支払いを代行する支払代行処理部であって、前記取引金額から前記売り手負担分を減額した支払金額を前記売り手の口座に振り込む立替払い処理を実行し、前記取引金額に前記買い手負担分を加算した集金金額を前記買い手の口座から回収する回収処理を実行する支払代行処理部と
   を備えることを特徴とする決済システム。
8. 申請取得部が、売り手と買い手との間の取引の支払い代行を申請する支払代行申請を取得する申請取得ステップと、
   手数料分配部が、前記支払代行申請に含まれる取引金額に応じた決済手数料を、買い手負担分と売り手負担分とに分配して設定する手数料分配ステップと、
   支払代行処理部が、前記申請取得ステップによって取得された前記支払代行申請に応じて、前記買い手から前記売り手への前記取引金額の支払いを代行する支払代行処理ステップであって、前記取引金額から前記売り手負担分を減額した支払金額を前記売り手の口座に振り込む立替払い処理を実行し、前記取引金額に前記買い手負担分を加算した集金金額を前記買い手の口座から回収する回収処理を実行する支払代行処理ステップと
   を含むことを特徴とする決済方法。
9. コンピュータに、
   売り手と買い手との間の取引の支払い代行を申請する支払代行申請を取得する申請取得ステップと、
   前記支払代行申請に含まれる取引金額に応じた決済手数料を、買い手負担分と売り手負担分とに分配して設定する手数料分配ステップと、
   前記申請取得ステップによって取得された前記支払代行申請に応じて、前記買い手から前記売り手への前記取引金額の支払いを代行する支払代行処理ステップであって、前記取引金額から前記売り手負担分を減額した支払金額を前記売り手の口座に振り込む立替払い処理を実行し、前記取引金額に前記買い手負担分を加算した集金金額を前記買い手の口座から回収する回収処理を実行する支払代行処理ステップと
   を実行させるためのプログラム。

Images