用于验证针对支付账户的再发性交易的系统和方法与流程

本申请要求2015年11月23日提交的美国专利申请序列号No.14/948,523的优先权和申请日的权益，通过引用的方式将其全部内容合并于此。

技术领域

本公开总体上涉及用于验证针对支付账户的再发性交易的系统和方法，并且具体地涉及用于将验证请求发送给与再发性交易所针对的支付账户相关联的消费者,其中，除非接收/认可消费者的响应，否则至少禁止对再发性交易的清算。

背景技术：

本节提供与本公开相关的背景信息，其不一定是现有技术。

消费者使用支付账户购买各种不同的产品(例如，商品和服务等)。购买可以是单次购买产品，也可以是多次重复购买相同或不同的产品。消费者知道向商家提供支付账户细节，并进一步授权商家以一个或多个定期时间间隔向支付账户收取产品的费用。例如，有线服务、贷款支付、公共服务等的自动支付是已知的，由此消费者向与消费者相关联的银行账户和/或支付账户提供按月收费的授权。

附图说明

在此描述的附图仅用于选定实施例的举例说明的目的，而不是全部可能的实现方式，并且不旨在限制本公开的范围。

图1是适用于验证从商家到与消费者相关联的支付账户的再发性交易的本公开的示例性系统的框图；

图2是可以在图1的示例性系统中使用的计算设备的框图；

图3是由商家验证针对与消费者相关联的支付账户的再发性交易的示例性方法，该方法可以在图1的系统中实现；

图4是可显示给与图1的系统和/或图3的方法有关的消费者的示例性界面，其中，用于验证针对与消费者相关联的支付账户的再发性交易；以及

图5是可显示给与图1的系统和/或图3的方法有关的消费者的另一个示例性界面，其中，用于验证针对与消费者相关联的支付账户的再发性交易。

在附图的各个视图中，相应的附图标记指示相应的部分。

具体实施方式

现在将参考附图更全面地描述示例性实施例。本文包括的描述和具体示例仅用于举例说明的目的，并不意图限制本公开的范围。

对于各种定期交付的产品(例如，商品和/或服务等)或其他产品，商家试图安排消费者对产品进行自动支付，由此商家安排针对与消费者相关联的支付账户进行定期、自动的交易以换取产品。通过这种方式，商家将交易提交给消费者的支付账户，并且通常能够从该支付账户接收按时支付，通常无需消费者同时参与交易(例如，无需消费者发起和/或进一步的批准交易等)。商家的这种“自动支付”选项可以针对各种不同的支付账户，并且已知的可针对各种产品(例如，公共服务、贷款、保险、会费、家庭服务等)。独特的是，本文的系统和方法使消费者能够在再发性交易被授权和/或清算之前验证再发性交易。具体地说，一旦发送来自商家的对再发性支付的授权请求，与再发性支付所针对的支付账户相关联的支付网络和/或发行方就可以保持授权请求，同时将验证消息发送给消费者。支付网络和/或发行方可以继续保持授权请求，或者可以在某些情况下继续对交易进行授权，但拒绝清算交易，除非从消费者接收到对验证消息的响应(和/或满足根据一个或多个偏好的特定标准)。通过这种方式，尽管商家能够设置针对支付账户的再发性交易，但与这些支付账户相关联的消费者具有批准/拒绝每个这样的再发性交易的能力。

图1示出了可以实现本公开的一个或多个方面的示例性系统100。尽管系统100以一种安排方式呈现，但是其他实施例可以包括以例如取决于处理针对支付账户的再发性交易的方式等的另外的方式安排的系统。

系统100通常包括商家102、收单方104、支付网络106和发行方108，它们中的每一个都耦合到网络112(并且与网络112通信)。网络112可以包括但不限于局域网(LAN)、广域网(WAN)(例如，互联网等)、移动网络、虚拟网络和/或能够支持图1示出的两个或更多个部分之间的通信的另一合适的公共和/或专用网络、或其任何组合。例如，网络112可以包括多个不同的网络，例如，通过支付网络106使得访问收单方104和发行方108可以访问的私人支付交易网络，以及单独的公众互联网，访问商家102、收单方104、支付网络106、发行方108和消费者114在需要时可以访问该公众互联网。

商家102通常与一个或多个消费者购买的产品(例如，商品和/或服务等)相关联。另外，商家102向其消费者提供再发性交易，其作为用于支付产品的选项，由此消费者(例如，消费者114等)提供某些支付账户信息，并且商家102(无需消费者的进一步授权)以一个或多个定期的时间间隔或不定期时间间隔(包括长期订单)(即作为再发性交易)对消费者收到的产品从消费者的支付账户收费。例如，这些产品可以包括公共服务(例如，水、气、电等)、电信或有线服务、贷款服务、期刊、订阅、保险服务、家庭服务(不论是住宅还是商业)、和/或任何其他产品。此外，虽然图1中仅示出一个商家102，但是应该理解，其他实施例可以包括多个商家、和/或可以包括提供各种不同产品的一个或多个不同类型的商家，例如，可以定期或者不定期的购买这些商品。但是，如本文所使用的商家通常允许再发性交易，作为支付产品的费用的选项。

继续参考图1，消费者114与支付账户(或与多个支付账户)相关联，消费者114通过该支付账户为产品的交易提供资金。

关于消费者114和商家102之间的交易，在接收到来自消费者114的对选择的产品(一个或多个产品)的支付信息时(例如，以自动支付注册或其他方式等)，商家102确定针对消费者114以及消费者114接收的产品(一个或多个产品)的支付交易时间表。该时间表通常定义针对与消费者114相关联的支付账户的再发性交易，可以定期或者不定期(例如，每月、每两个月、在产品交付时等)的进行该再发性交易。当应对交易付款时，商家102向收单方104提交对时间表中的每个再发性交易的授权请求(例如，图1中的授权请求118等)。授权请求的路径由图1中的标记为120的虚线表示，在下面将对其进行详细描述。另外，如图1所示，授权请求包括再发性交易指示符，例如，其可以具体包括ISO 8583消息内的指示符(例如，在根据ISO 8583格式的0100消息的D61SF4处的‘4’(表示“长期订单/再发性付款”)等)，或者其可以包括在其他消息和/或消息的格式中等。授权请求还包括支付账号、交易金额、商家ID、和/或如常规授权请求中所指示的和/或为处理再发性付款所必需的等的另外的信息。

如路径120所进一步指示的，收单方10 4通常相应地通过支付网络106(举例来说，例如通过万事达卡、维萨、发现卡、美国运通卡等)，将授权请求发送给发行方108，以(与向消费者114提供支付账户的发行方108一起)确定支付账户是否信誉良好以及是否有足够的信用或资金来完成交易。如果发行方108接受交易，则通常将授权该交易的回复返回给收单方104和商家102，从而允许商家102完成交易。随后由商家102和收单方104并且在商家102和收单方104之间(通过商家102和收单方104之间的协议)，以及由收单方104和发行方108并且在收单方104和发行方108之间(通过收单方104和发行方108之间的协议)(通过收单方104和发行方108的进一步通信)，对交易进行清算和/或结算。如果发行方108拒绝交易，则将拒绝交易的回复返回给商家102，从而允许商家102停止交易。

参考信用账户对上述交易进行了描述。然而，应该理解的是，购买交易可以进一步包括其他交易，例如，借记交易和预付交易。对于借记和预付费账户来说，交易及对交易的处理与上述交易基本上类似，但是可以进一步包括使用个人身份号码(PIN)授权和/或将费用更快速地记入支付账户等。

作为商家102、收单方104、支付网络106、发行方108和消费者114之间的上述交互的一部分，生成、收集和存储交易数据。交易数据至少代表多个交易，例如，授权的交易、清算的交易、尝试的交易等。在该示例性实施例中，交易数据至少由支付网络106存储(例如，存储在与支付网络106相关联的数据结构中等)。另外地或替代地，商家102、收单方104和/或发行方108可以将交易数据或其部分存储在数据结构中，或者可以根据使用或者需要(例如，为了清算等)，在系统100的两个部分之间传输交易数据。例如，交易数据可以包括支付账号、交易金额、商家ID、商家类别代码(MCC)，交易日期/时间、购买的产品以及相关描述或标识符等。应当理解的是，涉及交易的或多或少的信息，可以作为授权、清算和/或结算的一部分包括在在交易数据中并存储在系统100内的商家102、收单方104，支付网络106和/或发行方108。

在各种示例性实施例中，例如，在本文的不同交易中涉及的消费者(例如，消费者114等)注册他们的账户期间，被提示同意与他们的支付账户相关联的法律条款。这样一来，消费者就可以自愿地同意例如允许商家、发行方、支付网络等使用在注册期间收集的数据和/或收集的与处理交易相关的数据，并随后将其用于实现本文所述的一个或多个不同目的。

尽管图1中示出了一个商家102、一个收单方104、一个支付网络106、一个发行方108和一个消费者114，但是应当理解，在与本公开一致的其他实施例中，任何数量的这些实体(及其相关构成部分)可以包括在系统100中，或者可以作为系统的一部分而包括在其中。

图2示出了可以在系统100中使用的示例性计算设备200。例如，计算设备200可以包括服务器、工作站、个人计算机、膝上型计算机、平板电脑、智能电话、PDA等中的一个或多个。另外，计算设备200可以包括单个计算设备，或者其可以包括位置紧邻或分布在地理区域上的多个计算设备，只要计算设备被具体配置为如本文所述的那样起作用即可。然而，如下所述，不应该认为系统100限于计算设备200，这是因为可以使用不同的计算设备和/或计算设备的布置。另外，可以在其他计算设备中使用不同的组件和/或组件的布置。

在图1的示例性实施例中，商家102、收单方104、支付网络106和发行方108中的每一个被示出为包括或者实现在耦合到网络112的计算设备200中。此外，例如，与这些实体相关联的计算设备200可以包括单个计算设备、或者位置紧邻或分布在地理区域上的多个计算设备，同样只要这些计算设备被具体配置为如本文描述的那样起作用即可。另外，出于描述本文的目的，也可以认为与消费者114相关联的便携式通信设备116是与计算设备200一致的计算设备。

参考图2，示例性的计算设备200包括处理器202和耦合到处理器202(并与处理器202通信)的存储器204。处理器202可以包括一个或多个处理单元(例如，在多核配置中等)。例如，处理器202可以包括但不限于中央处理单元(CPU)、微控制器、精简指令集计算机(RISC)处理器、专用集成电路(ASIC)、可编程逻辑电路(PLC)、门阵列、和/或能够具有在此描述的功能的任何其他电路或处理器。

如本文所描述的，存储器204是允许数据、指令等存储在其中并从中检索出数据、指令的一个或多个设备。存储器204可以包括一个或多个计算机可读存储介质，例如但不限于动态随机存取存储器(DRAM)、静态随机存取存储器(SRAM)、只读存储器(ROM)、可擦除可编程只读存储器(EPROM)、固态设备、闪存驱动器、CD-ROM、拇指驱动器、软盘、磁带、硬盘和/或任何其他类型的易失性或非易失性物理或有形计算机可读介质。存储器204可以被配置为存储不限于交易数据(例如，授权数据、清算数据等)、偏好、设置(例如，默认设置等)、支付账户信息、再发性支付条件和/或时间表、和/或适合于如本文所述的使用的其他类型的数据(和/或数据结构)。

此外，在各种实施例中，可以将计算机可执行指令存储在存储器204中以供处理器202执行以使处理器202执行在此描述的一个或多个功能，使得存储器204是物理的、有形的且非暂时性的计算机可读存储介质。这样的指令经常提高正在执行本文中的各种操作中的一个或多个的处理器202的效率和/或性能。应该理解，存储器204可以包括各种不同的存储器，每个存储器都在本文描述的一个或多个功能或过程中实现。

在示例性的实施例中，计算设备200包括耦合到处理器202(并与处理器202通信)的呈现单元206(然而，应该理解，计算设备200可以包括除了呈现单元206之外的输出设备等。)。呈现单元206可视地或可听地向计算设备200的用户(例如，系统100中的用户114等)输出信息(例如，验证选项等)。可以在计算设备200显示各种界面(例如，如由基于网络的应用程序、网页、短消息(SMS)消息、电子邮件等)，并且特别是在呈现单元206显示这样的信息。呈现单元206可以包括但不限于液晶显示器(LCD)、发光二极管(LED)显示器、有机LED(OLED)显示器、“电子墨水”显示器、扬声器等。在一些实施例中，呈现单元206包括多个设备。

计算设备200还包括输入设备208，其接收来自用户的输入(即，用户输入)，举例来说，例如对验证选项的选择等。输入设备208耦合到处理器202(并与处理器202通信)并且可以包括例如键盘、指点设备、鼠标、触控笔、触敏面板(例如，触摸板或触摸屏等)，其他的计算设备和/或音频输入设备。此外，在各种示例性实施例中，诸如包括在平板电脑、智能手机或类似设备中的触摸屏用作呈现单元和输入设备两者。

另外，所示出的计算设备200还包括耦合到处理器202和存储器204(并与之通信)的网络接口210。网络接口210可以包括但不限于有线网络适配器、无线网络适配器、移动网络适配器或能够与包括网络112在内的一个或多个不同网络进行通信的其他设备。此外，在一些示例性的实施例中，计算设备200包括处理器202和并入处理器202或与其结合的一个或多个网络接口。

再次参照图1，系统100包括验证引擎122，验证引擎122被具体配置为通过可执行指令执行本文的一个或多个操作。如图1所示，验证引擎122被示出为与支付网络106和发行方108分开，但是如虚线所示，验证引擎122可以与支付网络106和发行方108的任一个合并。然而，在其他实施例中，应该理解，验证引擎122可以与系统100的其他部分(例如，收单方104等)合并。通常，可以基于例如验证消息由路径120中的何处发送给消费者114、和/或再发性交易的授权和/或清算如何受到本文描述的操作影响等，来实现和/或定位验证引擎122。

此外，应该理解的是，验证引擎122可以在与计算设备200一致的计算设备中的系统100中实现，或者在本公开的范围内的其他计算设备中实现。

在各种实施例中，消费者114向验证引擎122注册(例如，当签约系统100的一个或多个部分提供的自动支付服务时、当首次从商家102购买产品时、在其他时间等)。验证引擎122进一步与至少一个数据结构(例如，数据结构124等)相关联，所述数据结构中存储了消费者114和多个额外消费者的注册和/或账户信息。在特定实施例中，在注册时，消费者114可以在与消费者114相关联的便携式通信设备116中安装应用程序程序(即，如由可执行指令定义的)，消费者114的联系凭证(例如，唯一应用程序标识符等)存储在数据结构124中。或者，本文描述的用于便携式通信设备116的操作不是独立的应用程序，而是可以并入到一个或多个其他应用程序(例如，电子钱包应用程序等)中，其中验证引擎122识别消费者114的联系凭证并将其存储到数据结构124中。在又一个实施例中，验证引擎122可以以其他方式联系消费者114，举例来说，例如短消息、电子邮件等，由此存储在数据结构124中的联系凭证包括电话号码、电子邮件地址等。通过这种方式，验证引擎122被构建为检索指向消费者的便携式通信设备116的特定联系凭证，然后将一个或多个消息(例如，验证请求等)发送到便携式通信设备116。接着，便携式通信设备116被配置为接收来自验证引擎122的消息并相应地作出响应(例如，显示验证请求、向消费者114显示验证界面等)。

应该理解，可以将各种合适的联系凭证(例如，账户标识符、电话号码、电子邮件地址等)存储在数据结构124中并且与消费者114、消费者的便携式通信设备116、和/或消费者的支付账户相关联，由此验证引擎122能够将消息发送给消费者114。此外，应当理解的是，在其他实施例中，任何不同的通信设备(即，便携式设备或其他设备)可以与消费者114相关联，以提供与消费者114通信的相同或不同的媒介(其对于验证引擎122是已知的)。

除了为便携式通信设备116提供联系凭证之外，作为向验证引擎122的注册的一部分，消费者114还可以向验证引擎122提供存储在数据结构124中的一个或多个用户偏好。例如，偏好可以包括默认设置，该默认设置可以在接收到如下所述的授权请求、清算指示、和/或验证请求中的一个或多个之后的一个或多个时间间隔后(例如，在约一小时后、约两小时后、约六小时后、其他时间间隔等)，没有收到来自消费者114的验证响应的情况下，指示验证引擎122如何继续进行下去。此外，消费者对联系凭证的偏好可以进一步包括在数据结构124中，以通知验证引擎122消费者接收验证消息的优选媒介等。

此外，数据结构124可以包括与支付网络106和/或发行方108相关联的偏好，例如，包括关于保持(或不保持)授权和/或清算交易的条件。例如，发行方108可以包括交易金额和/或商家限定符，其作为交易要被如本文所述的验证的条件。此外，在各种实施例中，数据结构124包括要被验证的交易的支付账号(PAN)的列表。例如，某些消费者可能会选择参与再发性支付的验证，而其他消费者则可能不会。因此，与验证服务相关联的PAN的列表允许验证引擎122对选择进行验证的支付账户和不选择进行验证的支付账户进行区分。

通常，在系统100中，验证引擎122被配置为检测和/或接收某些授权请求，这些授权请求涉及由商家102(和/或系统100支持的其他商家)提交的再发性交易(针对选择对再发性交易进行验证的支付账户)。一旦检测到授权请求，验证引擎122就被配置为检索与支付账户相关联的联系凭证(从数据结构124中检索)并且将验证消息发送给在便携式通信设备116处的消费者114。这样一来，验证引擎122被配置为使得在消费者的便携式通信设备116上显示验证请求(例如，一个或多个验证界面、短消息、电子邮件等)，由此消费者114可以批准或拒绝与该授权请求相关联的再发性交易。同时，验证引擎122可以被配置为用于保持和/或禁止再发性交易的某些方面，例如，授权、清算等。在一个示例中，验证引擎122被配置为保持授权请求(或相应的授权应答)，直到识别出验证响应(例如，从消费者114接收到等)。在其他示例中，验证引擎122被配置为准许对再发性交易的授权，但是禁止对交易进行清算，直到识别出验证响应。在这些示例中，在识别出来自消费者114的验证响应后，验证引擎122被配置为允许继续进行再发性付款。否则，验证引擎122被配置为拒绝再发性交易，或者受到由消费者的一个或多个偏好(或其他偏好)所规定的其他方式的影响。

图3示出了用于在允许对交易进行清算(或者在一些方面，甚至对交易授权)之前，验证针对支付账户的再发性交易的示例性方法300。示例性方法300被描述为在验证引擎122和与消费者114相关联的便携式通信设备116中实现。然而，应当理解，方法300不限于验证引擎122或便携式通信设备116的这种配置，这是因为方法300可以在系统100中的其他计算设备200中或者在多个其他计算设备中实现。如此，不应该将本文的方法理解为限于示例性系统100或示例性计算设备200，并且同样地，不应将本文的系统和计算设备理解为限于示例性方法300。

商家102向系统100中的消费者(包括消费者102)提供各种产品。许多商家的产品由消费者随着时间的推移重复地购买(例如，按照定期的时间表等)，或者一次购买并分期付款。为了使这样的重复交易更方便，商家102通常接收消费者首次购买时(或者在向商家102或另一实体进行自动支付注册时等)的支付账户信息，并且在获得消费者的许可后，对于随后的针对重复产品或者重复支付的交易使用相同的支付账户信息。一般来说，一旦从消费者接收到支付账户信息，商家102就确定针对重复产品和/或重复支付的支付交易时间表，该时间表通常定义将处理(或者发起)针对消费者的支付账户的交易的时间(例如，日期等)。

结合针对消费者114的这种支付交易时间表，当其中的一个定期交易达到定义的时间时，商家102向收单方104提交进行定期交易的授权请求。接着，如上所述，在系统100中，收单方104然后通过支付网络106将授权请求发送给发行方108以进行处理(例如，授权、清算、结算等)。由于授权请求涉及定期(或再发性)交易，所以商家102还将再发性交易指示符和消费者的支付账号、定期交易的金额、商家ID以及处理该特定的定期再发性交易所需的任何附加信息包括在授权请求中(例如，在根据ISO8583格式的0100消息的D61处等)。

接着在方法300中，在302，验证引擎122基于授权请求中包括的再发性交易指示符，检测商家102生成的授权请求。如上所述，在系统100中，验证引擎122是独立的实体。这样，验证引擎122可以大体上在沿着商家102和发行方108之间的路径120的任何位置处检测授权请求。例如，验证引擎122可以在支付网络106或发行方108处检测授权请求是针对再发性交易的。在一些实施例中，验证引擎122可以查看从收单方104接收到的所有或基本上所有的授权请求，该授权请求通常或与特定支付账户(或特定商家(例如，商家102)等))相关联，并且在检测到再发性支付指示符时，将交易识别为再发性交易。特别地，再发性交易指示符可以作为特定数字和/或字母数字(即，数字和/或字母数字的组合)而被包括，例如，该再发性交易指示符包括根据ISO 8583格式的0100消息的D61SF4处的“4”(表示“长期订单/再发性付款”)，验证引擎122能够从其中检测到授权请求是针对再发性交易的。

或者，在其他实施例中，验证引擎122可以接收仅针对再发性交易的授权请求，然后按照本文描述的进行操作。在这样的其他实施例中，支付网络106和/或发行方108可以分别检测授权请求是否与再发性交易相关，并且随后只转发针对再发性交易的授权请求，其中，将针对再发性交易的授权请求传递和/或发送给验证引擎122(在此，广义上来说，验证引擎122随后检测到授权请求)。

接下来，在检测到来自商家102的授权请求包括再发性交易指示符时，在304，验证引擎122拦截授权请求，并例如将其保持在例如数据结构124中。在一个特定示例中，验证引擎122可以采用数据结构124作为验证引擎122保持的授权请求(针对多个再发性交易的授权请求)的队列(并如下所述的等待处理)。这样一来，验证引擎122有效地禁止支付网络106(例如，禁止支付网络106将授权请求发送给发行方108)和/或发行方108(例如，禁止发行方108授权或拒绝该授权请求等)对授权请求作进一步处理，这取决于验证引擎122在哪里拦截授权请求。关于这一操作，发行方108可能不会将对授权请求的授权应答返回给商家102，直到验证引擎122释放授权请求(例如，在识别出验证响应时)。在一些实施例中，在304，验证引擎122可以截取并保持授权应答。

在保持授权请求的同时，在306，验证引擎122将验证消息发送给消费者114。具体而言，在该实施例中，验证引擎122经由网络112将验证消息发送给消费者的便携式通信设备116。验证消息可以包括任何合适的消息，并且可以经由任何合适的介质(例如，电子邮件、SMS文本消息等)将其发送给消费者114。另外，验证消息可以包括一些内容，根据这些内容可以在便携式通信设备116上编译界面(如上所述，通过伴随的基于web的应用程序)，并且/或者验证消息可以包括到界面的链接，当选择该链接时，随后便可以在消费者的便携式通信设备116上显示界面。通常，通过发送验证消息，验证引擎122使得将界面显示给消费者114，其中，即可以以专用于被配置为与验证引擎122一起使用的应用程序的形式在便携式通信设备116上显示，也可以以常规媒介(例如，电子邮件、SMS消息等)在便携式通信设备116上显示，其允许消费者114批准(或验证)或拒绝特定的再发性交易。

图4示出了可以基于从验证引擎122接收的验证消息在消费者的便携式通信设备116上(如其中的指令所定义的)显示的示例性验证界面400。如图4所示，所示的验证界面400包括指示由消费者114检查的定期的再发性交易的部分402，其包括商家102的名称(即，“ABC有线电视公司”)和定期交易金额(即，187.36美元)。界面400还包括按钮404和406。为消费者114提供按钮404和406以响应验证引擎122，在该实施例中，按钮404和406包括批准定期的再发性交易(通过按钮404)或拒绝定期的再发性交易(通过按钮406)。也就是说，便携式通信设备116被配置为基于消费者114选择哪个按钮404或406(即，基于消费者在界面400的输入等)，向验证引擎122发送验证响应。在其他示例性界面中，可以允许消费者114采取其他动作，例如，包括批准具体的交易金额、联系商家102的顾客服务等。

所示的验证界面400还包括部分408，其中提供了针对消费者的支付账户处理的最后(或之前)的定期交易的细节(例如，根据商家102创建的消费者114的支付交易时间表等)。在这个例子中，计划的再发性交易包括增加48.77美元(即，187.36美元--138.59美元)，消费者114会认为这是和批准或拒绝当前的再发性交易这一决定相关的。通过这种方式，能够通知消费者114商家102试图确定的当前再发性交易的金额差异，而不是在商家改变金额之后再通知消费者114，这在商家102能够改变再发性付款金额(提前通知或不提前通知)时，消费者114对此特别感兴趣。

图5示出了与常规SMS消息格式一致的方式在通信设备116上显示的另一个示例性验证界面500。如图所示，来自验证引擎122的验证消息502依赖于作为通信媒介的传统的SMS消息传递格式，但是如在图4的界面400中提供的那样，转送了关于再发性交易的相同数据(例如，商家102的名称、定期交易的金额(即，187.36美元)等)。类似于界面400，图5的验证消息指示消费者114如何响应以进行验证，即，回复“1”批准，回复“2”拒绝。在图5所示的验证界面500中，消费者114在504以回复文本消息作出响应，该文本消息为“1”表示批准再发性交易。

应该意识到，可以设想其他界面和/或验证消息。在其他实施例中，例如，验证界面可以包括额外和/或不同字段和/或格式(例如，指示出做出响应所需的时间间隔以避免默认操作(例如，自动批准等))，以向消费者114提供额外和/或不同数据，以供消费者在决定批准或拒绝定期的再发性交易时进行检查/考虑。特别地，验证消息(或者例如通信设备116处的界面)可以包括再发性交易号码(例如，“账单号码”等)和联系支持(例如，电话号码、聊天软件MSN、聊天功能等)。在该示例中，消费者114经常能够通过使用再发性交易号码或消费者的一个或多个详细信息(例如，支付账号、姓名、地址、生日等)来联系验证引擎122、商家102或其他实体以查询再发性交易。另外，应该理解的是，无论是否包括附加信息，字段和/或字段的布置可以与图4的示例性界面400或者图5的示例性界面不同。

应该进一步理解的是，来自验证引擎122的验证消息可以导致向消费者114发出一个或多个不同的警报。例如，验证消息可以导致在通信设备116的呈现单元206发出“叮”声或其他警报。通过这种方式，特别是对于依赖于时间间隔的验证来说，向消费者114通知接收到需要响应的验证消息。

再次参照图3，在308，验证引擎122确定其是否已经从消费者114接收到批准再发性交易的验证响应。例如，消费者114在界面400在中简单地选择“批准”按钮404或“拒绝”按钮406，或者在界面500中发送指示“1”或“2”的答复文本消息(即，在504)，在这两种情况下，从而向验证引擎122发送响应。接着，当验证响应指示批准时，在310，验证引擎122批准授权请求(或授权应答，这取决于保持的是授权请求还是授权应答)并继续进行。然后，如前面在系统100中所述，如果发行方108批准交易(当保持授权请求时)，经由支付网络106将授权交易的回复从发行方108返回到收单方104和商家102，从而允许商家102完成交易。随后由商家102和收单方104并在商家102和收单方104之间，以及在由收单方104和发行方108并在收单方104和发行方108之间对交易进行清算和/或结算。如果发行方108拒绝交易，则将拒绝交易的回复返回商家102，从而允许商家102终止交易。

相反，在308，当验证引擎122从消费者114接收到拒绝定期交易的验证响应时，则验证引擎122终止授权请求。更具体地说，验证引擎122生成拒绝再发性交易的信息并将该信息发送给商家102(即，授权请求未被发行方108接收和/或响应)。在至少一个实施例中，由验证引擎122生成的授权应答包括至少一个数字和/或字母数字指示符，以通知商家102交易由于消费者行为而被拒绝。例如，可以根据ISO 8583格式或者其他消息和/或格式，而将指示符包括在验证引擎122的0110消息的DE60中。在其他实施例中，可以在任何授权应答或响应中省略拒绝交易的原因。

此外，当验证引擎122发送验证消息时，验证引擎122还启动用于接收验证响应的预定时间间隔(例如，约一小时、约两小时、约八小时等)的倒计时。预定时间间隔可由消费者114或验证引擎122(或另一实体)设定，并且该预定时间间隔潜在地取决于例如推定的响应时间间隔(给定的通信媒介、偏好、与支付网络106相关联的一个或多个约束等)。在312，验证引擎122确定预定时间间隔是否到期。当未到期时，验证引擎122返回到308，以等待验证响应。然而，如果在312验证引擎确定预定时间间隔已到期，则在314，验证引擎122检索(从数据结构124)出一个或多个偏好和/或设置(即，在该实施例中的默认设置等等)，并与检索出的一个或多个偏好和/或设置一致地动作。

例如，消费者114的默认设置或偏好(在数据结构124中)可以指示验证引擎122在无需验证响应的情况下，在预定时间间隔之后批准再发性交易。或者，如果在接收到验证消息之前预定时间间隔到期，则默认设置或偏好可以指示验证引擎122拒绝再发性交易。或者更进一步地，当在预定时间间隔期间没有接收到验证响应时，验证引擎122可以基于一个或多个偏好或设置而批准授权请求继续进行下去。在322，验证引擎然后可以使方法300继续进行到如下描述的操作，例如可以使验证消息再等待第二预定时间间隔以在清算再发性交易之前接收验证响应。另外或者替代地，在至少一个例子中，消费者偏好可以选择只有当交易的金额自上次或先前和商家的再发性交易以来已经改变(例如，有线服务的账单金额改变(例如，增加35美元等)，等)，或者高于预定金额(例如，对于金额高于20.00美元的再发性交易等)时才验证再发性付款。

应该意识到，各种偏好和/或设置可以包括何时以及如何采取行动来响应于没有验证响应。偏好和/或设置同样可以潜在的由消费者114、发行方108和/或与特定的再发性交易相关联的另一个实体来指定。

可选地，在方法300中(如图3中的虚线所示)，在316，验证引擎122可以允许由发行方108对授权请求进行处理，然后等待向消费者发送验证消息，直到生成对授权请求的回复。更具体地，类似于AFD(自动加油机)交易，验证引擎122可以发送授权消息，以仅确认消费者的支付账户对发行方108是否具有良好信誉，和/或确定消费者的支付账户中有可用于支付交易的足够的资金等。然后，如果发行方108以肯定的方式回答，则在306，验证引擎122可以将验证消息发送给消费者114(并且如上所述地继续)。当或者如果验证响应被接收(通过批准)时，则验证引擎122随后向发行方108发送完整的授权请求。然而，如果回复指示拒绝交易，则验证引擎122可以简单地允许(或根据需要释放)将授权应答发送给收单方104和商家102。这样，当包括该可选操作314或该可选操作314由验证引擎122执行时，则验证引擎122可以在发行方108最终会在消费者114验证或不验证的情况下拒绝交易时，避免将不必要的验证消息发送给消费者114。

继续参考图3，替代地(或附加地)在方法300中，在302，在检测到和/或接收到针对再发性交易的授权请求时，在318，验证引擎122可以将有关清算再发性交易(例如，在授权请求继续并被批准之后等)的验证消息发送给消费者114。具体而言，在该实施例中，验证引擎122经由网络112将验证消息发送给消费者的便携式通信设备116。这通常以与参考306所描述的发送验证消息类似的方式来完成。

在验证引擎122将验证消息发送给消费者114的几乎同时(或者更早或更晚)，在302，验证引擎122还允许授权请求(或应答)继续进行。与此相关地并且如之前在系统100中所描述的，如果发行方108拒绝交易，则将拒绝交易的回复返回给收单方104和商家102，从而允许商家102停止交易(可能不在318发送验证消息)。或者，如果发行方108批准交易，则将批准交易的回复返回给商家102，从而允许商家102继续进行再发性交易。则在可由商家102和收单方104并在商家102和收单方104之间对交易进行清算之前，以及由收单方104和发行方108并在收单方104和发行方108之间对交易进行清算之前，需要消费者114对交易进行验证。

在322，当验证引擎122从消费者114接收到批准定期交易的验证响应时，在324，验证引擎122批准对再发性交易进行清算，并继续进行。通常根据由商家102和收单方104并在商家102和收单方104之间进行的常规操作，以及根据由收单方104和发行方108和收单方104和发行方108之间进行的常规操作，继续进行上述清算处理。

然而，当在320，验证引擎122没有从消费者114接收到验证响应时，在326，验证引擎122拒绝对再发性交易进行清算。例如，验证引擎122可以生成一个或多个消息并将其发送给发行方108和/或收单方104，以将针对消费者的支付账户的交易取消和/或不支付(通过具体的撤销再发性交易，或者通过再发性交易金额的信贷和/或退货交易等)，由此再发性交易在相关的清算记录中基本上无效。特别地，验证引擎122可以生成消息并将其发送给发行方108，这将会撤销特定的再发性交易。收单方104然后会在清算过程中发现改撤销，并从商家的账户中扣除适当的金额。

鉴于以上所述，本文的系统和方法可允许消费者参与批准和/或拒绝针对消费者的支付账户的计划的再发性交易(例如，在初始设置之后)，从而改变了对再发性交易的常规的授权和/或清算。因此，涉及的消费者和/或商家可以享受自动支付类型选项的好处，同时仍然保留消费者对进行该交易的进一步验证的批准。通过这种方式，消费者能够拒绝反映与先前同意的交易和/或交易金额不同的再发性交易，和/或拒绝与消费者对针对支付账户的再发性交易的意图不一致的交易。

再次且如前所述，应该认识到，在一些实施例中，本文描述的功能可以在存储在计算机可读介质上并且可由一个或多个处理器执行的计算机可执行指令中描述。所述计算机可读介质是非暂时性计算机可读存储介质。作为示例而非限制，这样的计算机可读介质可以包括RAM、ROM、EEPROM、CD-ROM或其他光盘存储器、磁盘存储器或其他磁存储设备，或可用于携带或存储以指令或数据结构的形式的期望的程序代码并且可以由计算机访问的任何其他介质。上述的组合也应该包括在计算机可读介质的范围内。

还应该理解，当通用计算设备被配置为执行本文描述的功能、方法和/或过程时，本公开的一个或多个方面将通用计算设备转换成专用计算设备。

如基于前述说明书将理解的，本公开的上述实施例可以使用包括计算机软件、固件、硬件或其任何组合或子集的计算机编程或工程技术来实现，其中技术效果可以通过执行至少一个以下操作来实现：(a)接收针对支付账户并涉及商家的交易的授权请求，所述授权请求包括再发性交易支付指示符；(b)将验证请求发送给与所述支付账户相关联的消费者；(c)至少禁止清算所述交易，直到基于所述消费者的指示识别出对所述交易的验证，由此所述消费者能够在清算所述交易之前验证所述交易；(d)向所述商家发送包括对所述交易的批准的授权应答；(e)当在预定的时间间隔内没有识别出对所述交易的验证时，向所述商家发送拒绝授权应答；(f)当用于响应所述验证消息的预定时间间隔到时时，识别对所述交易的验证；(g)使授权应答包括消费者拒绝交易的指示符；和(h)检测针对所述再发性交易的授权请求中的再发性付款指示符；并将所述交易识别为再发性交易。

提供示例性实施例是为了使本公开详尽，并且将范围充分传达给本领域技术人员。阐述了许多具体细节，例如，具体的组件、设备和方法的示例，以提供对本公开的实施例的全面理解。对于本领域技术人员来说显而易见的是，不需要采用具体细节，示例性实施例可以以许多不同的形式来体现，并且都不应该被解释为限制本公开的范围。在一些示例性实施例中，没有详细描述公知的过程、公知的设备结构和公知的技术。

在此使用的术语仅用于描述特定示例性实施例的目的，而不意图是限制性的。除非上下文另有明确指示，否则单数形式“一”、“一个”和“该”可以意图包括复数形式。术语“包括”、“包含”、“含有”和“具有”是包含性的，并且因此指定所述特征、整体、步骤、操作、元件和/或组件的存在，但不排除存在或增加一个或多个其他特征、整体、步骤、操作、元件、组件和/或它们的组合。除非特别标识执行的顺序，否则不应将本文描述的方法步骤，过程和操作解释为必须要求它们以所讨论或说明的特定顺序执行。还应该理解可以采用附加的或替代的步骤。

当特征被称为“在...上”、“与...接合”、“连接到”、“耦合到”、“与...关联”、“包含在”或“与......通信”时，它可以是直接在其他特征之上，与其他特征接合、连接、耦合、关联、包含或通信，或者可以存在中间特征。如本文所使用的，术语“和/或”包括一个或多个相关所列项目的任何和所有组合。

另外，如本文所使用的，术语产品可以包括商品和/或服务。

虽然术语第一、第二、第三等可以在本文中用于描述各种特征，但是这些特征不应受这些术语的限制。这些术语可以仅用于区分一个特征与另一个特征。除非上下文明确指出，否则诸如“第一”、“第二”和其他数字术语的术语在本文中使用时并不意味着顺序或次序。因此，在不背离示例性实施例的教导的情况下，可以将本文讨论的第一特征称为第二特征。

为了举例说明和描述的目的，已经提供了示例性实施例的前述描述。目的不是穷举或限制本公开。即使没有具体示出或描述，特定实施例的单独元件或特征通常不限于该特定实施例，而是在适用的情况下可互换并且可用于选定实施例中。同样的情况在许多方面也可能有所不同。不认为这样的变化是背离本公开，并且旨在将所有这样的修改包括在本公开的范围内。