专利名称：支付应用架构的制作方法
技术领域：
本申请一般地涉及电子支付领域，并且在一个具体示例实施例中，涉及一种用于支付应用开发的架构。
背景技术：
随着不同支付提供者或协助者(facilitator)引入服务，电子支付系统已经在近些年得以发展。这些支付协助者可使用不同的、私有的编程界面来开发支付应用。每种应用可彼此独立地被开发。这种方法可能是有问题的，因为取决于服务，新的特征和要求可能必须单个地来实现。这种方法可能导致不必要的重复努力并且可能延迟为市场带来新的支付应用/服务的时间。
一些实施例在附图的图示中被作为示例而非限制来说明，在附图中图IA是描绘根据示例实施例的具有客户端-服务器体系结构的系统的网络图；图IB是说明根据一些示例实施例的可与图IA中的系统相关联的示例应用的框图；图1C-1D说明根据一些示例实施例的可与图IA中的系统中包括的数据库相关联的示例表。图2是说明根据一些示例实施例的支付应用架构的高级视图的框图；图3A是说明根据一些示例实施例的在支付情形中的隐喻的应用的示图；图;3B是说明根据一些示例实施例的在支付情形中的隐喻的另一应用的示图；图4A是说明根据一些示例实施例的在隐喻中包括的各阶段的示图；图4B是说明根据一些示例实施例的存在预批准的各阶段的示例的示图；图5是说明根据一些示例实施例的批准流的示例的流程图；图6是说明根据一些示例实施例的预批准流的示例的流程图；图7说明根据一些示例实施例的使用支付应用架构的发送款项情形的示例；图8说明根据一些示例实施例的使用支付应用架构的结账情形的示例；图9A-9B说明根据一些示例实施例的说明并行支付和链式支付的示例的示图；图10说明根据示例实施例的计算机系统形式的机器的图示表示，在该机器中，用于致使机器执行在此论述的任何一种或多种方法的指令集可被执行。
具体实施方式
对于一些示例实施例，公开了用于利用支付应用架构来开发支付应用的方法和系统。支付应用架构可包括隐喻(metaphor)和约束(constraint)。隐喻可包括参与者和对象。参与者和对象是支付交易的某些组成部分。约束可包括处理支付交易可遵循的规则。在下面的描述中，为了说明的目的，大量具体细节被提出，以便提供对示例实施例的透彻理解。然而，本发明可在没有这些具体细节的情况下被实施，这对于本领域技术人员来说将是很明显的。在示例实施例中，由应用配置的计算机系统(例如，客户端机器，服务器机器，等等)可构成被配置为并且进行操作以执行在此描述的某些操作的“模块”。因此，术语“模块”应当被理解为包含有形实体，即物理地构建的、被永久配置(例如，被硬连接)或临时配置(例如，被编程)以按照一定方式操作并执行在此描述的某些操作的实体。鍵支付应用架构可允许利用一组标准来开发支付应用。支付应用可覆盖不同的支付情形，例如包括结账、发送款项、请求款项、分割支付、批量支付、反复支付、汇款。示例情形可涉及一个或多个发送或支付方以及一个或多个接收方。支付交易可与一种或多种货币的资金转移相关联。支付交易可与有价项目或货物的转移相关联。例如，支付交易还可与一个或多个发送方和一个或多个接收方认为具有某些可量测价值的点数、里程数、酬金或者任何有形或无形的对象或服务相关联。支付交易架构可包括隐喻和约束。可以有结合隐喻和约束使用的或者应用于隐喻和约束的流和服务。利用支付应用架构，新支付应用的开发可以被简化。平台结构图IA说明描绘出根据示例实施例的具有客户端-服务器体系结构的系统100的网络图。具有基于网络的系统112的示例形式的系统经由网络114(例如，互联网、公共或私人电话、有线或无线网、利用诸如蓝牙或IEEE 802. Ilx之类的技术的私人无线网或其他网络)向一个或多个客户端提供服务器侧功能。图IA例如说明了在客户端机器120上执行的web客户端116 (例如，浏览器，诸如由MICROSOFT 开发的INTERNETEXPLORE 浏览器)。设备应用117可在客户端机器121上执行。程序性客户端118可在客户端机器122 上执行。客户端机器120-122中的每个可被称为基于网络的机器。此外，虽然在图IA中所示的系统100采用了客户端-服务器体系结构，但是实施例当然不限于这样的体系结构，而是同样可以在分布式、点对点式体系结构系统中得到应用。客户端机器120-122可包括移动设备、掌上型电脑、膝上型电脑、桌上型电脑、个人数字助理、蜂窝电话、通信设备、无线电话、座机电话、控制系统、相机、扫描仪、电视、有线电视、具有web浏览器的电视、传真机、打印机、寻呼机和/或个人信任的设备。客户端机器 120-122可包括卡，诸如智能卡、磁卡和/或钥匙卡。客户端机器120-122可包括电话或能够进行短消息传送服务(SMS)消息传送、多媒体消息传送服务(MMS)消息传送和/或生成音频音(诸如双音多频(DTMF)音)的任何设备。客户端机器120-122可使能浏览器。客户端机器120-122可参与到交互式消息中和/或开启通信会话，诸如SMS、电子邮件、可扩展超文本标记语言(xHTML)、无线应用协议 (WAP)、web、交互式语音响应(IVR)和/或其他移动界面。客户端机器120-122和基于网络的系统112之间的通信会话可涉及多种技术形态。例如，客户端机器120、121或122的用户可经由SMS而加入基于网络的系统112并接收作为带有将客户端机器120、121或122导向到WAP或web页面的嵌入式超级链接URL的SMS的响应通信。超级链接URL可从(一个或多个)应用服务器1 被直接递送给客户端机器120-122，并且可用于访问web站点或诸如WAP站点的微浏览器。客户端机器120-122可使能移动可视电话通信、数字电视信号和 /或数字无线电信号。客户端机器120-122可包括用于接收近场通信的接收机。具体地，转到基于网络的系统112，应用程序接口(API)服务器IM和web服务器 126可耦合到一个或多个应用服务器128，并且可提供对于一个或多个应用服务器1 的程序性界面和web界面。客户端机器120-122可利用这些界面中的一个或多个界面来访问 (一个或多个)应用服务器128。例如，web客户端116可经由web服务器1 支持的web界面来访问(一个或多个)应用服务器128。Web界面可包括web浏览器或诸如xHTML或WAP的任何微浏览器。类似地，程序性客户端118可经由API服务器IM提供的程序性界面和/或经由web服务器 126提供的web界面来访问(一个或多个)应用服务器1 提供的各种服务和功能。对于另一实施例，(一个或多个)应用服务器128的一个或多个应用支持的应用可被下载到客户端机器120-122。客户端机器120-122可主持(host)与(一个或多个)应用服务器128的一个或多个应用相关联的界面。客户端机器120-122上的界面可是API界面、SMS界面、web界面和 / 或 IVR 界面。诸如 Java 2 Platform Micro Edition (J2ME)、J2SE 和 J2EE 的消费无线设备平台允许开发者利用Java和无线工具包来创建用于客户端机器120-122的应用和程序。J2ME界面可包括用于客户端机器120-122的API。程序性客户端118的应用也可例如利用无线二进制运行时环境(BREW)来访问网络114。在客户端机器121上执行的设备应用117可经由web服务器126的web界面来访问(一个或多个)应用服务器128。设备应用117可在客户端机器121上被选出并在后台起动。另外或者替代地，设备应用117可经由API服务器124的程序性界面来访问(一个或多个)服务器128。在一个实施例中，在此描述的下载的应用可包括设备应用117。(一个或多个)应用服务器1 可主持一个或多个管理模块130和一个或多个支付模块132。( 一个或多个)应用服务器1 又被示出为耦合到协助访问一个或多个数据库136的一个或多个数据库服务器134。( 一个或多个)帐户管理模块130可提供对各种帐户的管理，如在此更详细论述的。在第三方服务器140上执行的第三方应用138可为客户端机器120-122的用户提供商品和服务。第三方应用138可经由API服务器IM提供的程序性界面来程序性访问基于网络的系统112。第三方应用138可与卖家、商家或者可与客户端机器120-122的用户进行交易的任何组织相关联。对于一些示例实施例，第三方应用138可与在线市场(例如，加利福尼亚圣何塞的eBay公司)相关联。(一个或多个)支付模块132可为客户端机器120-122的用户提供多种支付服务和功能。(一个或多个)支付模块132可允许用户在帐户中积累(例如，诸如美元的商用货币或者诸如“点数”的私有货币方面的)价金，然后经由各种可能的途径来兑换所积累的价金。(一个或多个)支付模块132还可对用户贷款和/或还可访问其他资金源以完成交易。资金源的示例包括信用卡、银行帐户和/或信用贷款(credit line)。(一个或多个)支付模块132可作为款项划拨器。与第三方应用138相关联的第三方可进行与用户的交易并且可从(一个或多个) 支付模块132接收信息。此信息可包括有关对于产品、服务的订购、礼物、赠品等的信息。此信息还可包括由用户指定的送货地址和包括支付确认的付款状态。(一个或多个)支付模块132可确保用户的金融信息相对于第三方是安全的。客户端机器120、121或122可主持与(一个或多个)应用服务器128的(一个或多个)支付模块132相关联的界面。Web客户端116、设备应用117和/或程序性客户端 118可与(一个或多个)帐户管理模块130和/或(一个或多个)支付模块132相关联。(一个或多个)支付模块132还可被实现为单独的软件程序，其不必要具有联网能力。对于此实施例，客户端机器120-122可直接连接到(一个或多个)支付模块132，而无需利用网络114。(一个或多个)支付模块132可访问数据库136，数据库136可被耦合到(一个或多个)数据库服务器134。数据库136可包括用户帐户信息。用户帐户信息可包括支付信息、信用卡信息、支票帐户信息、地址信息，等等。Web客户端116、设备应用117和/或程序性客户端118可操作由(一个或多个) 数据库服务器Π4支持的程序。例如，利用web客户端116，(一个或多个)数据库服务器 134可支持客户端机器120-122的用户界面上的一个或多个帐户信息链接。通过访问(一个或多个)数据库服务器134，用户可添加、修改或删除自己的帐户信息，例如包括送货地址、支付方式等等。网络114可包括移动电话网、无线广域网(WffAN)、有线电话网、无线局域网(无线 LAN或WLAN)、无线城域网(MAN)和/或无线个人区域网(PAN)(例如，蓝牙⑧网)。可用于连接的其他基于网络的技术包括P0N、VSAT卫星、微脉冲雷达、射频识别(RFID)、超宽带和/或红外。客户端机器120-122可利用诸如无线应用协议(WAP)和/或超文本传输协议(HTTP) 之类的移动互联网交换协议连接到web。市场应用图IB是说明在一个示例实施例中被提供作为联网系统112的部分的多种应用130 和132的框图。应用130和132可被主持在专用或公用服务器机器(未示出)上，这些专用或公用服务器机器被通信地耦合以使能服务器机器之间的通信。应用130和132本身 (例如，经由适当的界面)通信地耦合到彼此以及各种数据源，以便允许信息能够在这些应用之间被传送，或者以便允许应用130和32能够共享和访问公共数据。此外，应用130和 132可经由数据库服务器134访问一个或多个数据库136。联网系统112可提供多种发布、列表和价格设置机制，通过这些机制，销售者可对待售商品或服务进行列表(或者发布有关待售商品或服务的信息)，购买者可表达对这些商品或服务的兴趣或者表明购买这些商品或服务的愿望，并且价格可被设置以用于有关商品或服务的交易。为此，市场应用130被示出为包括至少一个发布应用140和一个或多个拍卖应用142，拍卖应用142支持拍卖形式列表和价格设置机制(例如，英式拍卖、荷兰式拍卖、维克里(Vickrey)拍卖、中式拍卖、复式拍卖、逆向拍卖，等等)。各种拍卖应用142还可提供支持这些拍卖形式列表的多种特征，诸如底价价格特征(通过此特征，销售者可指定底价价格)，以及列表和代理出价特征(通过此特征，出价者可采用自动代理出价)。
多种固定价格应用144支持固定价格列表形式(例如，传统的分类广告型列表或者目录列表)和买断(buyout)型列表。具体地，买断型列表(例如包括由加利福尼亚圣何塞的eBay公司开发出的现在购买(Buy-It-Now，BIN)技术)可结合拍卖形式列表被提供， 从而允许购买者针对通常高于拍卖的起始价格的固定价格来购买商品或服务，而这些商品或服务还被提供经由拍卖的销售。店铺应用146允许销售者在“虚拟店铺”内对列表进行分组，其可由销售者或者为销售者设置品牌或者以其他方式进行个性化。这样的虚拟店铺还可提供促销、刺激和特定于或者个性化用于相关销售者的特征。声誉应用148允许利用联网系统112进行交易的用户建立、构建和维护声誉，声誉对于潜在交易方而言是可得到的并被发布给潜在交易方。考虑，在例如联网系统112支持个人对个人的交易的情况下，用户可能没有可用来评估潜在交易方的可信性和信用度的历史和其他参考信息。声誉应用148例如允许用户通过由其他交易方提供的反馈来随时间建立在联网系统112内的声誉。其他潜在交易方然后可参考这样的声誉来评估信用度和可信性。个性化应用150允许联网系统112的用户个性化他们与联网系统112交互的各个方面。例如，用户可利用适当的个性化应用150来创建个性化的参考页，在此参考页上，可以看到有关用户作为(或曾经作为)参与方的交易的信息。此外，个性化应用810可使得用户能够个性化列表以及他们与联网系统112以及其他方交互的各个方面。联网系统112可支持例如被定制用于特定地理区域的若干市场。联网系统112的一种版本可定制用于英国，而联网系统112的另一种版本可被定制用于美国。这些版本中的每种版本可作为独立市场进行操作，或者可以是对公共基本市场的定制化(或国际化) 表示。联网系统112因此可包括联网系统112用来根据预定标准(例如，地理标准、人口标准或者市场标准)定制信息(和/或信息的表示)的若干国际化应用152。例如，国际化应用152可用于支持对于由联网系统112操纵并且可经由各个web服务器1 访问的若干区域性web站点的信息的定制。联网系统112的导航可由一个或多个导航应用IM来协助。例如，搜索应用(作为导航应用的示例)可使能对于经由联网系统112发布的列表的关键词搜索。浏览器应用可允许用户浏览各种分类、目录或存货数据结构，根据这些，列表可在联网系统112内被分类。各种其他导航应用可被提供以增补搜索和浏览应用。为了使得能经由联网系统112得到的列表项有尽可能多的可视化信息以及尽可能有吸引力，市场应用130可包括一个或多个成像应用156，利用成像应用156，用户可上载用于包括在列表中的图像。成像应用156还进行操作以将图像结合到被查看的列表内。成像应用156还可支持一个或多个促销特征，诸如呈现给潜在购买者的图库。例如，销售者可支付额外的费用来得到在用于促销的项目的图库中包括的图像。列表创建应用158允许销售者方便地创作有关他们希望经由联网系统112交易的商品或服务的列表，并且列表管理应用160允许销售者管理这样的列表。具体地，在特定销售者已经创作和/或发布了大量列表的情况下，这些列表的管理可能提出挑战。列表管理应用160提供用来帮助销售者管理这些列表的若干特征(例如，自动重列表、存货水平监控，等等)。一个或多个后续列表管理应用162也帮助销售者应对通常出现后续列表的若干动作。例如，当完成由一个或多个拍卖应用142协助的拍卖时，销售者可能希望留下有关特定购买者的反馈。为此，后续列表管理应用162可提供对于一个或多个声誉应用148的界面，以允许销售者方便地向声誉应用148提供有关多个购买者的反馈。纷争解决应用8 提供可解决在交易各方间出现的纷争的机制。例如，纷争解决应用164可提供通过若干步骤试图引导各方解决纷争的引导过程。在纷争不能经由引导过程解决的情况下，纷争可被升级给第三方调停者或仲裁者。若干欺诈防止应用166执行欺诈检测和防止机制，以减少在联网系统112内欺诈的发生。消息传送应用168负责生成消息和向联网系统112的用户递送消息，诸如，例如向用户广告有关联网系统112处的列表的状态的消息(例如，在拍卖过程期间向出价者提供 “出价结束”通知，或者向用户提供促销信息和推销信息)。各个消息传送应用168可利用任何数量的消息递送网络和平台来向用户递送消息。例如，消息传送应用168可通过有线网络(例如互联网)、普通老式电话服务(POTS)网络或无线(例如，移动、蜂窝、WiFi、WiMAX) 网络递送电子邮件(e-mail)、即时消息(IM)、短消息服务(SMS)、文本、传真或语音(例如， 基于IP的语音(VoIP))消息。推销应用170支持可为销售者得到用以使得销售者能够增加经由联网系统112的销售的各种推销功能。推销应用170还操作可被销售者调用的各种推销特征，并且可监视和追踪销售者所采用的推销策略的成功。联网系统112本身或者经由联网系统112进行交易的一方或多方可操作由一个或多个忠诚度/促销应用172支持的忠诚度程序。例如，对于与特定销售者建立和/或缔结的每次交易，购买者可挣取忠诚度或促销点数，并且购买者可被提供以所积累的忠诚度点数所能够兑换的酬金。支付架构应用174负责与支付应用开发者的交互，以使得能够开发支付应用。支付架构应用175可执行使得支付交易的组成部分与至少某些预定工具集相关联的操作，这些工具包括与发送实体(或者发送者)、接收实体(接收者)、支付系统(或支付协助者) 以及使能从发送者到接收者的价金转移的流相关联的工具。支付架构应用174可以能够访问数据库136中存储的信息。数据结构图IC是高级实体关系图，说明了可维护在数据库136中并被应用130和132利用并且支持应用130和132的各种表。用户表181包含对于联网系统112的每个注册用户的记录，并且可包括关于每个这样的注册用户的标识符、地址和金融工具信息。用户可在联网系统112内作为销售者、购买者或者既作为销售者又作为购买者而进行操作。在一个示例实施例中，购买者可是已经积累了价金(例如商用或私有货币)并且因此能够以所积累的价金交换联网系统112提供待售的项目的用户。用户表181可与一个或多个发送者和接收者相关联，其可被在图IB中描述的支付架构应用175使用。表180还包括项目表182，在项目表182中维护对于可经由联网系统112交易或者已经经由联网系统112交易的商品和服务的项目记录。项目表182内的每个项目记录还可被链接到用户表181内的一个或多个用户记录，从而使得将销售者和一个或多个实际或潜在购买者与各个项目记录相关联。交易表183包含对于有关在项目表182中存在记录的项目的每个交易(例如，购买或销售交易)的记录。订购表187被填充订购记录，每个订购记录与订购相关联。每个订购又可与在交易表183中存在记录的一个或多个交易有关。出价表188中的每个出价记录涉及在联网系统112处接收到的与拍卖应用142支持的拍卖形式列表相关的出价。在一个示例实施例中，反馈表184被一个或多个声誉应用 148用来构建和维护有关用户的声誉信息。历史表185维护曾经作为参与者的用户的交易的历史。一个或多个属性表186记录有关在项目表182中存在记录的项目的属性信息。仅考虑这样的属性的一个示例，属性表916可指示与特定项目相关联的货币属性，此货币属性标识销售者指定的用于有关项目的价格的货币。支付架构表190可包括可供支付架构应用174使用的信息。图ID提供有关在图IC中所示的被维护在数据库136内的支付架构表的进一步的细节。如所示的，支付架构表190可包括多个字段。每个字段可与某种用户信息相关联，例如，诸如下面更详细论述的隐喻191、对象192和约束193。支付应用架构对于一些示例实施例，利用支付应用架构开发的支付应用一般都使能价金(例如，资金、酬金点数，等等)从与一方(称为发送者)相关联的帐户到与另一方(称为接收者)相关联的帐户的转移。为了执行价金转移，支付应用的执行可基于一个或多个批准流。 这可能需要能够访问批准流和支付协助者的服务，或者需要具有发起批准流和利用支付协助者的服务的权限。支付协助者的一个示例是由加利福尼亚圣何塞的I^ayPal提供的服务。 具有访问权可不包括批准价金从发送者的帐户转出。具有批准权可隐含地包括具有访问权。如下面所述，这也可适用于预批准的情形。支付应用可生成付款请求。付款请求与支付交易有关。付款请求包括提供给支付协助者(或者支付协助者中的支付处理逻辑)的用于建立或定义一个或多个支付交易的指令。例如，在分割支付情形中，单个付款请求可涉及单笔支付交易或多笔支付交易。付款请求可以被看作是开发者用来建立支付交易的工具。付款请求可对于发送者和接收者是透明的。支付交易可对于发送者和接收者是更加可见的和可辨认的。图2是说明根据一些示例实施例的支付应用架构的高级视图的框图。支付应用架构200可用于开发支付应用220，支付应用220可形成在系统100中描述的一个或多个支付模块132。支付应用架构200可包括约束库205和隐喻库210。支付应用架构200还可使得支付应用220能够接收定制信息215。定制信息215可包括修改、替换或补充在约束库 205和/或隐喻库210中包括的信息的信息。对于一些示例实施例，隐喻库210可包括表示更具体的支付相关概念的高级视图的隐喻。隐喻可被设计为简单易懂的并且使得对于不同类型的支付应用220而言都是一致的。对于一些示例实施例，约束库205可包括与支付规则相关联的约束。一些约束可与默认值相关联。约束的一些示例包括支付频率、与支付相关联的货币，等等。对于一些示例实施例，支付应用架构中的隐喻可包括参与者、对象和阶段。参与者、对象和阶段可跨越利用支付应用架构200开发的多个支付应用以相类似的方式彼此交互。支付应用可被开发用于处理不同类型的支付交易。隐喻参与者图3A是说明根据一些示例实施例的、隐喻在支付情形中的应用的示图。在本示例中，示图300包括发送者305、接收者310和支付协助者(或者支付网络)315。发送者305、 接收者310和支付协助者315被认为是支付应用架构220内参与交易的参与者。A/发送者对于一些示例实施例，发送者305是针对支付协助者315开立的帐户的帐户持有者。支付款要从发送者305的帐户取出。发送者305可表示实际拥有帐户的任何人、多个人、或实体。发送者305也可表示已经接收到代表实际拥有者访问帐户的批准的任何人、多个人、实体或多个实体。发送者305可与一笔或多笔支付交易相关联。对于一些示例实施例，发送者305可与和支付协助者315有关的电子邮件地址相关联。例如，支付协助者315 可以是加密福尼亚圣何塞的I^aypal公司，并且与I^ypal公司有关的电子邮件地址可以是 SenderIDiPayPal. com。对于一些实施例，电子邮件地址可用移动电话号码或者其他对于帐户的独立引用来替代。对于一些示例实施例，在支付交易中可以有多个发送者305向单个接收者310发送支付。此支付情形被称为集合支付。B/接收者对于一些示例实施例，接收者310是针对支付协助者315开立的帐户的帐户持有者。接收者310可表示实际拥有帐户的任何人、多个人、或实体。接收者310还可表示已经接收到代表实际拥有者访问帐户的批准的任何人、多个人、实体或多个实体。接收者310可与一笔或多笔支付交易相关联。对于一些示例实施例，接收者310可与和支付协助者315 有关的电子邮件地址相关联。对于一些示例实施例，可以有多个接收者310正从单个发送者305接收支付。此支付情形被称为分割支付。对于一些示例实施例，在支付交易中可以有多个发送者305和多个接收者310。C/支付协助者对于一些实施例，支付协助者315可接收来自发送者305的付款请求320。付款请求320可具有详细描述付款请求的一个或多个项目。支付协助者315可处理付款请求320 并且可致使支付款325从发送者305的帐户被发送给接收者310的帐户。支付协助者315 可使得发送者305能够利用不同的支付工具。例如，支付工具可包括信用卡、借记卡、支票帐户、储蓄帐户，等等。图;3B是说明根据一些示例实施例的、隐喻在支付情形中的另一应用的示图。在本示例中描述的支付情形也可被称为支付扩展。示图390包括发送者305、接收者310、付款请求350和支付款355。对于一些示例实施例，支付应用架构200可使得支付款355从第一支付协助者或支付网络360被发送给第二支付协助者或支付网络365。支付协助者360和支付协助者365可是相同的支付协助者，或者他们可以是不同的支付协助者。类似地，“来自”的支付网络和“去往”的支付网络可以是相同的支付网络，或者他们可以是不同的支付网络。支付网络的一些示例可包括自动清算中心(ACH)、Debit、Swift和虚拟货币。在本示例中，支付网络也可被考虑作为支付应用架构200内参与支付交易的参与者。虽然下面的论述使用涉及由支付协助者处理支付的示例，但是应当注意，此论述也可应用于一个或多个支付协助者和/或一个或多个支付网络。
隐喻对象对于一些示例实施例，对象可包括付款请求、付款密钥和与付款请求以及付款密钥相关联的参数。付款请求可包括定义支付的信息。付款密钥可被加密并且可被用于请求批准或指示批准。如将要描述的，批准可与批准流或预批准流相关联。参数可被包括在超文本传输协议(HTTP)消息中。HTTP消息可在支付应用之间被发送，并且可由支付协助者处理。参考在图3A中所示的示例，付款请求320可包括金额、有关发送者的信息、有关接收者的信息以及货币。付款请求320还可包括其他相关信息，例如，诸如交易费用。交易费用是由支付协助者315收取用于处理支付交易的费用。交易费用可由发送者305支付或由接收者310支付。付款请求320被发送给支付协助者315并被支付协助者315处理。支付协助者315 可响应于接收到付款请求320而发布付款密钥。支付协助者315可将付款密钥发送给发送者305。付款密钥可用于批准。对于一些示例实施例，在发送者305批准付款请求之前，付款请求320不被处理。发送者305可基于批准流来提供批准(或批准指示)。应注意，从发送者305接收到的批准指示可以是肯定批准或否定批准。付款密钥唯一地与付款请求相关联，并且可用在与付款请求有关的随后的支付交易中。对于一些示例实施例，如果在经过了预定时间段之后还没有接收到批准，则等待来自发送者305的批准的付款请求可能超期。延期可被发布来防止付款请求超期。付款密钥的示例在图4A中被示为付款密钥420。对于一些示例实施例，批准可由发送者305在进行支付前提供。这被称为预批准。 在预批准的情形中，预批准请求可被创建并被发送给支付协助者。支付协助者可处理预批准请求并且可返回预批准密钥。随后，付款请求连同预批准密钥可一起被发送给支付协助者以供处理。对于一些示例实施例，预批准密钥可被发布用于一次未来的支付或一组反复的未来支付。预批准密钥可对于预批准请求是唯一的。发送者305可基于预批准流来提供预批准。预批准流可包括一组规则。对于一些示例实施例，预批准请求可能在预定时间段之后超期，除非此预定时间段被延期。预批准密钥的示例在图4B中被示为预批准密钥465。支付协助者可执行处理批准请求和预批准请求的功能。支付协助者还可执行处理其他支付相关请求的功能。这些功能中的一些功能可能在每笔支付交易中都需要，而一些功能可能是可选的。在不限制支付协助者的服务和/或能力的情况下，下面的表(表1)强调示出了一些示例功能。服务或能力名称-用途· Pay-用在各个支付交易中· GetPayStatus-用于确定支付的状态· GetPreApproval-用于获得对未来一次支付或反复支付的批准· GetPreApprovalStatus-用于确定发送者是否已经批准预批准请求· Capture-用于获取已被预留用于支付的资金。部分支付可能是不被允许的，但是在分 割支付中，可获取付款请求的特定部分或交易。· Refund-用在复杂的分割支付情形中，其中，在退款功能被使用时，来自多个接收者的退款全部立刻被触发。此功能可要求第三方访问权限。退款交易可由接收者通过调用Refund功能来执行。接收者将在Pay Key (付款密钥)中将要被退款的退款金额传送给发送者。· Interactive Voice Response (IVR) Approval-用于触发支付协助者的 IVR 月艮务以呼叫注册支付协助者用户的移动电话号码来获得对于支付的批准。· GetPayRequestDetails-用于基于付款密钥获得有关付款请求的信息。付款密钥可映射到一笔或多笔交易。· GetpreApprovalRequestDetails-用于基于预批准密钥获得有关付款请求的信息。表1隐喻阶段图4A是说明根据一些示例实施例的在隐喻中包括的各阶段的示图。示图400说明可以作为支付应用架构的隐喻的部分的阶段。可以有两个阶段。一个阶段被称为付款阶段405，另一阶段被称为批准阶段410。在付款阶段405期间，约束可被定义并呈现给支付协助者315。在批准阶段410，可由发送者305提供用于批准从发送者针对支付协助者315 开立的帐户提取资金的批准。如将在图4B中所描述的，批准阶段410的变形是预批准阶段 455。对于一些示例实施例，付款阶段405可发生在批准阶段410前。一个示例是简单结账情形，其中，付款请求之后跟随发送者305的批准。如所示出的，付款请求可包括作为参数的付款密钥420。与批准阶段410相关联的操作可基于批准流。批准流可将发送者305 导向到支付协助者315的web站点。支付协助者315的web站点可为发送者305提供用于提供批准所需信息的界面。例如，发送者305可是购买商家的web站点处的项目的消费者。 发送者305可从商家的web站点被重定向到支付协助者的web站点。此重定向可借助于与支付协助者315的web站点(例如，PayPal web站点)呈现的界面相关联的统一资源定位符(URL)链接。基于发送者305提供对于支付的批准，发送者305可被重定向回到商家的 web站点。在此情形中，重定向URL链接(例如，到商家的web站点的链接)可作为参数被发送，从而在批准流结束之后，发送者305被重定向到商家的web站点的指定页面。对于一些示例实施例，批准阶段410可以与批准通知流相关联。批准通知流可利用通知URL链接作为参数。通知URL链接可与商家相关联。例如，当发送者305提供批准时，商家被通知以便发送者305在商家的web站点处的购买交易可进行到下一步。在本示例中，商家充当接收者310的角色。对于一些示例实施例，批准阶段410可包括当从发送者的帐户转出资金时向发送者305发送通知。这可通过电子邮件、无线通信或可使能通知发送者305的任何其他形式的通信来执行。也可向接收者310发送类似的通知。图4B是说明根据一些示例实施例的预批准阶段的示例的示图。示图450说明预批准阶段455和付款阶段460。在预批准情形中，预批准阶段455可发生在付款阶段460前。 预批准阶段455可基于预批准流。预批准请求可被发起并被发送给发送者305。预批准请求可由接收者(例如，商家)310发起。预批准密钥465也可被发送。发送者305可通过与支付协助者315相关联的预批准界面来检查预批准请求。发送者305可向接收者310提供预批准。如上所述，预批准密钥465可是唯一的并且可与针对一次未来的支付或针对反复的未来的支付的预批准请求相关联。对于一些示例实施例，预批准密钥465可利用加密数据来发送。^lM约束可包括开发者用来更高效地开发支付应用的规则。这些规则可实现在支付流中。支付流可与批准流和/或预批准流相关联。参数可与支付流结合使用。参数可具有默认值。对于一些示例实施例，一些参数可用在支付流中，而它们的默认值不变。下面的表 (表2)说明可使用的支付流的示例摘要。
权利要求
1.一种协助支付应用的计算机执行的方法，该方法包括 将支付交易与发送者、接收者以及支付协助者相关联； 将从发送者到接收者的价金的转移与付款请求相关联；将支付交易与至少一个用于使得发送者批准付款请求的批准流相关联；以及响应于接收到发送者基于批准流对付款请求的批准的指示，使得支付协助者完成支付交易。
2.根据权利要求1所述的方法，还包括基于发送者对付款请求的批准，将付款密钥与付款请求相关联。
3.根据权利要求2所述的方法，其中，批准的指示包括肯定批准或否定批准。
4.根据权利要求3所述的方法，其中，付款请求由接收者或发送者发起。
5.根据权利要求3所述的方法，其中，付款请求从与接收者相关联的web站点发起。
6.根据权利要求5所述的方法，还包括将发送者从与接收者相关联的web站点导向到与支付协助者相关联的web站点；以及使得发送者检查付款请求并提供批准的指示。
7.根据权利要求6所述的方法，还包括基于接收到来自发送者的批准的指示，将发送者导向到与接收者相关联的web站点。
8.根据权利要求7所述的方法，其中，响应于接收到来自发送者的批准的指示使得支付协助者完成支付交易包括当批准的指示为肯定批准时，将价金转移给接收者。
9.根据权利要求8所述的方法，其中，将价金转移给接收者包括从发送者的帐户划拨出价金，发送者的该帐户与支付协助者相关联。
10.根据权利要求9所述的方法，其中，将价金转移给接收者还包括将价金存入接收者的帐户。
11.根据权利要求10所述的方法，其中，接收者包括第一接收者和第二接收者。
12.根据权利要求11所述的方法，其中，将价金存入接收者的帐户包括将价金存入第一接收者的帐户，并且将所述价金的至少一部分从第一接收者的帐户存入第二接收者的帐户。
13.根据权利要求11所述的方法，其中，将价金存入接收者的帐户包括将价金的一部分存入第一接收者的帐户，并且将价金的另一部分存入第二接收者的帐户。
14.根据权利要求10所述的方法，还包括在将价金存入接收者的帐户之前，使得在发送者的帐户中预留价金。
15.根据权利要求7所述的方法，其中，响应于接收到来自发送者的批准的指示使得支付协助者完成支付交易还包括向发送者通知价金的转移。
16.根据权利要求15所述的方法，其中，所述通知基于通知流。
17.—种包括指令的机器可读介质，当指令被一个或多个处理器执行时，处理器执行在权利要求1中所描述的操作。
18.一种计算机执行的方法，包括将支付协助者与支付交易中的发送者以及接收者相关联，支付协助者被配置为基于付款请求将价金从发送者的帐户转移到接收者的帐户；使得发送者基于批准流或预批准流来批准付款请求；以及使得支付协助者利用默认参数集中的至少一个默认参数来完成价金的转移。
19.根据权利要求18所述的方法，其中，所述默认参数集包括至少货币参数。
20.根据权利要求18所述的方法，还包括使得生成与预批准流相关联的预批准请求。
21.根据权利要求20所述的方法，还包括使得响应于预批准请求的生成而生成预批准密钥。
22.根据权利要求18所述的方法，还包括使得生成与批准流相关联的付款密钥。
23.根据权利要求18所述的方法，其中，付款请求由发送者发起，并且其中，响应于由发送者发起的付款请求，发送者被从与接收者相关联的web站点重定向到与支付协助者相关联的web站点。
24.根据权利要求23所述的方法，还包括响应于发送者对付款请求的批准，使得发送者被从与支付协助者相关联的web站点重定向到与接收者相关联的web站点。
25.根据权利要求18所述的方法，其中，发送者的帐户是针对支付协助者的。
26.根据权利要求25所述的方法，其中，价金被从发送者的帐户转移到接收者的帐户。
27.根据权利要求沈所述的方法，其中，接收者的帐户是针对支付协助者的或针对第三方支付网络的。
28.根据权利要求27所述的方法，其中，接收者包括主要接收者和次要接收者，并且其中，价金被转移到主要接收者的帐户，并且其中，价金的至少一部分被从主要接收者的帐户转移到次要接收者的帐户。
29.根据权利要求27所述的方法，其中，接收者包括主要接收者和次要接收者，并且其中价金部分地被转移到主要接收者的帐户，并且部分地被转账移次要接收者的帐户。
30.根据权利要求沈所述的方法，还包括在价金被转移到接收者的帐户之前，使得在发送者的帐户中预留价金。
31.根据权利要求沈所述的方法，还包括在价金被从发送者的帐户转出之后并且基于通知流来通知发送者。
32.根据权利要求31所述的方法，其中，所述通知是通过与发送者相关联的电话号码或电子邮件地址来执行的。
全文摘要
一种支付应用架构，可包括隐喻和约束。隐喻可以与作为支付交易的部分的参与者和对象相关联。约束可以包括可用于处理支付交易的规则和参数。
文档编号G06Q40/00GK102209972SQ200980144630
公开日2011年10月5日 申请日期2009年9月9日 优先权日2008年9月9日
发明者穆萨阿波·阿特-特拉斯, 詹森·亚历山大·克罗斯克, 达蒙·查尔斯·霍兰德 申请人:电子湾有限公司