CN107924512A

CN107924512A - 电子增量支付

Info

Publication number: CN107924512A
Application number: CN201680049778.9A
Authority: CN
Inventors: A·斯特伊; J·多尔蒂; A·苏博维莱; H·海恩斯; S·帕伦多; W·莫利托; P·J·弗洛尔
Original assignee: Mastercard International Inc
Current assignee: Mastercard International Inc
Priority date: 2015-07-01
Filing date: 2016-06-17
Publication date: 2018-04-17
Anticipated expiration: 2036-06-17
Also published as: AU2016285425A1; WO2017003717A1; US10535067B2; AU2016285425B2; CN107924512B; BR112017027686A2; US20170004498A1

Abstract

通过具有标准清算和结算时期的支付网络从多个开账单人中的指定的一个获得对支付交易的授权请求。经由支付网络传递对支付交易的授权请求的特定增量支付批准授权请求响应，从而指示将关于在授权请求之后在所选时期内按时间增量进行的多个增量支付中的支付交易来对多个开账单人中的指定的一个付款，而可选地不管资金对于与支付交易关联的账户是否可用。所选时期比标准清算和结算时期长。支付交易直到所选时期到期才被结算。

Description

电子增量支付

相关申请的交叉引用

本申请要求2015年7月1日提交的美国专利申请号14/789,457的优先权，其内容通过引用全部合并于此。

技术领域

本公开大体涉及电子和计算机领域，并且更具体地涉及支付卡网络及类似物。

背景技术

例如信用卡、借记卡和预付卡等支付卡的使用变得无处不在。大部分支付卡账户具有一个或多个关联的物理卡；然而，例如适当配置的“智能”蜂窝电话等非传统支付设备的使用在日益增加。在一些实例中，在实体店呈递卡或非传统支付设备。在无卡交易中，在商户处并未物理呈现卡或非传统支付设备。无卡交易的一个示例是网上购物。另一个示例是无卡循环支付，其中持卡人对商户提供支付卡账号和相关信息(例如，有效日期)并且商户使用该信息发起循环(例如，每月)交易。

发明内容

本公开的原理提供了电子增量记账的技术。在一个方面，示例性方法包括以下步骤：通过具有标准清算和结算时期的支付网络从多个开账单人中的指定的一个获得支付交易的授权请求；经由支付网络传递对支付交易的授权请求的特定增量支付批准授权请求响应，从而指示将关于在授权请求之后在所选时期内按时间增量进行的多个增量支付中的支付交易来对多个开账单人中的指定的一个付款，而不管资金对于与支付交易关联的账户是否可用。所选时期内的增量支付中的至少一个是继标准清算和结算时期之后。另外的步骤包括在标准清算和结算时期之后的一段时间之前限制对支付交易的至少部分清算和结算。

在另一个方面，另一个示例性方法包括以下步骤：在增量支付记账程序中登记多个账户持有者；通过具有标准清算和结算时期的支付网络从多个开账单人中的指定的一个获得支付交易的授权请求；以及将对支付交易的授权请求的特定增量支付批准授权请求响应派送到支付网络内，从而指示将根据增量支付记账程序关于在授权请求之后在所选时期内按时间增量进行的多个支付交易中的支付交易来对多个开账单人中的指定的一个付款，而不管资金对于与支付交易关联的账户是否可用。所选时期比标准清算和结算时期长。

在再一个方面，再一个示例性方法包括以下步骤：在增量支付记账程序中登记多个开账单人；以及经由支付卡网络获得对支付卡交易的授权请求的特定增量支付批准授权请求响应，从而指示将关于在所选时期内按时间增量进行的多个增量支付中的支付交易来对多个开账单人中的指定的一个付款。该所选时期比支付卡网络的标准清算和结算时期长。另外的步骤包括将增量支付批准授权请求响应传递到多个开账单人中的指定的一个。

在另一方面，示例性支付卡网络具有标准清算和结算时期并且包括：收单方支付卡网络接口，其配置成从多个开账单人中的指定的一个获得支付卡交易的授权请求；和发行商支付卡网络接口，其配置成从对应发行商获得对支付卡交易的授权请求的特定增量支付批准授权请求响应，从而指示将关于在授权请求之后在所选时期内按时间增量进行的多个增量支付中的支付卡交易来对多个开账单人中的指定的一个付款，而不管资金对于与支付卡交易关联的账户是否可用。该所选时期比标准清算和结算时期长。支付卡网络还包括清算和结算系统，其耦合于收单方支付卡网络接口和发行商支付卡网络接口；该清算和结算系统进而包括保持队列，其保持支付卡交易使得支付卡交易直到所选时期到期才完全结算。

本公开的方面预想了由本文的一个或多个实体执行的方法，以及由相同或不同实体促进一个或多个方法步骤。如本文使用的，“促进”动作包括执行该动作、使该动作更容易、帮助实施该动作或促成执行该动作。从而，通过示例并且没有限制，在一个处理器上执行的指令可以通过发送合适数据或命令来促成或帮助执行动作而促进由在远程处理器上执行的指令所实施的动作。未避免存疑，在行动者通过除执行动作外来促进动作的情况下，动作然而还是由一些实体或实体的组合执行。

本公开的一个或多个实施例或其元件可以采用计算机程序产品的形式实现，该计算机程序产品包括有形的计算机可读可记录存储介质，其具有计算机可用程序代码以用于执行所指示的采用非暂时性方式存储在其上的方法步骤。此外，本公开的一个或多个实施例或其元件可以采用系统(或装置)的形式实现，该系统包括存储器和至少一个处理器，该至少一个处理器耦合于该存储器并且操作以执行示例性方法步骤。再进一步，在另一个方面，本公开的一个或多个实施例或其元件可以采用用于实施本文描述的方法步骤中的一个或多个的部件的形式实现；该部件可以包括(i)专门硬件模块，(ii)采用非暂时性方式存储在有形计算机可读可记录存储介质(或多个这样的介质)中并且在硬件处理器上实现的软件模块，或(iii)(i)和(ii)的组合；(i)-(iii)中的任一个实现本文阐述的特定技术。传输介质本身和无实体信号本身定义成从要求保护的部件中排除。

本公开的一个或多个实施例可以提供大量有益技术效果。例如，因为系统的相关组件(授权、结算、消息规范等)已经存在并且可以如本文教导的那样修改来实现一个或多个实施例，经由现有支付网络的电子部分支付记账更容易且更可取。

本公开的这些及其他特征和优势将从其说明性实施例的下列详细描述变得明显，这些说明性实施例要结合附图来阅读。

附图说明

图1示出了可以实现本公开的技术的系统及其各种组件的示例；

图2描绘以下各项之间和之中关于本公开的一个或多个实施例有用的示例性相互关系：(i)支付网络，其配置成促进多个发行商与多个收单方之间的交易，(ii)多个用户，(iii)多个商户，(iv)多个收单方，以及(v)多个发行商；

图3是根据本公开的一个方面的从开账单人的角度来看的示范性方法的流程图；

图4是根据本公开的一个方面的从持卡人的角度来看的示范性方法的流程图；

图5是在本公开的一个或多个实施例中有用的示例性计算机系统的框图；

图6和7提供了根据本公开的一个方面的支付卡网络的操作的示例性详细视图；

图8示出了例如可以与图6和7的网络一起使用的一组支付网络接口处理器；

图9示出了例如可以与图6和7的网络一起使用的支付网络接口处理器上的端口布置，以及

图10是其中发行商具有多个支付网络接口处理器的情况。

具体实施方式

支付设备和关联支付处理网络

现在将关注图1，其描绘了根据本公开的一个方面的系统100的示例性实施例并且包括系统的各种可能组件。系统100可以包括一个或多个不同类型的便携式支付设备。例如，一个这样的设备可以是接触设备，例如卡102。卡102可以包括集成电路(IC)芯片104，其具有处理器部分106和存储器部分108。为了通信的目的，可以提供多个电触点110。除卡102外或代替卡102，系统100还可以设计成与例如卡112非接触式设备一起工作。卡112可以包括IC芯片114，其具有处理器部分116和存储器部分118。可以提供天线120用于非接触式通信，例如使用射频(RF)电磁波。可以提供振荡器或多个振动器和/或额外合适电路用于调制、解调、降频转换及类似物中的一个或多个。注意卡102、112是可以采用的多种设备的范例。系统100本身可以代替“智能”或“芯片”卡102、112或除它们之外与其他类型的设备一起运作；例如，常规磁条设备150(例如具有磁条152的卡)。此外，适当配置的移动设备(例如，“智能”蜂窝手机、平板、个人数字助理(PDA)及类似物)可以用于在一些实例中实施非接触式支付。新方法的一个非限制性示例是Apple Pay app，一种来自美国加利福尼亚州库比蒂诺市的Apple Inc.的移动支付和数字钱包服务。

IC 104、114可以包含处理单元106、116和存储器单元108、118。优选地，IC 104、114还可以包括控制逻辑、计时器和输入/输出端口中的一个或多个。这样的元件在IC领域中是众所周知的并且未单独图示。IC 104、114中的一个或两个还可以包括协同处理器，其又是众所周知的并且未单独图示。控制逻辑可以连同处理单元106、116来提供处理存储器单元108、118与输入/输出端口之间的通信所必需的控制。计时器可以提供来自处理单元106、116和控制逻辑的计时参考信号。协同处理器可以提供实时执行复杂计算的能力，例如加密算法所需要的那些。

存储器部分或单元108、118可以包括不同类型的存储器，例如易失性和非易失性存储器以及只读和可编程存储器。存储器单元可以存储交易卡数据，例如用户的主账号(“PAN”)和/或个人标识号(“PIN”)。单元108、118的存储器部分可以存储卡102、112的操作系统。操作系统加载并且执行应用且向这些应用提供文件管理或其他基本卡服务。可以用于实现本公开的一些方面或实施例的一个操作系统是MAOSCO Limited(英国Warrington,Birchwood,Kelvin Close,The Links,St.Andrews House邮编WA3 7PB的MAOSCO Limited)许可的操作系统。备选地，可以采用基于JAVA CARD^TM技术(美国加利福尼亚州Santa Clara市Network Circle 4150号、邮编95054的Sun Microsystems,Inc.许可)的基于JAVA CARD^TM的操作系统或从许多供应商可获得的专用操作系统。优选地，操作系统存储在存储器部分108、118内的只读存储器(“ROM”)内。在备选实施例中，闪速存储器或其他非易失性和/或易失性类型的存储器也可以在存储器单元108、118中使用。

除操作系统提供的基本服务外，存储器部分108、118还可以包括一个或多个应用。目前，这样的应用可以遵循的一个可能规范是由EMVCo,LLC(美国加利福尼亚州FosterCity，94404，邮递点M3-3D,Metro Center Boulevard 901号)阐述的EMV可互操作支付规范。将意识到应用可以采用多种不同方式配置。

技术人员还将熟悉在美国纽约州的万事达卡国际公司的许可下可用的 PayPass^TM规范(美国纽约州万事达卡国际公司的商标)。

如指出的，卡102、112是可以采用的多种支付设备的示例。这些支付设备的主要功能可不是支付，例如它们可以是实现合适技术的蜂窝手持电话。这样的设备可以包括具有常规形状因子的卡、更小或更大的卡、不同形状的卡、密钥卡、个人数字助理(PDA)、适当配置的手机或实际上是具有合适能力的任何设备。在一些情况下，卡或其他支付设备可以包括主体部分(例如，支付卡的层压塑料层、PDA的机箱或机柜、芯片封装及类似物)、与这些主体部分关联的存储器108、118和与主体部分关联且耦合于存储器的处理器106、116。存储器108、118可以包含合适的应用。处理器106、116可以操作以执行一个或多个步骤。应用可以是例如链接到卡存储器(例如电可擦除可编程只读存储器(EEPROM))中、采用固件加数据形式的软件代码的应用标识符(AID)。

许多不同类型的终端可以与系统100一起采用。这样的终端可以包括配置成与接触型设备102接口连接(interface with)的接触终端122、配置成与无线设备112接口连接的无线终端124、配置成与磁条设备150接口连接的磁条终端125、或组合终端126。组合终端126设计成与设备102、112、150的任何组合接口连接。一些终端可以是具有插入非接触式阅读器的接触终端。组合终端126可以包括存储器128、处理器部分130、阅读器模块132以及可选地项目接口模块，例如条形码扫描仪134和/或射频识别(RFID)标签阅读器136。项目128、132、134、136可以耦合于处理器130。注意终端126的构造原理能适用于其他类型的终端并且为了说明而详细描述。阅读器模块132一般可以配置成与卡或设备120接触通信、与卡或设备112非接触式通信、读取磁条152、或前述中的任意两个或两个以上的组合(可以提供不同类型的阅读器来与不同类型的卡接口连接，例如接触、磁条或非接触式)。终端122、124、125、126可以经由计算机网络138连接到一个或多个处理中心140、142、144。网络138可以包括例如互联网或专用网络(例如，虚拟专用网(VPN)，例如在下文关于图2描述的)。可以采用不只一个网络来连接系统的不同元件。例如，局域网(LAN)可以在零售店或类似物处使终端连接到本地服务器或其他计算机。支付网络可以连接收单方和发行商。在下文将提供关于一个特定形式的支付网络的另外的细节。处理中心140、142、144可以包括例如支付设备的发行商的主计算机。

由销售点146、148表示的许多不同的零售或其他场所可以连接到网络138。不同类型的便携式支付设备、终端或其他元件或组件可以使图1中的示例性设备描述的一个或多个特征组合或“混合且匹配”。

便携式支付设备可以促进用户与系统(例如系统100)的终端(例如122、124、125、126)交易。这样的设备可以包括处理器，例如上文论述的处理单元106、116。设备还可以包括耦合于处理器的存储器，例如上文论述的存储器部分108、118。此外，设备可以包括通信模块，其耦合于处理器并且配置成与终端(例如终端122、124、125、126中的一个)接口连接。通信模块可以包括例如触点110或天线120连同合适电路(例如前面提到的振荡器或多个振荡器和相关电路)，其准许经由接触或无线通信与终端接口连接。装置的处理器可以能操作以执行方法和技术的一个或多个步骤。处理器可以经由硬件技术执行这样的操作和/或在存储在存储器单元中的一个中的程序指令(例如应用)的影响下执行这样的操作。

便携式设备可以包括主体部分。例如，这在“智能”或“芯片”卡102、112的情况下可以是层压塑料体(如上文论述的)或在蜂窝电话情况下是手持机外壳和主体。

将意识到终端122、124、125、126是用于与持有者的支付设备交互的终端装置的示例。装置可以包括处理器(例如处理器130)、耦合于处理器的存储器(例如存储器128)和耦合于处理器并且配置成与便携式装置102、112、150接口连接的通信模块，例如阅读器模块132。处理器130可以能操作以经由阅读器模块132与用户的便携式支付设备通信。终端装置可以经由处理器130中的硬件技术或通过存储器128中存储的程序指令来运作。这样的逻辑可以可选地从例如处理中心140的中心位置通过网络138提供。可以可选地提供前面提到的条形码扫描仪134和/或RFID标签阅读器136并且其可以耦合于处理器以从待购买产品上的UPC代码或RFID标签收集属性数据，例如产品标识。

上文描述的设备102、112可以是国际标准化组织(ISO)7816兼容接触卡或设备或NFC(近场通信)或ISO 14443兼容近傍型卡或设备。在操作中，可以在无线终端124或阅读器模块132(或关联阅读器)上触碰或点击卡112，前者然后将电子数据非接触地传送到卡112或其他无线设备中的近傍型IC芯片。

处理中心140、142、144中的一个或多个可以包括数据库，例如数据仓库154。

应注意图1中描绘的系统可不仅涉及“实体”商户处的常规交易，而且还牵涉无卡交易，例如无卡网上交易或无卡循环支付。在一些实例中，在无卡网上交易期间可以捕捉互联网协议(IP)地址。在示例性无卡网上交易中，个体使用他或她的家庭计算机以通过互联网与电子商务商户的服务器通信。该个体将他或她的PAN提供给商户的服务器。商户使用PAN来发起授权请求，并且在收到指示批准的授权请求响应时将完成电子商务交易。在示例性无卡循环支付中，个体将他或她的PAN及相关数据提供给商户(例如，经由电话或邮件)。商户使用PAN来发起授权请求，并且在收到指示批准的授权请求响应时将完成循环交易。

在一些情况下，可以有这样的支付卡账户，其没有物理卡或与之关联的其他物理支付设备；例如，可以对顾客提供PAN、有效日期和安全码，但没有物理支付设备，并且将这些用于例如无卡电话或网上交易。在该方面，“持卡人”应理解为指支付卡账户的账户持有者，而不管持卡人实际上是否具有物理支付卡或其他物理支付设备。

参考图2，描绘多个实体之中的示例性关系。许多不同用户(例如，顾客)2002、U₁、U₂…U_N与许多不同商户2004、P₁、P₂…P_M交互。商户2004与许多不同收单方2006、A₁、A₂…A_I交互。收单方2006通过例如支付网络2008的单个运营商来与许多不同发行商2010、I₁、I₂…I_J交互，该支付网络配置成促进多个发行商和多个收单方之间的交易；例如，万事达卡国际公司(网络的运营商)或Visa国际服务组织(网络的运营商)。一般，N、M、I和J是可以相等或不等的整数。还注意元件2006、2010代表实际上分别对收单方和发行商实施处理的实体；在一些实例中，这些实体实施它们自己的处理；在其他实例中，它们分别使用收单方处理器和发行商处理器。

在常规信用授权过程期间，顾客2002对购买付款并且商户2004向收单方(收单银行)2006提交交易。收单方向发行商2010验证卡号、交易类型和金额并且储备对于商户的持卡人信用额度的金额。这时，授权请求和响应交换，典型地实时交换。经授权的交易“成批”存储，其然后被发送到收单方2006。在后续清算和结算期间，收单方通过支付网络2008发送批量交易，该支付网络2008将支付记入借方发行商2010并且记在收单方2006的账上。一旦对收单方2006付款，收单方2006对商户2004付款。

将意识到图2中示出的支付网络2008是配置成促进多个发行商与多个收单方之间的交易的支付网络的示例，该支付网络可以被看作“开放”系统。本公开的一些实施例可以与其他种类的支付网络一起使用，例如只有单个发行商和收单方的专有或封闭支付网络。此外在该方面，图2描绘四方模型，如技术人员将所知的；这四方是顾客2002、商户2004、收单方2006和发行商2010。然而，至少一些实施例也与三方模型一起使用，其中收单方和发行商是相同实体。

应再次注意详细说明性描述在ISO 8583支付卡网络的上下文中提供。然而，一个或多个实施例在其中交易可以适当标记为延迟清算和结算(当前或带有修改)的网络中能适用。从而，根据一个或多个实施例可以交付服务所经由的网络的非限制性示例包括MASTERCARD、VISA、AMERICAN EXPRESS或甚至PAYPAL或类似物。

例如网络138和/或网络2008的网络内的消息在至少一些实例中可以遵循ISO标准8583金融交易卡始发消息-互换消息规范，其是交换由持卡人使用支付卡进行的电子交易的系统的ISO标准。应注意技术人员将熟悉ISO 8583标准。然而，处于高度谨慎，下列文献出于所有目的通过引用全部明确合并于此(瑞士日内瓦ISO发布并且在ISO网站上可获得)：

·ISO 8583部分1：消息、数据元素和代码值(2003)

·ISO 8583部分2：对于机构标识码(IIC)的应用和注册规程(1998)

·ISO 8583部分3：对于消息、数据元素和代码值的维护规程(2003)

·ISO 8583：1993(1993)

·ISO 8583：1987(1987)

如本文使用的，“支付卡网络”是通信网络，其使用支付卡账号(例如主账号(PAN))来对支付卡交易授权并且促进支付卡交易的清算和结算-例如对于信用、借记、储值和/或预付卡账户。卡账户具有与它们关联的标准化支付卡账号，其允许交易的高效路由和清算：例如，ISO标准账号，例如ISO/IEC 7812兼容账号。卡账户和/或账号可以具有或可以没有物理卡或与它们关联的其他物理支付设备。例如，在一些实例中，组织具有对其分配支付卡账号、用于为组织进行购买的购买卡账户，但没有对应物理卡。在其他实例中，采用“虚拟”账号；这也称为PAN映射。PAN映射过程牵涉采取原始主账号(PAN)(其可以与物理卡关联或可以不与之关联)并且在其位置发行伪PAN(或虚拟卡号)。市售PAN映射技术方案包括从爱尔兰都伯林Carysfort大街Blackrock商业园街区1的Blackrock,Co.的Orbiscom Ltd.(现在是美国纽约州万事达卡国际购买公司的一部分)获得的那些；通过示例并且没有限制，Flitcroft等人的美国专利6,636,833和7,136,835的技术，这两个的完整公开出于所有目的通过引用全部明确合并于此。

一些支付卡网络使多个发行商与多个收单方连接；其他使用三方模型。一些支付卡网络使用ISO 8583消息传递。使多个发行商与多个收单方连接的支付卡网络的非限制性示例是网络和网络。

仍参考图2并且现在还参考图6和7，通过对额外细节的回顾和预备，顾客2002有效地向商户的终端126呈递他或她的卡150或其他支付设备(例如，呈递适当配置的“智能”电话或使用电子钱包)。磁条卡150和组合终端126通过示例示出，但意在一般代表任何种类的支付设备和任何种类的终端。有效呈递可以直接(用户进入商户2004的实体店)或虚拟(用户经由个人计算机的浏览器或类似物登录商户2004的网站，或打电话并且提供卡信息)发生。商户终端126捕捉卡账户信息(如直接呈递的话通过刷或无线通信；如远程的话通过手动键入或读取数据)并且将其转发到收单方2006。商户与持卡人之间的交互本身在支付卡网络的范围外。支付卡网络在收单方2006与网络2008之间的连接处介入；图6和7中点E与F之间的虚线包围网络2008。一般注意图6中的点A、B、C、E和F连接到图7中的对应点；整个网络和关联环境不适合在单个表上图示。

更具体地，收单方2006在图6和7的更特定示例中在其处具有支付网络接口处理器(PNIP 2012)。万事达卡接口处理器或MIP是PNIP的非限制性示例。在非限制性示例中，PNIP在机架式服务器上实现。PNIP典型地位于支付卡网络边缘处。在至少一些实例中，图2的支付卡网络是分布式网络，其中每个收单方和发行商在其处具有至少一个PNIP。每个收单方2006将与一个或多个商户2004有关系并且将经由终端驱动器2014与商户的终端126接口连接(收单方本身也可以充当商户)。此外，在该方面，商户位置将具有终端，在这里刷卡(或在这里呈递接触或非接触式设备)。收单方将采用终端驱动器2014来与那些终端接口连接。终端驱动器2014是代表允许收单方处理平台2015经由TCP、拨号或类似物而与商户的终端通信的软件和/或硬件的逻辑块(在图中的示例中示出TCP/IP接口2016)。每个商户将决定使用什么收单方来接受支付卡的一个或多个商标，并且收单方将对商户设置对商户的销售点设备合适的软件和/或固件。

收单方2006将经由PNIP接口2012从许多不同商户2004向支付卡网络运营商2008呈递交易。商户2004与收单方2006之间的连接典型地是TCP/IP接口2016。在商户2004处刷卡时交易所采用的格式可以与在被支付卡网络运营商实际接收时交易所采用的格式不同。收单方可以将交易转换成ISO 8583格式或是ISO 8583格式的特定实现的格式(例如，MASTERCARD CIS(客户接口规范)格式)。授权请求消息可以是例如通过商户2004与收单方2006之间的通信接口2016发送的ISO 8583消息型标识符(MTI)0100消息。

一旦在收单方2006的PNIP 2012处接收0100消息，可以关于格式、内容和/或上下文对交易执行一系列编辑。此外，可以实施筛选来确定消息是否涉及普通授权请求之外的某事物，称为增强服务。可以代表一个或多个发行商2010和/或网络2008本身的运营商来对增强服务筛选。可以提供集中成员参数系统(MPS)2018来容置用于驱动信贷授权交易的处理的参数。在一个或多个实施例中，从集中成员参数系统2018的提取每天分布到网络2008上的所有收单方PNIP 2012和发行商PNIP 2024来驱动信用卡交易的处理。

这时应注意在BANKNET中采用“ICA”和“BIN”，使得成员可以执行卡发行和/或收单活动。ICA或银行间卡片协会是由万事达卡分配的四至六位数标识以供成员用于唯一识别成员所负责的活动。BIN或银行标识号是由万事达卡向主要成员分配的唯一数字系列并且用作持卡人账号的前六位数。其他支付卡网络具有相似类型的数字，如对技术人员将是明显的。

在至少一些实施例中，相同的成员参数提取发送给所有PNIP并且交易使用这些PNIP来路由。在至少一些情况下，账号或账号范围在决定如何路由中使用。在一些情况下，基于账户范围在哪里“注册”来将交易路由到发行商PNIP。发行商用组ID或账户范围来发送MTI 0800注册请求消息。成员ID从PNIP端口2038配置抽提并且来自该账户范围的交易然后路由到从其接收注册请求的端口。成员ID可以在发行商站点处在多个PNIP上的端口上呈递-参见下文的图10的论述。

在一个或多个实施例中，基于账户范围，MPS 2018中的参数(或其本地提取)将确定如何处理指定交易；例如，产品代码、国家代码、货币代码及类似物，其包括发行商对于在特定账户范围上注册什么增强服务(如有的话)。就是说，对消息解析并且检查某些字段，其包括账户范围；账户范围与某一发行商关联并且基于此，可以有差别地对待消息。可以对消息解析，并且将其转换成内部数据格式，使得可以获得对所有个体数据元素的访问。在一个或多个实施例中，账号用作访问MPS 2018(或其本地提取)并且检索适合于处理指定交易的所有参数的密钥。在非限制性示例中，适合的消息解析器2020(和PNIP 2012上的其他程序)可以采用合适的高级语言或类似物来编写。

在示例性实施例中，中心MPS 2018一天一次创建提取，其被分发到网络上的端点(例如，PNIP 2012)，如在2022处看到的。这些提取包括PNIP处理消息并且确定它是否需要任何特殊处理所需要的相关信息。在一些实例中，消息接着路由到中心站点2009以执行增强服务。另一方面，如果不需要特殊服务，消息可以直接路由到发行商PNIP 2024，如在2026处看到的。

消息直接路由到发行商PNIP：在该方面，交易基于MPS提取2022直接路由到发行商PNIP 2024，如在2026处看到的。每个账户范围将具有在参数中标识的唯一目的端点(账户范围可以分组并且账户范围组的所有成员可以具有共同目的端点)。成员接口是指收单方处理器2006与收单方PNIP 2012之间的连接。该术语还适用于发行商PNIP 2024与发行商处理器2010之间的接口。收单方PNIP 2012与发行商PNIP 2024、收单方PNIP 2012与ASP 2050以及ASP 2050与发行商PNIP 2024之间及之中的连接称为到支付卡网络自身上的网络接口。在一个或多个实施例中，这可以是TCP/IP连接(如在2026处看到的)，其具有包括组地址的自定义路由能力。通常，TCP/IP地址指单个端点。组地址可以针对一组地址，并且将以使用多种协议的组中的计算机(例如，PNIP)中的任一个为目标。一些使用轮询调度法；其他可以使用先入列表法，其中消息总是首先路由到一个指定计算机并且然后仅在前者不可用时路由到第二计算机。组寻址可以是有用的，例如在为了冗余/容错而使收单方或发行商在相同位置具有多个PNIP的情况下。也可能使方法组合并且创设轮询调度，其中轮询调度内的地址是先入列表组地址，或相反，可能创设先入列表，其中先入列表中的地址是轮询调度组地址。这些能力在停工、维护及类似的情况下是有用的。

图8示出了四个PNIP 2028-1至2028-4的非限制性示例。在轮询调度法中，第一消息首先路由到PNIP 2028-1，第二消息到PNIP 2028-2，第三消息到PNIP 2028-3，第四消息到PNIP 2028-4，第五消息到PNIP 2028-1，以此类推。在先入列表法中，所有消息路由到PNIP 2028-1；如果它对于指定消息不可用，则消息路由到PNIP 2028-2；如果PNIP 2028-2不可用，则消息路由到PNIP 2028-3；如果PNIP 2028-3不可用，则消息路由到2028-4。图8中的每个PNIP 2028-1至2028-4可以是正如上文论述的先入列表或轮询调度所寻址的单个机器或一组机器。在一个或多个实施例中，PNIP 2012、2024之间的物理网络2026以及PNIP2012、2024与中心站点2009之间的物理网络2030、2032是私人多协议标签交换(MPLS)TCP/IP网络并且不是互联网。一旦PNIP 2012(或ASP 2050)确定发行商的网络组地址，消息路由到发行商PNIP 2024。一旦0100auth消息到达发行商PNIP 2024，执行额外编辑来复查并且确保消息已路由到正确位置。此外，检查成员ID，这是因为一些发行商可以共享单个PNIP并且有必要确定谈论中的交易要路由到共享该PNIP的发行商(成员)中的哪个。共享PNIP的发行商中的每个将在PNIP的成员侧上具有它自己的端口；交易基于成员参数路由到合适的端口。参见图9，其中广义PNIP 2028具有网络侧2034和成员侧2036。成员侧2036具有到成员1至N的N个端口2038-1至2038-N。N在本文用作广义的任意整数并且图9中N的值不一定与例如关于图2中的元件2002的N的值相同。

如在图10中示出的，在一些实例中，发行商在单个站点处具有多个PNIP设备2028，其具有网络侧连接2034，并且具有多个PNIP 2028，全部都连接到相同的主机系统(每个具有与相同成员(发行商)关联的端口1 2038-1)。

这时，0100消息被交付给发行商2010。发行商2010然后基于交易速度、购买限额、欺诈检测协议等来实施发行商处理和决策(例如，利用发行商处理平台2040)，并且提供合适的授权请求响应ISO 8583MTI 0110。在ISO 8583和它的特定实现内限定有许多不同的可能响应代码。每个交易由多个数据元素组成；来自发行商的响应包括在数据元素39中。一旦在发行商PNIP 2024上从平台2040接收0110消息，则就格式、内容和上下文来对它解析和编辑，包括DE 39的验证来确保它是有效值。

值得注意的是在一个或多个实例中，在其中交易接触支付卡网络的计算机的每个点处，无论它是收单方PNIP 2012、发行商PNIP 2024还是中心位置2009(下文论述)处的特殊服务计算机或多个计算机2050，交易上下文都得到保留。就是说，在消息发送到网络中的下一个节点之前，将副本保存在上下文管理器队列2042、2046、2058中，使得在交易折回时，请求可以与响应匹配，以便知道如何将响应路由回之前的路由点。上下文管理器队列中保存的项目中的一个是消息始发端的地址，使得它可以用于路由返回信息。一旦完成发行商PNIP验证，其包括格式、内容和上下文编辑，从上下文管理器队列2046提取交易并且检索路由返回地址，并且然后将0110消息发回它来自的地方；在该情况下，是收单方PNIP 2012(或ASP 2050)。收单方PNIP 2012然后接收消息并且对其解析且从它的上下文管理器队列2042中抽提出它的原始请求。注意多个收单方可以共享收单方PNIP并且因此有必要知道将响应路由回收单方PNIP上的哪个端口(参见图9的论述)。跟上下文管理器队列中的原始请求核对消息允许将消息路由回正确的端口。

每个PNIP 2012、2024典型地具有许多不同程序。这些可以包括例如解析器/编辑器2020、2043；参数文件管理器；交易上下文管理器；成员通信程序；网络通信程序；及类似物。请注意为了减少混乱，图6和7示出了“MPS提取”2022、2044；这典型地将包括提取本身和关联的参数文件管理器，其管理从MPS 2018获得提取。相似地，为了减少混乱，图6和7示出了“上下文管理器队列”2042、2046；这典型地将包括队列本身和关联的管理器，其管理队列的内容。在一个或多个实施例中，还存在用于在PNIP上的其他程序(过程间通信)之间通信的通信程序；为了避免混乱而将其从图6和7省略。

增强服务情况下的消息：在一个或多个实例中，特殊架构用于促进增强服务的交付(图6和7中的ASP 2050是非限制性示例)。增强服务的示例包括提供支出控制和/或虚拟卡号的MASTERCARD IN CONTROL产品(MASTERCARD IN CONTROL一般代表支出控制系统、卡控制系统及类似物，并且指示为采用MASTERCARD IN CONTROL的实施例不旨在意指对一个特定支出控制和/或卡控制系统的任何限制)。增强服务的其他实施例是忠诚奖励、重复支付取消等。一个或多个实例未将该复杂逻辑部署到网络边缘。此外在该方面，发行商和收单方PNIP 2012、2024因为它们驻存在客户端2006、2010上而称为在边缘上。典型的网络上可以有超过2000个PNIP。在一个或多个实例中使用的特殊架构是与位置2009关联的中心站点型架构。在中心站点2009处，某些计算机称为授权服务处理器或ASP 2050。

在收单方PNIP 2012上，在对账户范围检查成员参数文件时，确定交易是否需要增强服务。如果是的话，交易路由到中心站点ASP 2050，其具有到所有服务提供商系统的接口-ASP不一定提供服务本身(尽管它们在一些实施例中可以提供)，而可以在网络(例如，BANKNET)与实际服务提供商2051-1至2051-N之间调停。ASP典型地将具有经由DB2连接或其他合适连接到大型机2052的连接2053。如果交易富含额外数据，将对大型机2052进行数据库调用来从大型机数据库2054检索信息使得它可以在将交易转发到发行商之前插入交易。还可以提供到风险管理系统、决策管理系统、MASTERCARD IN CONTROL、奖励及类似物的接口连接。服务提供商2051-1至2051-N一般代表任何增强服务，在本文给出了其非限制性示例。

在一个或多个实施例中，通信层2056用于与服务提供商通信，合适的实现方式的非限制性示例是IBM MQ系列。0100消息可以发送给服务提供商，可选地包封在特定的“增强服务(ES)”报头内，该报头用履行服务所需要的任何额外信息来包装消息。服务提供商发送响应。ASP接受响应并且使0100交易富含服务响应，并且然后将整个包发送到发行商PNIP2024。一些增强服务在请求消息(0100)上处理并且其他在响应消息(0110)上处理。一旦响应消息在ASP上处理，将从ASP上的上下文管理器队列2058抽提出原始消息来确定将消息路由回的合适的收单方PNIP2012。收单方PNIP从那里将表现得正如上文论述的“消息直接路由到发行商PNIP”情况一样。特殊架构的一些实施例使用企业服务总线来调停并且促进服务2051中的一些。例如，MASTERCARD IN CONTROL服务可以经由企业服务总线的实例来访问。

数据进入数据仓库：在一个或多个实例中，流过发行商PNIP 2012、收单方PNIP2024和/或ASP 2050的每笔交易在每个点通过写日志记录来记录。全局文件传输系统2059一天多次(例如，六次)从每个节点抽提出日志并且将它们收集到大型机2052上的支持文件系统2060内。对日志文件解析并且将它们收集到一般日常文件内。对该一般日常文件擦除和修改以在大型机上创建合并文件，其然后被拉入数据仓库2062，在这里在存储交易之前执行额外数据操纵和擦除。数据仓库2062位于连接到收单方和发行商2012、2024的PNIP的中间节点(位置2009)处。通过阐明，在一个或多个实施例中，节点2009直接连接到PNIP2012、2024，但数据仓库未直接连接到2012和2024设备；相反，数据流过GFT和SF系统2059、2060并且在数据仓库中结束。数据仓库2062应与可以被发行商维持的数据仓库154区分开。

清算和结算：一个或多个实例采用清算和结算系统2074。在清算中，经由全局文件传输2059，收单方采用合适的消息格式(在非限制性示例中，是集成产品消息(IPM)格式)提交清算文件。文件从收单方的角度来看包含它们认为它们应该为什么付款。在一个或多个实例中，授权实际上未移动任何钱；授权仅验证持卡人是银行承认的有效持卡人，这将为了商品或服务而向商户付款。例如，在典型的餐厅光顾中，就收据金额来刷卡但然后添加小费。清算消息将具有实际食品金额加上小费。在一个或多个实例中，清算实际上并未移动钱；它仅仅解决实际金融。结算系统实际上发起金钱移动。此外在该方面，结算系统实际上告知银行要移动多少钱但实际上未移动金钱。在清算内，过程包括调解纠纷、退款等。在清算期间，文件从收单方发送到支付卡网络；支付卡网络然后使用清算和结算系统2074来获取文件并且划分它们且由发行商对它们分类。然后从每个发行商接收到响应文件，并且这些响应文件再次被划分并且再次分类回到正确的收单方。最后，数据流入结算系统并且金钱被移动。从而，在高级别处，验证请求和验证请求响应是实时的，并且清算和结算采用批量模式。

通过回顾并且预备额外细节，在至少一些实例中，采用批量模式，经由对于第一呈递具有DE24功能代码值200的ISO 8583MTI 1240消息来发起清算。一旦从收单方获得该消息，支付卡网络使用清算和结算系统2074将进行语法编辑、格式编辑、内容编辑和上下文编辑(典型地适用于每笔交易)。如果那些编辑被传递，则将计算与交易关联的交换和费用。基于计算，消息在传递给发行商之前也可以富含额外信息。然后确定结算金额。在清算周期内，对每个指定成员(例如，发行商或收单方)所欠的金额累积，并且这些相加到结算文件，其在适当时候被转发。

加密方面：考虑静态数据和运动数据的方面。静态数据的示例是日志文件，其实际上驻存在PNIP本身上-包含卡号或个人可标识信息(PII)的配置信息。在一个或多个实施例中，所有敏感静态数据在写入盘之前被加密。运动数据指实际上在传输介质(例如，线、同轴电缆、光纤电缆、RF链路)上移动的数据。所有PCI敏感数据(美国马塞诸塞州Wakefield市的PCI安全标准委员会LLC)无论是写入盘还是通过网络来发送都被加密。在至少一些实例中，收单方和发行商端内的内部链路因为假设客户端是依赖硬件的物理安全的物理安全设施而未被加密。另一方面，在至少一些实例中，外部链路(例如，链路2026、2030和2032)针对授权业务和批量文件传输全部被加密。

一个或多个实施例将具有到支付卡处理网络的其他品牌的接口2068。例如，MASTERCARD品牌的支付卡处理网络可以具有到例如AMERICAN EXPRESS、VISA、JCB、DISCOVER等网络的接口。根据情况可以提供适合的转化层以介于MASTERCARD(或其他)格式和其他网络使用的格式之间。在一个或多个实施例中，经由位于2009处的机器提供到其他支付网络的接口2068，但一般与添加有由其他支付网络格式根据需要加载的调解层的发行商PNIP 2024相似。一些商户可以仅具有到例如MASTERCARD网络的单个接口-来自该商户的所有交易可以路由到MASTERCARD，而不管使用什么卡-MASTERCARD将处理那些交易并且将它们路由到合适的网络。

ISO 8583支付卡网络上的增量支付记账及其示例性实施方式

一个或多个实施例提供增量支付(“IP”)记账-一种即使在资金并未立即可用时也使例如公用事业公司的开账单人能够从顾客收取支付卡付款的技术方案。该方法可以例如向已知顾客和工资程序的经验证成员提供。顾客因有能力具有更好的支付计划选项并且管理他们的支付(即使在对账单的付款日并未与工资发放日同步也如此)而受益。

在典型的循环记账支付场景中，顾客向商户提供他或她的预付(或其他)支付卡账号并且授权商户就顾客每月(或其他循环时期)、在某一预定日(例如，每月的第一日)的购买金额来对顾客开账单。在一些实例中，商户试图在预定日对存档卡号收费，但商户接收拒绝(例如，预付支付卡资金不足，活期存款账户对于借记卡资金不足，或支出限额的余额对于信用卡太低)。当前，在这样的情况下，商户可以对谈论中的月份切断顾客服务(在许可的情况下)和/或可以对逾期支付收取费用。

相比之下，在一个或多个实施例中，持卡人、发行商和开账单人选择性加入增量支付计划。在该方面，当在预定日时，商户向发行商2010发送授权请求(AUTH；例如，ISO 85830100)；发行商确定尽管持卡人“没有钱”(例如，预付支付卡资金不足，活期存款账户对于借记卡的资金不足，或支出限额的余额对于信用卡太低)，持卡人选择性加入增量支付程序。例如，发行商决策平台2040访问有持卡人账户记录的具有持卡人参与增量支付记账这一标志的数据库2041。如与当前技术相对，在一个或多个实施例中，发行商可以通过实际上指示“我拒绝典型交易(例如，如果持卡人当前资金不足)但我批准增量支付交易”来对AUTH请求作出响应。备选地，发行商可以简单地通过指出标志来对批准作出响应而不管持卡人持有的当前资金如何。发行商在预期持卡人实际上在支付卡账户具有资金可用的预定时间来对商户增量支付(在一个或多个实施例中，发行商承诺在任何情况下支付，即，无论持卡人在预定时间实际上是否有资金)。

如本文使用的，“预付支付卡”(也简称为“预付卡”)指根据信用或借记卡类型支付系统标准或规范(如与专用交通卡或类似物相对的)配置的卡或其他设备(例如，适当配置的蜂窝电话手持机)，其中与卡关联的储蓄余额驻存在中心或远程服务器上，设计该预付支付卡以供在常规信用或借记卡环境(例如，如图1、2&6-10中示出的那种)中使用，并且它被各种商户几乎举世公认。这样的卡还与信用或借记卡的区别在于它访问中心服务器而不是信用账户(例如，信用额度支出限额)或银行账户(例如，支票或其他活期存款账户)上的余额。借记卡典型地连接到支票账户而预付卡则没有。

一个或多个实施例使用特定“增量支付”交易。代替用常规批准或拒绝来对AUTH请求作出响应，发行商用特定“增量支付批准”作出响应。在常规场景(具有常规“批准”AUTH请求响应的常规AUTH请求)中，典型地将在发行商批准后约2-3天内对商户付款。在使用特定“增量支付”交易的一个或多个实施例中，在开账单人和持卡人都能接受的预选时期内(在非限制性示例中，是相等支付增量、每周支付、在发行商给出特定“增量支付批准”后三十(30)天内)以增量提供支付。此外，在一个或多个实施例中，通过发行商提供特定“增量支付批准”，发行商承诺在(延长)日期对商户支付，而不管持卡人实际上在这样的时间是否有资金可用。在该方面，发行商最终为顾客承担信用风险并且必须判断持卡人是否最后将有资金来支付。

在一个或多个实施例中使用的增量支付响应实现为数据元素39(DE39)中的新响应代码值。每笔交易由多个数据元素组成；来自发行商的响应包括在ISO 8583 0110 AUTH请求响应的数据元素39中。在响应中的DE39内，定义新的值，其将响应识别为增量支付响应。在一个或多个实施例中，发行商决策平台2040将响应标记为“增量支付”响应并且在发行商PNIP 2024指出DE39内指示响应是“增量支付响应”的特殊值时，采用合适方式处理响应。将ISO 8583 0110 AUTH请求响应发回收单方2006并且如果商户是将接受增量支付交易的商户的话则发回商户2004使得交易可以进行。在一些情况下，ISO 8583 0110 AUTH请求响应被直接发回收单方2006(如在2026处示出的)并且清算和结算至少部分被延迟，如在本文的其他地方描述的。在其他情况下，发行商PNIP 2024并未将ISO 8583 0110 AUTH请求响应直接发回收单方PNIP 2012而相反将AUTH请求响应视为需要增强的服务并且将它路由到ASP 2050。在该实施例中，当在ASP 2050处接收时，DE39内特殊值的存在对清算和结算系统2074触发消息来将对于指定交易的交易标识符置于标记数据库2075中(再次为免存疑，在任一情况下，ISO 8583 0110 AUTH请求响应被实时发回收单方2006使得如果商户接受增量支付交易则交易可以进行)。在采用标记数据库2075的实施例中，就标记数据库2075中交易标识符的存在来检查清算消息；如果存在的话，将那些交易置于保持队列2076中。在一个或多个实施例中，服务参数包括在从MPS(2018)到收单方PNIP 2012和发行商PNIP 2024平台的提取中来指示账户范围有资格得到增量支付服务。这些服务参数允许系统触发增强路由和/或服务履行。

在接受增量支付交易的一些实施例中，清算和结算完全被延迟。也就是说，在缺乏特定程序的情况下在对交易通常结算的时期内没有支付金额。在其他实施例中，在随时间增量式地对余额结算的常规时期内实行部分结算。清算和结算待延迟的时间量可以固定在预定值(直接是交易金额的一半并且两周的余额结算是非限制性示例)或在备选实施例中可以能配置为任何期望值。在增量支付之间的时期能配置的情况下，通知相关方，如下文论述的。

如指出的，在一个或多个实施例中，特定“增量支付批准”实现为ISO 8583 0110响应的数据元素39(DE39)中的新的响应代码值。当前，“由于某一原因而拒绝”是可能。在一个或多个实施例中，交易是“批准增量支付”。“增量支付”在该上下文中意指以两个或更多个增量来对商户支付，该两个或更多个增量总共可以等于商户收取的金额。此外在该方面，一般用“批准”或“有理由拒绝”代码来对授权请求作出响应。在一个或多个实施例中，定义新类型的批准，即，“增量支付批准”，其简单地指示对于指定交易，发行商将在比如说三十(30)天(或其他商定时期)内以增量支付所欠的金额而不是在通常的两到三天内一次性支付全部金额。

在一些实施例中，定价也可以不同。例如，商户支付的交换费与典型购买交易中的可以不同(例如，比其还低)。支付卡网络运营商也可以将交易定价为比发行商和收单方两者典型的更高或更低。

一个或多个实施例涉及由开账单人和持卡人选择性加入(例如，经由注册)。持卡人的获益之处在于随时间对账单付款而不是在资金不可用时一次性将全部发票金额记入借方。开账单人的获益之处还在于开账单人可以获得保证支付而不是杜绝与顾客联系或评估惩罚，即使随时间进行增量支付而不是立即进行支付也如此。

图3是根据本公开的方面从开账单人(例如，商户2004)的角度来看的示例性方法的流程图。图4是根据本公开的另外的方面从持卡人(例如，2002)的角度来看的示例性方法的流程图。在步骤302，一个或多个开账单人或商户加入增量支付计划。在步骤304，开账单人定义涉及持卡人待进行的增量支付的频率选项。在步骤402，一个或多个持卡人加入增量支付计划并且可选地用于电子记账。就是说，持卡人可以可选地告知商户该商户应只是每月对相同卡收费。作为登记过程的部分，持卡人提供合适信息，例如他或她的个人信息；工资证明、雇主和工资账户；员工验证等。更一般地，持卡人应指示他或她挣了多少。持卡人还请求在增量支付计划下对待特定开账单人(例如，电力公用事业)进行处理，如在步骤404中看到的。在步骤306，开账单人发起结账并且提交购买交易。发行商(例如，2010)用上文论述的增量支付消息(即，特定“增量支付批准”)来作出响应(在一些实施例中，增量支付消息仅在没有足够资金来对全部发票付款时使用)。

注意在一些实施例中，如果服务在工资卡程序上交付，则该工资卡的发行商应证实这个人继续为那个雇主工作；这称为“由工资程序验证”。

在步骤406，持卡人根据频率/支付金额收到发票。例如，六百美元的发票可以安排为在六个月过程中进行的两百美元的三个等额支付，每两个月支付一笔。可以例如经由电子邮件、文本消息接收对持卡人的交易活动结单(在线或打印)或类似物的确认。接着发生结算。

如果发行商在发行商经由增量支付交易给出特定“增量支付”批准后在商定日期(例如，每月或隔月的第一天)催促付款(push payment)，则在发行商侧上创建额外清算消息并且其被收单方接收。支付网络的运营商将保持清算请求并且然后将对于较低增量金额的新的清算消息发送给发行商。发行商然后将支付应付款项。支付网络运营商可以采用保持队列2076来保持商户对创建新清算消息、反映增量支付细节的清算请求。

通过回顾并且预备额外细节，在一个或多个实施例中，清算消息在进入系统时被搁置在一边。一般，延迟的清算和结算在实现增量支付协议时可以采用许多不同方式来完成：

第一非限制性示例性备选方案：标记0110auth请求响应来指示增量支付交易，并且因此是清算和结算消息。0110auth请求响应可以从发行商直接前往收单方并且回到商户；它不必经过中心设施2009。清算和结算消息被中心设施基于标志而拦截，并且基于增量支付交易标志而被置于保持队列2076中。商户在一天结束的时候将具有批量完成的交易来发送给收单方，其包括“常规”和“增量支付”交易。在商户构建清算消息时，有地方来指示一些交易是增量支付交易。商户向将文件发送给中心设施2009的收单方发送文件。支付网络使常规交易与增量支付交易分开。后者基于增量支付指示而被置于保持队列2076中。

在使用该备选方案的一个或多个实施例中，收单方在清算消息中放入增量支付标志。例如，与DE24功能代码值200结合的ISO 8583MTI 1240用于第一呈递，并且新的私人数据子元素(PDS)在MTI 1240消息内使用来将交易标记为增量支付交易。该标志由支付卡网络指出并且交易被置于保持队列2076中。如果增量支付之间的时期和/或增量支付金额是能配置的，则例如可以将登记/注册期间或0110和/或1240消息中的特殊数据元素或子元素中的时期和支付金额告知支付卡网络。还应注意，关于每个增量支付的清算和结算的延迟(其通常取决于收单方使用的交换费率指示器)，围绕交换费率指示器存在某些“时效性编辑”。例如，需要一些交易在(非限制性示例)3-5天内发入清算和计算；一些可能更长。然而，保持2周可能不能进行时效性编辑。此外，在至少一些实例中，支付网络将合适的消息发回以便于对账。在一个或多个实施例中，设置时效性编辑的多个方同意在登记/注册过程期间有延迟期。该备选方案是收单方寻常的业务，但排除包括新的PDS增量支付标志。

第二非限制性示例性备选方案：标记0110auth请求响应来指示增量支付交易；但清算和结算消息则不必这样。0110auth请求响应并未直接从发行商前往收单方且回到商户；它首先经过中心设施2009，在这里它的唯一交易号码进入标记的数据库2075。当清算和结算消息进入中心设施2009时，跟前面提到的标记的数据库2075来核对这些唯一交易号码并且通过将保持数据库中列出的那些增量支付交易置于保持队列2076中而对它们延迟清算和结算。

如与第一示范性备选方案中的一样，如果增量支付之间的时期(其包括交易与第一增量支付之间的时期)和每个增量支付的金额是能配置的，则例如可以将登记/注册期间或0110和/或1240消息中的特定数据元素或子元素中的时期和增量支付金额告知支付卡网络。将意识到支付金额可以是固定总额、交易金额的百分比或根据其他准则确定的金额。上文的关于围绕交换费率指示器的“时效性编辑”的注释在这里也能适用。

该备选方案是收单方寻常的业务；支付卡网络需要为清算和结算呈递的每笔交易跟标记数据库2075核对交易标识符并且在适当情况下将其置于保持队列2076中。

第三非限制性示例性备选方案：在这里，收单方延迟发起清算和结算。如果增量支付之间的时期和/或增量支付金额是能配置的，则例如可以将登记/注册期间或0110消息中的特定数据元素或子元素中的时期和/或增量支付金额告知收单方。上文的关于围绕交换费率指示器的“时效性编辑”的注释在这里也能适用。该备选方案是支付卡网络寻常的业务。

值得注意的是在备选方案中的任一个中，中心设施2009可以保持0110消息的副本并且使用ASP 2050将其置于文件中，以用于验证目的。

在一个或多个实施例中，为了使服务更易于实现，支付卡网络的运营商将记录所有增量支付授权并且在它们进入(例如，在队列2076中)时将‘清算消息’搁置到一边，并且然后根据合适的增量支付金融和时序来处理清算消息。

关于发行商催促付款，在“提取”付款(pull payment)中，待对其付款的实体发起支付；在“催促”付款中，进行支付的实体发起支付。换句话说，在“提取”付款中，卡账户被商户使用现有的销售点或与商户的收单方的交互点技术来处理；在“催促”付款中，买方而不是供应商或商户将信息推入商户的收单方(例如，经由例如在Lovelett等人在美国专利8,732,044(出于所有目的通过引用全部明确合并于此)中描述的电子交易装置等网关)。适合的备选术语是“供应商发起支付”(与PULL相同-待对其付款的实体(或如论述的第三方)有卡号并且将“命中”号码)和“买方发起支付”(PUSH-买方仅对待对其付款的实体(或如论述的第三方)给出卡号并且在买方就绪时指示该实体“命中”卡)。

如果在增量支付到期时在持卡人账户中没有资金可用，则在一些实施例中，发行商仍然对开账单人付款并且直接解决持卡人的问题。假设全部有序，开账单人在步骤308中向持卡人发送支付确认。与上文一样，可以例如经由电子邮件、文本消息在持卡人的交易活动结单(在线或打印)或类似物上接收确认(这些通信模式一般能适用于本文提到的通知)。如在步骤410中看到的，在一些实施例中，持卡人在每个增量支付之后接收支付确认(图4中的步骤408)。如果在持卡人的账户中没有资金可用于一个或多个增量支付，则发行商仍然对开账单人付款并且直接解决持卡人的问题。发行商可以关于持卡人采取适当动作，例如收取费用、进行第二次尝试、取消另外参与增量支付计划、取消卡账户、追讨欠款活动等，如能适用的法律、规则和规章所准许的。

一个或多个实施例使用支付卡网络；BANKNET和VISANET是非限制性示例。一个或多个实施例采用特定的、新颖“增量支付批准”授权请求响应。

一些实施例包括指示哪些客户可以在商户侧上具有增量支付功能性的编辑。在一些实例中，持卡人向发行商登记并且在增量支付登记的持卡人数据库2041中记录持卡人登记。开账单人登记是可选的-开账单人可以只选择与它们的收单方一起工作。例如收单方2006等收单方可以保持所登记的开账单人的数据库2021。发行商可不必登记；它们可以只决定开始使用增量支付交易类型。在一些情况下，发行商2010在成员参数系统2018中被标记为参与增量支付(IP)程序，如在2019处看到的。一些实施例提供BIN级控制来防止关于例如礼品卡的增量支付响应的使用。一些实施例准许发行商用“增量支付”批准作出响应，但如果收单方不想处理增量支付交易(例如，如果对应商户在数据库2021中不存在)则进一步准许收单方拒绝。在这样的实例中，就像当前在一些其他情况下所进行的那样，收单方向商户发送拒绝并且向发行商发回撤销。在一些情况下，唯一登记是持卡人向发行商登记。如上文论述的，作为登记过程的一部分，相关实体可以商定与增量支付关联的参数；即，时序和金额。

考虑到目前为止的论述并且继续参考图3、4和6-10，将意识到一般来说，根据本公开的方面的示例性方法包括以下步骤：通过具有标准清算和结算时期(在非限制性示例中，2-3天)的支付网络(例如，支付卡网络(2008是其非限制性示例)、PAYPAL型网络等)从多个开账单人(例如，2004)中的指定一个获得对支付交易的授权请求(ISO 8583 MTI 0100是非限制性示例)。该步骤可以例如由网络2008的边缘处的PNIP 2012实施。另外的步骤包括经由支付网络传递对支付交易的授权请求的特定增量支付批准授权请求响应(ISO 8583 MTI0110是非限制性示例)。传递包括例如从发行商沿ISO 8583 MTI 0110传递或在3方或PAYPAL型网络中既准备响应也发送响应。在前者情况下，例如，网络2008传递消息，如在2026处或可选地如在2032、2030处示出的。特定增量支付批准授权请求响应指示将关于授权请求之后在所选时期内按时间增量进行的多个增量支付中的支付交易来对多个开账单人中的指定一个付款，而不管资金是否对于与支付交易关联的账户可用。继标准清算和结算时期之后在所选时期内进行增量支付中的至少一个。甚至另外的步骤包括在继标准清算和结算时期之后的一段时间之前限制不对支付交易的至少部分清算和结算。例如，在一些实施例中，在标准清算和结算时期内进行第一增量支付并且继标准清算和结算时期之后进行一个或多个额外增量支付。在其他实施例中，继标准清算和结算时期之后按时间增量进行全部的增量支付。清算和结算因此在所选时期内增量式地发生。实现限制步骤的非限制性方式在本文别的地方论述。

在一些情况下，支付网络是支付卡网络(2008是非限制性示例)并且支付交易是支付卡交易。在至少一些这样的情况下，限制不清算和结算的步骤在支付卡网络中的中间节点(例如，2009)处实施，并且传递特定增量支付批准授权请求响应的步骤包括从与支付卡交易关联的支付卡的发行商2010获得响应(例如，经由PNIP 2024)。

在一些情况下，另外的步骤包括经由支付卡网络(例如，经由PNIP 2012)获得清算消息(在非限制性示例中，具有数据元素24功能代码值200和私人数据子元素增量支付标志的ISO 8583消息型指示符1240)，其指示要根据特定增量支付批准授权请求的条款来对支付交易清算和结算。在至少一些这样的情况下，限制步骤响应于清算消息(例如，响应于指出清算消息中的增量支付标志而将交易置于队列2076中)。

在备选方法中，另外的步骤包括响应于经由支付卡网络获得特定增量支付批准授权请求响应的步骤将支付卡交易的标识符存储在数据库(例如，标记数据库2075)中；以及经由支付卡网络获得清算消息，其指示要对支付卡交易清算和结算。在至少一些这样的情况下，限制步骤响应于在获得清算消息时在数据库中找到支付卡交易的标识符。例如，在该备选方案中，当PNIP 2024“看到”交易要作为增量支付交易来处理时，它将响应路由回ASP2050，在这里将交易标识符存储在标记数据库2075中；当清算消息进入时，在数据库中指出交易标识符并且将交易置于保持队列2076中。

在一些情况下，支付卡包括预付支付卡。

此外，考虑到目前为止的论述并且继续参考图3、4和6-10，将意识到一般来说，根据本公开的另一个方面的另一个示例性方法包括在增量支付记账程序中登记多个账户持有者的步骤(例如，发行商2010在数据库2041中登记账户持有者)。另外的步骤包括通过具有标准清算和结算时期(在非限制性示例中，2-3天)的支付网络(例如，支付卡网络(2008是其非限制性示例)、PAYPAL型网络等)从多个开账单人(例如，2004)中指定的一个获得对于支付交易的授权请求(ISO 8583 MTI 0100是非限制性示例)。例如，发行商决策平台2040经由PNIP 2024获得授权请求。再另外的步骤包括将对支付交易的授权请求的特定增量支付批准授权请求响应(ISO 8583 MTI 0110是非限制性示例)派送到支付网络内，从而指示将关于授权请求之后的支付交易在所选时期内以多个增量对多个开账单人中的至少一个付款，而不管资金对于与支付交易关联的账户是否可用。所选时期比标准清算和结算时期还长，因此对在标准清算和结算期后的支付安排至少一个增量支付并且在一些实施例中安排所有增量支付来满足支付交易。例如，发行商决策平台2040与PNIP 2024通信，从而指示增量支付批准。ISO 8583 MTI 0110中的增量支付指示可以是例如DE39中的增量支付标志。

在至少一些实例中，派送步骤响应于确定所需资金当前对于与支付交易关联的账户不可用。例如，平台2040将授权请求中所请求的金额与对应可用余额或账户的购买限额的余额比较。

在一些情况下，支付网络是支付卡网络(2008是非限制性示例)，支付交易是支付卡交易，并且账户是支付卡账户；并且登记、获得和派送的步骤在与支付卡网络(例如2008)接口连接的支付卡发行商(例如，2010)处实施。支付发行商发行所考虑的支付卡账户。

在一些实施例中，多个账户持有者的登记包括从多个持卡人中的每个获得工资细节；并且从多个账户持有者中的每个获得对多个开账单人中的至少一个使用增量支付记账程序的请求(参见，例如步骤406)。例如，持卡人可以经由登记用户接口与发行商决策平台2040的数据库2041接口连接，来存储工资细节以及受到特别对待的开账单人的身份。示例性用户界面在本文在别的地方论述。

在至少一些情况下，另外的步骤包括在登记期间获得对所选时期的商定和/或在每个增量支付中待支付的交易金额的部分，和/或每个增量支付之间的时间。可选地，所选时期开始的时间与持卡人中指定的一个的发薪日一致。在一些情况下，额外步骤包括在登记期间在电子记账程序中登记多个账户持有者中的至少一些。

在一些实例中，另外的步骤包括在派送特定增量支付批准授权请求响应之前证实信任条件仍适用于与支付卡交易关联的账户持有者中的指定的一个。例如，发行商2010在发送特定增量支付批准授权请求响应之前与工资程序核对，或更一般地，检查账户持有者中的持续信任。例如，可以对平台2040提供到工资程序、信用评级机构等的合适的网络连接。

此外，考虑到目前为止的论述并且继续参考图3、4和6-10，将意识到一般来说，根据本公开的再一个方面的又一个示例性方法包括在增量支付记账程序中登记多个开账单人(例如，2004)的步骤。例如，收单方2006向数据库2012添加登记的开账单人。另外的步骤包括经由支付卡网络(2008是非限制性示例)获得对支付卡交易的授权请求的特定增量支付批准授权请求响应(ISO 8583 MTI 0110是非限制性示例)，从而指示将关于在授权请求之后在所选时期内按时间增量进行的多个增量支付中的支付交易来对多个开账单人中的指定的一个支付，而可选地不管资金对于与支付交易关联的账户是否可用。所选的时期比对于支付卡网络的标准清算和结算时期还长。因此，将为标准清算和结算时期之后的支付安排增量支付中的一个或多个。例如，收单方平台2015经由PNIP 2012获得授权请求响应。另外的步骤包括将增量支付批准授权请求响应传递到多个开账单人中的指定的一个(例如，平台2015经由驱动器2014与合适的终端通信)。

可选地，另外的步骤包括经由支付卡网络获得对另一个支付交易的授权请求的另一个特定增量支付批准授权请求响应，从而指示将关于其他支付交易增量式地对不在多个登记的开账单人之中的开账单人支付。响应于其他特定增量支付批准授权请求响应与不在多个登记的开账单人之中的开账单人关联，另外的步骤包括向不在多个登记的开账单人之中的开账单人发送拒绝(例如，平台2015经由驱动器2014与合适的终端通信)并且向与其他支付卡交易关联的发行商发回撤销(例如，平台2015经由作为网络2008的边缘的PNIP 2012来与发行商通信)。

如指出的，在备选方法中，收单方在第一调度增量支付的时间之前限制不将对于支付卡交易的清算和结算消息派送到支付卡网络内。由于随后的增量支付到期而生成另外的清算和结算消息。例如，平台2014标记交易并且使它保持在耦合于平台2015的收单方保持队列(未示出)中。

在收单方限制不住派送清算和结算消息的那些实施方式中，所派送的清算消息可以例如是ISO 8583消息型指示符1240，其具有数据元素24功能代码值200和私人数据子元素增量支付标志。

对于登记步骤，在非限制性示例中，要登记的多个方可以经由登记用户界面与管理相关数据库的数据库管理系统接口连接。数据库程序和用户界面的非限制性示例在本文别的地方阐述。

在另一个方面，支付卡网络(2008是非限制性示例)具有标准清算和结算时期。支付卡网络包括收单方支付卡网络接口(PNIP 2012是非限制性示例)，其配置成从多个开账单人(例如，2004)中的指定一个获得对支付卡交易的授权请求(例如，ISO 8583 MTI0100)。支付卡网络还包括发行商支付卡网络接口(PNIP 2024是非限制性示例)，其配置成从对应发行商(例如，2010)获得对支付卡交易的授权请求的特定增量支付批准授权请求响应，从而指示将关于在授权请求之后在所选时期内按时间增量进行的多个增量支付中的支付卡交易来对多个开账单人中的指定的一个支付，而不管资金对于与支付卡交易关联的账户是否可用。所选时期比标准清算和结算时期还长。因此，将对晚于标准清算和结算时期的支付安排至少一个增量支付。特定增量支付批准授权请求响应可以是例如ISO 8583 MTI0110，其在DE 39中具有增量支付标志。支付卡网络在一些实施例中包括清算和结算系统(例如，2074)，其耦合于收单方支付卡网络接口和发行商支付卡网络接口。清算和结算系统包括保持队列(例如，2076)，其保持支付卡交易，使得支付卡交易直到所选时期到期时才得以完全结算。清算和结算系统配置成在所选时期内以增量实行保持队列中支付卡交易的清算和结算。在所选时期期间部分满足支付卡交易所进行的每个支付的确认由开账单人发送给持卡人(图3中的步骤308)。

系统和制造物品细节

本公开的实施例可以采用硬件和/或硬件和软件方面。软件包括但不限于固件、常驻软件、微代码等。软件可以例如连同以下中的一个或多个一起采用：终端驱动器2014；收单方处理平台2015；PNIP 2012；发行商决策平台2040；PNIP 2024；大型机2052；MPS 2018；GFT 2059；ASP 2050；通信层2056；服务2051；清算和结算系统2074；到其他支付卡网络的接口2068；终端122、124、125、126；阅读器模块132；根据支付系统标准(和/或规范)操作的支付网络2008的商户、发行商、收单方、处理器或运营商的主机、服务器和/或处理中心140、142、144(可选地具有数据仓库154)；及类似物。固件可以例如连同支付设备(例如卡102、112)以及阅读器模块132一起采用。

图5是可以实现本公开的一个或多个方面或过程中的部分或全部的系统500的框图。如在图5中示出的，存储器530将处理器520(其可以对应于例如处理器部分106、116、130；终端或阅读器模块132的处理器；中心140、142、144中的远程主机的处理器；实现各种功能性(例如图6-10中的)的主机和/或服务器的处理器；及类似物)来实现本文公开的方法、步骤和功能(在图5中统一示出为过程580)的一个或多个方面。不同的方法步骤可以由不同处理器执行。存储器530可以是分布式或本地的并且处理器520可以是分布式或单一的。存储器530可以实现为电、磁或光存储器，或这些或其他类型的存储设备(其包括如在上文关于卡102、112描述的存储器部分)的任何组合。应注意如果采用分布式处理器，组成处理器520的每个分布式处理器一般包含它自己的可寻址存储器空间。还应注意计算机系统500中的一些或全部可以并入专用或通用集成电路。例如，一个或多个方法步骤可以在专用集成电路(ASIC)中在硬件中实现而不是使用固件实现。显示器540代表各种可能的输入/输出设备(例如，显示器、打印机、键盘、鼠标、触控板等)。

例如，系统500一般代表例如实现各种功能(例如图6-10中的)的服务器和访问该服务器的客户端设备。

如本领域内已知的，本文论述的方法和装置的一个或多个方面中的部分或全部可以作为制造物品而分布，该制造物品自身包括有形的计算机可读可记录存储介质，其具有在其上包含的计算机可读代码部件。该计算机可读程序代码部件结合计算机系统可操作以实施步骤中的全部或一些来执行方法或创建本文论述的装置。计算机可用介质一般可以是可记录介质(例如，软盘、硬驱动、压缩盘、EEPROM或存储卡)，或可以是传输介质(例如，网络，其包括光纤、万维网、电缆或使用时分多址、码分多址的无线信道或其他射频信道)。可以使用已知或开发的可以存储适合与计算机系统一起使用的信息的任何介质。计算机可读代码部件是允许计算机读取指令和数据(例如磁介质上的磁变或压缩盘表面上的高度变化)的任何机构。介质可以分布在多个物理设备上(或在多个网络上)。例如，一个设备可以是与终端关联的物理存储器介质并且另一个设备可以是与处理中心关联的物理存储器介质。如本文使用的，有形的计算机可读可记录存储介质定义成包含可记录介质(非暂时性存储)，其的示例在上文阐述，但不包含传输介质或无实体信号。

本文描述的计算机系统和服务器各自包含存储器，其将使关联处理器配置成实现本文公开的方法、步骤和功能。这样的方法、步骤和功能可以通过示例并且无限制地通过元件122、124、125、126、140、142、144、2004、2006、2008、2010；2014；2015；2012；2040；2024；2052；2018；2059；2050；2056；2051；2074；2068中的一个、一些或全部上；实现平台或其他功能性的计算机上；服务器或与服务器接口连接的一个或多个客户端上及类似物上的处理能力来实施。存储器可以是分布式或本地的并且处理器可以是分布式或单一的。存储器可以实现为电、磁或光存储器，或这些或其他类型的存储设备的任何组合。此外，术语“存储器”应足够广泛地解释为包含能够从关联处理器所访问的可寻址空间中的地址读取或写入该地址的任何信息。利用该定义，因为关联处理器可以从网络检索信息，网络上的信息仍在存储器内。

从而，本公开的一个或多个实施例的元件(例如122、124、125、126、140、142、144、2004、2006、2008、2010；2014；2015；2012；2040；2024；2052；2018；2059；2050；2056；2051；2074；2068；实现平台或其他功能性的计算机；服务器或与服务器接口连接的一个或多个客户端上；及类似物)可以使用具有合适指令来实现本文描述的方法步骤的计算机技术。一些方面可以例如使用包括存储器和耦合于该存储器的至少一个处理器的一个或多个服务器来实现。存储器可以加载合适软件。处理器可以操作以执行本文描述的一个或多个方法步骤或另外促进它们的执行。

因此，将意识到本公开的一个或多个实施例可以包括计算机程序产品，其包括计算机程序代码部件，该计算机程序代码部件适于当这样的程序在计算机上运行时执行本文阐述的任何方法或权利要求的步骤中的一个或全部，并且将意识到这样的程序可以包含在计算机可读介质上。此外，本公开的一个或多个实施例可以包括计算机连同如本文描绘和描述的一个或多个装置元件或特征，该计算机包括适于促使计算机实施本文阐述的方法或权利要求的一个或多个步骤的代码。

如本文使用的(包括权利要求)，“服务器”包括运行服务器程序的物理数据处理系统(例如，如图5中示出的系统500)。将理解这样的物理服务器可以包括或不包括显示器、键盘或其他输入/输出组件。“主机”包括运行合适程序的物理数据处理系统(例如，如图5中示出的系统500)。

此外，应注意本文描述的方法中的任一个可以包括提供包含在一个或多个有形计算机可读存储介质上的截然不同的软件模块的系统的额外步骤。例如，所有模块(或其任何子集)可以在相同介质上，或每个可以在不同介质上。模块可以包括图中示出的组件中的任一个或全部。在一个或多个实施例中，模块包括：实现终端驱动器2014的至少一部分的终端驱动器模块；实现收单方处理平台2015的收单方处理平台模块；实现关于PNIP 2012、2024和ASP 2050描述的功能性的模块和/或子模块；实现发行商决策平台2040的发行商决策平台；实现关于大型机2052、MPS 2018、GFT 2059、通信层2056、服务2051、清算和结算系统2074和到其他支付卡网络的接口2068描述的功能性的模块和/或子模块；及类似物。数据库可以存储在非易失性(持久)存储器(例如硬驱动或多个驱动)中并且被适合的数据库管理系统访问。输入和输出可以经由适合的用户界面(UI)提供。方法步骤然后可以使用如上文描述的在一个或多个硬件处理器上执行的系统的截然不同的软件模块来实施。此外，计算机程序产品可以包括有形的计算机可读可记录存储介质，其具有适于被执行来实施本文描述的一个或多个方法步骤的代码，包括对系统预备截然不同的软件模块。

实现登记(或其他)UI的用户界面模块的一个示例是服务器向用户的计算设备的浏览器分发出的超文本标记语言(HTML)代码。HTML由用户的计算设备上的浏览器解析来创建图形用户界面(GUI)。在一些情况下，可以对另一个实体而不是最终用户操作服务并且UI牵涉API或类似物，其对另一实体提供对数据库的访问；最终用户在这样的情况下可以例如与另一实体提供的GUI交互。

本文论述的计算机可以例如由网络138、2008、另一个虚拟专用网(VPN)、互联网、局域网和/或广域网(LAN和/或WAN)中的一个或多个经由EDI层等而互连。注意元件2008代表网络和它的运营商。可以例如采用编译、解释、面向对象、汇编和/或机器语言(例如，C、C++、Java、Visual Basic、COBOL、汇编程序、结构化查询语言(SQL)及类似物(示范性和非限制性列表))来对计算机编程，并且这些计算机还可以使用例如可扩展标记语言(XML)、已知应用程序(例如Neo4j、开源图形数据库或相似的图形数据库)、关系数据库应用(例如，从美国纽约州Armonk市的国际商用机器公司可获得的IBM 软件；从美国北卡罗来纳州Cary市的SAS Institute,Inc.可获得的软件)、电子表格(例如，从美国华盛顿州Redmond市的Microsoft公司可获得的MICROSOFT 软件)及类似物。SQL或结构化查询语言是为管理关系数据库管理系统(RDMS)中保持的数据而设计的通用编程语言。SQL和RDMS分别是适合的查询技术和数据库管理系统的非限制性示例。可以对计算机编程来实现图中描绘的逻辑和/或数据流。在一些实例中，消息传递及类似物可以根据ISO规范8583金融交易卡始发消息-交换消息规范和/或ISO 20022或金融服务消息传递UNIFI标准，其出于所有目的通过引用也全部合并于此。

尽管已参考附图描述说明性实施例，要理解那些精确实施例是非限制性的，并且本领域内技术人员可以做出各种其他改变和修改而不偏离本公开的范围或精神。

Claims

1.一种方法，所述方法包括以下步骤：

通过具有标准清算和结算时期的支付网络从多个开账单人中的指定的一个获得支付交易的授权请求；

经由所述支付网络传递对所述支付交易的所述授权请求的特定增量支付批准授权请求响应，从而指示将关于在所述授权请求之后的所选时期内按时间增量进行的多个增量支付中的所述支付交易来对所述多个开账单人中的所述指定的一个付款，而不管资金对于与所述支付交易关联的账户是否可用，选择性时期内的增量支付中的至少一个是在所述标准清算和结算时期之后；以及

在所述标准清算和结算时期之后的一段时间之前限制清算和结算所述支付交易的至少一部分。

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

所述支付网络包括支付卡网络并且所述支付交易包括支付卡交易；

限制清算和结算的步骤在所述支付卡网络中的中间节点处实施；以及

传递所述特定增量支付批准授权请求响应的步骤包括从与所述支付卡交易关联的支付卡的发行商获得所述响应。

3.如权利要求2所述的方法，其进一步包括经由所述支付卡网络获得清算消息，所述清算消息指示所述支付交易要根据所述特定增量支付批准授权请求的条款来清算和结算，其中，所述限制响应于所述清算消息。

4.如权利要求3所述的方法，其中，所述支付卡网络包括ISO 8583支付卡网络，并且其中，在获得所述清算消息的步骤中，所述清算消息包括ISO 8583消息型指示符1240，所述ISO 8583消息型指示符1240具有数据元素24功能代码值200和专用数据子元素增量支付标志。

5.如权利要求2所述的方法，其中，所述限制包括将所述支付交易置于清算和结算系统的保持队列中。

6.如权利要求2所述的方法，其进一步包括：

响应于经由所述支付卡网络获得所述特定增量支付批准授权请求响应，将所述支付卡交易的标识符存储在数据库中；以及

经由所述支付卡网络获得清算消息，所述清算消息指示要对所述支付卡交易清算和结算；

其中，所述限制响应于在获得所述清算消息时在所述数据库中找到所述支付卡交易的所述标识符。

7.如权利要求2所述的方法，其中，在从所述支付卡的所述发行商获得所述特定增量支付批准授权请求的步骤中，所述支付卡包括预付支付卡。

8.一种方法，所述方法包括以下步骤：

在增量支付记账程序中登记多个账户持有者；

将对所述支付交易的所述授权请求的特定增量支付批准授权请求响应派送到所述支付网络内，从而指示将根据所述增量支付记账程序关于在所述授权请求之后在所选时期内按时间增量进行的多个增量支付中的所述支付交易来对所述多个开账单人中的所述指定的一个付款，而不管资金对于与所述支付交易关联的账户是否可用，所述所选时期比所述标准清算和结算时期长。

9.如权利要求8所述的方法，其中，所述派送步骤响应于确定所述资金当前对于与所述支付交易关联的所述账户不可用。

10.如权利要求9所述的方法，其中：

所述支付网络包括支付卡网络，所述支付交易包括支付卡交易，并且所述账户包括支付卡账户；以及

登记、获得和派送的步骤在与所述支付卡网络接口连接的支付卡发行商处实施，所述支付卡发行商发行了所述支付卡账户。

11.如权利要求10所述的方法，其进一步包括通过支付卡网络并且在所选时期内促成对所述多个开账单人中的所述指定的一个的多个增量支付，以满足支付交易。

12.如权利要求11所述的方法，其进一步包括在所述登记期间获得对所述所选时期的同意。

13.如权利要求12所述的方法，其中所述所选时期计时为在标准清算和结算时期之后开始。

14.如权利要求11所述的方法，其进一步包括在所述登记期间在电子记账程序中登记所述多个账户持有者中的至少一些。

15.如权利要求11所述的方法，其进一步包括在派送所述特定增量支付批准授权请求响应之前验证信任条件仍适用于与所述支付卡交易关联的所述账户持有者中的指定的一个。

16.如权利要求10所述的方法，其中所述支付卡网络包括ISO 8583支付卡网络，并且其中，在所述派送步骤中，所述特定增量支付批准授权请求响应包括ISO 8583消息型指示符0110，所述ISO 8583消息型指示符0110在数据元素39中具有增量支付标志。

17.一种方法，所述方法包括以下步骤：

在增量支付记账程序中登记多个开账单人；

经由支付卡网络获得对支付卡交易的授权请求的特定增量支付批准授权请求响应，从而指示将关于在所选时期内按时间增量进行的多个增量支付中的所述支付交易来对所述多个开账单人中的指定的一个付款，所述所选时期比所述支付卡网络的标准清算和结算时间长；以及

将所述增量支付批准授权请求响应传递到所述多个开账单人中的所述指定的一个。

18.如权利要求17所述的方法，其进一步包括在所选时期开始之前限制将对于所述支付卡交易的清算和结算消息派送到所述支付卡网络内。

19.如权利要求17所述的方法，其中，所述支付卡网络包括ISO 8583支付卡网络，所述方法进一步包括将清算消息派送到所述支付卡网络内，所述清算消息包括具有数据元素24功能代码值200和专用数据子元素(PDS)增量支付标志的ISO 8583消息型指示符1240。

20.一种支付卡网络，所述支付卡网络具有标准清算和结算时期，所述支付卡网络包括：

收单方支付卡网络接口，所述收单方支付卡网络接口配置成从多个开账单人中的指定的一个获得支付卡交易的授权请求；

发行商支付卡网络接口，所述发行商支付卡网络接口配置成从对应发行商获得对所述支付卡交易的所述授权请求的特定增量支付批准授权请求响应，从而指示将关于在所述授权请求后在所选时期内按时间增量进行的多个增量支付中的所述支付卡交易来对所述多个开账单人中的所述指定的一个付款，而不管资金对于与所述支付卡交易关联的账户是否可用，所述所选时期比所述标准清算和结算时期长；以及

清算和结算系统，所述清算和结算系统耦接于所述收单方支付卡网络接口和所述发行商支付卡网络接口，所述清算和结算系统包括保持队列，所述保持队列保持所述支付卡交易，使得所述支付卡交易直到所述所选时期到期才完全结算。

21.如权利要求20所述的支付卡网络，其中，所述清算和结算系统进一步配置成在所选时期内在保持队列中以增量实施支付卡交易的清算和结算。