CN107077677A - 用于在交易授权时处理实时返利的方法和系统 - Google Patents

Abstract

公开了用于处理涉及奖励账户的支付交易的系统和方法。一个示例性的方法包括接收涉及奖励账户的支付交易的授权请求。授权请求至少包括交易金额。该方法还包括基于奖励偏好确定支付交易是否具有奖励返利的资格，并且当支付交易具有资格时发送奖励返利请求。

Description

用于在交易授权时处理实时返利的方法和系统

相关申请的交叉引用

本申请是2014年8月21日提交的美国专利申请No.14/465,063的PCT国际申请并要求其优先权。美国专利申请No.14/465,063是2013年10月21日提交的美国专利申请No.14/058,548的部分继续申请。通过引用的方式将上述申请的全部公开内容并入到本文中。

技术领域

本公开涉及发起对使用奖励账户提供资金的支付交易的返利，具体地，涉及在基于奖励余额的支付交易处理之后，自动发起向奖励账户返利。

背景技术

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

为了增加使用量，许多支付卡发行商为使用她们的支付卡的持卡人提供奖励。奖励可以采用各种形式，例如，可以兑换现金或产品的奖励积分、现金返还、航空里程、特定商家的奖励积分(例如，旅游服务公司、酒店、批发商、零售商等)、基于活动的奖励等级，其中每个等级可能具有相应的收益等等。然而，这些传统的奖励方案通常需要持卡人采取大量的行动才能获得收益。此外，持卡人通常不能直接在销售点使用奖励，而是要求先兑换奖励、再收到奖励、然后在销售点使用奖励。

为了在销售点简化奖励收益的兑换，已经开发了一些系统和方法，以便在使用特定支付卡时就能够兑换奖励积分或其他收益。例如，在2009年9月4日提交的公开号为2010/0057553的美国专利中描述的系统使用仅授权使用奖励积分的余额的支付卡，通过引用的方式将该美国专利整体并入到本文中。然而，由于该卡仅被授权使用积分，所以该卡不可用于传统的支付交易，这可能会使消费者感到沮丧或混淆，特别是如果消费者不希望携带多个支付卡时。开发了在支付卡上包括物理开关的另一种系统，持卡人可以触发该物理开关，以便在作为传统支付卡的使用和通过奖励余额的支付之间进行切换。然而，这可能使可能会忘记在使用类型之间切换的消费者感到沮丧。此外，两种支付方式的差异可能导致持卡人无法使用信用和奖励余额来支付。

附图说明

当结合附图阅读时，从下面对示例性实施例的详细描述中可以更好地理解本公开的范围。附图中所包括的是如下的附图：

图1是示出根据示例性实施例的、用于发起对使用奖励账户提供资金的支付交易的返利的系统的高级架构。

图2是示出根据示例性实施例的、用于发起对由奖励账户提供资金的支付交易的返利的图1的处理服务器的框图。

图3是示出根据示例性实施例的、对使用奖励账户提供资金的支付交易的处理以及基于奖励余额发起和处理对奖励账户的返利的过程的流程图。

图4是示出根据示例性实施例的、在使用奖励账户提供资金的支付交易之后，由图2的处理服务器发起的返利请求的过程的流程图。

图5是用于接收消费者偏好选择的示例性界面的框图。

图6是示出根据示例性实施例的、用于发起对使用奖励账户提供资金的支付交易的返利的示例性方法的流程图。

图7是本公开的、适于在处理涉及奖励账户的支付交易中使用的的另一示例性系统的框图。

图8是根据图7的系统的、处理涉及奖励账户的支付交易的示例性方法的流程图。

图9是根据图7的系统的、处理涉及与第三方相关联的奖励账户的支付交易的示例性方法的流程图。

图10是示出根据示例性实施例的计算机系统架构的框图。

通过下文提供的详细描述，本公开的其他适用范围将变得显而易见。应当理解，示例性实施例的详细描述仅用于举例说明的目的，因此并不意在限制本公开的范围。

具体实施方式

现在将参照附图更全面地描述示例性实施例。

术语定义

支付网络-用于通过使用现金替代品来转移货币的系统或网络。支付网络可以使用各种不同的协议和进程来处理用于各种类型交易的货币转移。可以通过支付网络执行的交易可以包括产品或服务购买、信用购买、借记交易、资金转帐、账户提款等。支付网络可以被配置为通过现金替代品执行交易，所述现金替代品可以包括支付卡、信用证、支票、财务账户等。配置为执行成支付网络的网络或系统的例子包括由 等运营的网络或系统。本文对术语“支付网络”的使用可以指将支付网络作为实体和物理支付网络，例如，包括支付网络的设备、硬件和软件。

支付账户-可用于为交易提供资金的金融账户，例如，支票账户、储蓄账户、信用账户、虚拟支付账户等。支付账户可以与实体相关联，该实体可以包括个人、家庭、公司、社团、政府实体等。在某些情况下，付款账户可能是虚拟的，例如由等运营的账户等。

支付卡-与支付账户相关联的卡或数据，可以将支付账户提供给商家以通过相关联的支付账户为金融交易提供资金。支付卡可以包括信用卡、借记卡、签账卡、储值卡、预付卡、汽油特惠卡(fleet card)、虚拟支付号码、虚拟卡号码、受控支付号码等。支付卡可以是可以提供给商家的物理卡或者可以是表示相关联的支付账户的数据(例如，存储在诸如智能电话或计算机的通信设备中的数据)。例如，在某些情况下，可以认为包括支付账号的数据可以被认为是用于处理由相关联的支付账户提供资金的交易的支付卡。在某些情况下，在适用时可以将支票视为支付卡。

奖励账户-当支付账户用于为交易提供资金时，该支付账户可以为账户持有人赚取奖励。对相关领域的技术人员显而易见的是，奖励可以是积分、等级、返现、里程或其他合适的频率值的形式。可将累积奖励的金额称为奖励余额，例如，账户持有人赚取越多的奖励就可以导致奖励余额增加(例如，更高)。如本文所使用的，“积分”通常可以指对奖励账户的奖励，并且“积分余额”通常可以指奖励账户的奖励余额。

商家–为另一个实体(例如，消费者或其他商家)提供购买的产品(例如，商品和/或服务)的实体。对相关领域的技术人员显而易见的是，商家可以是消费者、零售商、批发商、制造商、或可以提供用于购买的产品的任何其他类型的实体。在某些情况下，商家可能对提供的用于购买的商品和/或服务有特殊的知识。在其他情况下，商家可能没有或可以不要求对提供的产品有任何特殊的知识。在一些实施例中，可以将参与单个交易的实体认为是商家。

发行者-建立(例如，开立)有利于受益人的信用证或信用额度以及由受益人根据信用证或信用额度规定的额度而提取的支票的实体。在许多情况下，发行者可能是授权开立信用额度的银行或其他金融机构。在某些情况下，可将任何向受益人提供信用额度的实体视为发行者。发行者开立的信用额度可以以支付账户的形式表示，并可以由受益人通过使用支付卡进行支付。

收单方-代表商家处理支付卡交易的实体。收单方可以是被授权代表商家处理支付卡交易的银行或其他金融机构。在许多情况下，收单方可以向作为受益人的商家开立信用额度。在可以是发行者提供的信用额度的受益人的消费者通过支付卡与由收单方代表的商家进行交易的情况下，则收单方可以向发行者交换资金。

支付交易-两个实体之间的交易，其中，货币或其他经济利益从一个实体交换到另一个实体。对相关领域的技术人员显而易见的是，支付交易可以是资金转移、购买商品或服务、偿还债务、或任何其他经济利益交换。在某些情况下，支付交易可以指通过支付卡和/或支付账户提供资金而进行的交易，例如，信用卡交易。这种支付交易可以通过发行者、支付网络和收单方来处理。处理这种支付交易的过程可以包括授权、批处理、清算、结算和提供资金中的至少一个。授权可以包括向商家提供消费者的支付明细，从商家向其收单方提交交易明细(例如，包括支付明细)以及由为交易提供资金的消费者的支付账户的发行者对支付明细进行验证。批处理可以指批量地存储授权的交易与其他授权的交易以分发给收单方。清算可以包括将批量的交易从收单方发送到支付网络进行处理。结算可以包括支付网络针对涉及发行者的受益人的交易将发行者记入借方。在某些情况下，发行者可以通过支付网络向收单方付款。在其他情况下，发行者可以直接向收单方支付。提供资金可以包括收单方针对已经清算和结算的支付交易向商家支付。对相关领域的技术人员显而易见的是，以上讨论的步骤的顺序和/或分类可以作为支付交易处理的一部分来执行。

用于处理奖励账户的返利请求的系统

图1示出了用于发起并处理对使用奖励账户提供资金的支付交易的返利的系统100。

系统可以与消费者102交互。消费者102可以具有支付账户，该支付账户具有由发行者104持有的可用的奖励(例如，奖励账户)。在某些情况下，发行者104可以向消费者102发行与奖励账户相关联的支付卡，以在使用奖励账户为支付交易提供资金时使用。消费者102可以与商家106进行由奖励账户提供资金的支付交易。

商家106(例如，或者与商家106相关联的收单方)可以将针对由奖励账户提供资金的支付交易的授权请求提交给支付网络108。支付网络108可以使用对于相关领域的技术人员来说将显而易见的方法和系统来处理支付交易。作为处理的一部分或在处理之后，支付网络108可将授权请求的副本发送到处理服务器110。发送到处理服务器110的授权请求可以至少包括支付信息(例如，指示用于为支付交易提供资金的奖励账户)和交易金额。

下面更详细讨论的处理服务器110可以被配置为基于奖励余额发起对奖励账户的返利请求。处理服务器110可以至少基于交易金额和至少一个转换规则来计算交易奖励值。转换规则可以基于商家106、消费者102、发行者104、支付交易的交易数据或任何其他合适的值。交易奖励值可以表示通过奖励为整个支付交易提供资金所需的奖励账户中的奖励值。例如，对于150美元的交易，计算的交易奖励值可为150个积分。

如下面更详细地讨论的，处理服务器110还可以存储对应于账户数据库112中的消费者102的账户数据条目。账户数据条目可以至少包括消费者102为支付交易提供资金所使用的奖励账户的奖励余额。在一些实施例中，处理服务器110可以与发行者104相关联和/或可以从发行者104接收账户信息(例如，奖励余额)。处理服务器110可以识别账户数据条目的扣减金额(reduction amount)，其中，扣减金额基于包括在账户数据条目中的奖励余额和交易奖励值中的较少者。在这种情况下，扣减金额可以解释奖励余额超过为支付交易提供资金所需的奖励金额的情况或奖励余额不超过奖励金额但只可以用于为支付交易提供部分资金的情况。

处理服务器110然后可以基于扣减金额来更新与消费者102相关联的账户数据条目中的奖励余额。处理服务器110还可以基于扣减金额和至少一个转换规则来计算要在用于支付交易的奖励账户上处理的返利的返利金额。处理服务器110然后可以向支付网络108提交返利请求，以基于兑换的奖励请求要向奖励账户的发行者104支付的返利金额。支付网络108可以使用对相关领域的技术人员来说显而易见的系统和方法来处理返利。

在一些实施例中，处理服务器110可以向消费者102发送指示向支付网络108成功传送返利请求的通知。可以通过短消息服务(SMS)消息、多媒体服务消息、电子邮件、传统邮件、电话、网站、应用程序或对于相关技术领域的技术人员来说将显而易见的任何其他合适的方法，将该通知发送给消费者102，可以将该通知传送给消费者102或与消费者102相关的计算设备。在其他实施例中，除了指示成功传送返利请求的通知之外或者作为其的备选，处理服务器110可以传送指示对返利请求进行了成功的处理的另一个通知。在一些实施例中，处理服务器110还可以向发行者104发送通知，例如，以基于所计算的更新的奖励余额提供对奖励账户的奖励余额的更新。

在一些情况下，当与消费者102相关联的账户数据条目的奖励余额小于交易奖励值时，处理服务器110可以向消费者102请求许可，以提交针对支付交易的返利请求。在这种情况下，处理服务器110可以向消费者102提交请求(例如，提交给与消费者102相关联的计算设备，例如，移动计算设备或进行支付交易的销售点设备)。消费者102可以响应该请求，该请求可以由处理服务器110接收并进行相应地处理。如果消费者102希望使用其奖励余额，处理服务器110可以如上所述提交返利请求，或者如果消费者102不希望使用其奖励余额，则可以不提交任何请求。在一些实施例中，处理服务器110可以被配置为基于部分使用奖励余额来提交返利请求。

本文讨论的系统和方法可以提供对传统系统和方法的许多改进，以使消费者102能够使用奖励账户的奖励来为支付交易提供资金。因为处理服务器110可以在不需要消费者102使用第二支付卡或在进行交易之前不需要执行任何动作的情况下，就可以使用奖励余额为支付交易提供资金，所以处理服务器110可以使通过奖励为支付交易提供资金更快更有效。因此，系统100对于消费者而言可能更容易接受，这转而可导致较高的使用率，这可以使消费者102和发行者104都受益。

此外，通过将对奖励的使用作为返利请求处理，支付交易本身可以在不需要修改现有的支付系统的情况下常规地进行。此外，可以在支付交易之后，将折扣请求作为清算记录发送，这可以导致返利请求的非常快速的处理。在这种情况下，可以在不受处理服务器110的中断或干预的情况下，常规地提交从商家106提交给支付网络108的初始授权请求，这使得可以保持常规处理速度，当与返利请求的清算速度相结合时，这可以导致以使消费者102不会感觉到的延迟，对使用奖励的支付交易的返利进行处理。

处理设备

图2示出了系统100的处理服务器110的实施例。对相关领域的技术人员将显而易见的是，图2所示的处理服务器110的实施例仅是示例性的，并且可能没有穷举出适于执行本文所述的功能的处理服务器110的所有可能的配置。例如，在图6中示出的并且下面将更加详细地讨论的计算机系统600可以是处理服务器110的合适配置。

处理服务器110可以包括接收单元202。接收单元202可以被配置为通过一个或多个网络协议在一个或多个网络上接收数据。接收单元202可以被配置为从支付网络108接收对应于由奖励账户提供资金的支付交易的授权请求，其中，所述授权请求至少包括交易金额和支付信息。支付信息可以包括账户标识符或其他合适的信息，对于相关领域的技术人员将是显而易见的是，其可以用于识别用于为支付交易提供资金的奖励账户。

处理服务器110还可以包括处理单元204。处理单元204可以使用支付信息来识别存储在与用于为支付交易提供资金的奖励账户相关联的账户数据库112中的账户数据条目208。存储在账户数据库112中的每个账户数据条目208可以包括与消费者奖励账户有关的数据，该消费者奖励账户至少包括账户标识符和奖励余额。账户标识符可以是用于识别的唯一值，例如，标识号码、支付账号(例如，相关联的奖励账户的账号)、用户名、电子邮件地址、电话号码等。奖励余额可以是消费者102为相关的奖励账户赚取的奖励余额。在一些情况下，奖励余额可以由处理服务器110(例如，经由接收单元202)从发行者104接收。

处理单元204还可以被配置为至少基于可以存储在存储器210中的交易金额和一个或多个转换规则来计算交易返利值。在某些情况下，交易返利值可以进一步基于以下中的至少一个：消费者102(例如，消费者102的账户级别)、发行者104(例如，发行者偏好、发行者类别等)、商家106(例如，商家偏好、商家类别、商业行业等)，包括在授权请求中的交易数据(例如，产品数据、交易时间和/或日期、地理位置等)以及对相关领域的技术人员来说将显而易见的更多因素。

处理单元204还可以被配置为识别扣减金额，扣减金额可以是包括在确定的账户数据条目208中的奖励余额和交易奖励值中的较少者。处理单元204随后可以基于当前的奖励余额和扣减金额来更新包括在识别的账户数据条目208中的奖励余额，并且可以基于识别的扣减金额和至少一个转换规则来计算返利金额。处理单元204可以针对计算的返利金额生成返利请求。在一个示例中，交易金额可以是100美元，并且处理单元204计算的交易奖励值可以是100个积分。识别的账户数据条目208可以包括75个积分的奖励余额。因此，处理单元204可以识别扣减金额为75个积分，其可以将奖励余额更新为零个积分，并且可以导致计算的返利金额为75美元。处理单元204随后可以生成向奖励账户返回75美元的返利请求。

处理服务器110还可以包括发送单元206。发送单元206可以被配置为通过使用一个或多个网络协议在一个或多个网络上发送数据。发送单元206可以被配置为将所生成的返利请求发送到支付网络108进行处理。

发送单元206还可以被配置为向消费者102和/或发行者104发送指示成功发送返利请求的通知。

在一些实施例中，接收单元202可以在成功处理返利请求时从支付网络108接收通知。在该实施例中，发送单元206还可以被配置为向消费者102和/或发行者104发送指示成功处理的通知。在一些情况下，可以在指示成功传送返利请求的先前通知之外，附加地或替代地传送该通知。

在识别的账户数据条目208的奖励余额小于支付交易的交易返利值，以及如果处理服务器110要求消费者102批准使用奖励为支付交易提供部分资金(例如，基于先前接收的消费者偏好，例如，可以将所述消费者偏好存储在识别的账户数据条目208中)的实施例中，发送单元206可以被配置为发送消费者102批准的请求以推进到消费者102。可以通过相关领域的技术人员显而易见的任何合适的方法将该请求传送到消费者102，例如，通过与消费者102相关联的计算设备或用于进行支付交易的销售点设备(例如，如授权请求中所指示的)。接收单元202可以被配置为接收来自消费者102的指示处理针对交易金额的部分金额的返利请求或者拒绝返利请求的响应。处理单元204可以识别包括在响应中的指示，并且可以相应的进行如上所述的动作。在一些实施例中，如果奖励余额小于计算的交易返利值，则账户数据条目208可以指示处理单元204是否生成返利请求。

支付交易的处理以及返利请求的后续处理

图3示出了使用奖励账户为支付交易提供资金的处理以及使用在奖励账户上赚取的奖励进行返利请求的后续处理的过程。

在步骤302，消费者102可以发起与商家106的支付交易以使用奖励账户购买商品或服务。作为发起支付交易的一部分，消费者102可以向商家106提供奖励账户的账号(例如，通过支付卡或其他合适的方法)。在步骤304，商家106(例如，或者与商家106相关联的收单方)可以生成授权请求并将授权请求提交给支付网络108以进行处理。在步骤306，支付网络108可以将授权请求转发给奖励账户的发行者104。在步骤308，发行者104可以批准支付交易(例如，基于奖励账户中的充足资金)，并且在步骤310，可以将指示批准的授权响应发送回支付网络108。

在步骤312，支付网络108可将指示批准支付交易的授权响应转发给商家106。相关领域技术人员显而易见的是，步骤304至312是使用传统的系统和方法处理支付交易的示例，并且可以包括附加步骤和/或附加实体。在步骤314，商家106可以向消费者102提供对商品或服务的收据和/或交易。

在步骤316，支付网络108可以向处理服务器110发送支付交易的授权请求的副本，所述授权请求的副本至少包括支付信息和交易金额。在步骤318，处理服务器110可以识别与用于为支付交易提供资金的奖励账户相关联的账户数据条目208，并且处理服务器110可以基于包括在识别的账户数据条目208中的奖励余额以及基于交易金额和至少一个转换规则计算的交易奖励值，并且可能基于如下所述的偏好的可能性，来进一步识别使用奖励对支付交易提供资金的可能性。例如，偏好(例如，奖励偏好)可以指示对所有交易、仅对下一个交易、不对任何交易、仅对高于最小阈值的交易、仅对可以完全使用奖励提供资金的交易等，使用奖励为支付交易提供资金。在消费者102可能被要求批准使用奖励来完全或部分地为支付交易提供资金的情况下，在步骤320，处理服务器110可以向消费者102提交批准请求。

在步骤322中，消费者102可以通过计算设备(例如，移动计算设备，商家106处的销售点设备等)或其他合适的方法来批准使用积分。在步骤324，可将指示消费者的批准的批准响应发送到处理服务器110。在步骤326，处理服务器110然后可以基于扣减金额和至少一个转换规则，并且可能基于批准或偏好，生成返利金额的返利请求。在步骤328，处理服务器110可以将返利请求发送到支付网络108。

在步骤330，支付网络108可以使用对相关领域的技术人员来说显而易见的方法和系统来处理返利请求。可以将返利从与商家106相关联的账户处理到与消费者102相关联的奖励账户。在步骤332，支付网络108可以将指示成功处理针对返利金额的返利的返利响应发送到奖励账户。在步骤334，处理服务器110可以向消费者102发送指示成功处理了返利的通知。在一些情况下，通知可以进一步包括更新的奖励金额和如相关领域的技术人员显而易见的其他合适的信息。

生成和发起返利请求的方法

图4示出了通过系统100的处理服务器110执行的、生成并处理返利奖励请求的方法，所述返利奖励请求针对的是使用奖励账户提供资金的支付交易的返利。奖励账户可以包括对消费者在使用奖励余额时的偏好的选择，并且可以包括如由发行者104、支付网络提供商、商家106和/或收单方选择的对使用奖励余额的计划偏好。

在步骤402，处理服务器110的接收单元202可以接收对使用奖励账户提供资金的支付交易的授权请求。授权请求可以至少包括支付信息和交易金额。在步骤404，处理单元204可以确定支付交易是否是使用奖励为支付交易提供全部或部分资金的有效交易。步骤404可以包括使用包括在授权请求中的支付信息来识别存储在账户数据库112中的账户数据条目208。如果没有识别出有效的账户数据条目208，则可以认为该交易不是有效的，并且可以结束该过程。

再次参考图4，如果识别出有效的账户数据条目208并且可以使用奖励来完全或部分地为交易提供资金，则在步骤405，处理服务器110基于一个或多个消费者和/或计划偏好(例如，奖励偏好)确定支付交易是否具有返利奖励请求的资格。账户数据库112中的每个账户数据条目208可以包括与奖励账户相关联的消费者偏好。消费者偏好可以指示何时应当为在销售点终端(物理或虚拟的)上进行的购买请求奖励返利，当购买不具有奖励返利请求的资格时，则反之。可以从与消费者102相关联的计算设备(例如，移动计算设备或者甚至是与消费者102进行支付交易时当前的销售点设备)接收消费者偏好。通常，在消费者102到达商家106之前，消费者102将通过消费者计算设备选择或提供奖励偏好，处理服务器110接收奖励偏好并将其存储在账户数据条目208中。备选地，消费者102可以在购买时、恰在支付购买之前、或者作为支付交易的一部分，通过移动计算设备或商家106处的销售点设备选择奖励偏好。

消费者偏好(例如，消费者奖励偏好)可以包括何时是否应该或不应该为购买请求奖励返利的各种不同的指示。

例如，消费者偏好选项可以包括对支付交易禁用奖励返利请求、对所有支付交易都使用奖励返利请求、仅对下一个支付交易使用奖励返利请求等。这允许消费者102决定他们什么时候想要获得为支付交易请求的奖励返利。如果奖励余额相对较小，或者如果消费者102希望使奖励余额累积达到更大的数量以用于将来的更重要的购买，例如，在一些示例中，消费者102可以暂且禁止使用奖励。备选地，例如，如果消费者102已经在奖励账户中累积了很多的奖励余额，或者希望尽快使用奖励，则消费者102可以选择对所有支付交易都使用奖励返利请求。此外，例如，如果消费者102希望使用奖励返利进行单次购买，但是在进行购买之后允许奖励余额增长，则消费者102可以选择仅为下一次购买使用奖励返利请求。例如，消费者102可以在购物时、当消费者102已经决定购买他/她希望使用奖励返利请求的商品时，在商家106处选择该奖励偏好。在进行了下次购买之后，消费者偏好会自动更改回禁用。消费者102然后能够改变偏好，以便具有用于后续支付交易的奖励返利请求。

在另一个示例中，消费者偏好可以包括特定商家(或多个商家)，以使得奖励返利请求应该仅用于在特定商家的支付交易。

作为可能的奖励偏好的另一示例，处理服务器110和/或消费者102可以选择最小标准，该最小标准必须满足为支付交易请求的奖励返利。在一个示例中，消费者可以选择最小购买金额为20美元，以使得奖励返利请求将仅用于涉及至少20美元的支付交易。例如，消费者102可以选择这种最小购买金额，以使得消费者可以使用普通的支付账户方法(例如，收费/借记奖励账户等)来支付较少的购买费用，同时保存奖励余额以用于金额较大的、更重要的购买。当然，消费者102可以采用各种其他原因来选择一个最少金额而不是另一个。在至少一个实施例中，消费者偏好可以包括最大购买金额。

可以通过消费者的计算设备上的接口或者通过消费者102和处理服务器110之间的其他交互(直接或间接的)来接收上述示例性消费者偏好和其他消费者偏好中的每一个，藉此处理服务器110随后接收消费者的偏好。

例如，图5示出了适于在消费者的移动计算设备上显示的界面450。界面450包括账号输入栏452，其可以从消费者102接收与消费者的奖励账户相关联的账号(例如，账户标识符)。界面450还包括密码栏454，其可以接收与奖励账户相关联的密码，以防止他人访问和/或更改消费者的奖励账户的偏好。界面450包括用于选择如上所述的最小购买金额456的单选按钮，其可以在支付交易等于或超过消费者102在金额栏458输入的最小购买金额时才发起返利请求。

界面450还包括单选按钮460，其与针对所有交易、不针对交易、以及仅针对下一个交易的偏好相关联，这与上文参考图4描述的偏好一致。当消费者102完成在界面450中选择一些或所有偏好，并且在452,454提供账号和密码时，消费者102通过点击提交按钮462将偏好提交给处理服务器110。处理服务器110依次接收偏好并存储相关的账户数据条目208。

应当理解，消费者的任何数量的不同偏好可以包括在界面(例如，界面450)中和/或从界面选择。通常，消费者偏好允许消费者102预先定义如何使用奖励余额(即通过一个或多个奖励偏好)，然后以常规方式简单地使用与奖励账户相关联的支付卡，而不必执行任何额外的动作和/或活动来使用奖励余额，从而消费者102更容易的使用奖励账户。

此外，在各种实施例中，奖励账户的发行者104可以设置奖励账户的最小购买金额，以使得仅对至少包含该金额的支付交易请求奖励返利。这可以允许发行者104限制消费者102无论金额多少对每次购买都使用奖励返利请求，从而使发行者104节省了与处理大量小额购买等的每个单独的奖励返利请求相关的任何开销。附加地或者备选地，如上所述，发行者104可以要求消费者102提交最小购买金额偏好。计划偏好可以进一步限制一定时期内的奖励返利请求的数量，限制可以使用奖励的商家106和/或保留奖励计划中的损耗(不允许消费者套现她们的所有积分)的各种其他选项，创建奖励计划级别变量，减少处理的奖励兑换金额，减少奖励兑换费用等。可以将发行人104、商家106、支付网络提供商或收单方建立的任何标准视为计划偏好(例如，计划奖励偏好)。

进一步参考图4，特别是在步骤405，处理服务器110基于包括上述那些的奖励计划偏好和/或一个或多个消费者来确定支付交易是否具有返利请求的资格。显而易见的是，在另一示例性的实施例中，步骤405可以位于方法中的其他位置(例如，在步骤406之后，在步骤408之后等)，或者可以不存在于该方法中。

仍然参考图4，如果基于一个或多个偏好确定交易具有返利请求的资格，则在步骤406，处理单元204可以确定该账户中是否有足够的奖励余额来为支付交易提供全部资金。步骤406可以包括基于支付交易的交易金额和一个或多个转换规则对交易返利值的计算，以及识别包括在确定的账户数据条目208中的奖励余额是否满足或超过计算的交易返利值。

如果奖励余额不足以为支付交易提供全部资金，则在步骤408，处理单元204可以例如基于包括在识别的账户数据条目208中的数据，确定是否存在与为支付交易提供部分资金的奖励账户相关联的消费者的默认批准、消费者偏好和/或计划偏好。默认批准可以由消费者偏好和/或计划偏好来指示。例如，发行者104可以在奖励余额足以为交易提供全部资金(即，完全提供资金)时选择仅允许奖励返利请求。发行者104可以选择该要求，以避免为单个支付交易执行单独的支付方式(即，利用奖励积分和利用常规的支付账户操作)，以减少与奖励积分兑换等相关的费用。在这种情况下，除非奖励余额大于或等于交易金额(或交易奖励值)，否则将不会生成奖励返利请求。消费者当前奖励积分余额的现金等价物必须大于交易金额。

备选地，计划偏好可以指示允许部分奖励余额使用。如果消费者偏好指示默认地提供部分支付，则即使奖励余额仅足以为部分支付交易金额提供资金，也可以产生奖励返利请求。即使奖金余额的现金等价物少于交易金额，仍将使用奖励余额。

如果消费者102不提供默认批准，则在步骤410，处理服务器110的发送单元206可以向消费者102发送批准请求。在一些实施例中，批准请求的通信方法可以包括在识别的账户数据条目208中。在步骤412，接收单元202可以从消费者102接收指示批准或拒绝使用奖励为支付交易部分提供资金的响应。在步骤414，处理单元204可以识别消费者响应中是否批准了使用奖励。如果没有批准使用，则可以完成该过程。

在一些实施例中，可以根据偏好以预定义的增量兑换积分。例如，如果消费者102具有10400个奖励积分，并且每个积分价值0.01美元，则通过使用转换规则，消费者的现金等价余额为104美元。如果计划增量设置为5美元，并且消费者试图购买价值136.23美元的商品，则将兑换100美元。消费者102将剩下400个积分，其金额达到4美元。消费者102将不能再次使用奖励积分，直到消费者102累积至少500个积分。此外，如果计划最小为10美元，则消费者102将无法使用奖励积分，直到消费者至少累积1000个积分。

如果消费者102在消费者响应中批准使用，或者如果消费者102默认批准使用，或者如果有足够的奖励余额为支付交易提供全部资金，则在步骤416，处理单元204可以从识别的账户数据条目208中的奖励余额中扣除相应的奖励金额。然后，在步骤418，处理单元204可以处理支付交易的返利。可以在计算返利金额时、生成对计算的返利金额的返利请求时、以及通过发送单元206将返利请求发送给支付网络108进行处理时，对返利进行处理，其中，可以基于交易奖励值、奖励扣减金额以及至少一个转换规则计算返利金额。在步骤420，发送单元206可以向消费者102发送指示对返利处理的通知。在一些情况下，通知可以包括以下中的至少一个：扣减金额、返利金额和更新的奖励余额。

发起对使用奖励账户提供资金的支付交易返利的方法

图6示出了发起对使用奖励账户提供资金的支付交易的返利的方法500。

在步骤502，多个账户数据条目(例如，账户数据条目208)可以存储在数据库(例如，账户数据库112)中，其中每个账户数据条目208包括与消费者奖励账户有关的数据，该消费者奖励账户至少包括账户标识符和奖励余额。在步骤504，接收设备(例如，接收单元202)可以接收涉及商家(例如，商家106)的支付交易的授权请求，其中授权请求至少包括支付信息和交易金额。在步骤506，处理设备(例如，处理单元204)可以至少基于交易金额和至少一个转换规则来计算交易奖励值。在一个实施例中，至少一个转换规则与以下至少一个相关联：商家106、交易金额、账户级别和商家类别。

在步骤508，处理设备204可以识别扣减金额，其中扣减金额是交易奖励值和包括在数据库112中的特定账户数据条目208中的较小者，在数据库112中包括的账户标识符对应于支付信息。在一个实施例中，每个账户数据条目208还可以包括如果奖励余额小于计算的交易奖励值是否使用相应的奖励余额的指示。在一些实施例中，包括在授权请求中的支付信息可以包括账户标识符，所述账户标识符包括在特定账户数据条目208中。

在步骤510，在数据库112中，可以基于识别的扣减金额，对包括在特定账户数据条目208中的奖励余额进行更新。在步骤512，处理设备204可以基于交易返利值和识别的扣减金额以及至少一个转换规则，计算返利金额。在步骤514，发送设备(例如，发送单元206)可以将针对计算的返利金额的返利请求从与商家106相关联的支付账户发送到与授权请求中包括的支付信息相对应的支付账户。在一些实施例中，可以将返利请求发送到支付网络(例如，支付网络108)。

在一个实施例中，方法500还可以包括：通过发送设备206向与特定账户数据条目208相关联的消费者(例如，消费者102)发送指示成功发送返利请求的通知。在另一个实施例中，方法500还可以包括：通过接收设备202接收响应于发送的返利请求而成功处理了返利的指示；以及通过发送设备206向与特定账户数据条目相关联的消费者102发送指示成功处理了返利的通知。

在一些实施例中，方法500还可以包括：当所述奖励余额小于交易奖励值时，在发送返利请求之前，通过接收设备202接收继续发送返利请求的指示。在另一个实施例中，可以响应于发送设备206将继续的请求发送到与特定账户数据条目208相关联的计算设备，而可以接收继续的指示。在另一个实施例中，继续的请求可以至少包括：包括在特定账户数据条目208中的奖励余额，并且可以通过以下方式中的至少一个来发送该请求：短消息服务消息、多媒体消息服务消息、电子邮件、以及向与支付交易相关的销售点设备的发送。

通过第三方奖励计划处理奖励的方法

在一些实施例中，与奖励账户相关的奖励余额可以由第三方(例如，航空公司、零售商等)存储。奖励账户可以包括指示与由第三方存储的奖励账户相关联的奖励余额的第三方指示符。第三方可以是保存消费者102的奖励积分余额的积分库。在这些情况下，处理服务器110可以被配置为基于涉及具有由第三方存储的奖励余额的奖励账户的支付交易的交易金额，将交易奖励值发送到第三方。交易奖励值可以指示为支付交易提供资金所需的奖励余额(例如，奖励积分、现金等价物等)的量。交易奖励值可以基于奖励计划、第三方和/或消费者配置。例如，支付服务提供商、第三方、消费者等中的任何一个都可以设置计算交易奖励值的标准。如果认为支付交易具有资格，则根据标准(例如，消费者偏好、计划偏好等)，将交易奖励值发送给第三方。

处理服务器110还可以向第三方发送支付交易信息，该支付交易信息可以包括但不限于交易位置、本地货币金额、结算货币金额、商家位置等。处理服务器110还可以发送用于计算所需积分的数量的评分规则，该评分规则可以包括每个积分的成本(例如，基本积分为100，每个积分的价值为0.01美元等)。然后，第三方处理器可以确定消费者102是否具有足够的奖励余额来完成兑换。如果消费者具有足够的奖励余额，则第三方处理器可以发送指示已经扣除了积分的消息，并且可以向消费者给出声明信用(statement credit)。第三方可以向奖励账户的发行者、支付网络提供商、商家和/或收单方发送返利请求。

图7示出了根据本公开的另一示例性实施例的、用于处理涉及具有第三方存储的奖励余额的奖励账户的支付交易的示例性系统。消费者550(例如，的消费者)在商家的销售点(POS)终端552进行购买。支付交易授权被发送到收单方554，然后发送到支付网络556。支付网络556可以链接到或包括用于在银行之间发送和接收信息的系统(例如，银行网络ASA)。然后将授权请求发送给发行者558。

将交易授权添加到由实时奖励(RTR)引擎560读取的队列中。RTR引擎560可以是支付网络556的一部分，并且可以由处理服务器实现。RTR引擎560应用可应用的过滤逻辑(包括消费者资格)，并确定需要多少积分来处理整个交易金额，或者确定如何处理部分交易金额的明细。RTR引擎560可以应用包括本文描述的任何消费者和/或计划偏好，以确定交易授权是否具有返利请求的资格。

如果根据消费者偏好和/或计划偏好，交易授权具有返利请求的资格，则RTR引擎560随后生成交易返利值(即，记分的交易结果)，其可以如本文所述那样计算(例如，基于至少一个转换规则等)。

在562，RTR引擎560随后确定与授权请求相关联的奖励账户是否是第三方奖励账户。如果奖励账户不是第三方账户，则支付交易由支付网络处理，该支付网络可以包括生成如本文所述的返利请求(例如，基于奖励交易值计算返利金额等)。

如果支付交易是针对涉及第三方的奖励账户，则RTR引擎560在即发即弃消息(fire-and-forget)中将交易返利值发送到第三方(或第三方交易处理器)。即发即弃消息通知第三方(或第三方交易处理器)为交易请求奖励返利的可能性。第三方交易处理器可以在支付网络556的内部。

第三方交易处理器调用与奖励账户相关联的发行者558的应用程序编程接口(API)，以确定交易是否应导致声明信用(即，应将奖励余额应用于交易)，以及是否应扣除必要的积分。如果奖励余额应适用于交易，则将返利发送到返利服务564，返利服务564可以是支付网络556的一部分。返利服务564将返利兑换保存在数据库中，例如，系统(MRS)数据库。然后可以结算返利，例如，批量地发送到全球清算管理系统(GCMS)。也可以将返利报告给奖励账户的发行者558，以使发行者558将返利应用于奖励账户。

如果第三方确定将支付余额应用于支付交易并发送相应的返利请求，则第三方可以基于返利请求的金额来减少与奖励账户相关的奖励余额。

图8示出了根据图7所示的系统处理支付交易的示例性的方法流程。将方法流程分为标明消费者550、支付网络(例如，商家、收单方554、可以包括银行网络(BankNet)、MRS和GCMS的支付网络556)、以及发行者558的动作。

根据该示例性的方法流程，在566，消费者550首先注册支付奖励-实时奖励(PWR-RTR)服务，此时，支付网络556将消费者注册到服务中(例如，通过创建新的奖励账户、将奖励余额和账户标识符与现有账户相关联等)。

当消费者550为了在商家购买而刷与奖励账户相关联的支付卡时，支付网络556接收到交易授权请求，并且可以将该交易授权请求存储在队列中(例如，交易授权请求副本由BankNet提供给MRS，然后MRS向BankNet确认收到交易，并存储授权交易)。

在568，支付网络556然后确定交易是否通过验证，其可以包括消费者偏好、计划偏好等。如果交易没有通过验证，则交易完成。如果交易通过验证，则支付网络556基于交易金额计算兑换积分(例如，通过基于至少一个转换规则计算交易返利值)。

在570，一旦计算了所需的兑换积分，则支付网络556接下来进行检查以查看奖励账户是否与第三方银行相关联。如果奖励账户利用第三方银行存储，则支付网络556向第三方发送外部即发即弃消息(例如，发送给第三方的消息，以使是第三方而不是支付网络556来处理进一步的奖励余额使用确定、奖励余额更新、返利请求生成等)，并且过程完成。发送的消息可以包括交易奖励值和其他交易和/或奖励账户信息。

在572，如果奖励账户不与第三方银行相关联，则支付网络556然后确定消费者的奖励账户的奖励余额是否可以支付交易的至少一部分(例如，消费者的奖励账户是否有足够的积分来支付交易的至少一部分)。如果消费者的奖励余额没有足够的积分，则可以向消费者发送指示缺少奖励积分的可选消息(例如，短消息(SMS)、电子邮件等)。

如果消费者确实具有足够的奖励余额积分来支付交易的至少一部分(或者如果不允许部分支付，但是奖励余额大于全部交易金额)，则开始兑换现金返还过程。根据方案，为交易生成返利请求文件。然后处理返利请求文件(例如，通过将文件提交到GCMS)。然后支付交易可以由支付网络556处理，并且由奖励账户的发行者558进行支付交易的结算。

计算兑换费(其可以基于返利请求的金额)并将其发送给发行者558。可以可选地将指示支付交易的状态和/或成功请求返利的兑换通知发送到消费者550。

图9示出了根据图7所示的系统来处理涉及与第三方相关联的奖励账户的支付交易的示例性的方法流程。将所示的方法流程分为在第三方的动作、在支付网络556(包括MRS服务、MRS和GCMS)的动作以及在发行者558的动作的多个动作。

在574，第三方首先处理奖励积分兑换(例如，响应于从支付网络556接收指示消费者想要使用消费者的奖励账户的奖励余额来为支付交易提供资金的消息)。第三方然后向支付网络556发送返利请求(例如，通过发起MRS返利兑换请求)。

在576，支付网络556然后处理返利请求(例如，MRS服务然后在不需要积分的现金返还过程之后开始兑换)。支付网络向第三方发送可以指示返利请求是否成功的消息。如果指示返利请求成功，则第三方流程完成(并且第三方可以相应地更新奖励余额)。如果返利请求不成功，第三方可以重复向支付网络发送返利请求的步骤。

在578，基于收到的返利请求，支付网络可以基于方案来创建返利文件。然后处理返利文件(例如，通过将文件提交给GCMS)。然后支付交易可以由支付网络556处理，并且由奖励账户的发行者558进行支付交易的结算。

计算兑换费并将其发送给与奖励账户相关联的发行者558。可以向消费者550发送可选的兑换通知。

在图8和9的流程图的框中描述了图8和9的步骤的更多细节，但是不应将其认为是对图8和9示出的示例性过程的限制。显而易见的是，在其他示例性实施例中，在不脱离本公开的范围的情况下，步骤的顺序可以变化，可以省略一些步骤，并且可以添加一些附加步骤。

计算机体系结构

图10示出了计算机系统600，其中本公开的实施例或其部分可以实现为计算机可读代码。例如，图1的处理服务器110可以使用硬件、软件、固件、具有存储在其上的可执行指令的非暂时性计算机可读介质或上述的组合在计算机系统600中实现，并且可以在一个或多个计算机系统或其他处理系统中实现。硬件、软件、或其任何组合可以包括用于实现图3-5的方法的模块和组件。

如果使用可编程逻辑，则可以在市售的处理平台或专用设备上执行该逻辑。本领域普通技术人员可以理解，所公开的主题的实施例可以利用各种计算机系统配置来实施，所述各种计算机系统配置包括多核多处理器系统、小型计算机、大型计算机，与分布式功能元件链接或集群的计算机、以及可虚拟地嵌入任何设备的普及式或微型计算机。例如，至少一个处理器设备和存储器可用于实现上述实施例。

本文所讨论的处理器单元或设备可以是单个处理器、多个处理器或其组合。处理器设备可以具有一个或多个处理器“内核”。本文所讨论的术语“计算机程序介质”，“非暂时性计算机可读介质”和“计算机可用介质”一般用于指有形介质，例如，可移动存储单元618、可移动存储单元622和安装在硬盘驱动器612中的硬盘。

根据该示例性计算机系统600描述了本公开的各种实施例。在阅读本说明书之后，如何使用其他计算机系统和/或计算机架构来实施本公开，对相关领域的技术人员来说将变得显而易见。虽然可以将操作描述为顺序过程，但是一些操作实际上可以并行的、并发的、和/或在分布式环境中执行，并且程序代码本地或远程地存储以由单处理器或多处理器机器访问。此外，在一些实施例中，在不脱离所公开的主题的精神的情况下，可以重新排列操作顺序。

处理器设备604可以是专用或通用处理器设备。处理器设备604可以连接到通信基础设施606，例如总线、消息队列、网络、多核消息传送方案等。网络可以是适于执行本文所公开的功能的任何网络，并且可以包括局域网(LAN)、广域网(WLAN)、无线网络(例如，WiFi)、移动通信网络、卫星网络、因特网、光纤、同轴电缆、红外线、射频(RF)或其任何组合。其他合适的网络类型和配置对相关领域的技术人员来说将是显而易见的。计算机系统600还可以包括主存储器608(例如，随机存取存储器、只读存储器等)，并且还可以包括辅助存储器610。辅助存储器610可以包括硬盘驱动器612和可移动存储驱动器614，例如软盘驱动器、磁带驱动器、光盘驱动器、闪存等。

可移动存储驱动器614可以以公知的方式从可移动存储单元618读取和/或写入可移动存储单元618。可移动存储单元618可以包括可由可移动存储驱动器614读取和写入的可移动存储介质。例如，如果可移动存储驱动器614是软盘驱动器，则可移动存储单元618可以是软盘磁盘。在一个实施例中，可移除存储单元618可以是非暂时性计算机可读记录介质。

在一些实施例中，辅助存储器610可以包括用于允许将计算机程序或其他可执行指令加载到计算机系统600中的替代装置，例如，可移动存储单元622和接口620。这种装置的例子可以包括程序盒和盒式接口(例如，在视频游戏系统中发现的)、可移动存储器芯片(例如，EEPROM、PROM等)和相关的插口、以及对相关领域技能的人员来说将显而易见的其他可移动存储单元622和接口620。

存储在计算机系统600(例如，主存储器608和/或辅助存储器610)中的数据可以存储在任何类型的合适的计算机可读介质上，例如，光存储器(例如，光盘、数字通用光盘、蓝光光盘等)或磁带存储器(例如，硬盘驱动器)。可以以任何类型的合适的数据库配置(例如，关系数据库、结构化查询语言(SQL)数据库、分布式数据库、对象数据库等)对数据进行配置。合适的配置和存储类型对于相关领域技术人员来说将是显而易见的。

计算机系统600还可以包括通信接口624。通信接口624可以被配置为允许在计算机系统600和外部设备之间传送软件和数据。示例性的通信接口624可以包括调制解调器、网络接口(例如，以太网卡)、通信端口、PCMCIA插槽和卡等。通过通信接口624传送的软件和数据可以是信号的形式，其可以是电子、电磁、光或对相关领域的技术人员来说将显而易见的其他信号。信号可以经由通信路径626行进，通信路径626可以被配置为携带信号，并且可以使用金属线、电缆、光纤、电话线、蜂窝电话链路、射频链路等来实现。

计算机程序介质和计算机可用介质可以指可以是存储器半导体(例如，DRAM等)的存储器，例如，主存储器608和辅助存储器610。这些计算机程序产品可以是用于向计算机系统600提供软件的装置。计算机程序(例如，计算机控制逻辑)可以存储在主存储器608和/或辅助存储器610中。也可以通过通信接口624接收计算机程序。当计算机程序被执行时，可以使计算机系统600能够实现本文所讨论的方法。特别地，当计算机程序被执行时，可以使处理器设备604能够实现如本文所讨论的图3-4、6和8-9所示的方法。因此，该计算机程序可以表示计算机系统600的控制器。

在使用软件实现本公开的情况下，可利用可移动存储驱动器614、接口620和硬盘驱动器612或通信接口624将软件存储在计算机程序产品中并加载到计算机系统600中。

除了其他特征之外，与本公开一致的技术还提供用于发起对使用奖励账户提供资金的支付交易的返利的系统和方法。虽然上文已经描述了所公开的系统和方法的各种示例性实施例，但是应当理解，它们仅仅是为了示例的目的，而不是限制。其不是详尽的，并且不将本公开限制到所公开的精确形式。在不脱离本公开的广度或范围的情况下，修改和变化可以根据上述教导获得，或者可以通过实践本公开获得。

如将基于前述说明书所理解的，本公开的上述实施例可以使用包括计算机软件、固件、硬件或其任何组合或子集的计算机程序或引擎技术来实现，其中，可以通过执行以下步骤中的至少一个来实现技术效果：(a)接收涉及奖励账户的支付交易的授权请求，其中所述授权请求至少包括交易金额，(b)基于奖励偏好确定支付交易是否有资格获得奖励返利，(c)在支付交易具有资格时，发送奖励返利的请求，(d)至少根据交易金额和至少一个转换规则，计算交易奖励值，(e)基于交易奖励值和奖励余额中的较小者计算返利金额，(f)基于返利金额更新奖励余额，(g)将交易奖励值和支付交易信息发送给第三方。

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

Claims (21)

1.一种向奖励账户发起返利的计算机实现方法，所述奖励账户与数据库中的账户数据条目相关联，所述账户数据条目至少包括所述奖励账户的账户标识符、奖励余额和奖励偏好，所述方法包括：

通过处理服务器接收涉及所述奖励账户的支付交易的授权请求，其中所述授权请求至少包括交易金额；

在处理服务器处，基于所述奖励偏好确定所述支付交易是否具有奖励返利的资格；以及

当所述支付交易具有资格时，从所述处理服务器发送奖励返利的请求。

2.根据权利要求1所述的方法，还包括：

至少基于交易金额和至少一个转换规则，通过所述处理服务器计算交易奖励值；以及

基于所述交易奖励值和所述奖励余额中的较小者，通过所述处理服务器计算返利金额。

3.根据权利要求2所述的方法，还包括：

基于所述奖励金额，在所述数据库中更新所述奖励余额；以及

其中，发送所述奖励返利的请求包括：当所述支付交易具有所述奖励返利的资格时，基于计算的返利金额发送奖励返利的请求。

4.根据权利要求1所述的方法，其中，所述奖励偏好包括消费者奖励偏好；并且其中，所述消费者奖励偏好包括以下中的至少一个：仅为下一个交易请求奖励返利的偏好、以及仅为高于消费者最小购买金额的交易请求奖励返利的偏好。

5.根据权利要求4所述的方法，还包括：当所述消费者奖励偏好包括仅针对下一个交易请求奖励返利的偏好时，在发送所述返利请求后，自动地将所述消费者奖励偏好改变为对任何交易都不请求奖励返利的偏好。

6.根据权利要求4所述的方法，其中，所述奖励偏好包括与所述奖励账户有关的至少一个计划奖励偏好；以及

其中确定支付交易是否具有资格包括：基于所述计划奖励偏好和所述消费者返利偏好，确定所述支付交易是否具有奖励返利的资格。

7.根据权利要求6所述的方法，其中，所述计划奖励偏好包括以下中的至少一个：仅当所述交易金额高于计划的最小金额时才允许奖励返利的请求的偏好、仅当所述奖励余额足以为所述交易完全提供资金时才允许奖励返利的请求的偏好、以及当所述奖励余额不够为所述交易完全提供资金时允许奖励的请求的偏好。

8.根据权利要求7所述的方法，其中，发送奖励返利的请求包括：当所述计划奖励偏好包括允许为部分交易请求奖励返利的奖励偏好时，基于所述奖励余额发送针对返利金额的奖励返利请求。

9.根据权利要求1所述的方法，还包括：

通过所述处理服务器接收至少一个消费者奖励偏好的消费者选择；以及

基于接收到的消费者选择，更新所述数据库中的账户数据条目中的奖励偏好。

10.根据权利要求9所述的方法，还包括：

使界面显示在消费者计算机系统上，所述界面提供多个可选择的消费者奖励偏好；以及

其中接收所述消费者选择包括：通过所述界面从所述消费者计算机系统接收所述多个可选择的消费者奖励偏好中的至少一个的选择。

11.根据权利要求1所述的方法，还包括：

至少基于交易金额和至少一个转换规则，通过所述处理服务器计算交易奖励值；以及

当与所述奖励账户有关的奖励余额存储在第三方时，通过所述处理服务器将所述交易奖励值和支付交易信息发送给第三方，从而允许所述第三方管理所述奖励余额。

12.一种用于处理涉及奖励账户的支付交易的系统，所述系统包括：

包括账户数据库的处理服务器，所述账户数据库包括多个账户数据条目，每个账户数据条目至少包括账户标识符和消费者奖励偏好；

其中所述处理服务器包括指令，当所述处理服务器执行所述指令时，所述指令使所述处理服务器执行以下操作：

接收涉及奖励账户的支付交易的授权请求，所述支付交易具有交易金额；以及

基于消费者奖励偏好，确定所述支付交易是否具有奖励返利的资格。

13.根据权利要求12所述的系统，其中，所述账户数据条目包括第三方指示符，所述第三方指示符指示与所述奖励账户有关的奖励余额是否由第三方存储；以及

其中当所述处理服务器执行所述指令时，所述指令进一步使所述处理服务器来：

至少基于交易金额和至少一个转换规则，计算交易奖励值；以及

当所述第三方指示符指示所述奖励余额由第三方存储时，将所述交易奖励值发送给所述第三方。

14.根据权利要求12所述的系统，其中，所述消费者奖励偏好指示最小购买金额；以及

其中，所述处理服务器执行所述指令时，所述指令使所述处理服务器来：

确定所述交易金额是否至少是最小购买金额；以及

如果所述交易金额至少为最小购买金额，则：

至少基于交易金额和至少一个转换规则，计算交易奖励值；

基于所述交易奖励值和与所述奖励账户有关的奖励余额中的较小者，计算返利金额；以及

基于所述返利金额更新所述奖励余额，其中，所述奖励返利的金额基于计算的返利金额。

15.根据权利要求12所述的系统，其中，所述指令能由所述处理服务器执行，以当所述交易具有资格时使所述处理服务器请求奖励返利。

16.根据权利要求12所述的系统，其中，所述消费者奖励偏好指示以下中的至少一个的奖励偏好：仅为下一个交易请求奖励返利、以及仅为高于消费者最小购买金额的交易请求奖励返利。

17.根据权利要求12所述的系统，其中，当所述处理服务器执行所述指令时，所述指令使所述处理服务器基于所述消费者奖励偏好和计划奖励偏好来确定所述支付交易是否具有奖励返利的资格。

18.根据权利要求17所述的系统，其中，所述计划奖励偏好指示以下中的至少一个的偏好：仅当所述交易超过计划最小金额时才允许请求奖励返利、仅当所述奖励账户的奖励余额足以为所述交易完全提供资金时才允许请求奖励返利、以及当所述奖励余额不够为所述交易完全提供资金时允许请求奖励返利。

19.一种包括指令的非暂时性计算机可读介质，当至少一个处理器执行所述指令时，所述指令使所述处理器：

接收与奖励账户相关联的消费者奖励偏好，所述消费者奖励偏好指示何时应当为涉及所述奖励账户的支付交易请求奖励返利，

接收涉及所述奖励账户的支付交易的授权请求，所述支付交易包括交易金额；以及

基于消费者奖励偏好，确定所述支付交易是否具有奖励返利请求的资格。

20.根据权利要求19所述的非暂时性计算机可读介质，其中，所述消费者奖励偏好包括仅为下一个交易请求奖励返利的偏好。

21.根据权利要求19所述的非暂时性计算机可读介质，其中，当所述处理器执行所述指令时，所述指令使所述处理器：

基于所述消费者奖励偏好和计划奖励偏好，确定所述支付交易是否具有奖励返利请求的资格；以及

当所述支付交易具有所述返利请求的资格时，发送所述奖励返利请求；

其中，所述计划奖励偏好包括：当所述交易金额高于计划的最小金额时才允许奖励返利请求的偏好和/或当所述奖励余额不够为所述交易完全提供资金时允许奖励返利请求的偏好。