用于处理资金支出交易的方法、系统和计算机程序产品

相关申请交叉引用

本申请要求于2018年8月10日提交的标题为“用于处理资金支出交易的方法、系统和计算机程序产品(Method,System,and Computer Program Product for Processing aFund Disbursement Transaction)”的第16/100,861号美国专利申请的优先权，所述美国专利申请的公开内容以全文引用的方式并入本文中。

技术领域

本公开涉及用于处理资金支出交易的方法、系统和计算机程序产品，且在一个示例中，涉及使用原始信用证交易处理资金支出交易的方法、系统和计算机程序产品。

背景技术

通常处理资金支出请求以将支出金额从企业商家账户支出到消费者账户。在一个示例中，企业商家账户是与保险公司相对应的账户，而消费者账户是与从保险公司购买保险单的索赔人相对应的账户。在消费者向保险公司提交保险索赔时，保险公司将根据保险单向消费者账户支出资金，以结算索赔。这些支出请求必须及时处理。

处理此类资金支出请求的现有系统仅凭借部分地基于企业商家信誉而建立的收单方控制。现有系统不会考虑企业商家账户中的实际可用资金金额。因此，当资金支出请求符合收单方控制的要求时，由收单方向消费者账户支出资金，而无论企业商家账户是否含有足够的资金能覆盖转账。此类系统将责任放在收单方系统，而不是作为资金不足的实体的企业商家。这实际上妨碍了收单方系统在资金支出交易情境中有效利用原始信用证交易。

发明内容

因此，且大体上，提供使用原始信用证交易转账来处理资金支出交易的改进的方法、系统和计算机程序产品。

根据非限制性实施例或方面，提供一种用于处理资金支出交易的计算机实施的方法，包括：由支出提供商系统的至少一个处理器接收资金支出请求，所述资金支出请求标识要从商家账户支出到消费者账户的支出金额；由所述至少一个处理器且部分地基于所述资金支出请求确定将从其转移所述支出金额的所述商家账户和将向其转移所述支出金额的所述消费者账户；由所述至少一个处理器基于所述支出金额和所述商家账户生成第一授权请求；由所述至少一个处理器将所述第一授权请求传送到所述收单方系统；由所述至少一个处理器从所述收单方系统接收第一授权响应，所述第一授权响应包括关于所述商家账户是否包括所述支出金额的确定；以及响应于确定所述第一授权响应包括授权支出所述支出金额的批准，由所述至少一个处理器生成第二授权请求，所述第二授权请求被配置成使得对应于所述消费者账户的发行方系统发起向所述消费者账户推送支付所述支出金额。

在一个非限制性实施例或方面，所述第二授权请求可以包括标识与所述资金支出交易相关联的交换费的类型标识符。所述方法还可包括：响应于确定所述商家账户包括所述支出金额，对所述商家账户冻结所述支出金额。可以在接收到所述资金支出请求1小时内传送所述第二授权请求。所述支出提供商系统可以包括支付网关。所述资金支出请求可以是使用对应于所述消费者账户的借记卡发起的。对应于所述商家账户的所述收单方系统可以由发行对应于所述商家账户的借记卡的发行方操作。所述商家账户可以对应于企业商家。

根据非限制性实施例或方面，提供一种用于处理资金支出交易的支出提供商系统，包括至少一个服务器计算机，所述至少一个服务器计算机包括至少一个处理器，所述至少一个服务器计算机被编程和/或配置成：接收资金支出请求，所述资金支出请求标识要从商家账户支出到消费者账户的支出金额；部分地基于所述资金支出请求确定将从其转移所述支出金额的所述商家账户和将向其转移所述支出金额的所述消费者账户；基于所述支出金额和所述商家账户生成第一授权请求；将所述第一授权请求传送到所述收单方系统；从所述收单方系统接收第一授权响应，所述第一授权响应包括关于所述商家账户是否包括所述支出金额的确定；以及响应于确定所述第一授权响应包括授权支出所述支出金额的批准，生成第二授权请求，所述第二授权请求被配置成使得对应于所述消费者账户的发行方系统发起向所述消费者账户推送支付所述支出金额。

在一个非限制性实施例或方面，所述第二授权请求可以包括标识与所述资金支出交易相关联的交换费的类型标识符。所述至少一个服务器计算机还可被编程和/或配置成：响应于确定所述商家账户包括所述支出金额，对所述商家账户冻结所述支出金额。可以在接收到所述资金支出请求1小时内传送所述第二授权请求。所述支出提供商系统可以包括支付网关。所述资金支出请求可以是使用对应于所述消费者账户的借记卡发起的。对应于所述商家账户的所述收单方系统可以由发行对应于所述商家账户的借记卡的发行方操作。所述商家账户可以对应于企业商家。

根据非限制性实施例或方面，提供一种用于处理资金支出交易的计算机程序产品，包括至少一个非瞬态计算机可读介质，所述非瞬态计算机可读介质包括程序指令，所述程序指令在由至少一个处理器执行时使所述至少一个处理器：在支出提供商系统上接收资金支出请求，所述资金支出请求标识要从商家账户支出到消费者账户的支出金额；部分地基于所述资金支出请求确定将从其转移所述支出金额的所述商家账户和将向其转移所述支出金额的所述消费者账户；基于所述支出金额和所述商家账户生成第一授权请求；将所述第一授权请求传送到所述收单方系统；从所述收单方系统接收第一授权响应，所述第一授权响应包括关于所述商家账户是否包括所述支出金额的确定；以及响应于确定所述第一授权响应包括授权支出所述支出金额的批准，生成第二授权请求，所述第二授权请求被配置成使得对应于所述消费者账户的发行方系统发起向所述消费者账户推送支付所述支出金额。

在一个非限制性实施例或方面，所述第二授权请求可以包括标识与所述资金支出交易相关联的交换费的类型标识符。所述程序指令还可使所述至少一个处理器：响应于确定所述商家账户包括所述支出金额，对所述商家账户冻结所述支出金额。可以在接收到所述资金支出请求1小时内传送所述第二授权请求。所述支出提供商系统可以包括支付网关。所述资金支出请求可以是使用对应于所述消费者账户的借记卡发起的。对应于所述商家账户的所述收单方系统可以由发行对应于所述商家账户的借记卡的发行方操作。所述商家账户可以对应于企业商家。

在以下编号的条款中阐述其它实施例或方面：

条款1：一种用于处理资金支出交易的计算机实施的方法，包括：由支出提供商系统的至少一个处理器接收资金支出请求，所述资金支出请求标识要从商家账户支出到消费者账户的支出金额；由所述至少一个处理器且部分地基于所述资金支出请求确定将从其转移所述支出金额的所述商家账户和将向其转移所述支出金额的所述消费者账户；由所述至少一个处理器基于所述支出金额和所述商家账户生成第一授权请求；由所述至少一个处理器将所述第一授权请求传送到所述收单方系统；由所述至少一个处理器从所述收单方系统接收第一授权响应，所述第一授权响应包括关于所述商家账户是否包括所述支出金额的确定；以及响应于确定所述第一授权响应包括授权支出所述支出金额的批准，由所述至少一个处理器生成第二授权请求，所述第二授权请求被配置成使得对应于所述消费者账户的发行方系统发起向所述消费者账户推送支付所述支出金额。

条款2：根据条款1所述的计算机实施的方法，其中所述第二授权请求包括标识与所述资金支出交易相关联的交换费的类型标识符。

条款3：根据条款1或2所述的计算机实施的方法，还包括：响应于确定所述商家账户包括所述支出金额，对所述商家账户冻结所述支出金额。

条款4：根据条款1至3中任一项所述的计算机实施的方法，其中在接收到所述资金支出请求1小时内传送所述第二授权请求。

条款5：根据条款1至4中任一项所述的计算机实施的方法，其中所述支出提供商系统包括支付网关。

条款6：根据条款1至5中任一项所述的计算机实施的方法，其中所述资金支出请求是使用对应于所述消费者账户的借记卡发起的。

条款7：根据条款1至6中任一项所述的计算机实施的方法，其中对应于所述商家账户的所述收单方系统由发行对应于所述商家账户的借记卡的发行方操作。

条款8：根据条款1至7中任一项所述的计算机实施的方法，其中所述商家账户对应于企业商家。

条款9：一种用于处理资金支出交易的支出提供商系统，包括至少一个服务器计算机，所述至少一个服务器计算机包括至少一个处理器，所述至少一个服务器计算机被编程和/或配置成：接收资金支出请求，所述资金支出请求标识要从商家账户支出到消费者账户的支出金额；部分地基于所述资金支出请求确定将从其转移所述支出金额的所述商家账户和将向其转移所述支出金额的所述消费者账户；基于所述支出金额和所述商家账户生成第一授权请求；将所述第一授权请求传送到所述收单方系统；从所述收单方系统接收第一授权响应，所述第一授权响应包括关于所述商家账户是否包括所述支出金额的确定；以及响应于确定所述第一授权响应包括授权支出所述支出金额的批准，生成第二授权请求，所述第二授权请求被配置成使得对应于所述消费者账户的发行方系统发起向所述消费者账户推送支付所述支出金额。

条款10：根据条款9所述的系统，其中所述第二授权请求包括标识与所述资金支出交易相关联的交换费的类型标识符。

条款11：根据条款9或10所述的系统，其中所述至少一个服务器计算机还被编程和/或配置成：响应于确定所述商家账户包括所述支出金额，对所述商家账户冻结所述支出金额。

条款12：根据条款9至11中任一项所述的系统，其中在接收到所述资金支出请求1小时内传送所述第二授权请求。

条款13：根据条款9至12中任一项所述的系统，其中所述支出提供商系统包括支付网关。

条款14：根据条款9至13中任一项所述的系统，其中所述资金支出请求是使用对应于所述消费者账户的借记卡发起的。

条款15：根据条款9至14中任一项所述的系统，其中对应于所述商家账户的所述收单方系统由发行对应于所述商家账户的借记卡的发行方操作。

条款16：根据条款9至15中任一项所述的系统，其中所述商家账户对应于企业商家。

条款17：一种用于处理资金支出交易的计算机程序产品，包括至少一个非瞬态计算机可读介质，所述非瞬态计算机可读介质包括程序指令，所述程序指令在由至少一个处理器执行时使所述至少一个处理器：在支出提供商系统上接收资金支出请求，所述资金支出请求标识要从商家账户支出到消费者账户的支出金额；部分地基于所述资金支出请求确定将从其转移所述支出金额的所述商家账户和将向其转移所述支出金额的所述消费者账户；基于所述支出金额和所述商家账户生成第一授权请求；将所述第一授权请求传送到所述收单方系统；从所述收单方系统接收第一授权响应，所述第一授权响应包括关于所述商家账户是否包括所述支出金额的确定；以及响应于确定所述第一授权响应包括授权支出所述支出金额的批准，生成第二授权请求，所述第二授权请求被配置成使得对应于所述消费者账户的发行方系统发起向所述消费者账户推送支付所述支出金额。

条款18：根据条款17所述的计算机程序产品，其中所述第二授权请求包括标识与所述资金支出交易相关联的交换费的类型标识符。

条款19：根据条款17或18所述的计算机程序产品，其中所述程序指令还使所述至少一个处理器：响应于确定所述商家账户包括所述支出金额，对所述商家账户冻结所述支出金额。

条款20：根据条款17至19中任一项所述的计算机程序产品，其中在接收到所述资金支出请求1小时内传送所述第二授权请求。

条款21：根据条款17至20中任一项所述的计算机程序产品，其中所述支出提供商系统包括支付网关。

条款22：根据条款17至21中任一项所述的计算机程序产品，其中所述资金支出请求是使用对应于所述消费者账户的借记卡发起的。

条款23：根据条款17至22中任一项所述的计算机程序产品，其中对应于所述商家账户的所述收单方系统由发行对应于所述商家账户的借记卡的发行方操作。

条款24：根据条款17至23中任一项所述的计算机程序产品，其中所述商家账户对应于企业商家。

在参考附图考虑以下描述和所附权利要求书之后，本发明的这些和其它特征和特性以及相关结构元件和各部分的组合的操作方法和功能以及制造经济性将变得更加显而易见，所有这些形成本说明书的部分，其中相同附图标号在各图中标示对应部分。然而，应明确地理解，图式仅出于说明和描述的目的，并非旨在作为本发明的限制的定义。

附图说明

下文参考附图中说明的示例性实施例更详细地解释本公开的额外优点和细节，在附图中：

图1A是用于处理资金支出交易的现有系统的示意图；

图1B是用于处理资金支出交易的现有方法的步骤图；

图2A是根据本公开原理的用于处理资金支出交易的系统的非限制性实施例或方面的示意图；

图2B是根据本公开原理的用于处理资金支出交易的方法的非限制性实施例或方面的步骤图；

图3是根据本公开原理的用于处理资金支出交易的方法的另一非限制性实施例或方面的步骤图；

图4是根据本公开原理的用于处理资金支出交易的拆分授权系统的非限制性实施例或方面的示意图；

图5是根据本公开原理的用于处理资金支出交易的方法的另一非限制性实施例或方面的步骤图；以及

图6是根据本公开原理的用于处理资金支出交易的方法的非限制性实施例或方面的过程流程图。

具体实施方式

出于以下描述的目的，术语“端部”、“上部”、“下部”、“右侧”、“左侧”、“竖直”、“水平”、“顶部”、“底部”、“横向”、“纵向”和其派生词应如其在附图中定向的那样与本发明有关。然而，应理解，除非明确指定为相反情况，否则本发明可以采用各种替代变型和步骤顺序。还应理解，附图中所示的以及在以下说明书中描述的特定装置和过程仅仅是本发明的示例性实施例或方面。因此，与本文公开的实施例或方面有关的特定尺寸和其它物理特性不应被视为限制。

本文所使用的方面、组件、元件、结构、动作、步骤、功能、指令等都不应当被理解为关键的或必要的，除非明确地如此描述。并且，如本文所使用，冠词“一”希望包括一个或多个项目，且可与“一个或多个”和“至少一个”互换使用。此外，如本文所使用，术语“集合”希望包括一个或多个项目(例如，相关项目、不相关项目、相关项目与不相关项目的组合等)，并且可与“一个或多个”或“至少一个”互换使用。在希望仅有一个项目的情况下，使用术语“一个”或类似语言。且，如本文所使用，术语“具有”等希望是开放式术语。另外，除非另外明确陈述，否则短语“基于”希望意味着“至少部分地基于”。

如本文所使用，术语“通信”可以指数据(例如，信息、信号、消息、指令、命令等)的接收、接纳、传输、传送、提供等。一个单元(例如，装置、系统、装置或系统的组件、其组合等)与另一单元通信意味着所述一个单元能够直接或间接地从所述另一单元接收信息和/或向所述另一单元传输信息。这可以指在本质上有线和/或无线的直接或间接连接(例如，直接通信连接、间接通信连接等)。另外，即使传输的信息可以在第一单元与第二单元之间被修改、处理、中继和/或路由，这两个单元也可以彼此通信。例如，即使第一单元被动地接收信息且不会主动地将信息传输到第二单元，第一单元也可以与第二单元通信。作为另一示例，如果至少一个中间单元处理从第一单元接收的信息且将处理后的信息传送到第二单元，那么第一单元可以与第二单元通信。

如本文所使用，术语“交易服务提供商”可以指接收来自商家或其它实体的交易授权请求(包括用于处理资金支出交易的请求)且在一些情况下通过交易服务提供商与发行方机构之间的协议来提供支付保证的实体。例如，交易服务提供商可包括支付网络，例如

如本文所使用，术语“发行方机构”可以指对客户提供用于进行交易(例如，资金支出交易或支付交易)，例如发起贷记和/或借记支付的账户的一个或多个实体，例如银行。例如，发行方机构可以向客户提供唯一地标识与所述客户相关联的一个或多个账户的账户标识符，例如主账号(PAN)。账户标识符可在例如支付卡的实体金融工具等支付装置上实施，和/或可以是电子的且用于电子支付。术语“发行方系统”指由发行方机构或代表发行方机构操作的一个或多个计算装置，例如执行一个或多个软件应用程序的服务器计算机。例如，发行方系统可包括用于授权交易的一个或多个授权服务器。

如本文所使用，术语“收单方机构”可指由交易服务提供商授权和/或批准以使用与交易服务提供商相关联的支付装置发起交易的实体。收单方机构可发起的交易可包括支付交易(例如，购买、原始信用证交易(OCT)、账户资金交易(AFT)等。在一些非限制性实施例中，收单方机构可以是金融机构，例如银行。如本文所使用，术语“收单方系统”可以指由收单方机构或代表收单方机构操作的一个或多个计算装置，例如执行一个或多个软件应用程序的服务器计算机。

如本文所使用，术语“资金支出交易”可以指其中资金从支付方账户转移到接收方账户的交易。此类交易的示例包括从保险公司或健康计划(支付方)向索赔人(接收方)支付的支出。

如本文所使用，术语“原始信用证交易”(OCT)可以指其中将资金贷记(推送)到接收方账户的交易方法。OCT交易也可以被称为“推送支付”。推送支付是由个人或实体向接收方发送(“推送”)资金，而不是接收方请求(“提取”)支付来发起的。如本文所使用，术语“账户资金交易”(AFT)可以指其中从发送方账户借记(“提取”)资金的交易方法。

如本文所使用，术语“账户标识符”可包括一个或多个PAN、令牌，或与客户账户相关联的其它标识符。术语“令牌”可以指用作PAN等原始账户标识符的替代或替换标识符的标识符。账户标识符可以是文字数字或字符和/或符号的任何组合。令牌可与一个或多个数据结构(例如一个或多个数据库等)中的PAN或另一原始账户标识符相关联，使得令牌可用于进行交易而无需直接使用原始账户标识符。在一些示例中，例如PAN的原始账户标识符可以与用于不同个人或目的的多个令牌相关联。

如本文所使用，术语“商家”可以指基于例如支付交易的交易向客户提供商品和/或服务或者对商品和/或服务的使用权的个人或实体。如本文所使用，术语“商家”或“商家系统”还可以指由商家或代表商家操作的一个或多个计算机系统，例如执行一个或多个软件应用程序的服务器计算机。如本文所使用，术语“销售点(POS)系统”可以指由商家用来与客户进行支付交易的一个或多个计算装置和/或外围装置，包括一个或多个读卡器、近场通信(NFC)接收器、RFID接收器和/或其它非接触收发器或接收器、基于接触的接收器、支付终端、计算机、服务器、输入装置，和/或可用于发起支付交易的其它类似装置。

如本文所使用，术语“企业商家”可以指利用资金支出交易向个人(例如，企业商家的客户、员工或承包商)或其它实体转移资金的商家。企业商家的非限制性示例包括以共享经济为基础的公司(例如，共享车公司向其司机支出费用)、保险公司和/或健康计划(例如，向其索赔人支出资金)；政府机构(例如，向其商业承包商支出费用)；等等。

如本文所使用，术语“支付装置”可以指代支付卡(例如，信用卡或借记卡)、礼品卡、智能卡、智能介质、工资卡、医疗保健卡、腕带、含有账户信息的机器可读介质、钥匙链装置或挂扣、RFID应答器、零售商折扣或会员卡、蜂窝电话、电子钱包移动应用程序、个人数字助理(PDA)、寻呼机、安全卡、计算装置、访问卡、无线终端、应答器等。在一些非限制性实施例中，支付装置可包括存储信息(例如账户标识符、账户持有者姓名等)的易失性或非易失性存储器。

如本文所使用，术语“支付网关”可以指实体和/或由此类实体或代表此类实体操作的支付处理系统，所述实体(例如商家服务提供商、支付服务提供商、支付服务商、与收单方有合约的支付服务商、支付集合人(payment aggregator)等)向一个或多个商家提供支付服务(例如交易服务提供商支付服务、支付处理服务等)。支付服务可以与由交易服务提供商管理的支付装置的使用相关联。如本文所使用，术语“支付网关系统”可以指由支付网关或代表支付网关操作的一个或多个计算机系统、计算机装置、服务器、服务器群组等。

如本文所使用，术语“支出提供商”可以指为商家(例如企业商家)提供服务以使商家能够向接收方(例如其消费者或其它商家)支出资金的实体。支出提供商可以是支付网关。如本文所使用，术语“支出提供商系统”可以指由支出提供商或代表支出提供商操作的一个或多个计算机系统、计算机装置、服务器、服务器群组等。

如本文所使用，术语“服务器”可以指或包括由互联网等网络环境中的多方操作或促进所述多方的通信和处理的一个或多个计算装置，但应了解，可通过一个或多个公共或专用网络环境促进通信，并且可能有各种其它布置。此外，在网络环境中直接或间接通信的多个计算装置(例如服务器、销售点(POS)装置、移动装置等可构成“系统”。如本文所使用，对“服务器”或“处理器”的提及可以指陈述为执行先前步骤或功能的先前所述服务器和/或处理器、不同的服务器和/或处理器，和/或服务器和/或处理器的组合。例如，如在说明书和权利要求书中所使用，陈述为执行第一步骤或功能的第一服务器和/或第一处理器可以指代陈述为执行第二步骤或功能的相同或不同服务器和/或处理器。

本公开的非限制性实施例或方面涉及一种用于处理资金支出交易的方法、系统和计算机程序产品。与现有系统不同，非限制性实施例在支出资金之前提供了包括收单方系统的独特组件布置。系统可以使用新的拆分授权方法，第一授权请求是与收单方系统(其作为商家账户的发行方系统)通信，以确保在发起支出之前商家账户中有足够的资金可用。以此方式，非限制性实施例有利地基于商家账户中实际存在的资金而不是仅仅基于收单方控制或商家信誉却不考虑商家账户中包括的实际资金来确定应从商家账户支出资金到消费者账户。只有当第一授权请求返回指示商家账户中有足够的资金可用的响应时，系统才可以发起第二授权请求。这种布置确保实际上只进行商家有足够的资金能覆盖的资金支出。非限制性实施例提供所有上述优点，而如果商家账户有足够的资金来完成支出，则仍使支出的资金在1小时内(例如在30分钟内)被提供给消费者。因为首先通过与收单方系统通信确保商家账户能够充分覆盖要支出的资金，同时及时向消费者支出资金，所以非限制性实施例提供了用于处理资金支出请求的改进的系统。

参考图1，示出了用于处理资金支出交易的现有系统100。系统100可以包括具有消费者账户的消费者110和与消费者账户相关联的借记卡112。借记卡可以包括账户标识符，例如16位个人账号(PAN)。消费者账户可以被配置成根据资金支出交易接收资金(为接收方账户)，或根据资金支出交易向不同接收方账户支出资金(为来源账户)。借记卡可用于发起资金支出交易和/或将消费者账户标识为资金支出交易的来源账户或接收方账户。借记卡112可用于使用销售点装置或由消费者向涉及将资金从来源账户支出到接收方账户的实体提供账户标识符(或与账户相关联的其它信息)来发起资金支出交易。

系统100还可以包括由商家(例如企业商家)或代表商家操作的商家系统114。在一个示例中，商家可以是通过资金支出交易向其消费者、员工、承包商等支出资金的个人或实体。商家可以是保险提供商、医疗保健提供商，或在处理索赔期间向其索赔人(其客户)一次性支付款项的其它实体。包括商家的资金的商家账户可以与商家系统114和商家相关联。商家账户可以被配置成根据资金支出交易接收资金(为接收方账户)，或根据资金支出交易向不同接收方账户支出资金(为来源账户)。商家账户可以包括与其相关联的借记卡，其可以用于发起资金支出交易和/或将商家账户标识为资金支出交易的来源账户。商家借记卡可以包括账户标识符，例如16位PAN。

系统100还可以包括支出提供商系统(DPS)116。DPS 116可被配置成从商家系统114接收并处理资金支出请求。DPS 116可以是支付网关、交易服务提供商，或涉及处理资金支出交易的任何其它中介实体。

系统100还可包括由交易服务提供商或代表交易服务提供商操作的交易处理服务器118。交易处理服务器(TPS)118可以被配置成处理各种交易，例如使用如本文描述的支付装置发起的支付交易以及资金支出交易。TPS118还可以处理与处理由TPS 118处理的交易类型相关联的交换费。

系统100还可以包括由发行方(其可以是银行或其它金融机构)或代表发行方操作的发行方系统120。发行方可以是消费者账户的发行方和消费者借记卡112的发行方。

系统100还可以包括由收单方(例如商家银行)或代表收单方操作的收单方系统122。收单方可以是与商家系统114相关联的商家的收单方。收单方也可以作为商家的发行方(但是收单方将在本文中称为收单方，以免与前述消费者的发行方系统120混淆)，因为收单方可以是商家借记卡和商家账户的发行方。

继续参考图1A，现有系统100的支付指令流程由实心箭头指示。在此支付指令流程中，在步骤1a，消费者110可以将与消费者借记卡112相关联的账户信息(例如，账户标识符)呈现或传送到商家系统114。作为响应，在步骤2a，商家系统114可以将资金支出请求传送到DPS。资金支出请求可以标识要从商家账户支出到消费者账户的支出金额。资金支出请求还可包括与消费者借记卡112和/或商家借记卡相关联的账户标识符。根据处理资金支出请求的需要，可以在资金支出请求中包括其它相关信息。在步骤3a，DPS生成单个授权请求，所述授权请求被配置成使得发行方系统120发起向消费者账户推送支付支出金额。TPS 118可以从DPS 116接收单个授权请求，并在步骤4a将单个授权请求传送到发行方系统120。应了解，DPS 116、TPS 118和/或发行方系统120可以是单独的系统和/或实体(如图1的流程所示)，或这些实体/系统中的任何一个可以组合成单个实体/系统。在一个非限制性示例中，DPS116、TPS 118和发行方系统120是由执行与每个单独的实体相关联的上述步骤中的每个步骤的单个实体或代表所述单个实体操作的单个系统。应了解，在整个公开内容中，DPS 116、TPS 118和/或发行方系统120可以是单个系统或拆分成若干单独的系统。

应了解，上述过程流程或下文描述的任何过程流程均认为本文所述的有序步骤是非限制性的，并且除非明确相反地规定，否则设想流程中的不同步骤顺序。

继续参考图1A，现有系统100的报告消息的流程由虚线箭头指示。在步骤1b，TPS118可以传递结算和对账数据以报告给收单方系统122。此信息可用于结算资金支出交易期间转移的资金。在步骤2b，TPS 118可以将报告消息传送到DPS 116，说明资金支出请求已被处理，并且发行方系统120已经或将要向消费者账户提供资金。在步骤3b，DPS 116可以将此报告消息传送到商家系统116。可以按任何顺序传送这些报告消息。

继续参考图1A，现有系统100中的资金流程由虚点箭头指示。在步骤1c，TPS 118可以向发行方系统120提供支出金额的资金。这可以由TPS 118将资金推送到发行方系统120或由发行方系统120从TPS 118提取资金来执行。在步骤2c，发行方系统120可以将支出金额的资金推送到消费者账户。应了解，在一些实施例中，可以按顺序切换步骤1c和2c。在步骤3c，收单方系统122向TPS 118提供支出金额的资金。这可以由TPS 118从收单方系统122提取资金或者由收单方系统122将资金推送到TPS 118来执行。在步骤4c，商家系统114向收单方系统122提供支出金额的资金。这可以由收单方系统122从商家系统114提取资金或者由商家系统114将资金推送到收单方系统122来执行。

参考图1B，示出了用于处理资金支出交易的现有方法150。在方法150中，在第一步骤152，消费者110向商家系统114提供消费者借记卡112(或其信息)以发起资金支出交易，使得支出金额可以支出到消费者账户。在第二步骤156，如先前所描述，商家系统114将资金支出请求传送到DPS 116。

在第三步骤160，DPS 116以单个授权请求的形式传送指令，这使发行方系统120发起向消费者账户推送支付支出金额。在一些非限制性实施例中，可以根据预先确定的收单方建立的规则生成并传送单个授权请求。这些收单方建立的规则不包括确定商家账户中是否有足够的资金可用以覆盖支出金额。相反，收单方建立的规则可以包括特定商家的交易限额和每小时/每日/每周/每月/季度阈值。例如，收单方建立的规则可以包括以下任何一项：单笔资金支出交易的最大金额、一段时间内(例如，一天)的资金支出交易的最大金额，和/或一段时间内的资金支出请求的最大计数。收单方建立的规则可以基于商家的信誉。收单方建立的规则是预先确定的规则，这样将它们传送到DPS 116和/或TPS或发行方系统120，使得在资金支出之前不与收单方系统122通信以确定资金支出请求是否在收单方建立的规则内。相反，DPS116可以确定资金支出请求是否遵循收单方建立的规则，并且如果遵循，则生成单个授权请求。在另一示例中，DPS 116可以生成单个授权请求，并将单个授权请求传送到TPS 118或发行方系统120，所述TPS或发行方系统考虑资金支出请求是否遵循收单方建立的规则，然后再允许进一步处理资金支出请求(包括资金支出)。在任何情况下，包括收单方建立的规则的现有系统在处理或支出资金支出请求的资金之前均未考虑商家账户中的实际资金金额。

在第四步骤164，发行方系统120可以向消费者账户提供支出金额，例如通过OCT交易(推送支付)向消费者账户提供支出金额。在第五步骤168，TPS 118可以如先前所描述将结算和对账数据传送到收单方系统122。在第六步骤172，TPS 118可以从收单方系统122接收收单方账户的支出金额的资金。在第七步骤176，收单方系统122可以从商家系统114的商家账户接收支出金额的资金。

参考图2A，示出了根据一些非限制性实施例的用于处理资金支出交易的非限制性系统200。系统200可以包括消费者210、消费者借记卡212、商家系统214、DPS 216、TPS 218、发行方系统220和/或收单方系统222，其包括图1A的系统100的相应对应部分的特征。然而，下文描述本发明系统200与现有系统100的区别及其组件的特征。

继续参考图2A，系统200的支付指令流程由实心箭头指示。在此支付指令流程中，在步骤1d，消费者210可以将与消费者借记卡212相关联的账户信息(例如，账户标识符)呈现或传送到商家系统214，以发起资金支出交易。作为响应，在步骤2d，商家系统214可以将资金支出请求(如先前所描述)传送到DPS 216。在步骤3d，DPS 216可以根据资金支出请求确定商家账户和/或消费者账户，并且部分地基于支出金额和商家账户生成第一授权请求。第一授权请求被配置成使得对应于商家账户的收单方系统222确定商家账户是否包括支出金额并且传送第一授权响应。第一授权响应可以指示账户中可用资金的金额，或者可以返回关于所查询的交易金额是否可以被账户中的可用资金覆盖的二进制响应。在一些非限制性示例中，第一授权响应被配置成发起账户资金转账(AFT)或其它授权请求，以验证商家账户中是否有足够的资金可用。DPS 216可以生成第一授权请求并将其传送到TPS218。在步骤4d，TPS 218可以将第一授权请求传送到商家账户的收单方系统222。TPS 218和/或DPS可以从收单方系统222接收第一授权响应，所述第一授权响应可以指示商家账户是否包括足够的资金能覆盖支出金额(授权支出的批准或拒绝支出的否决)。因此，响应于接收到第一授权请求，收单方系统222可以确定商家账户目前是否有等于或超过支出金额的足够资金。响应于确定第一授权响应包括授权支出金额(从收单方系统222)支出的批准，DPS 216可以生成第二授权请求，所述第二授权请求被配置成发起向消费者账户推送支付支出金额。在步骤5d，可以生成第二授权请求并传送到TPS 218。在步骤6d，TPS 218可以将第二授权请求传送到发行方系统220。

继续参考图2A，系统200的报告消息的流程由虚线箭头指示。在步骤1e，TPS 218可以传递结算和对账数据以报告给收单方系统222。此信息可用于结算资金支出交易期间转移的资金。在步骤2e，TPS 218可以将报告消息传送到DPS 216，说明资金支出请求已被处理，并且发行方系统220已经或将要向消费者账户提供资金。在步骤3e，DPS 216可以将此报告消息传送到商家系统216。可以按任何顺序传送这些报告消息。

继续参考图2A，系统200中的资金流程由虚点箭头指示。在步骤1f，TPS 218可以根据对支出金额的第二授权请求向发行方系统220提供资金。这可以由TPS 218将资金推送到发行方系统220或由发行方系统220从TPS218提取资金来执行。在步骤2f，发行方系统220可以将支出金额的资金推送到消费者账户。应了解，在一些实施例中，可以按顺序切换步骤1f和2f。在步骤3f，收单方系统222向TPS 218提供支出金额的资金。这可以由TPS218从收单方系统222提取资金或者由收单方系统222将资金推送到TPS 218来执行。在步骤4f，商家系统214向收单方系统222提供支出金额的资金。这可以由收单方系统222(或TPS 218代表收单方系统222)从商家系统214提取资金或者由商家系统214(或TPS 218代表商家系统214)将资金推送到收单方系统222来执行。

参考图2B，示出了根据一些非限制性实施例的用于处理资金支出交易的非限制性方法250。在方法250中，在第一步骤252，消费者210向商家系统214提供消费者借记卡212以发起资金支出交易，使得支出金额可以支出到消费者账户。在第二步骤256，如先前所描述，商家系统214将资金支出请求传送到DPS 216。

继续参考图2B，在第三步骤257，DPS 216可以生成第一授权请求并将其传送到TPS218。在第四步骤258，TPS 218可以将第一授权请求传送到收单方系统222。响应于接收到第一授权请求，收单方系统222可以确定商家账户目前是否有足够的资金能覆盖支出金额。以此方式，收单方系统222确保在处理资金支出交易时商家账户至少在商家账户中具有支出金额。确定在商家账户中有足够的资金可用时，可以对商家账户冻结支出金额，使得在处理资金支出交易完成之前商家账户中的资金不会低于覆盖支出金额的所需资金。

在本发明的方法250中，DPS 216、TPS 218和/或发行方系统220和/或收单方系统222可以另外考虑先前所述的收单方建立的规则，以进一步确定是否应处理完成资金支出交易。然而，收单方建立的规则不会消除收单方系统222确定商家账户是否有足够的资金能覆盖支出金额的步骤。

收单方系统222可以将第一授权响应传送到TPS 218和/或DPS 216，所述第一授权响应包括商家账户中是否有足够的资金可用于覆盖支出金额。

在第五步骤259，响应于从收单方系统222接收到第一授权响应的响应，所述第一授权响应包括授权支出的批准(商家账户有足够的资金能覆盖支出金额)，DPS 216可以生成第二授权请求。第二授权请求可以被配置成使发行方系统220发起向消费者账户推送支付支出金额。第二授权请求可以传送到TPS 218和/或发行方系统220。第二授权请求可以在DPS 216接收到支出请求1小时内(例如30分钟内、20分钟内、15分钟内、10分钟内、5分钟内或基本实时地(如本文所使用的，不到1分钟))由所述DPS传送。

在一些非限制性实施例或方面，第二授权请求还可以包括类型标识符，其标识处理的交易类型。根据一些非限制性实施例，第二授权请求可以包括将正被处理的交易标识为资金支出交易的类型标识符。在处理期间，收取用于处理资金支出交易的交换费的实体的系统可以基于类型标识符和与类型标识符相关联的比率来接收其交换费。与处理资金支出交易相关联的交换费可与其它类型的处理交易相同或不同(更高或更低)。交换费可以由相关系统(例如，TPS)基于类型标识符自动收取。

继续参考图2B，在第六步骤264，发行方系统220可以向消费者账户提供支出金额，例如通过OCT交易(推送支付)向消费者账户提供支出金额。发行方系统可在DPS接收到支出请求1小时内(例如30分钟内、20分钟内、15分钟内、10分钟内、5分钟内或基本实时地)将资金提供给消费者账户。在第七步骤268，TPS 218可以如先前所描述将结算和对账数据传送到收单方系统222。在第八步骤272，TPS 218可以从收单方系统222接收收单方账户的支出金额的资金。在第九步骤276，收单方系统222可以从商家系统214的商家账户接收支出金额的资金。

参考图3，示出了用于处理资金支出交易的方法300。在第一步骤310，DPS可以接收资金支出请求，所述资金支出请求标识要从商家账户支出到消费者账户的支出金额。在步骤312，DPS可以部分地基于资金支出请求确定将从其转移支出金额的商家账户和将向其转移支出金额的消费者账户。在步骤314，DPS可以基于支出金额和商家账户生成第一授权请求，并且第一授权请求可被配置成使得对应于商家账户的收单方系统确定商家账户是否包括支出金额。在步骤316，DPS可以将第一授权请求传送到收单方系统。在步骤318，DPS可以从收单方系统接收第一授权响应。在步骤320，DPS可以响应于确定第一授权响应包括授权支出支出金额的批准而生成第二授权请求，所述第二授权请求被配置成使得对应于消费者账户的发行方系统发起向消费者账户推送支付支出金额。

参考图4，示出了用于处理资金支出交易的拆分授权系统400的非限制性实施例或方面。在此系统中，在从商家系统(未示出)接收到资金支出请求时，DPS 416将资金支出交易的处理拆分成两个授权请求。DPS 416首先将(先前描述的)第一授权请求传送到收单方系统422。DPS 416可以将第一授权请求直接传送到收单方系统422，或者DPS 416可以例如通过TPS(未示出)将第一授权请求间接地传送到收单方系统422。在确定来自收单方系统422的(先前描述的)第一授权响应包括授权支出支出金额的批准后，DPS将(先前描述的)第二授权响应传送到发行方系统420。DPS 416可以将第二授权请求直接传送到发行方系统420，或者DPS 416可以例如通过TPS(未示出)将第二授权请求间接地传送到发行方系统420。

参考图5，示出了用于处理资金支出交易的方法500的非限制性实施例或方面。在步骤502，商家系统将资金支出请求传送到DPS。在步骤504，DPS生成第一授权请求并将其(直接或通过中间系统)传送到收单方系统。DPS(直接或通过中间系统)从收单方系统接收第一授权响应。当DPS确定第一授权响应包括拒绝资金支出交易(授权不成功)时，DPS与商家系统通信，通知商家系统资金支出请求的处理失败(步骤506)。此通知可包括资金支出请求被拒绝的原因，例如资金不足或未能满足收单方建立的规则之一。当DPS确定第一授权响应包括批准资金支出交易(授权成功)时，DPS生成并传送第二授权请求(步骤508)。在步骤510处，DPS进一步与商家系统通信，通知商家系统资金支出请求的处理成功。

在又一非限制性实施例或方面，一种用于处理资金支出交易的计算机程序产品包括至少一个非瞬态计算机可读介质，所述非瞬态计算机可读介质包括程序指令，所述程序指令在由至少一个处理器执行时使所述至少一个处理器执行本文描述的发明性系统或方法(例如，系统200、系统400、方法250、方法300、方法500、方法600)中的一个。所述至少一个处理器可以包括DPS。

提供以下示例以说明用于处理资金支出交易的系统、方法和计算机程序产品的实施例，且并不意图是限制性的。

参考图6，示出了用于处理资金支出交易的方法的非限制性示例。在此示例中，Paul Jones为消费者610，并且是拥有Acme Insurance(企业商家)的房屋业主保险单的个人。如先前所描述，Acme Insurance操作商家系统614。Paul Jones拥有由第一银行(发行方)发给他的借记卡和消费者账户，所述第一银行操作发行方系统620，如先前所描述。AcmeInsurance有由第一收单方(Acme Insurance的收单方)发行的借记卡和商家账户。如先前所描述，第一收单方操作收单方系统622。Acme Insurance的借记卡与操作TPS 618的第一交易服务提供商(“第一TSP”)相关联，如先前所描述。第一网关用作Acme Insurance的支付网关，并且第一网关操作DPS 616，如先前所描述。

上个月，一场暴风雨席卷了Paul在加利福尼亚州所在的社区，推倒了他前院的一棵大橡树。树坠落在其车库的屋顶上，对车库的很大一部分造成了结构性破坏。Paul请California Construction(一家建筑公司)修理了暴风雨造成的结构性破坏。维修费用总计15,000美元。Paul向Acme Insurance提出了15,000美元的房屋业主保险索赔(他的自付额为0美元)。Acme Insurance批准了Paul的索赔，并同意偿付他全部15,000美元的金额。

Acme Insurance同意使用资金支出交易来偿付Paul。在第一步骤(S1)，Paul向Acme Insurance的商家系统614提供他的借记卡，使得商家系统614具有与同Paul的借记卡相关联的Paul的消费者账户相关联的所需账户标识符。在第二步骤(S2)，商家系统614将资金支出请求传送到DPS 616，所述资金支出请求包括Paul的消费者账户的账户标识符和/或资金支出交易的支出金额(15,000美元)。资金支出请求中还可能包括与Acme Insurance的商家账户相关联的账户标识符。根据资金支出请求，DPS 616可以确定将从其转移15,000美元的商家账户和将向其转移15,000美元的消费者账户。

在第三步骤(S3)，第一网关DPS 616生成第一授权请求(如先前所描述)，以使对应于商家账户的第一收单方，即收单方系统622确定商家账户是否有足够的资金。在此示例中，DPS将第一授权请求传送到第一交易服务提供商的TPS 618。在第四步骤(S4)，TPS 618将接收到的第一授权响应传送到收单方系统622。在第五步骤(S5)，收单方系统622确定商家账户是否有足够的资金(至少15,000美元)能覆盖支出金额。各种系统(例如，DPS 616、TPS 618、收单方系统622和/或发行方系统620)可以考虑收单方建立的其它规则以确定支出请求是否也与之相符。在第六步骤(S6)，收单方系统622将第一授权响应传送到TPS 618，并且在第七步骤(S7)，TPS 618将第一授权响应传送到DPS 616。

继续参考图6，在第八步骤(S8)，响应于确定第一授权响应包括授权支出支出金额的批准(确定商家账户包括至少15,000美元)，DPS 616生成第二授权请求并将其传送到TPS618。此第二授权请求如先前所描述，且被配置成使得发行方系统620发起向Paul的消费者账户推送支付所述支出金额。在第九步骤(S9)，TPS 618将第二授权请求传送到第一银行的发行方系统620。

在第十步骤(S10)，发行方系统620可影响向消费者账户推送支付支出金额，使得15,000美元被提供给Paul。可在商家系统614将资金支出请求传送到DPS 616后1小时内将支出金额提供给Paul。在第十步骤(S11)，TPS618和收单方系统622进行通信，以将支出金额从收单方系统622转移到TPS618(因为TPS 618将支出金额转移到发行方系统620)。在此示例中，TPS 618从收单方系统622的收单方账户提取支出金额。在第十二步骤(S12)，商家系统614和收单方系统622进行通信，以将支出金额从商家系统614的商家账户转移到收单方系统622的收单方账户。在此示例中，收单方系统622(或TPS 618代表收单方系统622)从商家系统614提取支出金额。以此方式，在资金支出请求后的1小时内，将15,000美元的支出金额从Acme Insurance的商家账户转移到Paul的消费者账户，以使Paul可以快速使用资金，同时确保Acme Insurance的商家账户包括足够的资金能覆盖金额。

尽管已出于说明的目的而基于当前被认为是最实用和优选的实施例详细描述了本发明，但应理解，此类细节仅用于所述目的，且本发明不限于所公开实施例，而相反，旨在涵盖在所附权利要求书的精神和范围内的修改和等效布置。例如，应理解，本发明预期，在可能的范围内，任何实施例的一个或多个特征可以与任何其它实施例的一个或多个特征组合。