説明

自動化した支払い認証及び決済の方法及びシステム

本発明は、クレジットカード取得者及び/又は取引プロセッサに対する購入者/支払人又は供給者/受取人の代わりにEIPPサービスのサードパーティのサービスプロバイダが請求書品目名データ(レベルIIIデータ)による支払いカードの支払いの認証及び決済を開始することができるシステム及び方法を提供する。支払いの開始は、購入注文書に対して有効にされた予め承認した請求書若しくは注文確認、又は購入者/支払人の組織によって承認されるとともに支払いに対してスケジューリングされた請求書の提出に基づく。

【発明の詳細な説明】
【技術分野】
【0001】
この出願は、発明の名称が「統合された電子請求書提示及び支払いシステム及び方法」(System and Method for Integrated Electronic Invoice Presentment and Payment)である2003年6月18日に出願された米国特許出願第10/465394号に対する優先権を主張する、発明の名称が「自動化した支払い認証及び決済」(Automated Payment Authorization and Settlement)である2004年8月25日に出願された米国分割出願第60/604,215号に対する優先権を主張し、両出願は、参照によってここに組み込まれる。また、この出願は、発明の名称が「自動化された支払い認証及び決済」(Method and System For Automated Payment Authorization and Settlement)である2004年10月29日に出願された米国分割出願第60/623,656号に対する優先権も主張し、この出願の全体も、参照によってここに組み込まれる。
【背景技術】
【0002】
本発明は、自動化された支払い認証及び決済の方法及びシステムに関する。
【0003】
サードパーティのサービスプロバイダ(3PSPS)を用いることによって請求書送付及び支払いプロセスを自動化する試みがなされている。3PSPは、Ariba(登録商標)のような電子調達プロバイダ、Xign(登録商標)のような電子請求書・決済(EIPP)及びOracle(登録商標)のような企業資源計画(ERP)プロバイダを含む。これらの初期の3PSPの解決は、供給者/受取人/請求書作成機械の要求に焦点が当てられ、購入者/支払人/支払機の要求に十分に対処しなかった。例えば、多数の早期の3PSPの解決は、支払いの開始の効率的かつ有効な制御、決済の繰り延べ、購入者/支払人の金融システムでの銀行勘定調整及びこれらのかかる金融システムへの統合のような購入者/支払人/支払機の支払いに関する要求に十分に対処しなかった。
【0004】
また、現存する3PSPの解決は、企業間の支払いの手段としてクレジットカード、デビットカード、法人カード、購入カードのような支払いカードを一般的には用いていない。さらに、これら3PSPの解決は、支払いカードによる支払いに関連した支払い期間の使用又は支払いカードによる支払い前の購入者/支払人の請求書発行規則を有効にすることが許容されていない。
【0005】
さらに、現存する3PSPは、EPRシステムや買掛管理(A/P)システムのような組織の内部システムに支払いデータを自動的に統合することができない。したがって、組織は、請求書データにマニュアルで鍵をかけ、銀行勘定調整のために請求書データをカード取引に整合し、データを組織のERPシステム又はA/Pシステムにマニュアルで入力することが強いられる。このプロセスは、時間がかかるとともに人為的な誤りが生じる傾向にある。
【0006】
一部の現存する3PSPの解決は、金融電子データ交換(EDI)又は他の電子的な支払い技術を用いることができる。しかしながら、これらの支払方法は、内部システム及びプロセスに対するコストのかかる変更を含む著しいセットアップコストを要し、銀行取引における変更を必要とする。
【0007】
したがって、費用効果が高く、現存するプロセス及びシステムへの統合が簡単であり、有効な支払い及び金融記録の銀行勘定調整を許容する自動化されたEIPP方法及びシステムが必要とされる。
【0008】
米国特許出願第10/465,394号において、マスターカードは、あり得る支払方法として購入カードを利用する自動的な電子請求書提示及び支払いシステム及び方法を提供している。本発明は、従来のアプリケーションを向上する。本発明によれば、電子的な調達及び/又は請求書発行を行う3PSPによって、顧客は、マスターカードのクレジットカード口座における取引を自動的に決済することができ、これによって、顧客は、銀行の支払条件の下で購入注文(PO)又は請求書に基づく購入を行うことができる。支払人は、遅延した支払い期間と、発行銀行からの手数料を受け取る機会とから利益を得る。供給者は、(伝票処理のコストに対する)電子的な支払い受け取りと、ハードウェア又はソフトウェアに更に投資することなく(更に低い割引率を受け取るための)レベルIIIデータを渡す機会から利益を得る。金融機関及びそのプロセッサは、処理される多大な取引から利益を得る。取得期間及び取引プロセッサの例は、シティーバンク、ファーストデータ・コーポレーション、グローバルペイメント及びバンクオブアメリカである。
【発明の開示】
【0009】
本発明は、クレジットカード取得者及び/又は取引プロセッサに対する購入者/支払人又は供給者/受取人の代わりに3PSPが請求書品目名データ(レベルIIIデータ)による支払いカードの支払いの認証及び決済を開始することができるシステム及び方法を提供する。支払いの開始は、購入注文書に対して有効にされた予め承認した請求書若しくは注文確認、又は購入者/支払人の組織によって承認されるとともに支払いに対してスケジューリングされた請求書の提出に基づく。
【発明を実施するための最良の形態】
【0010】
図1及び3は、支払いカード取引の自動化した支払い認証及び決済用のシステムの例を示す。図1に示す実施の形態において、支払いが支払人によって開始され、それに対して、図3に示す実施の形態において、支払いが受取人によって開始される。図1及び3を参照すると、購入者/支払人100及び供給者/受取人130は、好適にはERPシステム110a及び130aをそれぞれ有する。ソフトウェアプロバイダ120を、調達サービス、請求サービス、提示サービス及び/又は支払いサービスを提供するEIPPシステム120aのような3PSPとする。例えば、ソフトウェアプロバイダ120を、マスターカードe−P3(登録商標)EIPPソリュージョンを提供するXign Corporation(登録商標)とすることができる。
【0011】
取得者/プロセッサ160を、支払いカード取引を処理する金融機関又は取引プロセッサとする。支払いネットワーク170を、マスターカード支払いネットワーク(登録商標)のような支払いカードネットワークとする。マーチャントサービス(MS)支払いゲートウェイ170aを、支払いカード取引の認証及び決済が好適に処理されるゲートウェイとする。発行銀行140を、支払いカードを購入者/支払人110に発行する銀行とする。MIS150を、発行銀行140の管理情報システムとする。図3のPOS装置310を、販売端末又は任意の同様な従来のシステムのポイントとし、それは、供給者/受取人130の位置又はその付近で金融口座データを許容し、報告動作、認証及び取引のロギングのために当該データを支払いネットワークに送信する。
【0012】
図2は、支払いが購入者/支払人110によって開始される支払いカード取引の自動化した支払いの認証及び決済を行う方法の一例を示すフローチャートである。図1及び2を参照すると、ステップ210において、購入者/支払人のERP110aは、請求書の支払いを承認し及びスケジューリングする。本実施の形態において、購入者/支払人のERP110aを、例えば、オラクル(登録商標)ペイアブルシステム(payable system)とする。ステップ220において、ソフトウェアプロバイダ120は、支払い認証及び決済のために、購入者/支払人のERP110aから支払いファイルを抽出し、支払いファイルを取得者/プロセッサ160に送信する。例えば、支払いファイルを、オラクルiPayment(登録商標)によるオラクルペイアブル金融システム又はマスターカードe−P3(登録商標)プロバイダにより購入者/支払人のERP110aから抽出することができる。
【0013】
支払いファイルは、マーチャントIDと、支払いカード口座情報と、ERP請求書の銀行勘定調整に用いられる独自の取引IDとを有し、請求書品目名データ(レベルIIIデータ)を有することができる。マーチャントIDを、供給者/受取人130の登録処理中に取得することができる。オラクルiPayment(登録商標)のようなソフトウェアプロバイダ120は、オラクルペイアブルのような購入者/支払人のERP110又はソフトウェアプロバイダ120の支払いインタフェース120aから支払いカード口座情報を取得することができる。
【0014】
ステップ230において、購入者/支払人110の支払いカードの支払い要求は、認証及び決済のためにマスターカード(登録商標)の支払いネットワークのような支払いネットワーク170に提供される。ステップ240において、支払いカード取引データは、支払いネットワーク170から発行銀行のMISアプリケーション150を通じて又は支払いネットワーク170から直接購入者/支払人110に供給される。好適には、支払いカード取引データは、支払いファイルからの独自の取引IDを有する(ステップ220参照)。
【0015】
ステップ250において、ソフトウェアプロバイダ120は、取得者/プロセッサ160によって提供される銀行取引の銀行勘定調整のために、独自の取引IDを有する支払い送金データを供給者/受取人130に提供する。例えば、支払い送金データを、銀行取引の銀行勘定調整のためにオラクルiPayment(登録商標)のようなe−P3(登録商標)プロバイダによって供給者/受取人130に提供される。最後に、ステップ260において、購入者/支払人110は、伝票発行サイクルの最後で発行銀行140との支払いカード取引を決済する。
【0016】
図4は、支払いが供給者/受取人130によって開始される支払いカード取引の自動化された支払い認証及び決済の方法の一例を示すフローチャートである。図3及び4を参照すると、ステップ410において、購入者/支払人のERP110aは、請求書の支払いを承認し及びスケジューリングする。ステップ420において、ソフトウェアプロバイダ120は、支払い認証及び決済のために、購入者/支払人のEPRシステム110aから支払いファイルを抽出し、(例えば、eメールによって)支払いファイルを供給者/受取人130に送信する。支払いファイルは、マーチャントIDと、支払いカード口座情報と、ERPの請求書の銀行勘定調整に用いられる独自の取引IDとを有し、請求書品目名データ(レベルIIIデータ)を有することもできる。マーチャントIDは、供給者/支払人130の登録処理中に取得される。ソフトウェアプロバイダ120は、購入者/支払人のERP100a又はソフトウェアプロバイダの支払いインタフェース120aから支払いカード口座情報を取得する。
【0017】
ステップ430において、供給者/受取人130は、認証及び決済のために支払いカード及び他の取引情報をPOS装置310を通じて取得者/プロセッサ160に提供する。取得者/プロセッサは、支払いネットワーク170を通じて認証及び決済情報を提供する。ステップ440において、ソフトウェアプロバイダ120は、整合のために、独自の取引IDを有する請求書品目名データを直接支払いネットワーク170に送信する。
【0018】
ステップ450において、支払いカード取引データが、支払いネットワーク170から発行銀行のMISアプリケーション150を経て又は支払いネットワーク170から直接購入者/支払人110に提供される。好適には、支払いカード取引データは、支払いファイルからの独自の取引IDを有する(ステップ420参照)。ステップ460において、支払い送金データが、銀行勘定調整のために取得者/プロセッサ160によって供給者/受取人130に提供される。最後に、ステップ470において、購入者/支払人110は、伝票発行サイクルの最後で発行銀行140との支払いカード取引を決済する。
【0019】
本発明の他の実施の形態を示す。これらの実施の形態は、マスターカードのP−Card(登録商標)のような購入カードの使用を参照するが、あらゆる支払いカードを代わりに用いることができる。本発明は、供給者/支払人130の登録、支払い認証及び/又は決済要求及び応答並びに例外ワークフロー通知を自動化し及び統合する機能を構築する際に、EIPPプラットフォーム120aを提供するソフトウェアプロバイダ120と取得者/プロセッサ160の両方をアシストする。
【0020】
ここで説明する実施の形態において、好適には、マーチャントサービス(MS)支払いゲートウェイ170aを用いる。MSゲートウェイ170aを、購入カード取引に対する認証及び決済が好適に処理されるゲートウェイとする。この処理を、バッチモードで満足することができ、この場合、レベルIII取引が、標準的なデータ交換フォーマット、例えば、810EDIフォーマットにおいて周期的な間隔でMSゲートウェイ170aに構築され及び送信される。好適には、MSゲートウェイ170aは、取引を適切なロケーションに送信するためにマーチャント識別子(「マーチャントID」)に基づいて取引を分離する。好適には、MSゲートウェイ170aは、824EDIフォーマットのような標準的なデータ交換フォーマットで認証応答を戻す。認証された取引に対して、MS支払いゲートウェイ170aは、好適には、提供されたレベルIIIデータによる決済処理を用いて処理を行う。
【0021】
図5は、本発明の実施の形態による購入カード取引を開始した注文書(PO)の即時の決済を表すフローチャートである。ステップ505において、購入者/支払人110は、POを購入者/支払人110のEPRシステム110aからソフトウェアプロバイダのEIPPシステム120aに電子的に送信する。ステップ510において、要求されたフォーマットで一旦POファイルがEIPPシステム120aに送信されると、POロードプロセスは、POを変換し、分析し及びEIPPシステム120aにロードするよう起動される。
【0022】
ステップ515において、一旦POがEIPPシステム120aにロードされるとともにフォーマット及び構造に対して有効にされると、EIPPシステム120aは、POのポストロード分析(post-load analysis)を開始する。ポストロード分析は、(i)供給者/受取人130及び購入者/支払人110についての情報がPOヘッダで利用できるか否かの決定(ii)支払い方法として提供される購入カード情報の決定及び認証(iii)新たなPO、二重PO又は変更POであるかの決定及び更なる処理に対するPOへの適切なフラグ立て、並びに(iv)支払い項目すなわち即時のPOであるか遅延したPOであるかの決定のような一連の基本的な確認を含む。
【0023】
ステップ520において、ポストロードPO分析が完了した後、好適には、POが更なる処理に対して新たなPOとしてフラグを立てるか変更POとしてフラグを立てるかを決定する。例外の場合、POは、適切な理由に従ってエラーとしてフラグを立てられ、ステップ523の例外キューに進む。POが変更POとしてフラグを立てられた場合、ステップ525において、EIPPシステム120aは、「変更PO」処理を開始する。元のPOが満足されるとともに購入者/支払人110と供給者/受取人130との間の関係に対して規定したルールに基づくか否かに応じて、システムは、POに対する変化に適用するよう処理を行い、PO履歴を発生する。
【0024】
変更POの場合、ステップ525において適切な処理が一旦完了すると、好適には、ステップ530において、変更が有効な変更であるか否か決定する。変更が有効でない場合、POは、エラーとしてフラグが立てられ、ステップ523の例外キューに進む。変化が有効である場合、POは、供給者/受取人130セットアップ情報及び/又はPOから取得されるベンダーID/顧客口座番号の詳細を用いて供給者/支払人130の一つ以上の代理業者に送出される。好適には、POについての情報を知らせるためにeメール通知を供給者/支払人130に送信する。
【0025】
ステップ535において、供給者/受取人130の代理業者は、好適には、送られた全てのPOの要約を見ることができる。POが、関連の購入口座番号を有する場合、当該POに対する要約文は、好適にはそのような場合を表す。また、POの要約文は、支払い項目が即時であるか否かを表す。供給者/受取人130の代理業者は、POの詳細を見ることを選択できる。POの詳細のビューを表示することができる。マスクされた購入カード情報をPO詳細ビューで利用することもできる。
【0026】
ステップ540において、PO要約又はPO詳細ビューから、供給者/受取人130の代理業者はPOをフリップ(flip)することができる。PO詳細の(購入者/支払人110によって規定されるような)編集可能なインタフェースが代理業者に提供される。この段階でも、購入カード番号はマスクされたままである。供給者/支払人130の代理業者は、注文確認に含まれる要素を量に従って選択する。供給者/支払人130の代理業者が、(部分的又は全体的な)フリップを実行するよう処理を行うとき、システムは、見積注文確認を発生する。見積注文確認は、POによって利用可能な場合には予め値が入れられた税及びFOBの編集可能な領域を有する。供給者/受取人130は、これらの要素を無効にすることができ、発生した請求書番号を無効にするとともに注文確認を発生するよう処理を行うこともできる。
【0027】
ステップ545において、POのステータスは「支払い処理」に変化し、EIPP120aは、独自の番号を発生するとともにその番号を注文確認に関連させる。ステップ550において、供給者/受取人130がMSゲートウェイによって取得されたか否かに基づいて、適切な支払い関連処理が開始される。供給者/受取人130がMSゲートウェイ170aによって取得されない場合、ステップ555において、供給者/受取人130に提供された注文確認ビューは、マニュアル支払い認証処理を開始するためのオプションを有する。
【0028】
ステップ560において、マニュアルオプションを選択する際に、認証コード及び(システムの日付が予め入れられた)取引日を入力するための編集可能な領域を有する注文確認のビューが供給者/受取人130に提供される。独自の番号もこのスクリーン上に表示することができる。この段階において、購入カード番号のマスクを外すことができる。供給者/受取人130は、外部のPOS装置310を通じて認証を行い、例えば顧客コードを促されたときに独自の番号をPOS装置310に入力する。
【0029】
認証された場合、ステップ565において、供給者/受取人130は、注文確認を認証コード及び取引日によって更新し、「支払済み」として注文確認にフラグを立てる。支払い認証が拒否され又は失敗する場合、このことがeメールを通じて購入者/支払人110と供給者/受取人130の両方に知らされ、「失敗」として注文書にフラグが立てられ、注文書が「失敗した認証」要約ビュー又はバスケットに配置される。
【0030】
ステップ550において供給者/支払人130がMSゲートウェイ170aによって取得された場合、EIPPシステム120aは、ステップ570に進み、MSゲートウェイ認証及び決済プロセスを行う。好適には、MSゲートウェイ認証及び決済プロセス(ステップ570)を、認証/決済ファイルをEIPPシステム120aによって発生するとともにMSゲートウェイ170aに送信するバッチ処理とする。ファイルは、レベルIII決済データを有する。ステップ575において、EIPPシステム120aは、認証コードを含む応答をMSゲートウェイ170aから受信し、認証されたすなわち「支払済み」として注文確認にフラグを立てるとともに認証コードを注文確認に関連する処理を行う。支払い認証が拒否され又は失敗する場合、このことがeメールを通じて購入者/支払人110と供給者/受取人130の両方に知らされ、「失敗」として注文書にフラグが立てられ、注文書が「失敗した認証」要約ビュー又はバスケットに配置される。MSに基づく認証に対して、取引は、好適には適切な理由コードを有する。
【0031】
供給者/受取人130は、特定の注文確認を詳細に観察するよう選択するために要約レベルで発生する互いに相違する注文確認の観察のオプションも有することができる。供給者/受取人(MSなし)がフリップ後に何も行わないことを選択することができる所定の注文確認が存在しうる。これらに対して、「マニュアル認証待機」としてフラグを立てる。
【0032】
一旦「支払済み」として注文確認にフラグが立てられると、ステップ580において、関連の情報を、特定のXMLスキーマにおいてマークするとともに、外部に出すことができるEIPP120aのXMLファイルに付加することができる。その間、注文確認は、EIPP120aで規定されたルーティング規則に基づいて購入者/支払人110に送出される。好適には、文書が注文確認であることを表す請求書/注文確認要約品目名に並列なインジケータが存在する。購入者/支払人110は、購入カードの詳細(口座番号の下4桁を除いてマスクされた購入カードの詳細)に従って注文確認の詳細を観察することができる。好適には、購入者/支払人110は、支払勘定システムに統合するために注文確認を外部に出すこと以外に注文確認に更なる処理を行わない。
【0033】
図6は、本発明の実施の形態による購入カード取引を開始したPOの遅延決済を表すフローチャートである。ステップ605において、購入者/支払人110は、POを購入者/支払人110のERP120aからソフトウェアプロバイダのEIPPシステム120aに電子的に送出する。ステップ610において、要求されたフォーマットで一旦POファイルがEIPP120aに送信されると、POロードプロセスは、POを変換し、分析し及びEIPPシステム120aにロードするよう起動される。
【0034】
ステップ615において、一旦POがEIPPシステム120aにロードされるとともにフォーマット及び構造に対して有効にされると、EIPPシステム120aは、POのポストロード分析を開始する。ポストロード分析は、(i)供給者/受取人130及び購入者/支払人110についての情報がPOヘッダで利用できるか否かの決定(ii)支払い方法として提供される購入カード情報の決定及び認証(iii)新たなPO、二重PO又は変更POであるかの決定及び更なる処理に対するPOへの適切なフラグ立て、並びに(iv)支払い項目すなわち即時のPOであるか遅延POであるかの決定のような一連の基本的な確認を含む。本実施の形態において、遅延POは、「請求書の日付から15日以内に全額を支払うこと」(net15)や「請求書の日付から30日以内に全額を支払うこと」(net30)のような支払い項目を有することができる。支払い項目が全く存在しなくてもよく、これは、好適には、遅延POの特別な場合と考えられる。
【0035】
ステップ620において、ポストロードPO分析が完了した後、好適には、POが更なる処理に対して新たなPOとしてフラグを立てるか変更POとしてフラグを立てるかを決定する。例外の場合、POは、適切な理由に従ってエラーとしてフラグを立てられ、ステップ623の例外キューに進む。POが変更POとしてフラグを立てられた場合、ステップ625において、EIPPシステム120aは、「変更PO」処理を開始する。元のPOが満足されるとともに購入者/支払人110と供給者/受取人130との間の関係に対して規定したルールに基づくか否かに応じて、システムは、POに対する変化に適用するよう処理を行い、PO履歴を発生する。変更POの場合、ステップ625において適切な処理が一旦完了すると、好適には、ステップ630において、変更が有効な変更であるか否か決定する。変更が有効でない場合、POは、エラーとしてフラグが立てられ、ステップ623の例外キューに進む。変化が有効である場合、POは、供給者/受取人130セットアップ情報及び/又はPOから取得されるベンダーID/顧客口座番号の詳細を用いて供給者/支払人130の一つ以上の代理業者に送出される。好適には、POについての情報を知らせるためにeメール通知を供給者/支払人130に送信する。
【0036】
ステップ635において、供給者/受取人130の代理業者は、好適には、送られた全てのPOの要約を見ることができる。POが、関連の購入口座番号を有する場合、当該POに対する要約文は、好適にはそのような場合を表す。POの要約文は、支払い項目が即時であるか否かを表す。供給者/受取人130の代理業者は、POの詳細を見ることを選択できる。POの詳細のビューを表示することができる。マスクされた購入カード情報をPO詳細ビューで利用することもできる。
【0037】
ステップ640において、PO要約又はPO詳細ビューから、供給者/受取人130の代理業者はPOをフリップすることができる。PO詳細の(購入者/支払人110によって規定されるような)編集可能なインタフェースが代理業者に提供される。この段階でも、購入カード番号はマスクされたままである。供給者/支払人130の代理業者は、注文確認に含まれる要素を量に従って選択する。供給者/支払人130の代理業者が、(部分的又は全体的な)フリップを実行するよう処理を行うとき、EIPPシステムは、見積注文書を発生する。見積注文書は、POによって利用可能な場合には予め値が入れられた税及びFOBの編集可能な領域を有する。供給者/受取人130は、これらの要素を無効にすることができ、発生した請求書番号を無効にするとともに注文確認を発生するよう645に進むこともできる。
【0038】
ステップ645において、発生した請求書は、承認及びスケジューリングのために適切な購入者/支払人110の代理業者に送出される。ルーティングは、購入者/支払人110のルーティングセットアップと、元のPOから取得される購入者/支払人110のID及び顧客口座番号についての他の関連の情報とによって決定される。
【0039】
ステップ650において、購入者/支払人110の代理業者は、購入者/支払人110のIDに送出された全ての請求書の要約を見ることができる。好適には、POの要約は、例えば、特定のロゴの使用や、関連の購入カード取引を有するあらゆるPOを表す。購入者/支払人110の代理業者は、請求書の詳細を見ることを選択できる。購入カード情報は、このような詳細なビューでも表示される。購入カード番号は、下4桁を除いてマスクされたままである。
【0040】
ステップ655において、購入者/支払人110の代理業者は、承認のために請求書を送出する。購入者/支払人110の代理業者は、購入者/支払人110の組織に対して規定されたワークフローを用いて、請求書を承認し及び/又は請求書を他の代理業者に送出する。ステップ660において、POに何らかの支払い項目が付加されているか否か決定し、そうである場合には、その支払い項目が何であるかを決定する。POが、明らかに存在する遅延支払い項目を有する場合、発生した請求書は、ステップ655においてこれらの項目に基づいてスケジューリングされ及び承認される。例えば、支払い項目がNet15を表す場合、請求書は、好適には、観察のために購入者/支払人110が利用できる日付から15日に支払いがスケジューリングされる。しかしながら、支払い項目が存在しない場合、ステップ667において、将来の日付の承認及び支払いに対する請求書をスケジューリングする。ステップ655において、請求書が一旦承認されると、承認された請求書は、ステップ655での観察のために供給者/受取人に送出される。
【0041】
ステップ670において、スケジューリングされた日付に到達すると、請求書の状態が「支払い処理」に変更される。好適には、独自の番号を発生させるとともに請求書に関連させる。ステップ670において、供給者/受取人がMSゲートウェイ170aによって取得されたか否かに基づいて、適切な支払い関連プロセスを開始する。供給者/受取人130がMSゲートウェイ170aによって取得された場合、EIPP120aは、MSゲートウェイ170aの認証及び決済プロセスを行うステップ675に進む。
【0042】
好適には、MSゲートウェイ170aの認証及び決済処理を、認証/決済ファイルをEIPP120aによって発生させるとともにMSゲートウェイ170aに送信するバッチ処理とする。好適には、ファイルは、レベルIII決済データを有する。EIPP120aは、認証コードを含むMSゲートウェイ170aから応答を受け取り、ステップ680において、認証されたものすなわち「支払済み」として請求書にフラグを立てるとともに認証コードを請求書に関連させる処理を行う。
【0043】
支払い認証が拒絶され又は失敗した場合、購入者/支払人110と供給者/受取人130の両方がその旨をeメールによって通知され、ステップ680において請求書に適切にフラグが立てられ、請求書が「失敗した認証」要約ビュー又はバスケットに配置される。MSゲートウェイ170aの認証に対して、取引は、好適には適切な理由コードを有する。
【0044】
ステップ670において、請求書が予定日に到達して「支払い処理」状態になったときにマーチャントが取得されなかったと決定され、すなわち、「マニュアル認証の待機」として供給者/受取人130にフラグが立てられたとき、ステップ685において、マニュアル認証プロセスが生じる。供給者/受取人130が、マニュアル認証を待機する請求書の詳細を見るとき、支払い処理を開始するオプションが供給者/受取人130に提供される。このオプションを選択する際、認証コード及び(システムの日付が予め入った)取引日を入力する編集可能な領域を有する請求書のビューを供給者/受取人130に供給する。独自の番号もこのスクリーン上に提示される。この段階において、購入カード番号はマスクされない。供給者/支払人130は、外部のPOS装置を通じて認証を行うとともに、促されたとき、例えば、顧客コードが促されたときに独自の番号をPOS装置に入力する。一旦認証されると、供給者/受取人130は、請求書を認証コード及び取引の日付によって更新し、「支払済み」として請求書にフラグを立てる処理を行う。
【0045】
支払い認証が拒絶され又は失敗した場合、購入者/支払人110と供給者/受取人130の両方がその旨をeメールによって通知され、ステップ690において請求書に適切にフラグが立てられ、請求書が「失敗した認証」要約ビュー又はバスケットに配置される。支払い認証が成功した場合、ステップ690において、「支払済み」として請求書にフラグが立てられ、ステップ695において、外部に送出するために関連の情報がEIPP XMLファイルに付加される。
【0046】
図7は、本発明の実施の形態によるPOのない購入カード取引の遅延決済を示すフローチャートである。本実施の形態において、EIPPシステム120aにロードされるPOが存在しない。ここでは、ステップ710において、請求書が供給者/受取人130によりソフトウェアプロバイダ120に電子的に送信される。ソフトウェアプロバイダ120において、請求書がステップ715でEIPP120aにロードされる。請求書ロードプロセス中、EIPP120aは、好適には、供給者/受取人130が購入カードを支払方法として許容したか否かを識別する。さらに、購入カードが、(購入者/支払人−供給者/受取人関係レベルで規定された)特定の顧客口座に対してデフォールト支払い方法(default payment method)として規定された場合、EIPPシステム120aは、購入カードを請求書に関連させる。
【0047】
購入者/支払人110は、購入カードを用いて支払いを行うよう認証された複数の代理業者を具えるユーザ群をセットアップする。購入者/支払人110のアドミニストレータは、カード名義人氏名、カード番号、満了日、CVC2コード等の購入カードの詳細を入力するとともに、購入カードを一つ以上のユーザ群に関連させることができる。購入者/支払人110のアドミニストレータは、購入カードがある特定の供給者/受取人130に対してのみ利用されるとみなすこともできる。
【0048】
ステップ715において、請求書がロードされ、請求書から利用できるルーティング情報に基づいて適切な購入者/支払人110の群に請求書が送出される。ルーティングを、ルーティングID又は顧客口座番号に基づいて行うことができる。ステップ720において、購入者/支払人110の代理業者は、ルーティングIDに送出された全ての請求書の要約を見ることができる。ステップ725において、購入者/支払人110の代理業者は、請求書を認証し及び/又は購入者/支払人110の組織に対して規定されたワークフローを用いて請求書を他の代理業者に送出する。購入者/支払人110の代理業者は、支払い方法を「購入カード」として選択することができ、すなわち、「購入カード」は、特定の顧客口座に対するデフォールト支払い方法として予め規定されており、この場合、EIPPシステム120aは、請求書に関連した購入カードを既に有する。
【0049】
ステップ730において、一旦「購入カード」が支払いオプションとして確立される場合、請求書は、将来の日付の支払いに対して自動的にスケジューリングされ、又は「スケジューラ」特権を有する購入者/支払人110の代理業者によってマニュアルでスケジューリングされる。ステップ735において、購入カードの詳細は、自動的に請求書に関連される。ステップ740において、請求書は、ステップ745で見るために支払いが承認されるとともに供給者/受取人130に送出される。
【0050】
ステップ750において、予定日に到達すると、請求書の状態は「支払い処理」に変更され、独自の取引番号を発生させるとともに請求書に関連させる。ステップ755において、供給者/受取人130がMSゲートウェイ170aによって取得されたか否かに基づいて、適切な支払い関連プロセスが開始される。ステップ760及び765において、供給者/受取人130がMSゲートウェイ170aによって取得された場合、EIPP120aは、MSゲートウェイ認証及び決済プロセスに進む。MSゲートウェイ認証及び決済を、好適には、認証/決済ファイルをEIPPシステム120aによって発生するとともにMSゲートウェイ170aに送信するバッチ処理とする。認証/決済ファイルは、好適にはレベルIII決済データを有する。
【0051】
ステップ770において、EIPPシステム120aは、認証コードを含むMSゲートウェイ170aから応答を受け取り、認証されたもの(支払済み)として請求書にフラグを立てるとともに認証コードを請求書に関連させる処理を行う。支払い認証が拒絶され/失敗する場合、購入者/支払人110と供給者/受取人130の両方はその旨がeメールによって通知され、請求書は、フラグが立てられるとともに「失敗した認証」要約ビュー/バスケットに配置される。MSゲートウェイ170aの認証に対して、取引は、適切な理由コードを有する。
【0052】
ステップ755においてマーチャントが取得されなかったことを決定した場合、すなわち、「待機マニュアル認証」として供給者/受取人130にフラグを立てることを決定した場合、マニュアル認証プロセスがステップ755で開始される。供給者/受取人130がそのような請求書の詳細(「待機マニュアル認証」)を見ると、支払い処理を開始するオプションが供給者/支払人130に提示される。このオプションを選択する際に、認証コード及び(システムの日付が入れられた)取引日を入力する編集可能な領域を有する請求書のビューを供給者/受取人130に提供することができる。独自の番号もこのスクリーン上に提示される。この段階では、購入カードの番号は好適にはマスクされない。供給者/受取人130は、外部のPOS装置310を通じて認証を行い、例えば顧客コードが促されたときにPOS装置310に独自の番号を入力する。
【0053】
ステップ780において、一旦認証されると、供給者/受取人130は、認証コード及び取引日によって請求書を更新し、「支払済み」として請求書にフラグを立てる処理を行う。ステップ780において支払い認証が拒絶され/失敗する場合、購入者/支払人110と供給者/受取人130の両方はその旨がeメールによって通知され、請求書は、フラグが立てられるとともに「失敗した認証」要約ビュー/バスケットに配置される。ステップ785において一旦請求書に「支払済み」としてフラグが立てられると、外部に送出するために、関連情報がマークされ、EIPP120aのXMLファイルに添付される。
【0054】
MS認証及び決済を、本発明によるMSゲートウェイ認証及び決済のプロセスの一例を示すフローチャートである図8に関連して更に詳細に説明する。好適には、MS認証及び決済を、組合せのバッチ処理とするが、認証及び決済を個別のプロセスとすることもできる。好適には、MS認証及び決済をバックエンドプロセスとし、すなわち、ユーザは、プロセスの実行に入るのを見ることができない。
【0055】
ステップ820において、認証/決済取引記録をステップ810のトリガに基づいて構成する。好適には、トリガを、注文確認請求書を発生したとき及び請求書が「支払い処理」状態に到達したときとする。このようなトリガが生じると、好適には、基本ファイルを、基本要素のみを有するスケジューリングに基づいて形成する。MSに対する伝送があるときに新たなファイルも構成される。このファイルに対して、好適には、支払い取引がEIPPシステム120a内で生じたときに記録が追加される。予め決定されたときに、好適には、ファイルがMSゲートウェイ170aに送出され、処理を再開する。
【0056】
認証/決済取引は、好適には810EDIフォーマットで行われ、レベルIII決済データを有する。独自の取引番号、EIPPで発生した整合及び顧客コードも好適にはこの取引の一部とする。認証/決済取引(レベルIII)に対するデータを、好適には(a)請求書に提示されるデータ要素、(b)データに関連した購入カード、及び(c)MSマーチャントゲートウェイ170aのセットアップ情報から取得する。好適には、認証/決済取引を、規則的な時間間隔で抽出し、バッチ認証/決済ファイルに添付する。好適にはバックアップファイルも更新される。
【0057】
ステップ830において、認証/決済ファイルは、処理のために予め規定された時間間隔でEIPPシステム120aを通じてMSゲートウェイ170aに送出される。MSゲートウェイ170aは、ソフトウェアプロバイダ120に対して規定されたマッピングセットアップに基づいて認証/決済ファイルをマッピングする。MSゲートウェイ170aは、適切に取得されたプラットフォームに対する取引を識別する。この識別に基づいて、更なる処理のために認証/決済ファイルを分割して対応するプラットフォームに送出する。MSゲートウェイ170aは、決済金額の合計値の制限に適合するために認証/決済取引を複数の取引に分割することができる。
【0058】
ステップ840において、認証応答は、MSゲートウェイ170aからEIPP120aに戻される。応答は、824EDIフォーマットでEIPP120aに戻される。ステップ850において、EIPP120aは、認証応答取引を受け取り、個別の応答記録を評価する。応答(失敗したか否か)に基づいて、システムは、対応する請求書を更新する。成功した認証が可能である場合、ソフトウェアプロバイダ120から取得した動作を行うことなく決済処理をMSゲートウェイ170aによって続ける。決済処理に対して応答がないことがMSゲートウェイ170aから予測される。
【0059】
認証が成功した場合、ステップ855において、認証されたものとして請求書にフラグが立てられ、その状態が適切に更新される。ステップ860において、請求書の詳細を認証の詳細にも関連させる。これは、供給者/受取人130に見える認証コード、取引日等を有する。購入者/支払人110は、取引日のみ見ることができる。独自の取引番号、デビット/クレジット等を有する支払い記録の他の詳細も請求書に関連させる。ステップ865において、特定の請求書に対して認証が成功したことを表すためにeメールの通知が供給者/受取人130に送出される。ステップ870において、EIPP XMLファイルに関連した取引を記録のために発生し、好適には必要に応じて外部に送出する。
【0060】
認証が成功しなかった場合、ステップ875において、請求書に対して適切にフラグが立てられ、ステータスが更新される。ステップ880において、購入者/支払人110及び供給者/受取人130の代理業者は、eメールによる通知が行われる。最後に、ステップ885において、取引が、適切な失敗認証例外「バスケット」に配置される。
【0061】
MS認証の失敗の処理を、本発明によるMS認証失敗の処理工程の一例を示すフローチャートである図9に関連して詳細に説明する。ステップ905において、MS認証失敗処理は、好適には、請求書又は注文確認に関連した認証要求が(i)MSゲートウェイ認証及び決済プロセスの一部としてMSゲートウェイ170aによって拒否され又は(ii)マニュアル認証及び決済プロセスの一部としてPOS装置310によって拒否されるときに開始される。認証拒否の理由を詳述するデータを、MSゲートウェイ170aの認証応答を通じて又はMSゲートウェイ170aによって取得されなかった供給者/受取人130の代理業者によるマニュアルエントリによって取得することができる。好適には、EIPPシステム「120aは、認証拒否理由を請求書確認に関連付ける。
【0062】
ステップ910において、請求書又は注文確認状態は「認証失敗」に変更される。ステップ915において、特定の請求書又は注文確認に対する支払い認証が失敗したことを助言するためにeメールの通知を購入者/支払人110及び供給者/受取人130に送信する。ステップ920において、購入者/支払人110及び供給者/受取人130は、特定の請求書又は注文確認の詳細を「認証失敗」要約ビューから見ることを選択でき、この場合、「認証失敗」として請求書にフラグが立てられる。これによって、MSゲートウェイ170aを通じて取得され又は供給者/受取人130によって入力された拒否の理由を、請求書又は注文確認の詳細ビューの一部及び理由を説明するとともに拒否の理由を解決するガイダンスを提供する他の情報として購入者/支払人110及び/又は供給者/受取人130に提示する。
【0063】
「認証失敗」状態の請求書又は注文確認の詳細ビューの一部として、購入者/支払人110は、「現状のままで再実行」又は「支払方法を無効にする」オプションも提供する。購入者及び供給者は、「認証失敗」に対するあり得る理由及び救済策にアクセスするために互いに調べることを選択できる。
【0064】
ステップ925において、購入者/支払人110は、支払い処理のために特定の請求書又は注文確認を「現状のままで再実行」することを選択できる。これは、EIPP120a又は外部調査を通じて取得した拒否の理由がそのような方向に影響を及ぼす場合に生じうる。ステップ930において、請求書又は注文確認状態は「支払い処理」に変更される。供給者/支払人130をMSゲートウェイ170aから取得した場合、ステップ935において、MSゲートウェイ170aの認証及び決済手順が実行される。供給者/受取人130がMSゲートウェイ170aによって取得されない場合、ステップ940において、「マニュアル認証待機」として請求書にフラグが立てられ、ステップ945において、請求書がマニュアル認証待機であることを助言するためにeメールが供給者/受取人130に送信され、マニュアル認証プロセスが実行される。
【0065】
ステップ925において、購入者/支払人110は、請求書又は注文確認に対する元の認証要求に関連した支払方法を無効にすることを選択できる。これは、例えば、EIPP120a又は外部調査を通じて取得した拒否の理由がそのような方向に影響を及ぼす場合に生じうる。「無効支払い方法」オプションが選択された場合、ステップ950において、購入者/支払人110は、好適には、一つ以上の他の支払方法を選択するためのビューが提示される。購入者/支払人110は、他の購入カードを含む利用できる支払方法のいずれかを関連付けることを選択できる。支払い方法を選択すると、ステップ955において、購入者/支払人110は、処理のために請求書又は注文確認を送出することができる。ステップ960において、請求書又は注文確認状態は「支払い処理」に変更される。
【0066】
ステップ950において、選択された支払い方法が購入カードでない場合、好適には、「既存」システムで規定されるような方法で処理が継続する。選択された支払い方法が購入カードである場合、及び、供給者/受取人130がMSゲートウェイ170aによって取得された場合、ステップ935において、MSゲートウェイ170aの認証及び決済プロセスを開始することができる。供給者/受取人130がMSゲートウェイ170aによって取得されなかった場合、ステップ940において、「マニュアル認証待機」として請求書にフラグが立てられる。ステップ945において、請求書がマニュアル認証待機であることを助言するためにeメールを供給者/受取人130に送信し、マニュアル認証プロセスを開始する。ステップ925において、請求書又は注文確認の拒否の詳細を見る際に、購入者/支払人110は、請求書に関連した購入カード情報を変更PO取引を通じて変更することを選択できる。これは、例えば、購入者/支払人110が全ての関連する請求書又は注文確認に反映した変更を有したい場合又は選択のために購入者/支払人110に対して他の支払方法を利用できない場合に生じうる。好適には、これは、EIPP120a内の請求書に関連したPOが存在する場合のみ生じる。
【0067】
ステップ965において、購入者/支払人110は、「変更PO」又は「変更購入カード情報」要求を発する。ステップ970において、POに関連した購入カード情報は、変更PO要求の情報によって更新される。ステップ975において、情報は、まだ「支払済み」状態でない請求書に対して発生した請求書又は注文確認に提供される。ステップ980において、「認証失敗」状態にある請求書に対して、状態が「支払い処理」にリセットされる。供給者/受取人130がMSゲートウェイ170aによって取得された場合、ステップ935において、MSゲートウェイ170aの認証及び決済プロセスを開始することができる。供給者/受取人130がMSゲートウェイ170aによって取得されなかった場合、ステップ940において、「マニュアル認証待機」として請求書にフラグが立てられる。ステップ945において、請求書がマニュアル認証待機であることを助言するためにeメールが供給者/受取人130に送信され、マニュアル認証プロセスが開始される。
【0068】
以下の表は、認証及び決済取引をMSゲートウェイに送出するためにEDI810フォーマットを利用する方法の一例である。
【0069】
【表1−1】

【0070】
【表1−2】

【0071】
【表1−3】

【0072】
【表1−4】

【0073】
【表1−5】

【0074】
【表1−6】

【0075】
【表1−7】

【0076】
【表1−8】

【0077】
【表1−9】

【0078】
【表1−10】

【0079】
【表1−11】

【0080】
【表1−12】

【0081】
【表1−13】

【0082】
【表1−14】

【0083】
以下の表は、認証応答をソフトウェアプロバイダ170に戻すためにEDI824フォーマットをMSゲートウェイ170aによって利用する方法の一例を示す。本例では、要求のフォーマットが適切であるか否かを確認するためにEDI997がMSゲートウェイ170aによって送出される。
【0084】
【表2−1】

【0085】
【表2−2】

【0086】
【表2−3】

【0087】
【表2−4】

【0088】
【表2−5】

【0089】
【表2−6】

【0090】
【表2−7】

【0091】
【表2−8】

【0092】
【表2−9】

【0093】
以下の表は、本発明によるMSゲートウェイ170aの応答/理由コードの例を説明する。以下の表において、“**”は、MSゲートウェイ170aの発生した応答を表す。
【0094】
【表3−1】

【0095】
【表3−2】

【0096】
【表3−3】

【0097】
【表3−4】

【0098】
本発明を、所定の好適な実施の形態を参照して説明したが、添付した請求の範囲によって規定したように、種々の変更、変形及び置換は、本発明の範囲を逸脱することなく当業者に既知又は明らかである。
【図面の簡単な説明】
【0099】
【図1】支払いが支払人によって開始される支払いカード取引の自動化された支払い認証及び決済を行うシステムの一例を示すブロック図である。
【図2】支払いが支払人によって開始される支払いカード取引の自動化された支払い認証及び決済を行う方法の一例を示すフローチャートである。
【図3】支払いが受取人によって開始される支払いカード取引の自動化された支払い認証及び決済を行うシステムの一例を示すブロック図である。
【図4】支払いが受取人によって開始される支払いカード取引の自動化された支払い認証及び決済を行う方法の一例を示すフローチャートである。
【図5】本発明の実施の形態による購入注文を開始した購入カード取引の即時決済を表すフローチャートである。
【図6】本発明の実施の形態による購入注文を開始した購入カード取引の遅延決済を表すフローチャートである。
【図7】本発明の実施の形態によるPOのない購入カード取引の遅延決済を表すフローチャートである。
【図8】本発明によるMSゲートウェイ認証及び決済のプロセスの一例を示すフローチャートである。
【図9】本発明によるMS認証失敗の処理のプロセスの一例を示すフローチャートである。

【特許請求の範囲】
【請求項1】
電子請求書・決済(EIPP)システムによって購入者と供給者との間で購入カードの取引を行う方法であって、
前記購入者の企業資源計画(ERP)システムで前記購入カードの取引に対する請求書を承認し、
前記購入者のERPシステムの支払いに対する請求書をスケジューリングし、
前記取引に関連した独自の取引識別子を有する支払いファイルを、前記購入者のERPシステムから抽出し、
独自の取引番号を含む支払いファイルを、前記購入者のERPから支払い認証及び決済の取得者に送出し、
前記取引を記述するデータを含む取引カード明細を前記購入者のERPに供給し、前記明細のデータが前記独自の取引識別子を有し、
前記購入カードの発行者との取引を前記購入者によって決済することを特徴とする方法。
【請求項2】
請求項1記載の方法において、前記供給者の口座の銀行勘定調整を行うために、前記独自の取引識別子を有する送金データを前記供給者に供給することを特徴とする方法。
【請求項3】
電子請求書・決済(EIPP)システムによって購入者と供給者との間で購入カードの取引を行う方法であって、
前記購入者の企業資源計画(ERP)システムで前記購入カードの取引に対する請求書を承認し、
前記購入者のERPシステムの支払いに対する請求書をスケジューリングし、
前記取引に関連した独自の取引識別子を有する支払いファイルを、前記購入者のERPシステムから抽出し、
認証及び決済のために、前記取引を記述するとともに前記独自の取引識別子を有するデータを、販売(POS)装置に提供し、
独自の取引番号を含む支払いファイルを、前記購入者のERPから支払い認証及び決済の取得者に送出し、
前記取引を記述するデータを含む取引カード明細を前記購入者のERPに供給し、前記明細のデータが前記独自の取引識別子を有し、
前記購入カードの発行者との取引を前記購入者によって決済することを特徴とする方法。
【請求項4】
請求項2記載の方法において、前記供給者の口座の銀行勘定調整を行うために、前記独自の取引識別子を有する送金データを取得者から前記供給者に供給することを特徴とする方法。

【図1】
image rotate

【図2】
image rotate

【図3】
image rotate

【図4】
image rotate

【図5】
image rotate

【図6】
image rotate

【図7】
image rotate

【図8】
image rotate

【図9】
image rotate


【公表番号】特表2008−511085(P2008−511085A)
【公表日】平成20年4月10日(2008.4.10)
【国際特許分類】
【出願番号】特願2007−530155(P2007−530155)
【出願日】平成17年8月25日(2005.8.25)
【国際出願番号】PCT/US2005/030384
【国際公開番号】WO2006/026418
【国際公開日】平成18年3月9日(2006.3.9)
【出願人】(500557864)マスターカード インターナシヨナル インコーポレーテツド (18)