交易处理系统及交易处理方法与流程
本发明涉及对于要通过数据通讯网络进行支付交易的支付授权请求进行处理的方法和支付系统，特别地但非排他地，适于作为金融账户持有人经由多个不同的在线商户系统的定购的结果所进行的支付授权请求。
背景技术：
越来越鼓励用户在线购物，即，经由互联网及相关技术。一般而言，现有的在线支付系统属于以下四种类型的布置之一：在第一种类型的布置中，在线商户系统收集来自金融工具持有人(此外，还被称为买方或持卡人)的支付详情，不需要买方直接与交易中可能涉及的任何其它实体打交道，并且在线商户系统将交易详情直接发送到他们的收单行系统。在第二种类型的布置中，在线商户系统收集来自买方的支付详情，不需要买方直接与交易中可能涉及的任何其它实体打交道，并且在线商户系统将交易详情发送至在线商户互联网支付服务提供商(商户ipsp系统)，其中，该系统代表商户来处理支付授权。商户ipsp系统随后将该详情传输至在线商户的收单行系统；该详情可直接传输至收单行或传输至代表收单行进行操作的支付处理器。为第二种类型的布置提供支持的商户ipsp系统的实例包括：protxtmveri-secure支付系统(vsp)。使用诸如前述商户ipsp系统的支付网关的优势在于：商户ipsp系统可以提供多种额外交易处理功能中的一种或多种，例如，代表在线商户进行结算、处理拒付、处理退款以及交易报告。在结算程序中，商户ipsp系统“成批”地向在线商户收单行系统递交给定时段内收集的在线商户批准的所有授权从而用于结算。拒付是由买方或由发行此次购买中使用的卡的银行启动的反向支付卡交易。这与退款不同，退款是经由商户ipsp系统由在线商户同意并启动的。交易报告涉及为已经由商户ipsp系统授权并选择性结算的累积交易提供总体报告的功能，从而商户能够(例如)选择日期范围进而查看涉及在该日期范围内进行的所有交易的总览。商户ipsp系统可以向在线商户提供安全的在线网站，正如所述，通过该网站来批准拒付、启动退款和/或浏览交易报告。
第三种类型的布置是在线商户系统将买方重新定向到替代的支付系统网站，买方与该网站进行交互以完成交易。该替代的支付系统直接和用户进行交互，该用户或是直接从其银行账户或是经由诸如支付卡的机制向该替代的支付系统提供支付。在使用根据传统支付实施方式的支付卡的情况下，替代的支付系统在传统支付系统中起到商户的作用，通过收单系统递交支付要求。来自用户的支付是对于替代的支付系统做出的。接下来，替代系统负责商户的任何付还。在第二种情况下，替代的支付系统实际上就像传统的票据交换所，通过直接对用户的账户记账将资金从用户的实际发单行账户划入该用户在替代支付系统中的账户。随后，替代的支付系统通常是通过传统的票据交换所来确保支付款已经发到商户的发单行账户。这个商户银行账户可以是他们传统的收单系统中所持有的相同账户，也可以是不同的账户。因此，第三种类型的支付系统在大多数时候用作中介，从而通常是经由消费者和商户的个人银行账户来取走用户的实际资金并通过该系统转给商户，潜在地，当这些资金通过该支付系统持有的账户时保有这些资金；第三种类型的支付系统的实例包括广为人知的paypal(tm)支付系统。这种支付系统也具有作为传统ipsp进行操作的能力，例如，通过提供相关的在线支付处理服务。
尽管这种类型的支付系统缓解了对于用户基于每个在线商户建立个人支付账户的需要，该用户与替代的支付系统而非在线商户系统有关系；但其也产生了数个显著的缺点：首先，在线商户既不能从收单行直接收到该支付款也不能利于其自身的、基于支付方案的支付保证，原因在于对于这些交易来说，商户与卡支付方案之间没有直接关系。其次，对于经由卡支付实现的交易，买方无法看到所购产品的个体在线商户(而是卡账单识别替代的支付系统实体)。第三，买方不受卡方案规则的保护，也可能未受到任何适用的消费者保护法的保护，原因在于该交易是利用支付系统而非利用在线商户系统进行的。
当用户单独与商户系统交互时，商户系统通常从买方获得支付卡数据、银行账户信息和/或其它财务数据。然后，商户将该信息或是直接或是通过商户ipsp系统提供的支付网关传至收单行处理系统。每一个商户系统由收单行分配商户账户识别码，该账户识别码用于在请求交易授权时向收单行识别该商户。这需要每个商户系统实现独立于其它商户的、其自身的支付处理能力；因此，需要买方为每一个商户单独地提供他们的支付信息。因此，针对买方交互的每个新商户，增大了暴露、盗用和/或欺诈使用买方金融数据的风险。
这些已知的支付系统要求用户按每次交易、或按照向商户ipsp(可替换地，非ipsp的支付系统)进行注册来输入他们的账户详情；因此，用户是取得相关支付详情的唯一接触点。尽管这是一个可接受的方法，账户识别码不容易记住，因此用户在相关时间点有账户详情的时候，通常只进行购买和/或签约支付服务和商户网站。
在第四种类型的支付系统布置中，提供一种额外的选项，由此买方能选择以继续经由他们的发单行进行支付，该发单行出于这种目的提供了在线银行网站。然而，在这种情况下，在线商户或者代表他们的商户ipsp系统需要同发单行系统交互，并且一旦支付处理转至发单行，该处理就以直接来自发单行持有的用户的交易账户(即，经常账户或支票账户)转账的票据支付方式进行。因此，第四种类型的布置不能提供从现有的商户ipsp系统或现有的卡方案系统(如visatm和mastercardtm)中可获得的交易处理功能。
技术实现要素：
根据本发明的至少一个实施方式，为要经由数据通信网络进行的支付交易的支付授权请求进行处理的方法所提供的系统和软件，正如独立权利要求详细说明的。这通过组合每一项独立权利中列举的特征来实现。因此，从属权利限定了本发明的进一步的详细实现方式。
更具体地，本发明的方面提供了对于要经由数据通讯网络进行的支付交易的支付授权请求进行处理的方法，该支付授权请求作为金融账户持有人经由多个不同的在线商户系统的定购的结果而进行，
其中，金融账户持有人持有关于多个不同发单行的账户，
该方法包括进行账户识别程序，包括：
从所述的多个不同发单行中识别与金融账户持有人关联的发单行；
在识别发单行的基础上，检索发单行传输数据，从而实现账户识别请求数据的传输，所述发单行传输数据取决于经识别的发单行并且该发单行传输数据识别与经识别的发单行相关联的、选定的账户识别系统；
基于检索到的发单行传输数据，传输在授权至少一次支付交易中使用的账户识别请求，该至少一次支付交易作为金融账户持有人经由至少一个在线商户系统进行的至少一次定购的结果而被发起；以及
接收响应于账户识别请求的账户识别响应，该账户识别响应识别能够在该至少一次支付交易中使用的金融账户身份。
因此，本发明的实施方式提供了一种装置，用于从多个发单行中识别一发单行作为要在给定交易中利用的发单行。本发明的实施方式提供了一种装置，用于使用户关于给定交易实时地指定特定的、用于为该交易扣款的银行账户。优选地，关于用户账户来对他们进行认证，由此为已知系统提供了改进，在已知系统中需要用户或是将支付详情发送到商户系统或是在交易前提供详情至(例如)第三方实体(用户之前已授权该第三方实体作为代表来处理支付)。需要理解的是，发行银行是指代表用户持有账户的银行；该账户可能附带了支付卡也可能未附带支付卡，本发明的实际实施方式同样适用于具有关于其发行银行的账户没有发行卡的用户。一般而言，可以将发行银行视为支付交易中的支付实体(支付方)。
在一种布置中，该方法在接收到该账户识别响应后进一步包括：
a)生成包括交易数据的支付授权请求，该交易数据包括：
i)金融账户持有人在支付交易中使用的金融账户身份；
ii)与第一在线商户相关联的、作为该支付交易收款人的商户身份；以及
iii)包括支付金额的交易详情；以及
b)传送该生成的支付授权请求，用于收单行支付处理器系统的随后处理，其中，该系统负责对于与第一在线商户关联的收单行的支付授权进行处理。
这实现了金融账户身份与所请求的交易相结合，成为端到端处理的一部分，并有利于降低交易详情与支付详情分离的风险。因此，优选地，响应于接收到该账户识别响应来生成支付授权请求。
本发明的实施方式实现了生成包括相同金融账户身份的多个支付授权请求：可对于每个支付授权请求进行单独的账户识别程序，该程序涉及在生成每一个支付授权请求之前传输账户识别请求并接收账户识别响应。在这种情况下，本方法可以包括生成包含了相同金融账户身份的多个支付授权请求，并且对于多个支付授权请求中的每一个持有该金融账户身份，使得对于全部的多个支付授权请求只需要单个账户识别程序，该程序包括传输账户识别请求并接收账户识别响应。这种布置的优点是对于与经识别的发单行通信所需的带宽进行限制。
在优选的实施方式中，数据通信网络包括多个不同的商户互联网支付服务提供商(商户ipsp系统)系统。该商户ipsp系统中的每一个被布置为将支付授权请求传输至多个收单行支付处理器系统中的至少一个；该多个收单行支付处理器系统中的每一个负责为至少一个收单行处理支付授权；并且多个在线商户中的每一个均与该多个商户ipsp系统之一相关联。在该布置中，本方法包括检索商户ipsp系统传输数据从而实现将支付授权请求数据传输至选定的、与第一在线商户相关联的商户ipsp系统，并且基于检索到的商户ipsp系统传输数据，将生成的支付授权请求传输至选定的商户ipsp系统。接下来，可以生成另外的支付授权请求并将其传输至收单行支付处理器系统，该系统负责处理对于与第一在线商户相关联的收单行的支付授权。商户ipsp系统提供一个系统，该系统使用加密技术通过互联网来传递卡数据、授权请求和授权响应，并因此提高了给定的支付授权请求的安全性。
优选地，本方法包括从第一在线商户系统接收商户身份，基于接收到的商户身份而生成的授权请求中包括该商户身份。因此，商户账户识别码传输至收单行。因此，针对这种交易的关系是在买方与在线商户之间，产生的好处在于买方受到卡方案规则和任何适用的消费者保护法的保护。
在特别优选的实施方式中，本方法是通过可信中介系统进行的，本方法包括：该可信中介系统从负责为在线商户产生支付授权请求的在线商户系统中接收支付授权请求(其关于支付交易的授权)，该接收到的支付授权请求是作为金融账户持有人经由在线商户系统进行定购的结果而被发起的。使一个集中的实体来协调各种通信具有扩展性的好处：特别地，可以响应于从在线商户系统接收到的该支付授权请求通过该可信中介系统来进行账户识别程序；可信中介系统能够接收支付授权响应并响应于此将支付授权响应传输至该第一在线商户系统。
此外，可信中介系统能为在线商户提供注册界面，通过该界面，在线商户能注册与其相关的商户ipsp系统，并可根据第一在线商户注册的商户ipsp系统来进行检索传输数据的步骤，使得支付授权请求数据传输至选定的、与第一在线商户相关的商户ipsp系统。
当由商户ipsp系统对使用本发明的系统被授权的交易进行处理时，在线商户使用对不同的交易类型公共界面来获取与这些交易有关的商户ipsp功能。这些交易类型可包括：支付授权请求经由可信中介系统发生，而另一种是单独授权的交易类型，其是可以由代表商户的ipsp在不通过可信中介系统的情况下进行处理的交易类型。该公共界面可包括安全在线网站。
对于拥有多个不同的金融账户的用户，该方法包括接收指示由金融账户持有人在多个不同的金融账户中对在支付交易中使用的账户所做出选择的数据，并且根据指出的选择来检索金融账户身份。便利地，其经由账户选择界面以有助于金融账户持有人，金融账户持有人借助该界面能够选择金融账户身份。
检索发单行传输数据的步骤可包括：检索针对选定的账户识别系统的网络地址；在一些布置中，网络地址能被传输至金融账户持有人，使金融账户持有人能访问该选定的账户识别系统。具体地，金融账户持有人能通过将识别信息提供至该选定的账户识别系统来进行识别程序。此外，在这种布置中，响应于由选定的账户识别系统对于金融账户持有人的认证，该金融账户持有人从该选定的可信中介系统接收账户识别响应。
在一些实施方式中，金融账户身份包括与该金融账户持有人相关的主账号(pan)，例如以支付卡号的形式。可替换地，金融账户身份可包括国际银行账号(iban)，或可替换地，银行识别码，优选地是国际银行识别码，诸如国家代码和分类代码，或bic代码，以及账号。但是，pan格式是优选的，原因在于其是使用现有的卡方案支付进行处理的格式。
根据本发明的另一方面，提供了一种方法，其对于经由数据通信网络做出的支付交易进行授权，支付交易作为由金融账户持有人经由商户数据处理系统做出定购的结果而被进行，该方法包括针对在线银行认证处理来访问已存储的在线银行认证详情，借助于此，金融账户持有人能够访问在线银行应用程序，该在线银行应用程序涉及金融账户持有人的至少一个金融账户，其中，该方法包括：
接收关于支付交易授权的请求，该请求作为金融账户持有人在商户数据处理系统中进行定购的结果而被发起；
响应于接收到的该请求，进行支付认证处理，其中，金融账户持有人提供与已存储的在线银行认证详情相对应的认证详情；
响应于输入的认证详情与已存储的在线银行认证详情进行验证的响应，检索在支付处理中使用的主账号(pan)；
将该检索的主账号(pan)传输至在授权支付交易中使用的互联网支付服务提供商(商户ipsp系统)。
在一些布置中，主账号(pan)仅被生成用于一次性使用。支付认证处理可由发单行数据处理系统进行，而这种方法至少能够部分地经由独立于发单行数据处理系统的交易处理数据处理系统来进行。例如，该方法可以包括发单行数据处理系统，该系统响应于对输入的认证详情的验证将检索到的主账号(pan)传输至该交易处理数据处理系统，并且该交易处理数据处理系统将检索到的该主账号(pan)传输至支付处理数据处理系统。
在主账号(pan)被交易处理数据处理系统存储的情况下，该方法包括检索该主账号(pan)，并响应于对输入的认证详情的核实将检索到的该主账号(pan)传输至商户ipsp系统。
应当理解，术语“在线商户”、“商户ipsp系统”、“可信中心中介系统”、“交易处理数据处理系统”和“收单行支付处理器系统”指的是逻辑部件。同样地，每个系统可体现为在物理上彼此分离，或物理上连接到一个或多个其他系统。例如，在给定组织作为商户ipsp系统和在线商户的主机的布置中，部件可以在物理上位于相同网络上或者甚至集成为单个系统的一部分。此外，在给定组织驻留商户ipsp系统和收单行支付处理器系统的情况下，部件可以在物理上位于相同网络上或者甚至集成为单个系统的一部分。再进一步来说，单个组织可以驻留在线商户、商户ipsp系统和收单行支付处理系统。因此，本发明的实施方式涵盖以下布置，在该布置中以ipsp角色执行的功能能够由也是商户和/或也是收单行的机构来实现。
根据本发明的其他方面，提供与在线商户系统和多个发单行通信的可信中介系统，每一个发单行都拥有与其相关的账户识别系统，该可信中介系统被布置为进行上述账户识别程序。此外，提供了与可信中介系统和多个商户ipsp系统通信的在线商户系统，该在线商户系统被布置为进行上述在线商户系统步骤。此外，提供了与可信中介系统以及多个在线商户系统通信的商户ipsp系统，该商户ipsp系统被布置为进行上述商户ipsp系统步骤。
本发明的多个方面还提供了在不同系统间分布的软件，其被适当地配置以执行上述方法。
本发明的其他特征和优势将通过参考附图、仅以示例方式给出的本发明的优选实施方式的描述中变得显而易见。
附图说明
图1是示出了根据本发明的第一实施方式的支付系统的示意图；
图2是示出了根据本发明的第二实施方式的支付系统的示意图；
图3是示出了根据本发明的又一实施方式的支付系统的示意图；
图4是示出了根据本发明的实施方式在使用图3的支付系统期间数据流的示意性流程图；
图5a是示出了根据本发明的实施方式的可信中介系统的部件的示意性框图；
图5b是示出了在根据所实现的本发明的实施方式的可信中介系统内的可信中介的部件的示意性框图；
图6是示出了根据本发明的实施方式的、与账户选择有关的消息流的示意性时序图；
图7至图10是示出了对于图6中所示的消息流可替换的消息流的示意性时序图；以及
图11是示出了采用本发明的另一实施方式的可替换、端到端的支付选择路径的示意性流程图。
具体实施方式
正如以上描述的，本发明的实施方式涉及支付系统和方法，具体地，涉及对于经由数据通信网络要进行的支付交易的支付授权请求进行处理的系统和方法，该支付授权请求作为金融账户持有人通过用户系统(诸如，个人电脑或其它计算装置)经由多个不同的在线商户系统的定购的结果来进行。
图1示出了根据本发明第一实施方式的支付系统，其中金融账户持有人利用用户系统u1持有关于多个不同发单行2a、2b的账户；这些发单行包括以下银行：其分配适当的借记卡号使得支付款能经由对于用户的卡方案系统汇回到消费者的经常账户，并且对于用户偿还有关该卡产生的任何债务的能力承担第一债务责任。然而，正如上面描述的，发单行将与用户的银行账户相关联的卡分配给用户的情况被视为本发明的实施方式的非限制性应用实例。正如可以从图中看到的，用户系统u1经由数据通信链路连接，当通过互联网购买物品时，金融账户持有人经由该用户系统u1能够参加与多个在线商户系统1a、1b、1c之一的交易。在线商户系统配备有使用户能够选择用于购买他们所选择物品的支付方法的软件，在本发明的实施方式中，支付选择软件包括以下选项：用户系统ul访问可信的中介系统4，金融账户持有人借助该中介系统能够指定特定的银行账户，用以从该账户中扣除支付款。
在优选的布置中，选择该选项触发了在线商户系统1a将用户重新定向到可信中介系统4，然后开始了涉及可信中介系统4、用户u1、以及多个发单行2a、2b之一的账户识别程序。因此，从商户的在线购物软件中选择银行账户选项有效地导致用户u1被重新定向并且与可信中介系统4以及相关的发单行2b通信；这些重新定向步骤在图中以虚线的方式示出。经由用户系统ul的金融账户持有人被要求(例如)通过从下拉列表中进行选择或直接输入数据来指定支付款要从其扣除的发单行的识别码，例如以国家代码和银行名称的形式(例如“gb”以及“hsbc”)，或诸如银行识别代码(bic)、swift代码，或银行汇款路径号码(也称作美国银行协会(aba)号)的代码，因此可信中介系统4识别相关的发单行系统2b(例如，通过查询保存了用于一系列发单行的在线银行网站详情的表格)，并重新定向用户系统ul以与其通信。在基于互联网的布置中，该重新定向可涉及将用户的浏览器定向到与发单行相关的网络服务器(通常称为在线银行登录页)。然后，金融账户持有人经由用户系统ul按照正常的方式登录进入他们的在线银行账户，发送在至少一次支付交易授权中所使用的账户识别请求。
正如以下将参考图6详细描述的，在可信中介系统4的控制下发生重新定向，也就是说，向用户显示的网页有效地封装在由可信中介系统4控制或与之相关发布的网页内。因此，一旦选择了要从中扣除支付款的账户，可信中介系统4随后从发单行2b接收能够用于该交易的、识别金融账户身份的账户识别响应。
该账户识别响应可包括：通常与链接至用户账户的借记卡相关的主账号(pan)；因此应当理解，本发明的实施方式尤其适于以下情况：用户u1期望从支付工具(通常是卡或者账户)中实现支付。一旦可信中介系统4接收了pan，就将其以支付授权请求的形式传送至收单行5处理器，或通过用户将支付详情输入商户在线系统的传统方法将pan传送至与商户1a相关收款人。该pan附有交易信息和商户的账户识别码，卡方案系统7将该交易路由至同一卡发单行2b。发单行2b接收授权请求并将具有响应码的响应发送至商户的收单行5的处理器，商户的收单行5的处理器按此将该响应转送到可信中介系统4。然后，可信中介系统4将响应转送到商户系统，在该系统中解释该响应并将相关的响应传递回持卡人和商户。按常规方式进行随后的清算和结算，并且涉及收单行5将核定的金额总数存入商户指定的账户。应当理解，与该处理中的结算部分有关的通信可通过单独的或双重的消息实现方式来实现。
尽管前述的实施例所描述的支付系统1的操作涉及从可信中介系统4发出的单个支付授权请求，但系统1也可以用于多个支付授权请求。可信中介系统4能够进行综合账户识别程序，该程序包括将用户u1重新定向到已识别的发单行，以便执行单个的前述账户识别请求程序，用于向收单行5处理器消息通知所有随后支付授权。用户u1可在生成每个支付授权请求并将其发送到收单行5处理器之前执行账户识别请求程序。可替换地，可信中介系统4能够重新定向用户从而进行个人账户识别程序，每一个该程序用于每个支付授权请求。
图2示出了支付系统的可替换实施方式，其中，系统1包括商户互联网支付服务提供商(商户ipsp系统)，该系统是由商户出于在互联网上进行安全贸易的目的所选择的支付网关。商户ipsp系统3提供了一个使用加密技术通过互联网来传递卡数据、授权请求和授权响应的系统。交易信息经由商户ipsp系统3发送至卡方案系统7，在卡方案系统中检验卡的有效性并且验证在该账户上的可用资金。授权码返回至收单行系统5并前进至商户ipsp系统3；该授权由商户ipsp系统3进行加密进而以加密的形式被传输至可信中介系统4，该可信中介系统将合适的响应发送至触发完成该定购的商户1a的网络服务器。因此，在该实施方式中，在将账户识别响应向收单行5的处理器的传输中涉及商户ipsp系统3。
在优选的实施方式中，在本文中称为可信中介的新型交易实体内包括可信中介系统4，正如现在将参考图3描述的，该可信中介与支付系统1的其它支付实体合作。可信中介10被示为能够将支付授权请求传输至多个不同商户ipsp系统3a、3b中的每一个。在线商户处理系统1a…1c中的每一个与商户ipsp系统3a、3b之一关联(如对于商户之一1c，虚线l1表示的)，也与收单行之一5b关联(如仍对于商户之一1c，虚线l2表示的)。至少一些商户ipsp系统3a、3b能被布置为将支付授权请求发送到多于一个收单行：这反映出的事实是，多于一个商户可经由给定的商户ipsp系统处理他们的支付，但每一个商户拥有关于不同收单行的账户。进一步地，根据本发明的实施方式，每一个商户在线处理系统1a...1c被更改为包括作为支付选项的“从经常账户支付”(pca)，其经由包含在可信中介10内的可信中介系统4来识别支付请求。
可信中介10将对应于已向该可信中介10注册的商户和发单行的数据连同交易数据保存在数据库db1中。由于可信中介10是与商户的现有商户ipsp系统交互而不是替代它，因此传递到收单行5b的是商户账户识别码。因此，这种交易的关系是在买方和在线商户之间，产生的益处是买方受到卡方案的规则和任何适用的消费者保护法的保护。另外，商户ipsp系统可为在线商户提供一项或多项附加的多种交易处理功能，例如，代表在线商户系统进行结算、处理拒付、处理退款和交易报告。另外，由于根据本发明实施方式的支付系统涉及在现有及已知的处理实体集合内添加可信中介10，因此除了经由可信中介10之外或替换经由可信中介，可以使用在背景技术部分中所描述的第一类型和第二类型布置根据传统方法进行支付。
现在参考图4，来描述根据本发明实施方式的支付系统1的操作。在步骤s401中，用户利用商户c的在线商户系统完成他们的购物体验，使用该商户系统发起结账，并根据通过通常可用的购物车和结账软件包(诸如，那些对于技术人员熟知的软件包)可用的传统方式继续进行虚拟结账。用户选择“从经常账户支付”(pca)作为支付选项(步骤s401)，引发商户处理系统lc将请求消息传递到可信中介10(步骤s403)；请求消息至少包括所选商品的支付金额、商户账户识别码以及该定购的识别码。然后，可信中介10将登录url发送给消费者(步骤s405)，提示用户开始账户选择处理：为用户呈现选择页面，用户按照参考图1所描述的方式将希望用于此次交易的发单行的名称和国家代码输入至该选择页面(步骤s407)。然后，可信中介10执行查询以获得相关发单行的url，并将重新定向指示发送至用户的浏览器，使用户的浏览器被重新定向到与他们已识别的发单行对应的在线登录页面(步骤s409)。用户u1使用他们的在线银行凭证(诸如，客户号码、密码、不易忘记的个人数据等)进行登录，使得发单行软件发送合格的支付账户列表和相应的借记卡详情以供用户u1选择(步骤s411)。正如以上描述的，账户和卡详情包括用于每个相应账户的pan。
一旦选定了所期望的账户，可信中介10就将授权请求消息发送至商户的商户ipsp系统3b，该请求消息包括选定账户详情、所需支付额以及商户识别码(步骤s413)。商户ipsp系统3b将授权请求发送至相关的收单行5b(步骤s414)，按照传统方法提示进行授权(或其他)(步骤s415)，将来自收单行5b的响应消息传输至商户ipsp系统3b(步骤s417)。假定该响应包括已授权的支付确认，在步骤s419中，商户ipsp系统3b将支付成功通知消息发送至可信中介10。该支付成功通知消息包括用于卡方案授权的参考以及用于卡方案交易的交易识别码。
此后，可信中介10将支付成功确认消息发送至商户系统1c(步骤s421)，该消息提示商户系统确认该用户的订单状态(步骤s423)。
从上述内容可以理解，传统的商户系统(包括他们的商户ipsp系统)需要进行更改从而包括“经常账户支付”(pca)作为支付选项并且确实与可信中介10交互。因此，商户ipsp系统向可信中介10显示支付授权业务，允许对于支付工具(通常为卡和银行账户)的支付和结算。此外，应理解，因为可信中介10与许多商户ipsp系统结合，因此该可信中介包括多种接口格式和协议，每种接口格式和协议均对应于相应的商户ipsp系统。此外，每个商户的系统配置有综合软件组件(例如，以插件形式)，其允许商户与可信中介10结合，以便使用pca作为支付方法来发起支付交易。
现在将参考图5a来描述可信中介系统4(文中称为pca)的配置和处理能力的细节。此后，将参考图5b描述被称为“安全支付系统”(ssp)的可信中介10的细节，在该可信中介中最便利地实现可信中介系统4。
可信中介系统4包括：呈现及连接处理部件504，其被配置为传输及管理各种银行专用数据和商户专用数据；下面将更详细地解释这些处理部件，但是总体上看，包括以下内容：
银行数据存储器：
可信中介系统4存储针对那些已签约“经常账户支付”(pca)服务的发单行的银行识别码(例如以银行识别码(bic)的形式)、或国家、支行和银行名称。对每个列出的发单行，数据库db1也保存识别对应于他们的在线银行签署页面的url的数据。
商户数据存储器：
可信中介系统4存储商户简档和注册数据。这些数据包括：商户账户识别码以及商户系统向其注册的商户ipsp系统3b的交易和网络识别码。保存这些数据从而使可信中介系统4能够按照上述方式来代表商户系统与商户ipsp系统3b进行通信，合称为商户ipsp系统传输数据或简单地称为传输数据。此外，可信中介系统4包括支付授权服务，可信中介系统4通过该服务来代表商户实现支付。此外，由于可信中介系统4与许多商户ipsp系统结合，因此其包括多个接口格式和协议。在商户数据存储器中保持用于每个商户ipsps系统的相关格式和协议详情。因此，上述传输数据包括从给定在线商户系统发出的支付授权请求对于ipsp识别码、网络地址和/或网络协议的映射，该映射使支付授权请求能够路由至相关商户ipsp系统。
因此，应该理解的是，任何提供pca服务的给定商户的注册均涉及商户指定其预定的商户ipsp系统。便利地，可信中介系统4可保存一组对应于激活的商户ipsp系统的记录：每组记录可包括网络识别码和可信中介系统4所需的储存在数据库db1中的通信协议。因此，在向可信中介系统4注册期间，给定的在线商户可以(例如)经由可信中介系统4的呈现部件504协调的下拉式列表来选择该在线商户预订的商户ipsp系统；然后，相应的传输数据(或至其的链路)可结合保持在数据库db1中的商户记录进行存储。因此，如果给定的在线商户响应于接收到来自商户系统的支付授权请求而已经以上述方式指定了其相应的商户ipsp系统，则可信中介系统4可对数据库执行适当的查询进而检索与相应的商户ipsp系统对应的网络识别码、协议要求等。
应用编程接口(api)服务适配器：
可信中介系统4包括api服务适配器，其实现可信中介系统4与支付系统1的消息基础设施之间的连接。该适配器被配置为管理可信中介系统4对外部服务(诸如对于商户ipsp系统3b的支付授权)的请求的实行，并且被配置为显示一组可由诸如商户ipsp系统3b的外部功能使用的可信中介系统4服务。
交易专用部件和数据：
可信中介系统4储存交易数据，诸如由可信中介系统4管理的支付授权和结算。此外，可信中介系统4可储存与商户在线活动以及整体系统活动关联的审计数据。
需要注意的是，上述部件未包括用于储存用户专用数据的装置，这是因为用户实时地(即，在实现交易的时刻)指定支付方法，并且因为用户要由其在线银行来认证支付服务。因此，可信中介系统4不必保存用户专用数据。然而，应当理解，这是本发明的一个可选方面：可信中介系统4可以、并且事实上在一些实施方式(诸如下文参考图11所描述的实施方式)中需要存储用户凭证。实际上，当用户选择使用由可信中介10(下文称为“ssp”服务)提供的可替换功能时，用户数据被接收进而保存。以下参考图5b描述由可信中介10提供的相关功能。
属于图5a中所示的布置，且如上所述，可信中介系统4优选地作为网络应用服务器实现，例如，作为管理并提供对于平台的公共业务逻辑进行访问的j2ee兼容的应用服务器501，以及用作来自商户和用户的浏览器的、对可信中介系统4的外部http请求的进入点的网络服务器&j2eeservlet引擎503。
网络服务器和servlet引擎503包括呈现部件，其向商户系统显示基于网络服务的支付api或api包装。此外，网络服务器和servlet引擎503包括上述的呈现处理部件504，其被配置为生成和管理如上所述的对于商户和银行的界面。
j2ee应用服务器501管理用于网络平台和应用程序的所有业务逻辑。业务逻辑包括：功能软件部件511a、511b，其可实现为(例如)会话ejb(enterprisejavabeans)。例如，这些功能组包括：支付服务逻辑、以及欺诈与安全服务模块；此外，服务器501还包括实现为ejb3.0指定java对象511a、511b的对象，其提供对于储存在db1中的、诸如上述的审计数据和交易数据的静态和持久数据的存取。可信中介系统4还包括处于包装形式的网络服务，其向支付系统1的其他元件显示会话ejb。更具体地，在其他对象中，功能对象511f、551g与外部服务使能器(诸如欺诈服务515a)交互合作。这些应用服务器部件511f、511g经由一组api(通称为与部件513a相关的api)与应用程序部件通信。当实现为网络服务器时，使用安全机制(例如，经由通过安全套接层协议的http(https))将数据在支付系统1的元件(即，在图3和图4中示出的那些元件)与可信中介系统4之间传输。
如上所述，除了按照以上方式协调用户u1的账户选择并因此结合可信中介系统4之外，可信中介10包括以下功能：除了基于每次交易来指定交易额之外或作为其替换，使用户u1能够从多个预配置的账户中进行选择。经由在本文中称为“安全支付系统”(ssp)的服务使上述功能对于用户是可用的。如将在下文中详细描述的，数据库db1能以存储的一组记录的形式(其便利地称为远程存储器、或用户钱包)为用户保存一组支付详情；用户可添加其能选择用于为交易进行支付的账户和卡的详情，使得可信中介10更新用户钱包的内容。这使得用户能够基于每次交易选择支付方法，同时消除对于用户为单独的商户提供支付详情的需求。因此，假设商户预订可信中介10，用户只需仅仅一次向单个实体提交其相应的支付详情。其优势在于，与要求用户u1经由商户系统输入他们的卡支付详情的传统支付系统相比，降低了可能发生的欺诈的风险。
也如上所述，可信中介10连接至发单行系统2a、2b。该连接有助于使用熟知的3-d安全认证机制对持卡人(买家)在将支付手段添加到其钱包时对其进行验证。在以visa国际服务协会的名义、公开号us2002/0194138公开的美国专利申请10/156，271中评述了用于3-d安全的协议，其全部内容结合于此作为参考。该协议使用通过安全套接层(ssl)连接发送的消息(通常为xml消息)，正如在前述专利公开中作为支付人认证服务(pas)所评述的。当向用户钱包添加支付工具或当可信中介10确定给定的请求交易符合预定风险等级时(诸如可能是交易涉及高价值商品运至国外的情况等)，可使用该服务。在下文中更详细描述了执行风险评估的方式和对给定交易实际确定的风险等级。
如通过虚线l3示意性示出地，卡方案系统7通信地连接至可信中介10；这表明可信中介10已经预订了卡方案系统7提供的账户更新服务(未标示于图3中，但下文中参考图5b作为部件515d进行了描述)，并由此接收更新的卡信息，例如，当卡遗失、被盗或过期并因此重新给用户发卡时。这种服务的实例是visa账户更新器服务(vau)，而另一个是masercard自动记账更新器。在一种布置中，对于由卡方案系统7提供的账户更新服务的界面是批次导向的：可信中介10向卡方案系统7提交请求，该请求包括向系统10注册的特定用户详情。批界面通常用于(例如，安全文件传输协议(sftp)或connect:direct(tm))将请求文件发送至账户更新服务，其中，账户更新服务负责收集重发卡的详情。在一段时间后，可信中介10接入账户更新服务并收集响应文件，然后为ssp系统的相关用户本地更新支付手段。可替换地，该界面可以是基于消息的，从而实时地校验或更新个人主账号。作为直接将请求发送至卡方案系统7的可替换方式，可信中介10可模仿在线商户的操作将请求发送至已知的收单行系统5a…5c，用于随后转送至卡方案系统7。
图5b为可信中介10的部件的示意性图示。由于在该布置中，使用网络服务器技术将可信中介系统4在可信中介10内实现，因此在一个实施例中，可信中介10也是网络服务器。为了提供ssp服务，可信中介10包括以下元件：
用户注册部件和数据：
当用户希望利用由可信中介10提供的、预存储的支付手段便利条件时，他们需要完成账户注册处理，该处理允许用户创建所谓的“安全支付系统”(ssp)账户。要求该账户由适当的数据构成，该数据可用于经由从提供ssp服务作为支付选项的商户系统的ssp服务来进行支付。
可经由任何适当的界面来执行用户向可信中介10的注册，最便利地，当可信中介10实现为网络服务器时经由网络浏览器执行注册。一旦注册，每个用户都有与其相关的简档，其储存针对用户的人口数据和识别数据，且可通过呈现部件504对该简档进行更改，并且能够显示用户交易数据用于用户查看。此外，用户还可拥有地址簿条目，其保存运送详情；呈现部件504使用户能够更改运送详情。如图5b所示以及在下文更详细解释的，在可信中介10实现为网络服务器的情况下，呈现部件504与用户的浏览器交互从而允许以上述方式对用户数据进行选择和修改。
注册可经由多种渠道来实现：
·经由“安全支付系统”(ssp)站点——用户登录可信中介10的网站并对该用户呈现注册页面，该页面被设计为获取用户的身份和优选的支付详情。
·从支付处重新定向——如果用户在商户的在线系统内且希望使用“安全支付系统”(ssp)选项进行支付，则如果还未注册的话，他们需要进行注册。用户被重新定向至与可信中介10相关的注册屏面，然后被重新定向回商户的在线系统。
·经由在线银行进行注册——假设可信中介10包括必要的集成功能，则用户可注册来自其银行的在线账户管理内的“安全支付系统”(ssp)服务。
用户认证部件：
根据下面列出的3种已知类别可直接利用可信中介10、或经由用户的在线银行可以执行对用户进入ssp服务用于支付交易的认证，在经由用户的在线银行的情况下，用户登录其在线银行账户(使用以下列出的三种类别之一)，因此银行系统软件将用户重新定向回可信中介10。
1-因子认证—用户知晓的事物(例如，用户名和密码、通行短语或个人身份号码(pin))
2-因子认证—如同1因子认证加上用户所拥有的(例如，身份证、安全令牌、软件令牌、电话或手机)
3-因子认证—如同2-因子认证加上用户处于或进行的(例如，指纹或视网膜模式、dna序列(对于何为充分具有多种定义)、签名或语音识别、唯一的生物电信号或其他生物特征识别码)
实现认证机制的实例为上述的3-d安全服务——通过可信中介系统10变得更加便利，发单行提示买家仅对于银行和买家知晓的密码。由于商户不知道该密码且不负责获得该密码，因此发单行可将该密码用作购买者确实是其持卡人的证据。
用户账户数据：
如上所述，用户可有一组与其相关的记录(例如，以远程储存器或钱包的形式)，其储存用户输入的支付工具的详情，并且用户希望以永久方式储存其详情用于经由可信中介10检索和存取。呈现部件504使用户能够选择和添加/移除支付手段列表。
交易专用部件和数据：
除了储存与商户在线活动相关的审计数据外，可信中介10还可储存用户活动数据。
消息通知服务：
可信中介10配置有电子邮件代理，其编写和发送电子邮件，用于电子邮件地址认证、用户激活以及定购单确认。
网络服务器及servlet引擎503包括呈现部件，其向商户系统显示基于网络服务的支付api或api包装506。
除了上述业务逻辑部件511f和511g外，j2ee应用服务器501还包括功能软件部件511c...511e，该功能软件部件与诸如下列的外部服务使能器引擎504协作：地址确认服务515a、电子邮件应用程序(包括接入电子邮件服务器)515b、3-d安全服务515c、账户更新服务515d、以及欺诈服务515e等。与图5a所示布置一致，应用服务器组件经由一组api(通常与部件513a...513e相关)与应用部件515a...515e通信。
在3-d安全服务功能部件511c的情况下，该部件使用基于风险的规则或与该规则合作，其中，该规则被调用从而确定在用户与可信中介10之间的交互中是否应当涉及该部件。该规则通常在欺诈服务515e的控制下进行配置，并且例如可以针对以下情况来明确指明在用户向ssp服务注册支付工具时应当调用3-d安全方法(以确保该用户为合法持卡人)：针对买方进行的第一笔交易；针对超过确定金额的交易；针对涉及了商品运出买方国家领土的交易；以及针对特定种类的商品和/或服务。可触发3-d安全服务的其他事件(包括针对所有交易调用该服务)对于本领域的技术人员是显而易见的。
转到卡方案系统7提供的账户更新(au)功能部件511d和相应的服务515d，au部件511d包括定期检验数据库db1中的个人用户钱包中储存的支付工具的终止日期的例行程序，并向卡方案系统7提交关于支付工具要在指定的时间窗内到期的用户详情的请求。随后，au部件511d访问账户更新服务511d，收集其生成的响应文件，进而基于响应文件的内容更新相关用户钱包中的支付工具。
现在将更详细地描述上述参考图4描述的处理步骤，具体地，根据本发明的第一实施方式，由可信中介系统4执行的步骤使用户能够选择用于支付的交易账户。转到图6，在步骤s6.1，用户选择“经常账户支付”(pca)作为支付方式并向商户网站提交其选择。这触发了来自商户系统的请求，具体地，由商户系统检索对应于来自可信中介10的pca服务的url。这导致商户网站利用内嵌框架重载其支付页面，该页面内容对应于pcaurl，随后发送密匙命令并创建安全会话(步骤s6.3)。收到了来自可信中介10的pcaurl，用户u1通过输入银行识别码(诸如，国家、银行和支行)选择银行识别代码(bic)(步骤s6.5)。
然后，该选择被转送至可信中介系统网络应用程序501(步骤s6.7)，触发应用程序501检查该选定银行为pca服务的参与者(步骤s6.9)。假定情况如此，可信中介系统4从数据库db1中储存的数据中检索银行登录页面的url，将其发送给内嵌框架(步骤s6.11)，使得用户的浏览器将用户定向至其在线银行网页(步骤s6.13)。需要注意的是，用户登录其在线银行账户用于向可信中介4进行认证，即，不需要利用中介支付处理实体10进行第二次认证处理。
然后，用户u1输入其在线银行详情(步骤s6.13)；假定登录成功，银行软件就激活自到期令牌(步骤s6.15)。该令牌作为认证证据可用于任何api调用，且因此返回至内嵌框架，与指令一起将内嵌框架重新定向回可信中介系统4(步骤s6.17)。该重新定向指令触发要被发送到可信中介系统4应用程序的请求消息，命令可信中介系统4应用程序请求来自银行软件的、用于该用户的账户列表(步骤s6.19)。因此，使用在步骤s6.17中传输至可信中介系统4的认证令牌进行对于在线银行软件的api调用，从而获得账户列表和pan(步骤s6.21)。然后，账户列表发送到可信中介系统4应用程序(步骤s6.23)，该应用程序生成用于向用户显示的账户选择页面(步骤s6.25)，使用户能够选择账户并将其选择提交至可信中介系统4应用程序(步骤s6.27)。然后，再次使用银行令牌，可信中介系统应用程序501将该账户选择连同对于与选定账户对应的账户识别码的请求转发至发单行软件(步骤s6.29)。作为响应，银行软件将通常与链接至用户账户的借记卡相关的pan号返回到可信中介系统4应用程序(步骤s6.31)。
接收了pan，网络服务器及servlet引擎503经由支付授权服务将支付详情发送至商户的商户ipsp系统3b，通过该支付授权服务，可信中介10实现代表商户的支付要求提交；这涉及到针对收到支付api506来创建授权请求，将支付授权请求转换为api格式的商户api，且将该格式化的请求传输至商户ipsp系统3b。结算请求也传输至支付api506，其执行将结算请求转换为api格式的商户api并将其传输至商户ipsp系统3b。应理解的是，该通信可通过单一的或双重的消息实现方式来实现。这些格式化和传输动作记录在由对应于商户系统的可信中介10保存的交易数据储存器中。
一旦通知授权该支付请求，网络服务器及servlet引擎503就将回执商户url以及成功授权的通知传输到内嵌框架，使内嵌框架清空，以来自商户系统的javascript代码进行重载，并因此移除内嵌框架，进而将用户返回到商户的网站。最后，商户显示成功支付页面。
特别地，图6所示处理的优势在于向用户呈现该用户自己的银行品牌签署页面；此外，银行也对认证用户承担完全责任，因此可应用其自己的认证方法和领域。再者，由于银行软件发送令牌到可信中介系统内嵌框架，并且该令牌被传送到可信中介系统应用程序501，使可信中介系统应用程序能够开始与发单行的通信会话，向用户呈现标准化界面用于从其银行检索账户识别码以及相关的账户识别码。
平行于前述步骤，应用服务器501可记录用户活动并将其发送到审计数据储存器，同时发送相应的系统和事件信息到第三方欺诈通知系统(由图4中所示的公共服务使能器之一515a代表)。欺诈通知系统包括，但不限于：欺诈风险引擎，其执行欺诈风险分析，以便生成风险评分以及针对该交易的推荐动作；已知诸如由rsatm在其防欺诈套件中提供的适当的欺诈通知系统，此处不再赘述。风险评分和动作以及针对商户和用户的其他交易详情储存在数据库db1中。
构想使用户能够从其发单行选择账户的可替换方法：图7至图10中示出了这种可替换方法的实例。图7与图6中所示实施方式的不同之处在于：响应于用户已提交了其签署详情，发单行发送账户选择url，使得在银行软件的直接控制下而非经由银行软件提供的api来提供用户账户。因此，步骤7.1至7.13依次进行每个步骤6.1至6.13，然后在步骤7.15处，银行软件将账户选择url发送到商户网站中载入的可信中介系统的内嵌框架。一旦显示，用户可从所列账户中选择账户(步骤7.17)，然后所选账户提交给银行软件(步骤7.19)，并且将对应于所选账户的pan号传送到可信中介系统应用程序(步骤7.21)。
图8示出了一种布置，其中，可信中介系统4和发单行之间的交互已经传送至诸如rsa(tm)或arcot(tm)第三方：该第三方代表发单行来提供服务。步骤8.1至8.19依次进行作为每个步骤6.1至6.9；在步骤8.11处，可信中介系统4根据配置数据识别作为由第三方驻留的银行签署url，且将其显示在内嵌框架中。随后，用户输入其登录详情，这些详情被传输到第三方(步骤8.13)。作为响应，第三方提供主机服务为任何随后的api调用创建自到期令牌(步骤8.14)，并将账户选择url发送到内嵌框架，用于在商户网站上向用户显示。如参考图7的步骤7.15至7.21所描述的，依次进行步骤8.15至8.21。
图9示出了一种布置，其中用户将其在线银行详情提供给可信中介系统4，随后，该可信中介系统使用签署信息自动登录到发单行，然后检索账户列表。在该布置中，可信中介系统应用程序503作为在线商户系统与发单行之间的介体。如参考图6所描述的，步骤9.1至9.11依次进行，但在步骤9.13处，登录详情被发送到可信中介系统应用程序503，该应用程序检索银行登录url，并利用在步骤9.13处接收到的用户登录详情来构造该银行登录url，且代表用户执行登录至在线银行软件(步骤9.15，步骤9.17)。然后，账号被传输至可信中介系统应用程序503(步骤9.19a)，该应用程序将该账号连同成功登录的通知一起转送至内嵌框架(步骤9.19b)。在内嵌框架内显示账户选择页面(步骤9.21)，且用户的账户选择被转送至可信中介系统应用程序503，用于转交至发单行网络服务器(步骤9.23，步骤9.25)。最后，pan从发单行网络服务器发送到可信中介系统应用程序503(步骤9.27)。
图10示出了一种布置，其中可信中介系统应用程序503使用api从而自银行软件检索账户列表。对于图9的实施方式，需要用户首先选择其银行，然后可信中介系统应用程序503提供签署页面用于用户输入其在线银行签署详情。然后，对发单行进行调用，从而检索针对用户提供的签署信息的账户列表。更具体地，如参考图6所描述的依次进行步骤10.1至10.13，然后在步骤10.15，响应于对用户的签署详情的接收，发单行软件生成认证令牌，其随后被传输至可信中介系统4的内嵌框架(步骤10.17)。作为响应，可信中介系统4发送对应于用户的账户列表请求(在步骤10.15认证)，该请求伴随有认证令牌。假定认证令牌与步骤10.15处生成的令牌匹配，则账户列表发送到中介系统应用程序503(步骤10.19a)，该应用程序暂时储存账户(包括账户识别码)，且在商户的在线系统处在内嵌框架中调整其显示(10.19b)。因此，当用户从列表选择账户时(步骤10.21)，就会导致中介系统应用程序503根据储存在其自身本地及临时储存器中的号码来识别对应的pan。
作为另一可替换方式，用户可由可信中介10认证并将责任委托给可信中介10从而实现登录到用户选定的银行账户。登录可基于用户提供的一组合适的凭证执行，诸如信用卡号和/或到期日，用户可以实时输入或从储存的卡详情中选择这些凭证，且其形成选定的发单行对用户进行认证的基础。
图11为总流程图，示出了在“安全支付系统”(ssp)服务的控制下、使用根据本发明的实施方式所选定的支付手段来实现支付的过程中涉及的步骤：在步骤s11.1，用户从商户的在线购物软件中选择“支付和注册”选项，然后用户首先被要求通过提供个人信息(诸如，姓名、电子邮件地址、密码、联系电话以及可能递送地址)来创建ssp账户(步骤s11.2)。这些详情被存入数据库，然后向用户呈现两个选项：或是通过卡进行支付或是从经常账户进行支付。标记为分支的步骤11.3a总体上对应于参考图1至5a以及图6至10描述的处理步骤，而步骤11.3b对应于用户选择输入并储存要用于交易的卡的详情的选项。因此，后一种可替换方式使用参考图5b所描述的可信中介10的ssp功能，其中，呈现部件504向用户提供输入卡详情的界面，然后将其储存在数据库db1中。如上所述，优选地，当用户输入相应卡的详情用于储存在其钱包和/或响应特定交易事件时调用3-d安全部件511c。
然后，不论用户选择的支付选项如何，提示用户验证其全部交易详情是正确无误的，或通过(例如)提供可选递送地址对交易详情进行添加/编辑。然后，用户可以结束交易。一旦完成了支付选择处理，可信中介继续进行(例如)参考图4的步骤s413至s421所描述的交易，利用将确认消息传送到在线商户来完成该过程。
根据以上所述，应该理解，本发明的实施方式可视为包括数个部分，即a)调用；b)认证；c)账户选择；以及d)支付途径。关于部分a)，“经常账户支付”(pca)选项可直接从在线商户的网站调用(如参考图1-8所描述的)，或者经由“安全支付系统”服务(ssp)调用(如参考图11所描述的)。
关于对用户针对选择支付账户的请求的认证，可使用用户银行保存的信息在选定发单行的控制下执行(图1-8)，或在可能涉及注册处理的可信中介10的控制下执行(图11)。在这两种情况下，应该理解的是，不需要像可信中介一样进行注册，原因在于根据用户成功登录其在线银行账户已有效地对该用户进行了认证。
关于支付账户的选择，用户在一个给定的发单行内可以有多个账户，而且实际上可能拥有关于多个发单行的账户。因此，呈现给用户的界面(不管其直接来自在线商户的系统，或经由ssp服务)使得用户可识别其选定的发单行以及其中的实际银行账户。当通过发单行进行认证时，银行向用户呈现账户列表，该用户选择银行账户详情并将其发送到pca服务。当通过ssp服务进行认证时，ssp服务基于之前保存的数据呈现账户列表，供用户选择。
最后转向支付途径，如参考图1至10所描述的，可经由与买方相关的商户ipsp系统、使用提供的pan来实现交易。作为可替换方式，可经由卡方案系统或收单行系统从用户账户记账该交易并存入商户账户。作为另一可替换方式，可经由可选的账户密匙从用户账户记账该交易并经由可选账户密匙存入商户账户。
以上实施方式应理解为本发明的示意性实施例。构想本发明的其他实施方式。例如，尽管在前述实施例中，可信中介10被描述为接收来自在线商户系统的支付请求，在商户ipsp系统向用户提供结账服务的布置中，可信中介10可附加地或可替换地接收来自商户ipsp系统的支付请求。在这类实施方式中，这种商户ipsp系统被更改为提供“安全支付系统”(ssp)作为附加的支付选项。
然而，在以上实施方式中，金融账户身份以pan的形式给出，在可替换方式中可以使用其他的金融账户身份。例如，用户的国际银行账号(iban)，或可替换地，银行识别码(其优选地为诸如国家代码和分类代码，或bic代码)，以及账号。然而，优选pan格式，原因在于使用现有的卡方案支付处理该格式。
尽管在以上实施方式中，使用与用户的金融账户永久相关的pan，可替换地或附加地，发单行系统可提供一次性pan(生成其用于一次性使用)作为账户识别码响应，并且由发单行系统存储大量的这种一次性pan并将其映射至单个金融账户。
此外，在以上实施例中，假定该处理的起点为在线商户的网站；然而，在原始交易不是在线商户系统的情况下，也可结合实现票据支付或其他发票来使用本发明的实施方式。传统的票据支付情况假定典型地通过自动化交易所(ach)从买方(买家)到收款人的推式支付(pushpayment)，从而由买方(支付人)的发单行发起该支付。尽管在情况下是从除了商户系统之外的起点发起该交易，但实际的金融交易仍然通过商户的代理进入交易处理环境。因此，从金融方面来说，应视为拉式支付(pullpayment)；然而，因为该支付由买方(支付人)发起，用户会认为其为推式支付。
此外，尽管优选实施方式使用内嵌框架网络技术将用户导航至不同的网站，应该理解的是，作为替代，可以采用标准的网站重新定向。在这种可替换布置中，取决于用户浏览器在任何时间点通信的实体(或其对应的url)，用户的浏览器将被导航离开以及导航回到可信中介系统4网站。例如，在认证和/或用户选择账户期间，用户浏览器可由ssp网站重新定向到用户发单行提供或代表用户发单行的网站，并且一旦完成用户认证和/或账户选择，用户浏览器就可由发单银行网站重新定向回到ssp网站。
上文中，当术语“系统”用于诸如商户系统、商户ipsp系统、可信中介系统、账户识别系统和其他实体的实体时，该术语应当理解为表示经由数据通信链路连接至其他数据处理功能的、在一个或多个物理站点处提供的数据处理功能。每个功能可以通过以下各项提供：单个数据处理节点(例如，服务器计算机)、或彼此提供故障切换备用的一组数据处理节点(诸如，服务器计算机机群)、和/或关于组中的其他组件提供不同的模块化子功能的一组互连的数据处理节点(例如不同服务器计算机的交互工作组)。
从上述内容可以理解，在包括支付系统1的多种实体之间的通信经由诸如互联网的数据通信网络进行。支付系统1的每个实体(发单行；发单银行内的账户识别系统，其用于识别要从中扣除支付款的经常账户；可信中介系统；可信中介；收单行处理器；商户ipsp系统；以及在线商户系统)经由诸如互联网协议(ip)地址或其他适当的识别码的网络识别码是可识别的。
因此，通信网络可包括包含了一种或多种技术的固定线路网络，即，混合通信网络；例如，该网络可包括与公用开关电话网络(pstn)结合的互联网和/或能支持例如一种或多种以下通信协议的移动通信网络：gsm(全球移动通信系统)、wcdma(宽带码分多址)、gprs(通用分组无线业务)。除了移动通信网络之外或作为其替代，诸如无线局域网(wlan)或蓝牙
上述实施方式之一涉及本发明关于具有关联的卡的银行账户的应用；其他的实施方式不需要银行账户与任何类型的支付产品关联，尽管其他的实施方式依然可能涉及与诸如手机或生物特征信息的支付产品相关的银行账户。可构想其他应用。
应当理解，关于任何一个实施方式所描述的任何特征都可单独使用或与所描述的其他特征组合使用，也可与任何其他实施方式的一个或多个特征组合使用，或与任何其他实施方式组合使用。此外，在不偏离所附权利要求限定的本发明的范围的情况下，也可采用上面未描述的等价物和变形例。
- 还没有人留言评论。精彩留言会获得点赞！