CN103765861B - 移动设备的支付选择和授权 - Google Patents

Abstract

当使用电子支付类型进行支付时，用户可通过与所述用户的移动计算设备的通信来提供另外的所有权验证。例如，所述用户可在零售商的商店刷她的银行卡。所述零售商可通过发行方（“主机”）授权所述银行卡。所述主机可通过在所述移动计算设备上运行的移动应用程序把请求发送到所述用户，所述请求可请求所述用户批准或拒绝所述采购请求。在各种实施方案中，所述主机的请求可要求所述用户通过所述移动应用程序输入个人和/或授权信息（例如，PIN、密码、生物特征识别等）以批准所述请求。在一些方面，所述主机可允许所述用户在所述用户在所述授权过程期间通过所述移动应用程序从所述主机可用的一个或多个电子支付类型上分割或分配支付金额。

Description

移动设备的支付选择和授权

相关申请案

本PCT申请请求2011年6月27日提交的题为“Payment Selection andAuthorization by a Mobile Device”的美国专利申请no.13/170,144的权益。美国专利申请no.13/170,144以引用的方式全部并入本文。

本PCT申请请求2011年6月27日提交的题为“Payment Selection andAuthorization”的美国专利申请no.13/170,121的权益。美国专利申请no.13/170,121以引用的方式全部并入本文。

发明背景

大多数商户允许客户用信用卡、借记卡和其它类型的银行卡或电子帐户（例如，礼品卡等）来进行支付。当客户使用这些类型的支付类型来实现支付请求时，商户通常执行验证过程。验证过程常电子发生在从卡读取标识符（例如，通过刷卡器、射频标识符（RFID）读卡器、微芯片读卡器等）之后。验证过程常联系卡的发行人或发行人的代表以决定是否批准采购请求的请求金额。

一些支付类型使用个人识别号（PIN）或其它密码以防止未经授权使用支付类型。例如，在销售点（POS），用户可使用刷卡器来刷她的借记卡，然后在读卡器的键盘上输入相关PIN。读卡器和键盘通常暴露给包括职员的其他人看到，因此潜在影响PIN的保密性。在一些实例中，例如在自动取款机，键盘至少部分被罩子覆盖以防止或限制其他用户看到键盘。

通常，人们有多种支付类型，例如许多信用卡、借记卡、礼品卡和其它卡或支付类型。钱包里携带多张卡可能不方便。另外，如果所述许多卡丢失、放错了地方，或被盗，那么一次携带多张卡给个人造成极大的风险和/或不便。

附图简述

参看附图描述了具体实施方式。在附图中，参考数字的最左边的数字指示所述参考数字首次出现在哪个附图中。不同的附图中的相同的参考数字指示相似或相同的项目。

图1是提供移动支付选择和授权的说明性计算环境的示意图。

图2a-2c是图1的计算环境中包括的各种组件的说明性计算架构的方块图。

图3是使用移动设备应用程序来授权支付的说明性过程的流程图。

图4是示出来自图1示出的计算环境的各种行动者之间的互动的说明性过程的流程图。

图5是在支付授权期间选择电子支付类型的说明性过程的流程图。

图6是开始支付请求的软拒绝的说明性过程的流程图。

图7是选择授权类型以供移动设备应用程序使用的说明性过程的流程图。

图8是使得能够进行支付选择和授权的说明性用户界面（UI）。

图9是使得能够管理来自主机的授权消息的说明性UI。

具体实施方式

概述

本揭露提供当使用例如信用卡、借记卡、礼品卡的电子支付类型或其它类型的电子支付时增强安全性、隐私和方便的技术和系统。当使用电子支付类型进行支付时，用户可通过与用户的移动计算设备（例如，手机、平板计算机等）的通信来提供另外的所有权验证。例如，用户可在零售商的商店输入或刷她的信用卡（亲自或在线）。零售商然后可通过网关处理信用卡信息以验证卡是否有效、是否有足够的资金，和/或其它原因。网关可把请求转发到发行方（“主机”）。根据各种实施方案，主机可通过在移动计算设备上运行的移动应用程序把请求发送到用户，所述请求可要求用户批准或拒绝采购请求。在各种实施方案中，主机的请求可要求用户通过移动应用程序输入个人和/或授权信息（例如，PIN、密码、生物特征识别等）以批准请求。

在一些实施方案中，主机可管理用户的许多电子支付类型。主机可允许用户在用户在授权过程期间通过移动应用程序从主机可用的各种电子支付类型上分割或分配支付金额。例如，用户可从主机接收请求，选择与最初向商户提供的卡不同的卡，然后接受支付请求。从商户的观点来看，支付可使用商户接收的支付类型来处理并开始所述过程。然而，主机可使用用户通过移动应用程序选择的支付类型来向商户提供实际支付。

本文所述的技术和系统可用若干方式来实施。下文参看以下附图提供了示范性实施。

说明性环境

图1是提供移动支付选择和授权的说明性计算环境100的示意图。环境100包括与商户104互动的用户102。商户104可具有实体位置和/或用户102可通过一个或多个网络106访问的电子交易市场。例如，电子交易市场可能是使用户102能够采购商品和/或服务或允许用户浏览出售、出租、租赁或者商户104提供的物品的基于目录服务的网站。

商户104可使用电子支付类型（EPT）108接受来自用户102的支付且也可接受其它支付类型（例如，现金、个人支票、汇票等）。EPT108是可包括例如信用卡和借记卡的银行卡，以及礼品卡、储值卡，或任何其它类型的电子支付的支付工具。EPT108可通过下文讨论的一系列的事件来处理，以使得用户102能够使用移动计算设备110（“用户设备”）来授权EPT108的使用。用户设备110可能是移动电话、智能手机、平板计算机、笔记本计算机、上网本、个人数字助理（PDA）、游戏设备、媒体播放器，或包括与网络106的连接且使得能够进行用户输入的任何其它移动计算设备。

在通过商户104的销售点（POS）系统112和/或商户服务器114从用户102接收到EPT108之后，商户可把授权请求116发送到网关118。网关118可为商户104的代表金融机构和/或把请求116从商户路由到主机120的路由实体，主机120是把EPT108发行给用户102且/或管理用户的EPT108的帐户的一方。

根据一个或多个实施方案，主机120包括主机服务器122，主机服务器122可接收请求116、处理所述请求，然后把修改的请求124发送到与用户102相关的用户设备110。在处理期间，主机服务器122可从主机120维护的帐户数据126检索关于EPT108的信息。帐户数据126可包括用于创建修改的请求124、用户102的选择、用户的可用电子支付类型、存储的用户偏好，和关于EPT108和/或用户102的其它数据的规则，所述规则可用以创建修改的请求124。

通常在商户104接收EPT108的标识符后不久，用户设备110可接收修改的请求124。修改的请求可由用户设备110使用不同于用以把EPT108发送到商户104的通信路径的通信路径来接收。修改的请求124可由在用户设备110上运行允许用户102使用用户界面128接收信息并接受或拒绝修改的请求124和其它可能选择的支付应用程序来处理。支付应用程序可产生扩展回答130（即，响应），扩展回答130被再次使用不同于用以把EPT108发送到商户104的通信路径的通信路径来发送回主机服务器122。扩展回答130可包括接受、特殊代码（例如，个人识别号（PIN）、密码或其它个人信息），和可能与指定电子支付类型相关的选择（例如，选择使用哪个EPT来满足修改的请求124）。主机120可验证扩展回答130中的信息，例如验证PIN是否正确且用户接受请求116。主机服务器122然后可把回答132发送到网关118，回答132可在相当短的时间量之后被转发到商户服务器114和/或商户104的POS系统112。与扩展回答130不同，回答132可包括较少信息且主要涉及接受或拒绝支付请求116而不是包括针对主机120的特殊代码或其它信息。

通过结合用户设备110使用EPT，用户102可体验更大的安全性以防止滥用他们的EPT。例如，如果EPT108（或EPT108的标识符）被盗且用以从商户104或使用上述技术的其它商户采购物品，那么用户102可简单拒绝采购请求以防止骗购。在修改的请求询问PIN或其它特殊代码的情况下，即使小偷（或其它未经授权人员）处理用户设备110，用户102也可防止未经授权使用。另外，通过使用用户设备110来输入安全代码，例如当用户经受骗局（例如，卡盗用、假PIN键盘等）而与自动取款机互动时，盗窃安全代码可能更困难。

在一些实施方案中，商户104可直接与主机120通信且/或主机120可执行网关118的一些或所有操作。因此，在一些实施方案中，环境100可能不包括网关118而不会影响本文所述的技术。

网络106可包括使得能够在环境100中所述各种计算设备之间进行快速通信的有线和/或无线网络。在一些实施方案中，网络可包括局域网（LAN）、广域网（WAN）、移动电话网络（MTN），和其它类型的网络，所述网络可能彼此结合使用以促进各种计算设备（即，商户服务器114、主机服务器122和用户设备110）之间的通信。参看以下附图更详细描述了所述计算设备。

图2a-2c示出了图1的计算环境中包括的各种计算设备的说明性计算架构。

图2a示出了商户服务器114、POS系统112或两者的说明性计算架构。所述架构可包括处理器202和存储器204。存储器204可存储各种模块、应用程序、程序或其它数据。存储器204可包括当被处理器202执行时使处理器执行本文所述的商户104的操作的指令。在一些实施方案中，存储器204可存储交易管理器206和授权模块208，授权模块208可能是交易管理器的部分或与交易管理器分开。交易管理器206可处理与用户102的交易并接收EPT108。授权模块208可通过网关118或直接通过如上所述的主机120来授权EPT108以决定如回答132所指示是否批准EPT。在一些实施方案中，交易管理器206、授权模块208或每个的部分可分布在例如POS系统112和商户服务器114的多个计算系统上。

图2b示出了主机服务器122的说明性计算架构。所述架构可包括处理器210和存储器212。存储器212可存储各种模块、应用程序、程序或其它数据。存储器212可包括当被处理器210执行时使处理器执行本文所述的主机120的操作的指令。在一些实施方案中，存储器212可存储帐户管理器214和授权管理器216。帐户管理器214可管理存储各种规则、设置、EPT和与主机120有帐户的每个用户的其它数据的帐户数据126。授权管理器216可可能通过网关118处理来自商户104的通信，以至少部分基于与用户设备110的用户互动来接受或拒绝支付请求。

图2c示出了用户设备110的说明性计算架构。所述架构可包括处理器218和存储器220。存储器220可存储各种模块、应用程序、程序或其它数据。存储器220可包括当被处理器218执行时使处理器执行本文所述的用户102的操作的指令。在一些实施方案中，存储器220可存储可与主机服务器122的授权管理器216和/或帐户管理器214互动的支付应用程序222。支付应用程序222还可包括验证模块224、条件模块226和选择模块228。依次讨论每个模块。

根据各种实施方案，验证模块224可基于从主机服务器122的授权管理器216接收的修改的请求124来决定是否产生授权的安全代码请求（例如，UI等）。当被主机服务器122（或可能支付应用程序222）请求时，验证模块224可要求用户输入例如PIN、密码、生物特征识别数据或其它个人信息的安全代码，以接受源自商户104且通过主机服务器122发送的支付请求。

条件模块226可提供关于用户设备110的信息、应用用于安全代码的条件且/或提供对修改的支付请求124的自动批准或拒绝，或其它涉及其它类型的信息。例如，授权管理器216可请求用户设备110的位置，所述位置可使用全球定位系统（GPS）、三角测量或其它信息来提供。当所述信息匹配商户的位置、用户102的已知位置（例如，在家里、在工作等），或另一指定或已知位置时，授权管理器216可调整用户要求的响应以接受支付（例如，删除安全代码的要求等）。

选择模块228可使得用户102能够选择支付并把支付分配在用户可用且存储在帐户数据126中的其它EPT之间。例如，帐户数据126可包括用户的许多不同类型的EPT之间的相关性，当向商户104提供任一EPT时，可访问所述相关性。主机然后可通过使用通过选择模块228选择的EPT来由商户104实现支付请求116。用户102可基于百分比、支付金额或其它分配来在多个EPT之间分配资金。

说明性操作

图3是使用移动设备应用程序来授权支付的说明性过程300的流程图。过程300示出为逻辑流图中的许多方块，所述方块代表可在硬件、软件或它们的组合中实施的操作的顺序。在可执行方块中所述各种操作的各自的实体下组织所述许多方块。在软件上下文中，方块代表存储在一个或多个计算机可读存储介质上的计算机可执行指令，当所述计算机可执行指令被一个或多个处理器执行时，执行详述操作。通常，计算机可执行指令包括执行特定功能或实施特定抽象数据类型的例程、程序、对象、组件、数据结构等。描述操作的顺序不欲理解为限制，且任意数量的所述块可用任何顺序和/或并联相结合来实施过程。应相应地理解除过程300之外的本揭露所述的其它过程。

参看环境100描述了过程300，且过程300可由用户设备110与主机服务器122、POS系统112和/或商户服务器114中的一个或多个合作来执行。当然，过程300（和本文所述的其它过程）可在其它类似和/或不同环境中执行。

在302，用户102可使用EPT108向商户104提供支付。例如，用户102可在实体位置与商户104互动并把EPT直接提交给商户104。用户也可通过可使用网络106访问的电子交易市场与商户104互动。在一些实例中，用户可使用用户设备110通过浏览器或应用程序转账EPT108。

在304，用户设备110可使用支付应用程序222来接收请求（即，修改的请求124）以授权采购，所述请求可从商户服务器114路由通过网关118和/或主机服务器122而到达用户设备110。支付应用程序222可能不同于可用以把EPT108传递到商户（例如，通过浏览器等）的应用。请求可包括另外的信息，例如，代码要求、可用电子支付类型、请求的细节，例如欠款、交易中包括的物品等。

在306，支付应用程序222可至少部分基于使用用户设备110提供的来自用户102的输入来决定授权或拒绝支付。当在308（沿着“否”路线）用户102决定拒绝支付时，支付应用程序222可把响应发送到主机服务器122以拒绝支付。然而，当用户决定授权支付请求（从决定操作306沿着“是”路线）时，过程300可在310继续。

在310，支付应用程序222可对请求产生响应（或回答）。响应可包括选择一个或多个EPT（包括或不同于操作302中使用的EPT），所述EPT可由选择模块228收集且/或处理。响应也可包括代码，例如，PIN、密码、生物特征识别传感数据，或可由验证模块224收集且/或处理的其它个人信息。在一些实例中，当用户102希望拒绝支付请求时，响应可包括拒绝命令。响应也可包括可由条件模块226收集且/或处理的条件信息，例如用户设备110的位置。

在312，支付应用程序可把响应和相关信息发送到主机120的主机服务器122。当响应正确时，例如，当响应满足来自主机120的请求中包括的代码和/或条件要求时，主机服务器122然后可把响应中继到网关118且/或中继到商户104。

图4是示出来自图1示出的环境100的各种行动者之间的互动的说明性过程400的流程图。过程400中示出的操作在可执行各自的操作的实体下示出；然而，在其它配置中，操作可至少部分由其它实体执行。例如，商户服务器114下指定的一些或所有操作可由POS系统112执行。操作可包括加密/解密数据以实现在每个实体之间发送的信息的安全性。

在402，商户服务器114可通过EPT108从用户102接收支付。

在404，商户服务器114可请求对在操作402接收的支付的授权以验证资金、认证电子支付类型，或用于其它原因。

在406，可能是商户104或另一实体的代表金融机构的网关118可识别发行方（即，主机120）以授权支付。

在408，通过帐户管理器214，主机服务器122可决定与来自操作404和406的授权消息和支付相关的用户102。主机服务器122可通过帐户数据126将EPT108的标识号与用户102匹配。

在410，主机服务器122可决定授权参数。授权参数可基于授权规则，例如自动授权的采购（例如，白名单、在预定金额下等），或者处理支付请求的授权的特定要求（例如，除了接受以外是否需要安全代码等）。

在412，主机服务器122可决定用户是否有资格使用EPT108。例如，主机服务器122可决定用户的帐户是否具有必需的资金来满足支付，且/或主机服务器可执行各种欺诈检查以决定所述请求是否由于欺诈风险而应被拒绝。当主机服务器122决定用户有资格使用所述EPT或其它EPT且/或欺诈风险是可接受的（小于阈值分数等）时，处理可在414继续。

在414，当需要授权时，通过授权管理器216，主机服务器122可把修改的请求（例如，修改的请求124）发送到与用户102相关的用户设备110。在一些实例中，用户102可委托例如家庭成员、业务伙伴、同事、朋友等的其他人来进行授权或采购（使用EPT）。因此，操作用户设备110的用户102可能不一定是向商户104提供EPT108的用户。

在416，通过支付应用程序222，用户设备110可处理包括授权参数的授权消息。例如，支付应用程序222可通过验证模块224决定是否请求代码、使用条件模块226决定条件（例如，用户设备的位置等），或者在向用户102提供请求之前或期间执行其它可能的操作。另外，通过支付应用程序222，用户设备110可使得用户102能够选择其它或另外的EPT来实现使用选择模块228在操作402开始的采购。

在418，用户设备110可把响应（回答）发送回主机服务器122。响应可包括接受或拒绝、代码、指定EPT和条件信息中至少一个或多个。

在420，通过授权模块216，当用户接受支付时，主机服务器420可验证响应。例如，授权模块216可验证代码正确、满足条件等，这些可使用帐户数据126来执行。

在422，授权模块216可决定响应是否被授权（即，被接受且正确）、用户102是否具有足够的资金来进行支付，和支付是否可能是欺诈性的。当响应被从用户授权且信息（例如，代码、条件等）正确时，或者当决定操作414不需要授权时，且当足够的资金可用且欺诈风险很低（例如，小于阈值分数等）时，接受响应可在424被发送到商户服务器114，所述接受响应可在426通过网关转发。当用户102拒绝响应、用户缺少足够的资金，且/或欺诈风险高时，拒绝（谢绝）响应可在428被发送到商户服务器114，所述拒绝响应可在430通过网关转发。当在用户102通过用户设备110进行授权通信之前主机服务器122基于预定因素决定用户的帐户缺少足够的资金且/或支付可能是欺诈性的时，支付也可沿着决定操作414的路线“否”被拒绝。

图5是在支付授权期间选择EPT的说明性过程500的流程图。虽然过程500描述为由用户设备110通过下文讨论的支付应用程序222执行，但是例如当基于帐户数据126中存储的规则选择决定时，过程500也可通过帐户管理器214部分或全部由主机服务器122执行。

在502，支付应用程序222可接收授权消息。授权消息可包括欠款、条件、代码要求和/或其它信息。

在504，支付应用程序222的选择模块228可提供EPT以供用户102选择，所述EPT可不同于提供到商户104（例如，在操作302）的EPT108。

在506，选择模块228可接收EPT的选择以满足欠款的至少一部分。

在508，选择模块228可接收与在操作506选择的EPT相关的金额（或百分比等）。

在510，选择模块228可决定用户102是否将使用或选择另外的EPT。例如，如果在操作508进行选择之后仍有欠款，那么用户102可能被提示来输入另一EPT和/或另一金额，这样可能沿着“是”路径把过程导引回操作506（或操作508）。

当从操作510沿着“否”路径将使用其它EPT时，支付应用程序222可在512把授权发送到主机以实现来自操作502的授权消息。

在各种实施方案中，支付应用程序222可从主机服务器122征求金融信息（例如，余额信息等）以尝试防止透支或通过EPT的信用额度。当支付应用程序222决定有可能透支时，支付应用程序可在决定操作510提示用户和/或请求使用另一EPT。

在一些实施方案中，帐户数据126可包括为用户选择EPT的特定规则。例如，帐户数据126可包括对于特定商户使用特定EPT的规则。特定EPT可为对于特定商户包括另外的奖励（积分、里程等）的信用卡。这些规则可由用户创建、从用户102的历史交易中开采，或者为用户而创建。在一些实施方案中，首选EPT（或可能多个EPT）可由帐户管理器214为用户而预选且例如通过预选择过程通过支付应用程序222而经受用户的确认。

图6是开始支付请求的软拒绝的说明性过程600的流程图。当在灯火管制时间（例如，深夜等）请求授权过程时且/或当用户102不响应请求时，可使用软拒绝。过程600可由主机服务器122执行；然而，其它实体或计算设备也可用以实施过程。

在602，主机服务器122可接收请求以授权源自商户104且可能通过网关118中继的采购。

在604，通过授权管理器216，主机服务器122可决定是否存在使得能够自动回复采购请求而无需通过用户设备110与用户102通信的规则。例如，授权管理器216可使用帐户管理器214提供的信息来决定帐户数据126中存储的决定是否自动回复请求的设置或规则。所述规则可指示自动批准某些采购金额（例如，在类别、商户的阈值金额下，或通常等），这可产生自动接受而无需通过用户设备110与用户102互动。所述规则也可黑名单一些采购，所述一些采购可产生自动拒绝而无需通过用户设备110与用户102互动。当如决定操作604所决定，请求没有资格进行自动回复时，处理可在606继续。

在606，授权管理器216可决定请求是否可可能根据帐户数据126中存储的规则或设置来通过用户设备110发送到用户102。例如，用户102可决定灯火管制某段时间以免接收到授权消息，例如深夜到清晨（或其它日子、时间等）。当授权管理器216决定灯火管制这个时间时，授权管理器可在608发出软拒绝，所述软拒绝可充当对在602接收的请求的暂时拒绝。在这种情况下，主机服务器122可在610执行延迟，且可再次决定（在延迟之后）灯火管制时间是否已过去。

当在606没有灯火管制（沿着“否”路线）时，处理可在612继续。在612，通过授权管理器216，主机服务器122可通过支付应用程序222的用户设备110把请求发送到用户102。

在614，主机服务器122可决定是否在预定时间量内从用户102接收到响应。当在预定时间量内接收到响应时，在616（可能在操作614决定之前）接收响应，然后所述响应被转发到商户104（可能通过网关118）。

然而，当在614没有在预定时间量内接收到响应（沿着“否”路线）时，通过授权管理器216，主机服务器122可在620应用规则以在622决定是否尝试再次联系用户。例如，规则可指示主机120批准来自批准商户、达到预定金额，和/或基于其它标准的支付请求。类似地，规则也可指示主机120由于规则中指定的各种原因而拒绝支付。规则也可指示主机120的在决定操作622决定不再尝试之前执行的若干尝试。当授权管理器216在决定操作622再次尝试时，处理可在操作608通过发出软拒绝重新开始，然后在操作610进行到通过延迟，如上文所讨论且图5中示出。

当在操作622的决定是不再尝试时，例如当根据规则或由于规则中包括的其它原因而达到或超过极限时，授权管理器216可使用来自操作620的规则来决定响应，以实现支付请求或拒绝支付请求。所述响应然后在618可可能通过网关118被转发到商户。

图7是选择授权类型以供移动设备应用程序使用的说明性过程700的流程图。过程700可由主机服务器122执行；然而，其它实体或计算设备也可用以实施过程。过程700可与驻留在用户设备110上的支付应用程序222的条件模块226合作操作。如下文所讨论，参照与用户设备110的位置相关的条件描述了过程700；然而，其它条件也可使用过程700来实施。

在702，主机服务器122可接收授权采购的请求。

在704，主机服务器122可决定授权是否受例如用户设备110相对于商户104的位置的位置的条件限制。当授权在决定操作704沿着“是”线路受条件限制时，处理可在706继续。

在706，主机服务器122可通过条件模块226请求用户设备110的位置，条件模块226可例如通过用户设备110中的GPS接收器来获得位置（或其它信息）。

在从用户设备110接收到条件信息之后，在708，主机服务器122可把用户设备110的位置与商户104的位置或者与用户102相关的已知位置（例如，用户家中、办公室、经常去的位置等）作比较。在710，主机服务器122可基于比较决定设备的位置是否匹配商户的位置或已知位置。非匹配可在712记录而匹配可在714记录。

在716，通过授权管理器216，主机服务器122可决定授权要求。在一些实施方案中，授权可基于结果（即，操作712和714）。决定可包括其它相关因素。例如，相关因素可包括支付是否用于远程交易（例如，在线、基于电话等）或者实体位置中的公平交易。在后一种情况下，用户设备的位置和商户的位置相匹配（操作714）可减少授权过程（简化或没有）。在前一种情况（远程交易）下，用户设备110的位置可与已知和/或频繁位置（家里、工作地点、学校等）作比较，所述比较然后可用以选择授权过程。例如，当用户设备110位于未知位置（例如，不在家等）时，可使用更困难的授权过程（例如，包括代码请求）。

在718，通过授权管理器216，主机服务器122可把授权消息发送到用户设备。

在720，通过授权管理器216，主机服务器122可接收并验证响应。当在722响应被批准且正确（例如，接收正确的代码（如果请求）等）（沿着“是”路线）时，主机服务器122可在724可能通过网关118把批准发送到商户。当响应被拒绝时或者可能当在722代码不正确时或在过度延迟之后（例如，图6的操作620）（沿着“否”路线），主机服务器122可在726可能通过网关118把拒绝发送到商户。

在一些实施方案中，从操作708-714决定的位置信息可被主机服务器122用作另一检查点以决定是否实现支付请求。例如，过程700可包括在请求位置信息之前或同时把授权消息718发送到用户设备110。操作720可使用来自操作712-714的信息以决定是否可能推翻用户批准支付的决定。例如，当主机服务器122在712决定位置不同且可能是欺诈（例如，有人偷了用户设备110等）时，即使从用户设备110接收到有意图批准支付的授权消息且授权消息包括正确代码（如果请求），主机服务器122也可拒绝支付。

说明性界面

图8是使得能够进行支付选择和授权的说明性用户界面（UI）800。UI800可通过在用户设备110上运行的支付应用程序222提供给用户102。UI800可包括信息部分802、支付选择部分804、代码部分806、决定部分808或它们的任何组合。依次讨论每个部分。

信息部分802可提供欠款810且可能提供支付交易的描述，例如商户812的标识符和/或描述814，描述814可列出支付交易的物品/服务或其它细节。在一些实施方案中，描述可包括更多信息的链接。

支付选择部分804可部分由选择模块228填充且包括根据图5示出的过程500的选择。支付选择部分804可包括用户至少部分基于主机服务器122可访问的帐户数据126中的信息可用的EPT816。另外，支付选择部分804可包括每个EPT816包括的金额的选择，例如采购金额818和/或欠款820的百分比。示出采购金额的100％用于第一EPT的一项的图8中示出说明性数据。在一些实施方案中，这可由选择模块228填充作为默认项以便于用户102。选择模块228可基于规则来创建默认项以例如使用户能够从各自的EPT获得额外奖励，所述规则例如创建一些商户或产品类别对于特定EPT的偏好的存储在帐户数据中的规则。

当授权消息需要时，代码部分806可包括输入代码的一个或多个选择。在一些实例中，如图8示出，代码部分中可包括多个选择。然而，在一些实例中，代码部分806只可允许某些类型的代码，例如PIN822、生物特征识别824、模式826或其它类型的代码。

决定部分808可包括拒绝支付请求的拒绝命令828和接受支付请求的接受命令830。在一些实施方案中，当不需要代码时，代码部分806可被省略、变灰，或以其它方式不可用。在这种情况下，用户可能只需要选择接受命令830来授权请求的支付。

UI800也可包括另外的信息。例如，当用户不是通过UI800接收信息的用户102（例如，被委托人代表授权用户102使用EPT等）时，UI800可包括来自开始支付的用户的个人信息（通过文字、音频、视频等）。

图9是使得能够管理来自主机的授权消息的说明性UI900。UI900可通过帐户管理器214提供到用户102，所述帐户管理器214由主机服务器122提供服务且可通过用户设备（例如，用户设备110或另一计算设备）访问。UI900可包括最近活动部分902、规则部分904、菜单部分906或它们的任何组合。依次讨论每个部分。

最近活动部分902可包括之前交易，所述之前交易可允许用户102容易制定未来发生的交易或类似的交易的规则。最近活动部分902可包括交易的实体指示符908和日期910。对于每个交易，最近活动部分902可包括自动批准实体、类别、类型等的授权消息的白名单选项912，白名单选项912可包括根据指定时间段最高指定交易金额（例如，每周50美元、一次交易100美元等）。所述选项也可包括自动拒绝实体、类别、类型等的授权消息的黑名单选项914。另外，最近活动部分902可允许用户102选择实体、类别和/或类型的授权类型916。在一些实施方案中，最近活动选择也可使用EPT选择器918来使用户102能够把EPT与实体、类别和/或类型相关。

规则部分904可能使用户102能够创建可应用来自动接受或拒绝授权消息的规则。所述规则可包括描述920、零用钱922和/或授权类型924。例如，零用钱922可包括时间段。规则部分904可包括“添加更多”命令926以添加另外的规则。用户也可能能够通过UI900删除规则或以其它方式管理规则。

菜单部分906可包括使用户能够导航UI900的命令。所述命令可包括关闭命令928、帮助命令930，和/或把UI900获得的信息保存在帐户数据126中供主机服务器122使用的保存命令932。

条款

1.一种使用移动设备来授权支付的方法，所述方法包括：

在配置有可执行指令的所述移动设备的控制下，从主机且通过所述移动设备接收请求以授权使用具有相关的银行卡标识符的银行卡来支付，所述银行卡标识符被发送到商户的位置上的商户或电子通过不同于用以接收所述请求的通信路径的通信路径；

向所述移动设备的用户提供包括至少所述商户的名称和所述支付的金额的所述请求的描述；

从所述用户接收对所述请求的响应，所述响应包括所述用户输入的安全代码；和

响应于所述请求，把包括所述安全代码的所述响应发送到所述主机，当所述安全代码正确时，所述响应请求所述主机授权向所述商户用所述银行卡进行所述支付。

2.如条款1所述的方法，还包括：决定包括所述移动设备的位置的位置信息，所述位置与批准位置相比且用以进行以下中至少一个：触发来自所述用户的所述安全代码的请求或识别交易的欺诈风险。

3.如条款1所述的方法，其中所述提供还包括：提供所述商户的名称和与所述支付相关的交易中包括的所述物品或服务的描述。

4.如条款1所述的方法，还包括：从电子支付类型的所述用户接收作为提供给所述商户的所述银行卡的替代的选择，所述电子支付类型满足向所述商户的所述支付，且其中所述发送所述响应包括向所述主机发送所述电子支付类型。

5.如条款1所述的方法，还包括：从包括或不包括所述银行卡的另外的电子支付类型的所述用户接收一个或多个选择以满足向所述商户进行的所述支付，且其中所述发送所述响应包括向所述主机发送所述另外的电子支付类型。

6.一个或多个存储当在一个或多个处理器上执行时执行包括以下动作的计算机可执行指令的计算机可读存储介质：

从主机且通过所述移动设备接收请求以授权使用不同于用以接收所述请求的银行卡处理路径的通信路径来对商户进行源自提供支付的支付；

向所述移动设备的用户提供包括至少所述支付的金额的所述请求的描述；

从所述用户接收对所述请求的响应，所述响应包括至少接受或拒绝所述请求；和

把所述响应发送到所述主机作为对所述请求的回答，所述回答授权或拒绝向所述商户进行源自提供支付的支付。

7.如条款6所述的一个或多个计算机可读介质，其中所述请求包括对至少部分基于所述商户或所述支付的金额选择的唯一标识符的请求，所述唯一标识符包括所述用户正确输入以接受所述支付的代码。

8.如条款6所述的一个或多个计算机可读介质，其中所述动作还包括：

决定所述移动设备的位置；和

把所述移动设备的所述位置发送到所述主机，其中所述请求至少部分基于相对于所述商户的位置的所述移动设备的所述位置。

9.如条款8所述的一个或多个计算机可读介质，其中所述决定所述移动设备的所述位置是使用全球定位系统（GPS）或三角测量来执行的。

10.如条款6所述的一个或多个计算机可读介质，其中所述提供还包括：提供所述商户的标识符和与所述支付相关的交易中包括的所述物品或服务的描述。

11.如条款6所述的一个或多个计算机可读介质，其中所述请求是第二请求，且其中所述动作还包括在所述第二请求之前接收第一请求，所述移动设备在阈值时间量之前不响应所述第一请求且导致在所述接收到所述第二请求之前软拒绝所述支付。

12.如条款6所述的一个或多个计算机可读介质，其中所述动作还包括向所述用户提供另外的电子支付类型供选择以满足所述支付。

13.如条款12所述的一个或多个计算机可读介质，其中所述另外的电子支付类型中的一个是至少部分基于把所述各自电子支付类型与商户相关以获得与所述电子支付类型相关的奖励的规则而为所述用户预选的。

14.如条款6所述的一个或多个计算机可读介质，其中所述动作还包括从另外的电子支付类型的所述用户接收选择以满足对所述采购的所述响应，且其中所述发送所述响应包括向所述主机发送所述另外的电子支付类型。

15.如条款14所述的一个或多个计算机可读介质，其中所述提供支付与原始电子支付类型相关，且其中所述动作还包括接收当处理时共同满足由于所述商户而进行的所述支付的所述各自电子支付类型的资金的分配。

16.如条款6所述的一个或多个计算机可读介质，其中所述动作还包括从不同电子支付类型而不是与所述提供支付相关的电子支付类型的所述用户接收选择，所述不同电子支付类型满足由于所述商户而进行的所述支付。

17.如条款6所述的一个或多个计算机可读介质，其中所述支付提供与原始电子支付类型相关，且其中所述动作还包括选择包括或不包括原始电子支付类型的另外的电子支付类型以满足由于所述商户而进行的所述支付。

18.一种方法，包括：

在具有可执行指令的移动设备的控制下，在所述移动设备上接收请求以授权进行从用户提供到商户的电子支付，所述电子支付是使用不同于用以接收所述请求的银行卡处理路径的通信路径而提供到所述商户；

从所述用户接收对所述请求的响应，所述响应包括至少接受或拒绝所述请求；和

把所述响应发送到所述主机作为对所述请求的回答，所述回答授权或拒绝向所述商户进行源自提供支付的支付。

19.如条款18所述的方法，还包括：向所述移动设备的所述用户提供包括至少所述支付的金额和所述商户的指示的所述请求的描述。

20.如条款18所述的方法，其中所述请求包括请求所述用户正确输入安全代码以接受所述支付。

21.一种方法，包括：

在具有可执行指令的一个或多个服务器的控制下，接收请求以授权来自商户的支付，所述支付由用户使用银行卡为满足交易而提供到所述商户，所述请求包括至少支付标识符和金额；

识别与所述支付标识符相关的所述用户的移动设备；

至少部分基于所述金额决定施加到所述用户的授权要求；

把包括所述授权要求的授权消息发送到所述移动设备，所述授权消息使得所述用户能够接受或拒绝授权所述支付的所述请求；

至少部分基于所述发送所述授权消息，通过所述移动设备从所述用户接收用户响应，所述响应接收自与不同于用以把所述支付发送到所述商户的应用程序的支付应用程序的通信；

至少部分基于所述用户响应来决定是否实现所述授权要求；

把包括接受或拒绝向所述商户进行所述支付中一个的响应发送到所述商户，所述接受取决于所述实现所述授权要求；和

代表所述用户把所述支付的所述金额转账到所述商户的帐户。

22.如条款21所述的方法，其中所述授权消息包括请求个人识别号（PIN）或生物特征识别数据中至少一个以满足所述授权要求。

23.如条款21所述的方法，其中所述用户响应包括选择电子支付类型而不是所述支付标识符的所述银行卡，所述电子支付类型将使用来满足由于所述商户而进行的所述交易的所述金额的至少一部分。

24.如条款21所述的方法，还包括：应用决定所述授权要求的至少一个规则。

25.如条款24所述的方法，其中至少部分基于所述用户的输入来创建所述至少一个规则。

26.一种方法，包括：

在具有可执行指令的一个或多个服务器的控制下，

接收请求以授权来自商户的支付，所述支付由用户为满足交易而提供到所述商户，且所述请求包括至少支付标识符和金额；

识别与所述支付标识符相关的所述用户的移动设备；

至少部分基于所述金额决定施加到所述用户的授权要求；

把包括所述授权要求的授权消息发送到所述移动设备，所述授权消息使得所述用户能够接受或拒绝授权所述支付的所述请求；

至少部分基于所述发送所述授权消息，通过所述移动设备从所述用户接收用户响应；

至少部分基于所述用户响应来决定是否实现所述授权要求；和

把包括以下中一个的响应发送到所述商户：

当实现所述授权要求且所述用户接受授权所述支付的所述请求时，接受向所述商户进行所述支付，或者

拒绝向所述商户进行所述支付。

27.如条款26所述的方法，还包括：代表所述用户把所述支付的所述金额转账到所述商户的帐户。

28.如条款26所述的方法，其中所述从所述用户接收所述响应在与不同于用以把所述支付发送到所述商户的应用程序的支付应用程序的通信中执行。

29.如条款26所述的方法，其中所述用户请求包括个人识别号（PIN）或生物特征识别数据中至少一个以满足所述授权要求。

30.如条款26所述的方法，还包括：创建决定所述授权要求的至少一个规则，所述至少一个规则是至少部分基于所述用户的用户输入来创建的。

31.如条款30所述的方法，其中所述规则包括对于指定时间段与阈值支付金额相关的白名单或黑名单所述商户、类别或类型中至少一个。

32.如条款26所述的方法，还包括：

请求所述用户的所述移动设备的位置；和

接收所述移动设备的所述位置，

其中所述位置信息用以决定所述授权要求或与对所述商户进行的所述支付相关的欺诈风险。

33.如条款26所述的方法，其中所述用户响应包括选择电子支付类型而不是具有所述支付标识符的支付类型，所述电子支付类型将使用来满足由于所述商户而进行的所述交易的所述金额的至少一部分。

34.如条款26所述的方法，其中所述授权消息是第二授权消息，且其中所述动作还包括：

在所述第二授权消息之前把第一授权消息发送到所述用户；和

在把所述第二授权消息发送到所述用户之前，把软拒绝通知发送到所述商户以至少暂时拒绝所述支付。

35.如条款26所述的方法，还包括：

决定所述用户是否至少部分基于预定规则而在当前时间不能接收所述授权消息；和

当所述用户至少部分基于所述预定规则在所述当前时间不能接收所述授权消息时，延迟把所述授权消息发送到所述用户。

36.一个或多个存储当在一个或多个处理器上执行时执行包括以下动作的计算机可执行指令的计算机可读存储介质：

接收请求以授权来自商户的支付，所述请求包括至少支付标识符和金额；

识别与所述支付标识符相关的用户；

至少部分基于所述金额决定施加到所述用户的授权要求；

把授权消息发送到所述用户，所述授权消息包括至少所述金额且所述授权要求使得所述用户能够接受或拒绝授权所述支付的所述请求；

至少部分基于所述发送所述授权消息，通过所述移动设备从所述用户接收用户响应；

至少部分基于所述用户响应来决定是否实现所述授权要求；和

把包括接受或拒绝向所述商户进行所述支付中一个的响应发送到所述商户，所述接受取决于所述实现所述授权要求。

37.如条款36所述的一个或多个计算机可读介质，其中所述授权消息是第二授权消息，且其中所述动作还包括：

在所述第二授权消息之前把第一授权消息发送到所述用户；和

在把所述第二授权消息发送到所述用户之前，把软拒绝通知发送到所述商户以至少暂时拒绝所述支付。

38.如条款36所述的一个或多个计算机可读介质，其中所述动作还包括：

决定所述用户是否至少部分基于预定规则而在当前时间不能接收所述授权消息；和

当所述用户至少部分基于所述预定规则在所述当前时间不能接收所述授权消息时，延迟把所述授权消息发送到所述用户。

39.如条款36所述的一个或多个计算机可读介质，其中所述用户响应包括选择不同于与所述支付标识符相关的初始电子支付类型的第二电子支付类型，且其中所述动作还包括使用所述第二电子支付类型来办理向所述商户的支付。

40.如条款36所述的一个或多个计算机可读介质，其中所述授权要求是基于至少部分基于支付金额和所述商户来选择认证过程的规则，其中所述认证过程的至少一个选择包括请求所述用户在所述用户响应中提供个人识别号（PIN）。

结论

虽然主题已用结构特征和/或方法动作专用的语言进行了描述，但是应理解，在所附权利要求书中定义的主题并不一定限于所述特定特征或行为。相反，特定特征和行为揭露为实施权利要求的说明性形式。

Claims (14)

1.一种用于对通过移动设备接收的支付请求授权的设备，该设备包括：

用于从主机且通过移动设备接收请求以授权使用不同于用以接收所述请求的银行卡处理路径的通信路径来对商户进行源自提供支付的支付的装置；

用于向所述移动设备的用户呈现包括至少所述支付的金额的所述请求的描述的装置，所述请求的描述随着付款授权代码的提示一起被展示，所述付款授权代码至少部分地基于所述商户的标识或所述商户的类别从多个付款授权代码中被预选；

用于从所述用户接收对所述请求的响应的装置，所述响应至少部分地基于所述付款授权代码的正确输入来表明接受所述请求；以及

用于把所述响应发送到所述主机作为对所述请求的回答的装置，所述回答用于授权向所述商户进行源自所述提供支付的支付。

2.如权利要求1所述的设备，所述设备还包括：

用于决定所述移动设备的位置的装置；以及

用于把所述移动设备的所述位置发送到所述主机的装置，

其中所述请求至少部分基于相对于所述商户的位置的所述移动设备的所述位置。

3.如权利要求1所述的设备，其中所述请求是第二请求，且所述设备还包括用于在所述第二请求之前接收第一请求的装置，所述移动设备在阈值时间量之前不响应所述第一请求且导致在接收到所述第二请求之前软拒绝所述支付。

4.如权利要求1所述的设备，所述设备还包括用于从所述用户接收另外的电子支付类型的选择以满足对所述请求的所述响应的装置，且其中所述发送所述响应包括向所述主机发送所述另外的电子支付类型。

5.如权利要求4所述的设备，其中所述提供支付与原始电子支付类型相关，且所述设备还包括用于接收当处理时共同满足由于所述商户而进行的所述支付的各自电子支付类型的资金的分配的装置。

6.如权利要求1所述的设备，所述设备还包括用于从所述用户接收不同电子支付类型而不是与所述提供支付相关的电子支付类型的选择的装置，所述不同电子支付类型满足由于所述商户而进行的所述支付。

7.一种用于对通过移动设备接收的支付请求授权的方法，该方法包括：

在具有可执行指令的一个或多个服务器的控制下，接收请求以授权来自商户的支付，所述支付由用户为满足交易而提供到所述商户，且所述请求包括至少支付标识符和金额；

识别与所述支付标识符相关的所述用户的移动设备；

至少部分基于所述金额决定施加到所述用户的授权要求；

把包括所述授权要求的授权消息发送到所述移动设备，所述授权消息使得所述用户能够接受授权所述支付的所述请求，所述授权消息包括所述请求的描述，该描述随着在所述用户的所述移动设备中的付款授权代码的提示一起被展示，所述付款授权代码至少部分地基于所述商户的标识或所述商户的类别从多个付款授权代码中被预选；

至少部分基于所述发送所述授权消息，通过所述移动设备从所述用户接收用户响应，所述用户响应至少部分地基于所述付款授权代码的正确输入表明接受所述请求；

至少部分基于所述用户响应来决定是否满足所述授权要求；以及

把响应发送到所述商户，该响应包括：当满足所述授权要求且所述用户接受授权所述支付的所述请求时，接受向所述商户进行所述支付。

8.如权利要求7所述的方法，其中所述从所述用户接收所述响应在与不同于用以把所述支付发送到所述商户的应用程序的支付应用程序的通信中执行。

9.如权利要求7所述的方法，其中所述用户响应包括个人识别号(PIN)或生物特征识别数据中至少一个以满足所述授权要求。

10.如权利要求7所述的方法，还包括：创建决定所述授权要求的至少一个规则，所述至少一个规则是至少部分基于所述用户的用户输入来创建的。

11.如权利要求7所述的方法，还包括：

请求所述用户的所述移动设备的位置；以及

接收所述移动设备的所述位置，

其中所述位置用以决定所述授权要求或与对所述商户进行的所述支付相关的欺诈风险。

12.如权利要求7所述的方法，其中所述用户响应包括选择电子支付类型而不是具有所述支付标识符的支付类型，所述电子支付类型将被使用来满足由于所述商户而进行的所述交易的所述金额的至少一部分。

13.如权利要求7所述的方法，其中所述授权消息是第二授权消息，且其中所述方法还包括：

在所述第二授权消息之前把第一授权消息发送到所述用户；以及

在把所述第二授权消息发送到所述用户之前，把软拒绝通知发送到所述商户以至少暂时拒绝所述支付。

14.如权利要求7所述的方法，还包括：

至少部分基于预定规则决定所述用户在当前时间是否不能接收所述授权消息；以及

当所述用户至少部分基于所述预定规则在所述当前时间不能接收所述授权消息时，延迟把所述授权消息发送到所述用户。