CN102483823A - 实时应付帐款web服务 - Google Patents

Abstract

web服务便利利用由开户行向帐户持有人开立的帐户对供应商的发票进行实时支付。由web服务从客户端接收的标识了商业帐户池中的一个商业帐户的信用限额的支付请求，被从web服务发送到开户行，以确定帐户和帐户持有人的信用限额的可用性。如果开户行的对请求的响应确认可用性，从web服务向开户行发送支付指令，以对供应商的发票进行支付。可另选地，请求可以是确定单次使用帐户(SUA)的可用性以及对来自开户行的帐户持有人的信用限额的调整的可用性，以便在SUA上为对应于来自供应商(尚未提供涉及发票的商品和/或服务)的未来的发票的购买向该供应商进行未来的单次支付。

Description

实时应付帐款web服务

对相关申请的交叉引用

本申请要求2009年8月31日提出的名称为“Real Time AccountsPayable Web Services”的美国临时申请案序列No.61/238,648，以及2010年8月25日提出的名称为“Real Time Accounts Payable WebService”的美国申请序列No.12/868,436的优先权，这两者都以引用的方式并入本文中。

技术领域

本发明涉及企业向其过去或未来的供应商的应付帐款，更具体而言，涉及应付帐款web服务。

背景技术

为做生意，企业需要原材料、制成品，以及供货。另外，企业还需要各种服务提供商。无论是向企业提供商品还是服务，关于向企业提供的那些商品及服务，必须对每一个这样的供应商进行支付。每一个供应商都向企业发送发票，以便为它提供给企业的商品和服务得到支付。发票是被企业用来为该企业接收到或将接收的商品及服务向供应商给予报酬的手段。在企业收到发票之后，发送发票的供应商通常将等待若干天，向其提供了商品和/或服务的企业才能对商品和/或服务进行支付。企业通常通过应付帐款系统来向其供应商进行支付。由企业向供应商的支付可以通过现金、支票，或通过由诸如企业的银行之类的开户行向企业开立的帐户上的支付。在帐户上给每一个供应商进行支付是特别有益的。这些优点包括来自为企业向供应商支付提供资金的开户行的激励和回扣，电子支付处理而不是处理支票付款可以降低企业的成本，企业通过使用信贷而不是使用现金流来向其供应商支付对企业来说是“浮动”优点，以便最大化流动资本等等。

企业通常将从其供应商为由其相应的供应商向企业提供的商品及服务接收到很多发票。周期性地，企业将从它接收的那些发票中标识它希望支付的那些发票。为支付每一张发票，可能需要企业的各组织(例如，出纳、财务、应付帐款，审计和合规、信息技术、采购等等)之间的协作工作流，以保护和控制对于支付的批准。

一旦标识了一组要支付的发票，进一步确定对于每一张发票的支付方法。在利用由开户行向企业开立的帐户支付那些发票的情况下，通常使用批处理。企业用来支付其应付帐款的帐户常常被称为商业帐户，或者可另选地，对应于“商业卡”的帐户。商业帐户可以具有预存的资金，或者它可以是周转信贷帐户，或一次性的信贷帐户(例如，即期信贷)。

在应付帐款批处理中，由企业标识通过发票(例如，一批发票)以便通过企业的帐户支付系统的处理来进行支付。企业的商业帐户的开户行将接收到该批发票。企业可以每天向其商业帐户开户行发送一批发票。然后，开户行将对该批中与每个供应商相对应的发票向供应商转帐。在开户行为应付帐款提供资金的情况下，企业将在财务上负责向开户行存足够的资金，以便支付给开户行，使其在帐户上向企业的供应商进行对应于该批发票的支付，加服务费、利息，以及违约金。由于企业因同意允许开户行为企业的应付帐款提供资金而表现出对开户行的忠诚度，开户行可以给企业提供奖励、激励，以及回扣。

在供应商为对发票进行立即付款的企业提供激励的情况下，由于延迟，现有技术的对商业帐户上的支付的应付帐款的批处理不适当。相应地，应该给企业提供实时支付应付帐款功能，通过该功能，企业可以在企业的商业帐户上进行实时的电子支付。

发明内容

在一种实现中，在web服务中从客户端接收标识商业帐户池中的一个商业帐户的请求。该请求包括对于被请求的未使用的一个商业帐户的信用限额。web服务连同指令一起向被请求的未使用的一个商业帐户的开户行发送请求，该指令指示开户行确定商业帐户池中的被请求的未使用的一个商业帐户的可用性以及由开户行向帐户持有人(开户行向该帐户持有人开立了商业帐户池中的每一个商业帐户)提供的可用信用中的信用限额的可用性。web服务将从开户行接收对请求的响应。当响应包括关于被请求的未使用的一个商业帐户和被请求的未使用的一个商业帐户的被请求的信用限额两者的可用性的确认时，web服务向开户行发送支付指令，以通过使用被请求的未使用的一个商业帐户的可用信用限额来向供应商进行发票的电子支付。请求和响应都是实时发生的。在替换实现中，请求以及其响应，以及支付指令被包含在具有标记语言的格式的数据的一个或多个传输中。

在另一种实现中，由web服务从客户端接收请求。请求包括确定按商业帐户(单次使用帐户，SUA)的单次使用的金额对信用限额进行调整是否可用的指令。SUA将被用来向开户行向其开立了SUA的帐户持有人的供应商进行未来的单次支付。单次支付所针对的发票来自尚未提供涉及发票的商品和/或服务的供应商。web服务向SUA的开户行发送请求以及SUA的标识符和所述金额。请求包括这样的指令，即指示开户行判断根据向帐户持有人开立了SUA的SUA的开户行所提供的可用信用按所述金额对SUA的信用限额进行所请求的调整的可用性。响应于请求，web服务接收对请求的响应。当响应包括验证SUA和所请求的对SUA的信用限额调整已经均被开户行确定为可用的信息时，web服务向开户行发送支付指令以通过使用SUA的经调整的信用限额来进行涉及供应商的发票的单次支付。请求和响应都是实时发生的。在前述的实现的替代方案中，涉及接收的请求和接收的对请求的响应中的每一个的电子通信，以及发送到开户行的支付指令，都是包含具有标记语言格式的数据的一个或多个传输。

在再一个实现中，提供了“更新支付指令/征用请求web服务”以更新如上文所描述的处于挂起状态的现有支付指令或请求。

在更进一步的实现中，提供了“重新发送通知请求web服务”以请求重新发送如上文所描述的如在挂起状态的支付指令或请求。

附图说明

通过下面的结合图形对本发明进行的详细说明，本发明的实现将变得更加显而易见，在图形中，相同的元件带有相同的附图标记。

图1示出了对于支付指令web服务的示例性方法；

图2示出了对于征用请求web服务的示例性方法；

图3示出了对于更新支付指令/征用请求web服务的示例性方法；

图4和5示出了相应的示例性后端处理流程，其中，图4示出了支付指令和征用请求的过程，而图5示出了对于周期性的批匹配和失效处理的过程；

图6描绘了用于处理图1的来自客户端的对于“支付指令web服务”的请求，图2的征用请求web服务，或图3的更新支付指令/征用请求web服务的示例性方法的流程图；

图7描绘了自动化的web服务环境，使用流程图，示出了各种网络设备处于通信中的应付帐款自动化web服务；以及

图8示出了示例性支付处理网络，以描绘一般环境，其中，可以处理商业帐户上的对于支付的交易，其中，企业是由开户行向企业开立的商业帐户的持有人，商业帐户上的交易由企业与商家(例如，企业的供应商)执行，以交换商家向企业提供商品和/或服务。

具体实施方式

在万维网上提供了“支付指令web服务”。“支付指令web服务”允许企业为已经接收的(和/或由供应商向企业所提供的)商品和/或服务向其供应商进行实时的电子支付(e-支付)。实时e-支付是在由开户行向企业开立的商业帐户上进行的。企业的进行实时电子支付的请求此处被称为“支付指令”。相应地，当供应商对企业为供应商的发票进行立即付款而提供激励时，通过“支付指令web服务”在企业的商业帐户上进行的实时e-支付将允许企业收集如果通过现有技术的应付帐户的批处理早就丢失的激励。此外，企业将享有基于Web的e-支付的方便性，以最大化其流动资本，同时自动化其应付帐款处理的支付指令方面。

在使用中，“支付指令web服务”允许创建支付指令以指示供应商使用企业的商业帐户，以便为已经进行并向企业(例如，买方公司)开了发票的采购进行支付。“支付指令web服务”可以被用来在“应付帐款自动化”应用程序中处理“特别(Adhoc)”支付指令。“支付指令web服务”将为对“支付指令web服务”的一次调用捕捉单个支付指令。支付指令将基于接收的数据而处理。在处理结束时，将提供支付指令的完成状态的响应。

在一种实现中，“支付指令web服务”将从客户端接收标识商业帐户池中的一个商业帐户的请求。一个商业帐户将是未使用的，池中的其他商业帐户已经被使用或正在使用中。被请求的一个未使用的商业帐户将被用来向所请求的未使用的一个商业帐户的帐户持有人的供应商进行支付。一种支付是针对来自供应商的发票的。由“支付指令web服务”接收的请求将包括对于被请求的未使用的一个商业帐户的信用限额。“支付指令web服务”向被请求的未使用的一个商业帐户的开户行发送请求以及指令，该指令指示开户行确定商业帐户池中的被请求的未使用的一个商业帐户的可用性以及由开户行向帐户持有人(开户行向该帐户持有人开立了商业帐户池中的每一个商业帐户)提供的可用信用中的信用限额的可用性。

“支付指令web服务”从开户行接收对请求的响应。当响应包括关于被请求的未使用的一个商业帐户和被请求的未使用的一个商业帐户的被请求的信用限额两者的可用性的确认时，“支付指令web服务”向开户行发送支付指令，以通过使用被请求的未使用的一个商业帐户的可用信用限额来向供应商进行发票的电子支付。优选地，请求的接收和接收的对请求的响应两者都是实时地发生的。优选地，接收的请求和接收的对请求的响应中的每一个都是包含标记语言的格式的数据的一个或多个传输，并且，被发送到开户行的支付指令是包含标记语言的格式的数据的一个或多个传输。

还提供了“征用请求web服务”。在“征用请求web服务”中，企业可以指定一个商业帐户，在该商业帐户上，可以为企业尚未从供应商接收的商品和/或服务对将向其进行未来的支付的该供应商进行未来的支付。在此情况下，商业帐户将是单次使用帐户(SUA)，因为该帐户将只被企业用来向一个供应商进行一次支付。可另选地，企业可以要求对企业的现有的商业帐户中的一个的信用限额进行调整。进行所请求的对商业帐户的信用限额的调整，以便企业可以为企业尚未从供应商接收的商品和/或服务对将向其进行未来的支付的该供应商进行一次或多次未来的支付。“征用请求web服务”此处被称为具有“征用(requisition)”功能，因为企业征用单次使用的SUA来向供应商支付，或因为企业征用对现有的商业帐户的信用限额的调整以便向企业的供应商进行一次或多次支付。

在使用中，“征用请求web服务”允许创建征用以向“买方公司”企业提供“许购定额”信用限额。买方公司将使用有关被申请的通过“征用请求web服务”所提供的商业帐户的信息，以便启动未来从未来的供应商的购买。“征用请求web服务”可以和作为商业帐户的单次使用帐户(SUA)的开立一起，或和对现有商业卡上的信用限额的调整一起提供此信息。“征用请求web服务”，总而言之，用于创建新的征用和开立单次使用帐户，或用于更新与征用相关的现有的商业帐户的信用限额。

在一种实现中，由征用请求Web服务从客户端接收请求。请求是按SUA的单次使用的金额调整信用限额。SUA将被用来向开户行对其开立了SUA的帐户持有人的供应商进行单次支付，支付是针对来自供应商的发票的。征用请求web服务向SUA的开户行发送请求以及SUA的标识符和所述金额。请求包括这样的指令，即指示开户行判断根据向帐户持有人开立了SUA的SUA的开户行所提供的可用信用按所述金额对SUA的信用限额进行所请求的调整的可用性。响应于请求，征用请求web服务接收对请求的响应。当响应包括验证SUA和所请求的对SUA的信用限额调整被确定为可用的信息时，征用请求web服务向开户行发送支付指令以通过使用SUA帐户的经调整的信用限额来对供应商的发票进行单次支付。优选地，请求和响应都是实时发生的。优选地，涉及接收的请求和接收的对请求的响应中的每一个都是包含标记语言的格式的数据的一个或多个传输，并且，被发送到开户行的支付指令是包含标记语言的格式的数据的作为一种个或多个传输。

还提供了“更新支付指令/征用请求web服务”。“更新支付指令/征用请求web服务”用于更新在帐户支付自动化平台内的如上文所描述的处于挂起状态(尚未匹配或过期的)的现有的支付指令或征用请求。所支持的改变包括调整商业帐户的到期日期，替换联系人信息(例如，电子邮件地址和电子邮件便笺)，包括更新支付金额或恢复过期的支付指令。

还提供了“重新发送通知请求web服务”。“重新发送通知请求web服务”是请求重新发送支付指令和/或征用请求通知/汇款电子邮件。可以向当前被作为正在被引用的支付指令/征用请求的一部分持续的接收者列表发送通知/汇款。

还提供了“获得单次使用帐户清单请求web服务”。“获得单次使用帐户清单请求web服务”是请求由开户行向企业(例如，向银行的企业客户)开立的位于已经被预留供企业使用的商业帐户池中的单次使用商业帐户(SUA)的总数报告。报告还将包括当前可被企业用来完成新请求的这样的商业帐户的数量。这样的商业帐户池可以由例如，企业(例如，买方标识(ID))和商业帐户的不同的代理帐号来定义。

在图1-3中的每一个中，在框102，202，302分别示出了请求者-客户端。请求者-客户端是通过与开户行(如在图8中的附图标记804(i)处示出和进一步讨论的)协作来支付其应付帐款的实体。作为示例，图8示出了负责在交易支付网络800中向商家(m)810进行支付的帐户持有人(a)808。帐户持有人(a)808与开户行(i)804一起协作，以提供将被帐户持有人(a)808持有的单次使用帐户(SUA)或者扩大现有商业帐户上的信用，以便可以在商业帐户上向商家(m)810进行支付。在每一种情况下，商业帐户都是由开户行(i)804向帐户持有人(a)808开立的。

图1描绘了过程100，其中，通过在万维网上提供的“支付指令web服务”请求支付指令。支付指令web服务允许企业为已经接收的(和/或由供应商向企业所提供的)商品和/或服务向其供应商进行实时的电子支付(e-支付)。实时e-支付是在由开户行向企业开立的商业帐户上进行的。企业的进行实时电子支付的请求此处被称为“支付指令”，例如，图1中被示为支付指令请求104。在图1中，请求者-客户端102执行Web浏览器，或其他万维网访问应用程序，以向web服务接口(WSI)认证传输支付指令请求104。在框106，WSI认证尝试认证对支付指令的请求。在支付指令请求在框106经过web服务接口认证之后，如果支付指令请求没有通过认证，那么，方法100移动到框120。在框120，支付指令请求以适当的错误代码被拒绝，在框120，向请求者-客户端102发送诊断消息，过程100移动到框128，在此，有进一步被返回到请求者-客户端102的服务请求。然而，如果在框108支付指令请求被视为被查询所认证，那么，过程100移动到框110。在框110，在验证过程中验证支付指令请求的消息。在框112，查询此验证过程。如果对支付指令请求的消息的验证失败，那么，过程100移动到框120，在此，支付指令请求再一次以适当的错误代码被拒绝，向请求者-客户端102发送诊断消息，在框128请求的服务是针对将消息返回到请求者-客户端202的。

然而，如果在框112支付指令的消息被视为被查询所验证，那么，过程100移动到框114，而支付指令请求被发送到处理平台。作为示例，在图7中的框708中，处理平台被视为应付帐款处理平台。过程100从框114移到框116，在此，处理支付指令请求。在框118，进行对支付指令请求的响应的格式化。作为示例，格式化是以诸如可扩展标记语言(XML)或其变体之类的标记语言进行的，以便可以遵守用于因特网和web服务的协议，并可以符合该协议。过程100从框118移到框122，在此，进行查询。框122处的查询是关于处理支付指令请求的过程是否是成功的。如果对支付处理的支付指令请求不成功，那么，过程100从框122移到框120，在此，支付指令请求以适当的错误代码被拒绝，在框102，通过框128的服务请求向请求者-客户端发送诊断消息。

然而，如果处理支付指令请求的过程成功，如由查询在框122确定的，那么，在框124向请求者-客户端102发送响应，商业帐户的开户行在框126发出支付通知的请求。此后，过程100返回到请求者-客户端102，以便完成下一个对支付指令的实时应付帐款请求。

图2示出了过程200，其中，通过征用请求web服务来处理征用请求，通过该web服务，企业可以指定一个商业帐户，在该商业帐户上，可以为企业尚未从供应商接收的商品和/或服务对将向其进行未来的支付的该供应商进行未来的支付。商业帐户是用于只向一个供应商进行一次支付的单次使用帐户(SUA)。可以对企业的信用限额进行调整，以便企业可以为企业尚未从供应商接收的商品和/或服务对将向其进行未来的支付的该供应商进行一次或多次未来的支付。

在框206，请求者-客户端202执行Web浏览器，或万维网访问应用程序，以向web服务接口(WSI)认证传输征用请求204。征用请求204是企业征用SUA以便单次使用以向供应商进行支付的请求。可另选地，企业可以征用对企业的现有的商业帐户中的信用限额进行调整，以便企业可以向企业的供应商进行一次或多次支付。在框206，WSI认证尝试对征用请求进行认证。

在征用请求在框206经过web服务接口认证之后，如果征用请求没有通过认证，如由查询在框208确定的，那么，方法200移动到框220。在框220，征用请求以适当的错误代码被拒绝，在框220，向请求者-客户端202发送诊断消息，过程200移动到框228，在此，有进一步被返回到请求者-客户端202的服务请求。然而，如果在框208征用请求被视为被查询认证，那么，过程200移动到框210。在框210，在验证过程中验证征用请求的消息。如果对征用请求的消息的验证失败，那么，过程200移动到框220，在此，征用请求再一次以适当的错误代码被拒绝，并向请求者-客户端202发送诊断消息，其中，在框228请求的服务是针对将消息返回到请求者-客户端202的。

然而，如果在框212征用请求的消息被视为被查询验证，那么，过程200移动到框214，而征用请求被发送到处理平台。作为示例，在图7中的框708中，处理平台被视为应付帐款处理平台。过程200从框214移到框216，在此，处理对支付的征用请求。在框218，进行对征用请求的响应的格式化。作为示例，格式化是以诸如XML之类的标记语言进行的，以便可以遵守用于因特网和web服务的协议，并可以符合该协议。过程200从框218移到框222，在此，进行查询。框222处的查询是关于处理征用请求的过程是否是成功的。如果征用请求不成功，那么，过程200从框222移到框220，在此，征用请求以适当的错误代码被拒绝，在框202，通过框228的服务请求向请求者-客户端发送诊断消息。

然而，如果对征用请求的处理成功，如通过框222处的查询所确定的，那么，在框224向请求者-客户端202发送响应，开户行可以按征用请求行动。开户行的动作可以是开立可以被用来向供应商进行未来的支付的单次使用帐户(SUA)。在框226之后，过程200返回到请求者-客户端202，以便完成下一个实时应付帐款征用请求。

开户行的动作也可以是对现有商业帐户的信用限额进行调整，以便商业帐户将具有足够的信用限额，以向供应商进行未来的支付。商业帐户的信用限额可以被向上或向下调整，两种情况都可以影响企业在其开户行具有的总的信用限额。调整以增大现有商业帐户的信用限额可以降低企业从开户行可用信用的量，而向下调整可以使得来自开户行的由开户行向企业开立的商业帐户的更多的信用可用于由企业使用。

图3示出了过程300，其中，通过“更新支付指令/征用请求web服务”处理更新支付指令请求或者征用请求的请求。更新现有的支付指令请求或征用请求的此web服务，涉及在帐户支付自动化平台内处于挂起状态(尚未被匹配或过期)的那些请求。所支持的改变包括调整商业帐户的到期日期，替换联系人信息(例如，电子邮件地址和电子邮件便笺)，包括更新支付金额或恢复过期的支付指令。请求者-客户端302执行Web浏览器，或万维网访问应用程序，以向web服务接口(WSI)认证传输更新请求304。在框306，WSI认证尝试对更新请求进行认证。在更新请求在框306经过web服务接口认证之后，如果更新请求没有通过认证，如由查询在框308确定的，那么，方法300移动到框320。在框320，更新请求以适当的错误代码被拒绝，在框320，向请求者-客户端302发送诊断消息，过程300移动到框328，在此，有进一步被返回到请求者-客户端302的服务请求。然而，如果在框308更新请求被视为被查询认证，那么，过程300移动到框310。在框310，在验证过程中验证更新请求的消息。如果对更新请求的消息的验证失败，那么，过程300移动到框320，在此，更新请求再一次以适当的错误代码被拒绝，并向请求者-客户端302发送诊断消息，其中，在框328请求的服务是针对将消息返回到请求者-客户端302的。

然而，如果在框312更新请求的消息被视为被查询验证，那么，过程300移动到框314。在框314，标识由将被更新的支付指令或征用请求构成。此后，尝试进行验证请求。如果验证不成功，如由查询在框316确定的，那么，过程300移动到框320，在此，更新请求以适当的错误代码被拒绝，在框302，通过框328的服务请求向请求者-客户端发送诊断消息。如果查询在框316认为验证成功，则过程300移动到框316，在此，更新请求被发送到处理平台。作为示例，在图7中的框708中，处理平台被视为应付帐款处理平台。过程300从框316移到框318，在此，处理对支付的更新请求。在框321，进行对更新请求的响应的格式化。作为示例，格式化是以诸如XML之类的标记语言进行的，以便可以遵守用于因特网和web服务的协议，并可以符合该协议。过程300从框321移到框322，在此，进行查询。框322处的查询是关于处理更新请求的过程是否是成功的。如果更新请求不成功，那么，过程300从框322移到框320，在此，更新请求以适当的错误代码被拒绝，在框302，通过框328的服务请求向请求者-客户端发送诊断消息。然而，如果对更新请求的处理成功，如通过框322处的查询所确定的，那么，在框324向请求者-客户端302发送响应，开户行可以按更新请求行动。

图4示出了其中分别可以实施图1-3的过程100-300的环境400。环境400示出了被标记为“支付指令/请求”的开始框。此框示出了可以作出实时自动支付指令请求或征用请求，以在商业帐户上向商家/供应商进行支付，或可以作出扩展现有商业帐户上可用信用的请求，以便可以由商业帐户的持有人向供应商进行支付。在接收到这样的请求时，映射和加载过程将请求馈送到应付帐款数据库存储。如图4所示，应付帐款数据库存储包括支付指令请求和/或征用请求数据以及企业元数据。通过使用来自应付帐款数据库存储的这些数据，进行关于特定指令请求是否是针对用于只向供应商支付一次的单次使用商业帐户(图4中标记为“SUA”的)，或者指令类型(图4中标记为“REG”)是否是针对以定期的方式放大已经开立的商业帐户的信用限额的，以便可以由商业帐户持有人通过付款通知来从该帐户的可用信用中向供应商进行支付。取决于指令类型SUA或REG，在图4中示出了根据相应地表示的箭头的下一个过程。

对于图4中所示出的标记为“REG”的箭头，下一个过程将是，对于使用现有的商业帐户，检索现有的卡限制或帐户限制，将会对该商业帐户的信用限额作相对应的调整，以便由帐户持有人从可用于该商业帐户的信贷中向供应商进行支付。对于图4中所示出的标记为“SUA”的箭头，从由开户行向帐户持有人开立的这样的商业帐户池中检索商业帐户。然后，对SUA的信用限额作初始调整，以便帐户持有人可以通过付款通知来向供应商进行支付。

无论所采取的过程是由REG箭头所表示的还是由SUA箭头所表示的过程，一旦处理完该支付通知，将从WSI向给帐户持有人(即，企业)开立商业帐户的开户行发回响应。诸如在图4中所示出的消息基础结构，可以便利从WSI发回到开户行的响应，以便开户行完全知道帐户持有人将向其供应商进行付款的帐户所有事情。如图4所示，支付消息基础结构便利开户行的响应的返回，还在标记为“支付指令/请求”的初始框通知请求者。

环境400还示出了审核和可追溯性数据收集过程。另外，还有批处理协调模块，其中，结算数据库与数据协调过程进行通信。数据协调过程涉及用于批处理协调的自动复位引擎。相应地，虽然环境400便利由帐户持有人通过单次使用帐户或者现有帐户中的信用的扩大向供应商的实时支付，仍然，可以对于已经由帐户持有人通过使用由开户行向帐户持有人开立的各种帐户向其进行了支付的那些供应商执行协调批处理的、非实时的过程。还示出了通过环境400中的基础结构进行数据审核报告的可追溯性以及用于元数据捕捉(可以是手动过程)的预订服务。

过程500示出了具有被描绘的各个步骤的信用限额调整过程。过程500是图4中的环境400的进一步的例示。过程500从框502开始，其中，捕捉由从由各种供应商发送到帐户持有人(即，企业)的各种帐单的处理过的结算构成。过程500移动到框504，在此，对于所有不匹配的挂起的指令，有匹配过程将每一个请求(对现有的发票的支付指令请求和对未来发票的征用请求)匹配到相对应的结算。在框506作出关于支付请求是否已经被匹配的查询。如果已经匹配，那么，过程500移动到框508，作出关于是否已经请求了信用限额复位的进一步的查询。如果在框506中没有匹配支付，那么，查询的结果是过程500移动到框522，在此，确定请求是否过期。如果请求已经过期，那么，过程500移动到框524。如果在框506和508中的查询都是肯定回答，那么，过程500移动到框524。

在框524，有对处理器服务进行的调用，涉及调整商业帐户上的由帐户持有人用来向供应商进行支付的信用限额。框524与卡管理web服务进行通信，以通过消息基础结构全套设备528发送和接收消息。消息基础结构全套设备528便利在框530中看到三种不同类型的处理器提供的web服务中的一种。web服务的处理器服务可以由交易处理设备或其代理(如图8中的交易处理设备(th)802)来提供，如下面比较全面地说明的。这些处理器提供的web服务便利与商业帐户的开户行不同的多种功能，包括：(i)调整对由开户行向帐户持有人开立的商业帐户的限制，以便将会有足够的资金可用或足够的信用可用，供帐户持有人向供应商进行支付；(ii)便利新单次使用帐户的可用性，从该帐户可以由向其开立了SUA的帐户持有人向供应商进行支付；以及(iii)对现有商业帐户的信用限额进行调整。

在框524，过程500前进到框512，以确定对支付指令的处理是否成功。如果过程没有成功，那么，过程500移动到框530。在框530，作出示出了信用限额复位失败的关于状态的标记或其他报告。在框530触发异常警告，此后，过程500在框532以失败结束。可任选地，可以通过消息基础结构全套设备528，通过卡管理服务526，发送表征失败的消息。

如果框512处的查询确定对支付指令的处理已经成功，那么，过程500移动到框514。在框514，设置指令被关闭的状态，相应地，发送关于匹配的支付指令和过期的支付指令的通知。一旦在框514关闭了关于状态的设置指令，过程500移动到框516，在此，进行关于商业帐户是否是SUA的查询。如果不是，则过程500在框520，指出成功。然而，如果商业帐户是SUA，那么，在框518，SUA被返回到帐户池，过程500在框520成功结束。

在框508处看到的查询是关于是否有必要对帐户上的信用限额进行调整，如果没有必要对帐户的信用限额进行调整，那么，过程500可以移动到框520，完成，因为不需要对已经被标识为用于支付指令的帐户进行调整。图5示出了用于调整对由开户行向帐户持有人开立的帐户的限制的方法500。如此处所使用的，帐户持有人可以持有来自开户行的一个或多个帐户。开户行将使用过程500来适当地调整对帐户的限制，以便可以为提供到帐户持有人的各种商品及服务向帐户持有人的供应商进行支付或被提供到帐户持有人在财务上对其负责的另一实体。这些对各种帐户的信用限额的调整是通过各种处理器提供的web服务在web服务基础结构中进行的。在过程500内流动的消息将优选地是典型地用于万维网和/或因特网通信协议的标记语言。这些消息传送服务在框526中被标记为“卡管理web服务”。标记为“消息基础结构”的框528便利与如标记为“处理器提供的web服务”的框530和标记为“卡管理web服务”的框528中所示出的那些功能进行通信。

图6描绘了用于处理来自客户端(如图1-3中的请求者-客户端102，202和302)的支付请求的示例性方法600的流程图。在过程600的步骤602中，请求方客户端将通过HTTPS上的SOAP消息来调用web服务。支付指令请求优选地为嵌入在SOAP正文内的XML格式。在过程600的步骤604中，传入的请求将由交易处理设备web服务基础结构(WSI)网关(例如，分别参见图1-3中的框108、208和308)进行认证。作为示例，“交易处理设备”可以由图8中的交易处理设备(th)802来实现或由其代理来实现。如果认证失败，则支付请求将以适当的错误代码/响应于支付请求而返回的消息被拒绝(例如，分别参见图1-3中的框120，220和320)。

如果认证成功，那么，对请求的处理将继续，过程600移动到框606。在框606，将验证XML内容，以确保支付指令标识符没有被预先接收，从而确保请求是新的支付指令。另外，还将会有支付指令具有任何所需值的验证(例如，分别参见图1-3中的框112，212和312)。如果验证失败，则支付请求将以适当的错误代码/响应于支付请求而返回的消息被拒绝(例如，分别参见图1-3中的框120，220和320)。

如果支付请求通过验证，则它将被路由到AP自动化平台(例如，参见图7中的附图标记708)供进行处理，过程600移动到框608。在框608，基于商业帐户的标识符，应付帐款自动化服务将拉SUA或者将使用现有所提供的商业帐户来处理支付请求，然后将完成状态返回到web服务。然后，过程600移动到框610，在此，web服务将格式化对发送到请求方客户端(如图1-3中的请求者-客户端102，202和302)的支付请求的XML响应(例如，分别参见图1-3中的框118，218和321)。

图7示出了其中开户行702通过因特网与网络设备704进行通信的环境700。开户行(在图8中，示例为开户行(i)804)，向企业(在图8中，示例为帐户持有人(a)808)开立商业帐户。网络设备704通过web服务接口与交易处理设备的应付帐款在线web服务模块706进行通信。交易处理设备的示例在图8中为交易处理设备(th)802。作为示例，而不作为限制，交易处理设备可以是诸如Visa Inc.、MasterCard、American Express、Discover Card、Diners Club等等之类的支付卡公司。交易处理设备应付帐款在线web服务模块706通过交易处理设备web服务接口与应付帐款处理平台708进行通信。应付帐款处理平台708的示例在图1-3中被分别称为附图标记114、214、以及318。

在某些实现中，上文所描述的单个的方框可以被组合、消除或重新排序。在某些实现中，指令被编码到计算机可读介质中，其中，那些指令由硬件(例如，一个或多个处理器)来执行，以执行图1-7中的框中的一个或多个。在其他实现中，指令驻留在任何其他计算机程序产品中，其中，那些指令由计算系统外部的，或内部的计算机执行，以执行图1-7中的框中的一个或多个。在任一种情况下，指令可以被编码在非瞬时计算机可读介质中，包括，例如，磁性信息存储介质、光信息存储介质、电子信息存储介质等等。“电子存储介质”可以表示，例如，但不仅限于，一个或多个设备，诸如，但不仅限于，PROM、EPROM、EEPROM、闪存PROM、CompactFlash、SmartMedia等等。结合此处所公开的各实现所描述的方法、过程或算法的各个步骤可直接用硬件、由处理器执行的软件模块、或两者的组合来实现。在某些实现中，指令被编码到计算机可读介质中，其中，那些指令由处理器来执行，以执行在描述图1-7时所列举的步骤中的一个或多个。

支付处理系统

现在转向图8，示出了示例性支付处理系统800，以描绘其中可以执行方法100-700的一般环境。在支付处理系统800中，商家(m)810可以与帐户用户(au)在由开户行(i)804向帐户持有人(a)808开立的帐户(即，预存款帐户)上执行对于商品和/或服务的交易，其中，对于交易的支付和被支付的过程由交易处理设备(th)802来协调，其中，交易处理设备802包括交易处理设备(1)到交易处理设备(TH)，其中，TH可以达到并大于八位整数。交易包括来自不同的实体的参与，每一个实体都是支付处理系统800的组件。

支付处理系统800具有多个商家810，包括商家(1)810到商家(M)810，其中，M可以达到并大于八位整数。

支付处理系统800具有多个预存款帐户808，每一个预存款帐户808都由相对应的帐户持有人(1)808到帐户持有人(A)808持有，其中，A可以达到并大于十位整数。

支付处理系统800包括帐户用户(1)808到帐户用户(AU)808，其中，AU可以与十位整数一样大或更大。每一个帐户用户(au)808都使用由开户行(i)804向相对应的帐户持有人(a)808开立的帐户(即，预存款帐户)与商家(m)810执行对于商品和/或服务的交易。来自帐户上的交易的数据由商家(m)810收集，并被转发到相对应的受理行(q)806。受理行(q)806将数据转发到交易处理设备802，该交易处理设备802便利对于交易的从由开户行(i)804开立的预存款帐户向帐户持有人(a)808的支付。

支付处理系统800具有多个开户行804。每一个开户行(i)804都可以由相对应的代理开户行(ai)804帮助处理一个或多个交易，其中，“i”可以是从1到I的整数，其中，“ai”可以是从1到AI的整数，其中，I和AI可以与八位整数一样大或更大。

支付处理系统800具有多个受理行806。每一个受理行(q)806都可以由相对应的代理受理行(aq)806帮助处理一个或多个交易，其中，“q”可以是从8到Q的整数，其中，“aq”可以是从8到AQ的整数，其中，Q和AQ可以与八位整数一样大或更大。

支付处理系统800具有交易处理设备802以处理多个交易。交易处理设备802可包括一个或多个网络和交换机802。每一个网络/交换机(ns)802都可以是位于不同于其他网络/交换机(ns)802的地理位置的大型计算机，其中，“ns”是从1到NS的整数，其中，NS可以与四位整数一样大或更大。

专用通信系统820，822(即，专用通信网)便利交易处理设备802和每一个开户行(i)804和每一个受理行(q)806之间的通信。因特网812，通过电子邮件，万维网，蜂窝电话，和/或其他可选的公共和专用通信系统，可以便利每一个开户行(i)804、每一个受理行(q)806、每一个商家(m)810、每一个帐户持有人(a)808，以及交易处理设备802之间的通信822a-822e。可另选地并可任选地，一个或多个专用通信系统824、826以及828可以分别便利每一个受理行(q)806和每一个商家(m)810、每一个商家(m)810和每一个帐户持有人(a)808，每一个帐户持有人(a)808和每一个开户行(i)804之间的相应的通信。

每一个受理行(q)806都可以由相对应的代理受理行(aq)806帮助处理一个或多个交易，其中，“q”可以是从8到Q的整数，其中，“aq”可以是从8到AQ的整数，其中，Q和AQ可以与八位整数一样大或更大。

商家(m)810可以是销售商品和/或服务的人或实体。商家(m)810也可以是，例如，制造商、经销商、零售商、装货代理、药店、杂货店、加油站、五金店、超市、精品店、餐厅或诊所。在B2B环境中，帐户持有人(a)808可以是从另一个商家(m)810进行采购的第二商家。商家(m)810可以使用可以与受理行(q)806、交易处理设备802或开户行(i)804进行通信的至少一个销售点终端(POS)。如此，POS终端与支付处理系统800进行可操作的通信。

通常，交易从帐户用户(au)808向商家(m)810呈现便携式消费者设备开始，以启动商品或服务交换。便携式消费者设备可以与由开户行(i)804向帐户持有人(a)808开立的帐户持有人(a)808的帐户(例如，预存款帐户)相关联。

便携式消费者设备可以是支付卡、礼品卡、智能卡、智能介质、工资单卡、保健卡、腕带、包含帐户信息的机器可读的介质，诸如ExxonMobil Corporation在市场上销售的

设备之类的钥匙链设备，超市折扣卡、蜂窝电话、个人数字助理、寻呼机、社保卡、通达卡、无线终端或转发器。便携式消费者设备可包括易失性或非易失性存储器以存储诸如帐号或帐户持有人(a)808的姓名之类的信息。

商家(m)810可以使用POS终端以从便携式消费者设备获取帐户信息，如帐户持有人(a)808的帐号。便携式消费者设备可以使用包括任何合适的电的、磁的或光的连接系统(诸如使用射频的无触点系统，或诸如磁条读取器之类的磁场识别系统或接触系统)的机制，与POS终端连接。POS终端向对应于便携式消费者设备的帐户的开户行(i)804发送交易授权请求。可另选地，或组合地，便携式消费者设备可以与开户行(i)804、交易处理设备802或受理行(q)806进行通信。

开户行(i)804可以使用交易处理设备802来授权交易。交易处理设备802也可以清算交易。授权包括开户行(i)804，代表开户行(i)804的交易处理设备802，诸如通过使用业务规则，参考开户行(i)804的指令，授权交易。业务规则可包括来自交易处理设备802、帐户持有人(a)808、商家(m)810、受理行(q)806、开户行(i)804、相关的金融机构，或其组合的指令或原则。交易处理设备802可以维护被授权的交易的日志或历史。一旦被批准，商家(m)810将记录授权，允许帐户用户(au)808从商家(m)810或其代理接收商品或服务。

商家(m)810可以，在个别的时段，诸如当天结束时，通过支付处理系统800将被授权的交易的列表或其他交易相关的数据提交到受理行(q)806，供进行处理。交易处理设备802可以将已提交的被授权的交易列表与其自己的被授权的交易的日志进行比较。如果发现匹配，则交易处理设备802可以将来自相对应的受理行(q)806的授权交易金额请求传输到参与每一个交易的相对应的开户行(i)804。一旦受理行(q)806从开户行(i)804接收到对被授权的交易金额的支付，受理行(q)806就可以将支付转帐到商家(m)810，减去诸如处理交易的费用之类的任何交易成本。如果交易涉及贷记或预付卡，则受理行(q)806可以选择在向商家(m)810支付之前不等待开户行(i)804转发支付。

在前面的过程中可以有间歇的步骤，其中一些可以同时发生。例如，受理行(q)806可以启动清算和结算过程，这可以导致向受理行(q)806支付交易的金额。受理行(q)806可以从交易处理设备802请求清算和结算交易。清算包括开户行(i)804和受理行(q)806之间的财务信息的交换，而结算包括资金的交换。交易处理设备802可以提供与交易的结算有关的服务。对交易的结算包括将交易结算的金额从交易处理设备802通常选择的诸如结算银行之类的结算所储存到受理行(q)806通常选择的诸如清算银行之类的清算所。开户行(i)804将相同的金额从开户行(i)804通常选择的诸如清算银行之类的清算所储存到结算所。如此，典型的交易涉及各种实体以请求、授权，以及完成处理交易。

优选地，支付处理系统800将具有适于调整实时和批处理中可以被授权，清算和结算的交易的数量和数据有效负载大小的网络组件。这些包括硬件、软件、数据元素，以及用于前者的存储网络设备。支付处理系统800的示例包括至少部分地由American Express、MasterCard、Discover Card、First Data Corporation、Diners Club，以及Visa Inc.以及前述的各公司的代理运营的那些。

每一个网络/交换机(ns)802可包括用于处理交易的一个或多个数据中心，其中，每一个交易都可包括最多100个千字节的数据或更多。对应于交易的数据可包括有关交易中的商品及服务的类型和数量的信息，有关帐户持有人(a)808、帐户用户(au)808、商家(m)810，商品及服务的激励待遇、赠券、回扣、奖励、忠诚度、折扣、返还、交换、现金返还交易等等的信息。

作为示例，网络/交换机(ns)802可包括用于通过系统820，822进行通信的一个或多个大型计算机(即，一个或多个IBM大型计算机)，一个或多个服务器场(即，一个或多个Sun UNIX超级服务器)，其中，大型计算机和服务器场可以位于不同的地理位置。

每一个开户行(i)804(或其代理开户行(ai)804)和每一个受理行(q)806(或其代理受理行(aq)806)都可以使用一个或多个路由器/交换机(即，Cisco路由器/交换机)来分别通过专用通信系统820，822与每一个网络/交换机(ns)802进行通信。

交易处理设备802可以将有关通过支付处理系统800处理的交易的信息存储在数据仓库中，如可以合并为多个网络/交换机802的一部分。可以对此信息进行数据挖掘。数据挖掘交易研究和建模可以用于广告、帐户持有人和商家忠诚度激励和奖励，欺诈检测和预测，开发表明通过使用支付处理系统800相对于利用现金、支票支付和被支付或其他传统的支付机制所取得的可能的节省量和效率的工具。

图8包括一个或多个交易处理设备(th)802和接入点830、832。诸如票据付款行和第三方授权代理之类的其他实体也可以通过接入点连接到网络。交换中心是可以位于世界上任何地方的数据处理中心。在一个实施例中，在美国有两个，在英国和日本各一个。每一个交换中心都托管了执行网络交易处理的计算机系统。交换中心充当网络的通信设施的控制点，包括基于IBM SNA协议的高速度租用线路或卫星连接。优选地，连接交换中心(交易处理设备(th)802)与远程实体的通信线路使用基于IBM SNA-LU0通信协议的专用的高带宽电话线路或卫星连接。消息是使用ISO 8583标准的任何合适的实现通过这些线路发送的。

接入点830，832通常由位于连接在中心的主机计算机和交换中心之间的处理中心的小型计算机系统构成。接入点便利消息和文件在主存和支持交易的授权、清算和结算的交换中心之间的传输。受理行(q)806和其接入点之间的，以及接入点和开户行(i)804之间的电信链路通常是中心内的本地链路，并使用由中心首选的专有的消息格式。

数据处理中心(如位于受理行、开户行或其他实体内)托管了支持商家和企业场所的处理系统并维护客户数据和记帐系统。优选地，每一个处理中心都链接到一个或两个交换中心。处理器连接到最近的交换中心，如果网络经历中断，则网络自动将交易路由到辅助交换中心。每一个交换中心还都链接到所有其他交换中心。此链接允许处理中心通过一个或多个交换中心相互进行通信。此外，处理中心还可以通过交换中心访问其他程序的网络。此外，网络还确保所有链接都具有多个备份。从网络的一个点到另一点的连接通常不是固定的链路；相反，交换中心在进行任何给定的传输时都选择尽可能好的路径。围绕任何有故障的链路的重新路由都是自动进行的。

交易处理设备(th)802可以将有关通过交易处理系统800处理的交易的信息存储在数据仓库中，如可以合并为多个网络/交换机802的一部分。可以对此信息进行数据挖掘。数据挖掘交易研究和建模可以用于广告、帐户持有人和商家忠诚度激励和奖励，欺诈检测和预测，并开发工具以证明相对于利用现金支付和被支付或其他传统的支付机制通过使用交易处理系统800所可能取得的节省量和效率。系统是交易处理系统800中的交易处理设备(th)802的示例组件。目前，

系统部分地由Visa Inc.公司运营。到2006年为止，

system Inc.每天在170个国家中所使用的超过十亿的帐户中处理大约3亿次的交易。超过16,000的财务指令通过VisaNet系统连接到大约3千万商家(m)810。在2007，通过

系统清算和结算了大约4兆美元的大约710亿次交易，其中一些涉及在大约2秒内大约24,000英里的通信长度，为处理交易中的数据，进行了多次停止。

与此处所公开的实现一起对步骤、方法、过程，以及设备的描述参考了图形，其中，相同的附图标记代表相同或类似的元件。尽管是通过最佳模式来进行描述的，但是，本领域的技术人员可以理解，描述计划涵盖可以被包括在如所附权利要求书所定义的本发明的精神和范围以及由下面的描述和图形所支持的它们的等效内容内的替代方案、修改和等效内容。在本说明书中对“一个实现”或“实现”的引用，或类似的语言，意味着，涉及实现所描述的特定功能、结构或特征包括在本发明的至少一个实现中。如此，在本说明书中出现的短语“在一种实现中”或“在实现中”以及类似的语言可以，但不一定都是指同一个实现。

在一个或多个实现中，所描述的本发明的功能、结构或特征可以以任何合适的方式来组合。此外，在下面的描述中，列举了很多具体细节，以便提供对本发明的各种实现的全面的了解。然而，那些本领域的普通人员将认识到，本发明可以在没有一个或多个具体细节的情况下来实现，或利用其他方法、组件、材料等等来实现。在其他情况下，没有示出或详细描述已知的结构、材料、或操作，以避免使本发明的某些方面变得模糊。

结合此处所公开的各实现所描述的方法、过程或算法的各个步骤可直接用硬件、由处理器执行的软件模块、或两者的组合来实现。在某些实现中，指令被编码到计算机可读介质中，其中，那些指令由处理器来执行，以执行所列举的步骤中的一个或多个。

方法或过程中的各个步骤或动作可以按照所示出的顺序执行，或者也可以按另一种顺序执行。另外，也可以省略一个或多个过程或方法步骤，或者也可以将一个或多个过程或方法步骤添加到这些方法和过程中。可以在方法和过程的开始、结尾，或中间现有的元素中添加额外的步骤、块或动作。

本发明可具体化为其它具体形式而不背离其精神或本质特征。所描述的实现在所有方面都应被认为仅是说明性而非限制性的。从而，本发明的范围由所附权利要求书而非前述描述指示。落入权利要求书的等效方案的含义和范围内的所有改变应被权利要求书的范围所涵盖。

Claims (20)

1.一种包括多个步骤的方法，每一个步骤都是由执行软件的计算硬件来执行的，其中，所述步骤包括：

在web服务中接收来自客户端的标识商业帐户池中的一个商业帐户的请求，其中：

所述一个商业帐户是未使用的，而所述商业帐户池中的其他所述商业帐户正在使用中；

所请求的一个未使用的商业帐户将被用来在该商业账户上对于来自所述供应商的发票向帐户持有人的供应商进行一次支付；以及

所述请求包括对于所请求的未使用的一个商业帐户的信用限额；

从所述web服务向所请求的未使用的一个商业帐户的开户行发送确定下列各项的可用性的请求：

所述商业帐户池中的所请求的未使用的一个商业帐户；以及

由所述开户行向所述帐户持有人提供的可用信用中的所请求的信用限额，其中所述开户行向所述帐户持有人开立了所述商业帐户池中的每一个所述商业帐户；

在所述web服务处接收来自所述开户行的对请求的响应；以及

当所述响应包括验证所请求的未使用的一个商业帐户和对所请求的未使用的一个商业帐户的所请求的信用限额两者都被确定为可用的信息时，向所述开户行发送支付指令以通过使用所请求的未使用的一个商业帐户的可用信用限额来对供应商的发票进行电子支付，其中，接收所述请求，向所述开户行发送所述请求，以及从所述开户行接收所述响应都是实时发生的。

2.如权利要求1所述的方法，其中：

接收的请求和接收的对所述请求的响应中的每一个都包括包含标记语言的格式的数据的传输；以及

发送到所述开户行的支付指令包括包含标记语言的格式的数据的传输。

3.如权利要求1所述的方法，其中，接收所述请求，向所述开户行发送所述请求，以及从所述开户行接收所述响应中的每一项都是由与所述供应商的受理行和所述开户行进行通信的交易处理设备执行的，以便利对所请求的未使用的一个商业帐户上的关于授权、清算和结算的涉及所述发票的交易的处理。

4.一种包括用于执行如权利要求1所述的方法的通过网络进行通信的一个或多个服务器的设备。

5.一种具有可由硬件执行以执行如权利要求1所述的方法的指令的非瞬时计算机可读介质。

6.一种包括多个步骤的方法，每一个步骤都由执行软件的计算硬件来执行，其中，所述步骤包括：

在web服务上接收来自客户端的按商业帐户的要被使用的金额来调整信用限额，以在该商业账户上对于所述供应商的发票向帐户持有人的供应商进行支付的请求；

与请求一起从所述web服务向所述商业帐户的开户行发送帐户的标识符和所述金额，以确定根据向所述帐户持有人开立了所述商业帐户的开户行所提供的可用信用按所述金额对所述商业帐户的信用限额进行请求的调整的可用性；

在所述web服务处接收来自所述开户行的对请求的响应；以及

当所述响应包括验证所述商业帐户和对于所述商业帐户的所请求的信用限额调整两者都被确定为可用的信息时，向所述开户行发送支付指令以通过使用所述商业帐户的经调整的信用限额来对供应商的发票进行电子支付，其中，接收所述请求，向所述开户行发送所述请求，以及从所述开户行接收所述响应都是实时发生的。

7.如权利要求6所述的方法，其中：

接收的请求和接收的对所述请求的响应中的每一个都包括包含标记语言的格式的数据的传输；以及

发送到所述开户行的支付指令包括包含标记语言的格式的数据的传输。

8.如权利要求6所述的方法，其中，接收所述请求，向所述开户行发送所述请求，以及从所述开户行接收所述响应中的每一项都是由与所述供应商的受理行和所述开户行进行通信的交易处理设备执行的，以便利商业帐户上的关于授权、清算和结算的涉及所述发票的交易的处理。

9.包括用于执行如权利要求6所述的方法的通过网络进行通信的一个或多个服务器的设备。

10.具有可由硬件执行以执行如权利要求6所述的方法的指令的非瞬时计算机可读介质。

11.一种包括多个步骤的方法，每一个步骤都由执行软件的计算硬件来执行，其中，所述步骤包括：

在开户行处从web服务接收确定下列各项的可用性的请求：

所述商业帐户池中的未使用的商业帐户，其中，所述未使用的商业帐户将被用来在该商业账户上对于来自所述供应商的发票向帐户持有人的供应商进行一次支付；以及

由所述开户行向所述帐户持有人提供的信用限额，其中所述开户行向所述帐户持有人开立了所述商业帐户池中的每一个所述商业帐户；

在所述开户行处确定下列各项的可用性：

所述商业帐户池中的所请求的未使用的商业帐户；以及

所请求的信用限额；

从所述开户行向所述web服务发送来自所述开户行的对所述请求的响应，所述响应具有验证所请求的未使用的一个商业帐户和所请求的未使用的一个商业帐户的所请求的信用限额被确定为可用的信息；

在所述开户行处从所述web服务接收通过使用所请求的未使用的一个商业帐户的所述可用信用限额来向所述供应商进行所述发票的电子支付；以及

从所述开户行，通过使用所请求的未使用的一个商业帐户的所述可用信用限额，发送以所述供应商为受益人的所述发票的支付，其中，接收所述请求，发送所述响应，接收所述支付指令，以及发送所述对所述发票的支付都是实时发生的。

12.如权利要求11所述的方法，其中，所述请求、所述响应以及所述支付指令中的每一个都包括一个或多个传输，每一个传输都包含标记语言的格式的数据。

13.如权利要求11所述的方法，其中，所述web服务是与所述供应商的受理行进行通信并与所述开户行进行通信的交易处理设备，以便利对所请求的未使用的一个商业帐户上的关于授权、清算和结算的涉及所述发票的交易的处理。

14.包括用于执行如权利要求11所述的方法的通过网络进行通信的一个或多个服务器的设备。

15.包括可由硬件执行以执行如权利要求11所述的方法的指令的非瞬时计算机可读介质。

16.一种包括多个步骤的方法，每一个步骤都由执行软件的计算硬件来执行，其中，所述步骤包括：

在商业帐户的开户行处从web服务接收所述商业帐户的标识符以及从来源于与所述web服务进行通信的客户端的请求导出的金额，

其中，所述请求是确定根据向帐户持有人开立了商业帐户的所述商业帐户的开户行所提供的可用信用按所述金额对商业账户的信用限额进行调整的可用性，其中，来自所述客户端的所述请求是对于来自所述供应商的发票进行从所述商业帐户向所述帐户持有人的供应商的所述金额的支付；

在开户行处，使用所述商业帐户的所述标识符和所述金额，确定对于所述帐户持有人按所述金额对所述商业帐户的信用限额进行调整的可用性；

从所述开户行向所述web服务发送对所述请求的响应，所述响应包括验证所述商业帐户和对于所述商业帐户的所请求的信用限额调整两者都被确定为可用的信息；

在所述开户行处从所述web服务接收通过使用所述商业帐户的调整的信用限额来向所述供应商进行所述发票的电子支付；以及

通过使用所述商业帐户的可用信用限额，从所述开户行向所述web服务发送以所述供应商为受益人的所述发票的支付，其中，接收所述请求，确定，发送响应，接收支付指令，以及发送对发票的支付都是实时发生的。

17.如权利要求16所述的方法，其中，所述请求、所述响应以及所述支付指令中的每一个都包括一个或多个传输，每一个传输都包含标记语言的格式的数据。

18.如权利要求16所述的方法，其中，所述web服务是与所述供应商的受理行进行通信并与所述开户行进行通信的交易处理设备，以便利对所述商业帐户上的关于授权、清算和结算的涉及所述发票的交易的处理。

19.一种包括用于执行如权利要求16所述的方法的通过网络进行通信的一个或多个服务器的设备。

20.一种包括可由硬件执行以执行如权利要求16所述的方法的指令的非瞬时计算机可读介质。

Images