CN104603808A - 支付装置和方法 - Google Patents

Abstract

一种用于从付款方向收款方执行支付的方法，其中方法包括：接收对支付的支付请求，支付请求响应于收款方从付款方请求资金而生成；使用支付请求生成交易代码和支付明细，交易代码由付款方获得；从付款方接收交易代码；以及，响应于接收交易代码，向付款方提供支付明细中的至少一些，支付明细中的至少一些包括支付金额和收款方的指示，由此容许付款方认授权支付。

Description

支付装置和方法

技术领域

本发明涉及用于在付款方和收款方之间执行支付的方法和装置。

背景技术

在本发明说明书中所提及的任何先前公开文件(或任何源自这些文件的信息)，或任何众所皆知的事物，不可以且不应被视为认同、准许或是任何形式的建议，而是认定公开文件(或任何源自这些文件的信息)，或众所皆知的事物形成本发明所属技术领域内的通常知识的一部分。

当前，客户面对用于向商家或个人作出支付的一系列可用选项。传统的现金支付逐渐被电子支付(包括通过网络在线支付)替代。

甚至现金支付可能也涉及一些形式的电子交易，尤其是在用于支付的现金由自动取款机(ATM)供应的情况下。典型的ATM交易从用户的身份验证开始，通常通过用户刷卡并输入个人识别号码，随后通过用户请求一笔资金作为现金分发。ATM之后将与用户的银行通信，以接收交易能够继续进行(即，所请求额度的资金能够从用户的账户提取)的批准。一旦交易被批准，所请求额度的资金以及任何可适用的附加费将从用户的银行转移至ATM所有者的银行，并且所请求额度的现金将从ATM被分发。

然而，利用由ATM供应的现金支付具有其自身相关联的问题。例如，如果ATM所有者的银行不是用户的银行的ATM网络的部分，用户可能需要支付高额的ATM附加费。每日提取限额通常强加于ATM交易上，这能够防止现金被用于作出大额支付。在任何情况下，携带大量现金对于用户而言是一种冒险活动，因为现金可能容易被盗或者丢失。重要的是，现金支付需要付款方与收款方实质上见面，以移交现金，这往往限制了这种支付类型的有效性。

电子资金转账(EFT)容许账户之间的电子交易，并且由此提供现金支付的灵活性，这种情况下，支付能够在无实际存在的情况下作出。要求从客户支付的商家或个人为客户提供信息，该信息识别资金将要被转达的目标银行账户，并且通常提供客户参考信息，以容许支付能够核对。这种信息能够被提供在用于购买的***上，或者可以简单地以特定方式被提供(例如，当个人同意将一笔资金转移给另一个人时)。

在任何情况下，客户能够之后使用网上银行来请求将资金转移至所识别的目标银行账户。客户输入目标银行账户信息、同意支付金额并接收该金额将在期限内被转移的通知。

然而，对客户输入目标银行账户信息的要求(通常是对于客户毫无意义的一长串数字)导致人为错误。典型地不存在目标银行账户信息已经正确地被输入或者资金将被转移至正确的接收者的验证，因为接收者详细信息并没有与转移通知一起提供给客户。接收者仅仅在资金事实上已经被接收在接收者的账户中时才接收支付的通知。在一些情况中，这可能在客户的请求之后多达4-5天。如果客户未能输入有意义的客户参考信息，还可能使支付的核对困难。

鉴于上述困难，EFT支付对于在线购买而言通常被认为是不合适的，因为直到支付能够由被接收在接收者的账户的资金确认，商品才能发货。

已经开始逐渐采用更加先进的在线支付***，因为这些容许客户通过互联网更加方便地作出支付。在线支付***的一个示例是BPAY，其在澳大利亚被广泛使用。在商家能够通过该***接受支付之前，商家典型地需要在该在线支付***的供应商注册。商家将之后被分配开账单代码，商家必须之后将其连同客户参考号码一起纳入账单中。

接收这种账单并希望作出支付的客户可能使用网上银行(或者替换地使用手机银行，尽管这在此可能不会被考虑)来这样做。尤其，客户登陆他们的网上银行账户(包括根据客户的银行的需要供应验证信息)，在此之后，客户输入开账单代码和客户参考号码以及支付金额和客户的账户(资金将从该账户被扣除)的确认。客户的银行之后将资金转移至开账单者的银行(通常作为分批处理的部分在下一个营业日转移)，在此之后，转移的明细将被发送至在线支付***供应商，用于之后发送给注册的开账单者。

尽管这些类型的在线支付***便于在支付账单中使用，但仍存在一些缺陷。客户参考号码典型地是长串数字，其必须由客户手动输入，并且在支付过程期间并没有用于验证客户参考号码的正确性的手段，所以人为错误可能导致作出不正确的支付。商家将不会得到支付成功的通知，并且直到所转移的资金在期限内进入开账单者的银行账户才能确信成功。这可能使得这种在线支付***不适于用于商品必须发货的在线购买。由在线支付***供应商收取的费用对于商家而言还可能是昂贵的，并且，由于仅仅已注册的商家能够发出账单，这实际上限制了在线支付***的适用性，从而使得只有企业能够接受支付，而个人不可以。

在线***和借记卡交易已经逐渐成为进行在线购买的常用机制。典型地，客户将访问商家的网站，以选择用于购买的商品或服务，并且在确认他们的选择之后，将在商家的网站上向客户呈现安全支付页面。客户之后将在支付页面上输入卡信息。

这触发授权过程，其中授权请求通过信用/借记卡公司最终从商家被传输至商家的银行(“收单银行”)并之后被传输至客户的银行(“发卡银行”)，并且授权响应之后被传回商家。这一授权过程将通常为大约几秒钟或更短，并且在成功授权后，商家将处于考虑已授权的支付完成的位置，并且能够安排商品/服务的递送。

与已授权的支付相关联的资金的真正转移将在客户的银行和商家的银行之间的资金交换中单独发生。交换费通常由商家支付。这一过程可能需要几天。

尽管多年以来大量安全措施已应用于在线信用和借记卡支付，主要的安全风险仍存在，如果客户的卡被盗或者丢失，任何持有该卡的人都能够作出支付。另一个安全方面在于，由于卡详细信息通过商家的网站输入，商家可以拥有卡详细信息，如果商家的安全性被破坏，卡详细信息可能面临潜在的滥用。此外，仅仅少量的***公司存在，并且这些公司因此能显著控制卡支付市场并且要求高额交换费，其典型地分摊给商家并且通过提高价格转而分摊给客户。

一些第三方公司已通过提供对一种或多种在线支付***的访问将自己建立为“支付网关”。有时这些第三方公司可以事实上在资金从付款方向收款方转移时起到资金的中间接收者的作用。这能够帮助使对于收款方和/或付款方与实际的银行、卡公司等等具有关系的需要最小化或消除，并且与能够被接受或进行的支付类型相比，其容许在各种类型支付中更大的灵活性。然而，这些第三方公司将典型地对交易收取他们自己的费用，这种费用可能很高。

US2010/0174626涉及一种处理对将通过代表在线商家的数据通信网络进行的支付交易的支付授权请求的方法。由于金融工具持有者通过多个不同的在线商家***制定的规则，支付授权请求进行，所述在线商家中的每一个具有在线商家身份。该方法由可信中央中介***进行，该可信中央中介***被配置为将支付授权请求传送至多个不同的在线商家互联网支付服务供应商(IPSP)中的每一个。在一些实施例中，在通过使用户向独立的可信实体提交他们各自的支付明细来删除对于用户向个人在线商家***或他们的商家IPSP***提供支付明细的要求的同时，用户可以在每一交易基础上选择支付方法。

由此，US2010/0174626可以被看作是涉及传统的“电子钱包”技术，其中接口被提供用于协调由IPSP依次进行的在线支付交易。还应当注意，该文件大致集中于卡方案的使用，并且由此将受到如上所述的他们的限制。

US2007/0073629公开了一种用于对在线交易进行支付而不需要向商家透露敏感商业信息的自动支付***和结算***。该支付***和结算***提供媒介，以在世界各地独立于客户和商家位置执行电子商务交易。这容许银行为他们的客户提供一种用于互联网购买的支付方法，而不需要使用***或透露***信息或银行账户信息。

应当注意，US2007/0073629的***的操作需要客户向它们的银行单独提供交易ID和交易的金额，以容许支付完成。而且，这一***要求结算***在资金被发到商家之前接收并保存所转移的资金，这实际上在资金被成功转移之前引入了额外的交易。

考虑到以上问题，应当认识到，存在与现有支付***相关联的许多缺点。

发明内容

在一种广义的形式中，本发明力图提供一种用于从付款方向收款方执行支付的方法，其中该方法包括：

a)接收对支付的支付请求，该支付请求响应于收款方从付款方请求资金而生成；

b)使用支付请求生成交易代码和支付明细，该交易代码由付款方获得；

c)从付款方接收交易代码；以及，

d)响应于接收交易代码，向付款方提供包括支付金额和所述收款方的指示的支付明细中的至少一些，由此容许付款方授权支付。

典型地，该方法包括从以下对象中的至少一个接收支付请求：

a)收款方；以及

b)收款方的金融机构。

典型地，该方法包括向以下对象中的至少一个提供交易代码：

a)收款方；

b)收款方的金融机构；

c)付款方；以及

d)付款方的金融机构。

典型地，该方法包括从以下对象中的至少一个接收交易代码：

a)付款方；以及，

b)付款方的金融机构。

典型地，该方法包括：

a)接收授权指示，该授权指示响应于付款方对支付的授权而被生成；以及，

b)响应于该授权指示，使资金从付款方转移至收款方，以由此执行支付。

典型地，该方法包括使用付款方和收款方的注册账户详情使资金从付款方转移至收款方。

典型地，该方法包括向以下对象中的至少一个提供支付结果的通知：

a)收款方；

b)收款方的金融机构；

c)付款方；

d)付款方的金融机构。

典型地，该方法包括：

a)从付款方的金融机构接收交易代码；以及，

b)向付款方的金融机构提供支付明细，由此容许付款方通过付款方的金融机构授权支付。

典型地，该方法包括由于欺诈迹象过滤以下对象中的至少一个：

a)支付请求；

b)交易代码；以及，

c)支付明细。

根据权利要求1至9中任一项所述的方法，其中该方法包括在提供支付明细中的至少一些之前验证交易代码。

典型地，支付请求包括由收款方供应的支付请求参数，支付明细中的至少一些使用支付请求参数而生成。

典型地，支付请求参数包括以下项目中的至少一个：

a)支付金额；

b)收款方的指示；

c)支付作出所指向的收款方的账户的身份证明；

d)用于支付的收款方参考；

e)支付如何能够作出的条件；以及，

f)与支付相关联的产品的详细信息。

典型地，该条件包括以下条件中的至少一个：

a)支付是否能够部分作出；

b)支付是否能够超额支付；

c)支付必须作出的期间；以及，

d)支付是否为重复支付。

典型地，交易代码包括一串多个字母数字字符。

典型地，交易代码使用Base36数字***而生成。

典型地，交易代码内至少一些预先确定的字符位置被用于编码关于付款方和支付中的至少一个的信息。

典型地，交易代码由多个付款方获得，并且该方法包括：

a)从多个付款方中的每一个接收交易代码；

b)向多个付款方提供支付明细中的至少一些；以及，

c)从多个付款方中的每一个接收对支付的各自部分的授权，从而使得这些部分的总金额等于或者大于由收款方请求的支付的金额。

典型地，该方法包括通过付款方的金融机构与付款方通信。

在另一广义的形式中，本发明力图提供一种用于提供交易代码的方法，交易代码用于在从付款方向收款方执行支付中使用，其中该方法包括收款方的金融机构：

a)从收款方接收对支付的支付请求，该支付请求响应于收款方从付款方请求资金而生成；

b)向支付服务供应商提供支付请求，以容许交易代码和支付明细使用支付请求而生成；

c)从支付服务供应商接收交易代码；以及，

d)向收款方提供交易代码。

典型地，该方法包括由于欺诈迹象收款方的金融机构过滤支付请求。

典型地，该方法包括收款方的金融机构：

a)从收款方获得认证信息；以及，

b)在向支付服务供应商提供支付请求之前验证认证信息。

在另一广义的形式中，本发明力图提供一种用于接收授权的方法，该授权用于在从付款方向收款方执行支付中使用，其中该方法包括付款方的金融机构：

a)从付款方接收交易代码，该交易代码与用于支付的支付明细相关联；

b)向支付服务供应商提供交易代码；

c)从支付服务供应商接收与交易代码相关联的支付明细中的至少一些，支付明细中的至少一些包括支付金额和收款方的指示；

d)向付款方提供支付明细中的至少一些；以及，

e)从付款方接收授权，以根据支付明细中的至少一些作出支付。

典型地，该方法包括由于欺诈迹象付款方的金融机构过滤支付明细中的至少一些。

典型地，该方法包括付款方的金融机构：

a)从付款方获得认证信息；以及，

b)验证该认证信息。

典型地，该方法包括付款方的金融机构：

a)响应于付款方对支付的授权，生成授权指示；以及，

b)向支付服务供应商提供授权指示，以由此容许支付服务供应商使资金从付款方转移至收款方，以由此执行支付。

典型地，该方法包括，响应于接收授权，付款方的金融机构使资金从付款方转移至收款方，以由此完成支付。

在另一广义的形式中，本发明力图提供一种用于从付款方向收款方执行支付的方法，其中该方法包括，在由付款方操作的付款方站点处：

a)获得交易代码，该交易代码与用于支付的支付明细相关联；

b)向支付服务供应商提供交易代码；

c)从支付服务供应商接收与交易代码相关联的支付明细中的至少一些，支付明细中的至少一些包括支付金额和收款方的指示；

d)显示支付明细中的至少一些；

e)从付款方接收授权，以根据支付明细中的至少一些作出支付；以及，

f)生成授权指示，用于使资金从付款方转移至收款方，以由此执行支付。

典型地，授权指示被提供给以下对象中的至少一个：

a)支付服务供应商；以及，

b)付款方的金融机构。

典型地，该方法包括付款方站点接收认证信息，用于容许付款方的身份在授权之前被验证。

典型地，认证信息被提供至以下对象中的至少一个：

a)支付服务供应商；以及，

b)付款方的金融机构。

典型地，交易代码由付款方站点使用以下方式中的至少一个获得：

a)短讯服务(SMS)；

b)即时消息(IM)；

c)电子邮件；

d)多音多频信号传输法(DTMF)；

e)无线通信；

f)近场通信(NFC)；

g)条形码；

h)QR码；以及，

i)由付款方手动输入。

在另一广义的形式中，本发明力图提供一种用于从操作付款方站点的付款方向操作收款方站点的收款方执行支付的方法，其中该方法包括：

a)在收款方站点处，生成对支付的支付请求；

b)在支付处理站点处，

i)接收支付请求；以及，

ii)使用支付请求生成交易代码和支付明细；

c)在付款方站点处，获得交易代码；

d)在支付处理站点处：

i)从付款方站点接收交易代码；以及，

ii)向付款方站点提供支付明细中的至少一些，支付明细中的至少一些包括支付金额和收款方的指示；以及，

e)在付款方站点处：

i)接收支付明细中的至少一些；以及，

ii)从付款方获得授权，以根据支付明细中的至少一些作出支付。

典型地，该方法包括：

a)在付款方站点处：

i)响应于来自付款方的授权，生成授权指示；以及，

ii)向支付处理站点提供授权指示；以及，

b)在支付处理站点处：

i)接收授权指示；以及，

ii)响应于授权指示，使资金从付款方转移至收款方，由此执行支付。

典型地，该方法包括支付处理站点从以下对象中的至少一个接收支付请求：

a)收款方站点；以及，

b)收款方金融机构站点。

典型地，该方法包括支付处理站点向以下对象中的至少一个提供交易代码：

a)收款方站点；

b)收款方金融机构站点；

c)付款方站点；以及，

d)付款方金融机构。

典型地，该方法包括支付处理站点从以下对象中的至少一个接收交易代码：

a)付款方站点；以及，

b)付款方金融机构站点。

典型地，该方法包括，在付款方金融机构站点处：

a)从付款方站点处接收授权指示；以及，

b)向支付处理站点提供授权指示，以由此使资金从付款方转移至收款方。

典型地，该方法进一步包括由于欺诈迹象，由以下对象中的至少一个过滤支付请求：

a)收款方站点；

b)收款方金融机构；以及，

c)支付处理站点。

典型地，该方法进一步包括由于欺诈迹象，由以下对象中的至少一个过滤支付明细中的至少一些：

a)付款方站点；

b)付款方金融机构；以及，

c)支付处理站点。

在另一广义的形式中，本发明力图提供一种用于从操作付款方站点的付款方向操作收款方站点的收款方执行支付的方法，其中该方法包括：

a)在收款方站点处：

i)生成对支付的支付请求；以及，

ii)向收款方金融机构提供支付请求；

b)在收款方金融机构站点处：

i)接收支付请求；以及，

ii)向支付处理站点提供支付请求；

c)在支付处理站点处：

i)接收支付请求；以及，

ii)使用支付请求生成交易代码和支付明细；

d)在付款方站点处：

i)获得交易代码；以及，

ii)向付款方金融机构提供交易代码；

e)在付款方金融机构站点处：

i)接收交易代码；以及，

ii)向支付处理站点提供交易代码；

f)在支付处理站点处：

i)接收交易代码；以及，

ii)向付款方金融机构提供支付明细中的至少一些，支付明细中的至少一些包括支付金额和收款方的指示；

g)在付款方金融机构站点处：

i)接收支付明细中的至少一些；以及，

ii)向付款方提供支付明细中的至少一些；

h)在付款方站点处：

i)接收支付明细中的至少一些；以及，

ii)从付款方获得授权，以根据支付明细中的至少一些作出支付；以及，

i)响应于授权，使资金从付款方转移至收款方，以由此执行支付。

在另一广义的形式中，本发明力图提供一种用于从操作付款方站点的付款方向操作收款方站点的收款方执行支付的方法，其中该方法包括：

a)在收款方站点处，生成对支付的支付请求；

b)在付款方站点处：

i)获得交易代码和支付明细，交易代码和支付明细使用支付请求而生成；

ii)获得认证信息；

iii)从付款方获得授权，以根据支付明细进行支付；以及，

iv)生成授权指示和认证信息；以及，

c)在支付处理站点处，响应于授权指示和认证信息，使资金从付款方被转移至收款方，以由此执行支付。

典型地，该方法进一步包括，在支付处理站点处：

a)从收款方站点接收支付请求；以及，

b)使用支付请求生成交易代码和支付明细。

替换地，该方法进一步包括，在收款方站点处，使用支付请求生成交易代码和支付明细。

典型地，支付请求包括由收款方供应的支付请求参数，支付明细中的至少一些使用支付请求参数而生成。

典型地，支付请求参数包括以下项目中的至少一个：

a)支付作出所指向的收款方的账户的身份证明；

b)用于支付的收款方参考；

c)要支付的资金额；

d)支付如何能够作出的条件；以及，

e)与支付相关联的产品的详细信息。

典型地，该条件包括以下条件中的至少一个：

a)支付是否能够部分作出；

b)支付是否能够超额支付；

c)支付必须作出的期间；以及，

d)支付是否为重复支付。

典型地，该方法进一步包括：

a)在支付处理站点处，将支付明细与交易代码相关联；以及，

b)在付款方站点处：

i)获得交易代码；以及，

ii)从支付处理站点获得与交易代码相关联的支付明细，并向付款方显示支付明细中的至少一些用于授权。

典型地，交易代码包括一串多个字母数字字符。

典型地，交易代码通过使用Base36数字***而生成。

典型地，交易代码内至少一些预先确定的字符位置被用于编码关于付款方和支付中的至少一个的信息。

典型地，接收编号在支付已执行之后生成，接收编号包括用于支付的交易代码。

典型地，接收编号进一步包括除了交易的字符之外的字符的可扩展部分，该可扩展部分被用在多个支付针对相同的交易代码作出的情况下。

典型地，该方法被用于由付款方执行支付，用于来自收款方的产品的在线购买，该方法进一步包括，在收款方站点处：

a)从付款方接收用于购买的产品的选择，付款方使用付款方站点以访问由收款方站点托管的收款方网站；

b)生成对产品的支付的支付请求；

c)将支付请求传输至支付处理站点；

d)支付已执行时，从支付处理站点接收确认；以及，

e)安排产品向付款方的递送。

典型地，认证信息和授权指示由持有付款方的账户的金融机构站点获得。

典型地，该方法进一步包括：

a)在金融机构站点处，接收交易代码和支付明细；

b)在付款方站点处，与金融机构站点通信，以根据支付明细提供认证信息并授权与交易代码相关联的支付；以及，

c)在支付处理站点处，从金融机构接收授权指示，并将资金从付款方转移至收款方，以由此执行支付。

典型地，该方法进一步包括将交易代码嵌入被提供给付款方的条形码中，付款方站点通过扫描和解码该条形码获得交易代码。

典型地，该条形码通过以下方式中的至少一个被提供给付款方：

a)将条形码打印在***上；

b)将条形码显示在收款方站点上；

c)将条形码显示在付款方站点上；

d)将条形码打印在物品上。

典型地，付款方操作第一付款方站点和第二付款方站点，第二付款方站点为移动计算设备，条形码被显示在第一付款方站点的显示器上并且由第二付款方站点扫描和解码，从而使得交易代码由第二付款方站点获得。

典型地，付款方操作第一付款方站点和第二付款方站点，第二付款方站点为移动计算设备，该方法进一步包括：

a)在第二付款方站点处，向付款方提供一次性密码；以及，

b)在第一付款方站点处，使付款方输入该一次性密码，以由此获得认证信息中的至少一些。

典型地，付款方站点为移动计算设备，其操作应用软件，用于容许与支付处理站点安全通信。

典型地，该方法被用于由付款方执行对来自收款方的产品的购买的销售点支付，该方法进一步包括：

a)在收款方站点处：

i)生成对由付款方选择用于购买的产品的支付的支付请求；以及，

ii)向付款方提供交易代码；

b)在付款方站点处：

i)获得交易代码；

ii)从付款方获得认证信息并获得授权；以及，

iii)向支付处理站点提供授权指示和认证信息；以及，

c)在收款方站点处：

i)支付已执行时，从支付处理站点接收确认；以及，

ii)向付款方提供产品已支付的确认。

典型地，支付处理站点向付款方站点提供交易代码。

典型地，收款方和付款方中的每一个为账户持有者，其在金融机构持有至少一个账户并且具有在支付处理站点注册的各自的账户详情。

典型地，账户持有者的账户的注册包括：

a)在支付处理站点处：

i)从账户持有者接收配对请求；以及，

ii)生成配对代码并向账户持有者提供配对代码；

b)在金融机构处：

i)接收配对代码；

ii)与支付处理站点通信，以获得配对代码的验证；以及，

iii)向支付处理站点提供账户持有者的账户详情；以及，

c)在支付处理站点处，存储账户详情，以由此注册该账户。

典型地，该方法进一步包括使多个付款方作出支付的部分，从而使得部分的总金额等于或大于由收款方请求的支付的金额。

典型地，多个付款方中的每一个操作各自的付款方站点，该方法进一步包括，在每一付款方站点处：

a)获得交易代码和支付明细；

b)从付款方接收对作出与交易代码相关联的支付的特定部分的授权；

c)将授权指示传传输至支付处理站点，以容许支付处理站点使资金从付款方转移至收款方，以由此执行支付的部分；以及，

d)接收支付的部分的接收编号。

典型地，由收款方请求的支付金额已由多个付款方共同支付时，支付处理站点向收款方提供通知。

典型地，该方法进一步包括支付处理站点在使资金转移之前认证付款方的身份。

典型地，该认证包括以下方式中的至少一个：

a)要求由付款方在付款方站点处输入认证代码；

b)要求付款方站点具有与注册设备标识匹配的设备标识；以及，

c)要求输入与注册生物特征标识匹配的生物特征标识。

在另一广义的形式中，本发明力图提供一种用于从操作付款方站点的付款方向操作收款方站点的收款方执行支付的方法，其中该方法包括，在支付处理站点处：

a)从收款方站点接收对支付的支付请求；

b)使用支付请求生成交易代码和支付明细；以及，

c)响应于由付款方站点生成的授权指示和认证信息，使资金从付款方转移至收款方，以由此执行支付。

在另一广义的形式中，本发明力图提供一种用于从操作付款方站点的付款方向操作收款方站点的收款方执行支付的方法，其中该方法包括，在付款方站点处：

a)接收使用支付请求生成的交易代码和支付明细，该支付请求由收款方站点生成；

b)显示支付明细；

c)响应于所显示的支付明细，从付款方接收授权和认证信息；以及，

d)生成授权指示和认证信息用于传输至支付处理站点，以容许支付处理站点使资金从付款方转移至收款方，以由此执行支付。

在另一广义的形式中，本发明力图提供一种用于从付款方向收款方执行支付交易的装置，该装置包括由付款方操作的付款方站点、由收款方操作的收款方站点以及由支付服务供应商操作的支付处理站点，其中该装置用于：

a)在收款方站点处，生成对支付的支付请求；

b)在付款方站点处：

i)获得交易代码和支付明细，交易代码和支付明细使用支付请求而生成；

ii)获得认证信息；

iii)从付款方获得授权，以根据支付明细进行支付；以及，

iv)生成授权指示和认证信息；以及，

c)在支付处理站点处，响应于授权指示和认证信息，使资金从付款方转移至收款方，以由此执行支付。

典型地，付款方站点和收款方站点使用通信网络与支付处理站点通信。

典型地，该装置用于执行如上所述的方法。

在另一广义的形式中，本发明力图提供一种用于从操作付款方站点的付款方向操作收款方站点的收款方执行支付的装置，该装置包括与付款方站点和收款方站点通信的支付处理站点，其中支付处理站点用于：

a)从收款方站点接收对支付的支付请求；

b)使用支付请求生成交易代码和支付明细；以及，

c)响应于作出与由付款方站点生成的交易代码和认证信息相关联的支付的来自付款方的授权的授权指示，使资金从付款方转移至收款方，以由此执行支付。

在另一广义的形式中，本发明力图提供一种用于从付款方向收款方执行支付交易的装置，该装置包括由付款方操作的付款方站点、由收款方操作的收款方站点以及由支付服务供应商操作的支付处理站点，其中该装置用于：

a)接收使用支付请求生成的交易代码和支付明细，该支付请求由收款方站点生成；

b)显示支付明细；

c)响应于所显示的支付明细，从付款方接收授权和认证信息；以及，

d)生成授权指示和认证信息用于传输至支付处理站点，以容许支付处理站点使资金从付款方转移至收款方，以由此执行支付。

附图说明

本发明的一个示例现将参考附图来描述，其中：

图1是用于在付款方和收款方之间执行支付的方法的一个示例的流程图；

图2是分布式计算机体系结构的一个示例的示意图；

图3是处理***的一个示例的示意图；

图4是终端站点的一个示例的示意图；

图5A至5K是用于执行对在线购买的支付的方法的一个示例的流程图；

图6A至6C是用于执行支付的方法的一个示例的流程图，其中交易代码由付款方通过扫描条形码而获得；

图7A至7C是用于执行对销售点购买的支付的方法的一个示例的流程图；

图8A和8B是用于在支付服务供应商注册账户的方法的一个示例的流程图；

图9示出用于使用网上银行对在线购买作出支付的示例装置配置；

图10示出用于使用支付服务供应商的网站对在线购买作出支付的示例装置配置；

图11示出用于使用移动设备对在线购买作出支付的示例装置配置；

图12示出用于从付款方向收款方作出支付的示例装置配置；

图13示出用于从客户向商家作出销售点支付的示例装置配置；

图14是用于从付款方向收款方执行支付的方法的一个示例的流程图；

图15A至15C是用于执行支付的方法的一个示例的流程图，其中收款方和付款方与各自的金融机构交互；

图16A至16B是用于响应于支付请求提供交易代码的方法的另一示例的流程图，其包括由收款方金融机构和支付服务供应商过滤支付请求；以及，

图17A至17D是用于响应于交易代码被获得执行支付的方法的另一示例的流程图，其包括由付款方金融机构和支付服务供应商过滤支付。

具体实施方式

大体上，本发明提供用于容许从付款方(例如客户)向收款方(例如商家)作出支付的方法。该支付将大致被执行为电子交易，付款方操作付款方站点且收款方操作收款方站点。支付处理站点将大致负责使资金转移。支付处理站点典型地由支付服务供应商操作，用于帮助支付。

现将参考图1的流程图来描述用于进行支付的一个示例方法。

根据步骤100，该方法典型地由收款方通过使收款方站点生成对支付的支付请求而开始。如进一步将要解释的，支付请求能够针对收款方所期望的很多不同类型的支付而生成。例如，收款方可以是操作网上交易的商家，并且支付请求可以响应于客户对商品的在线购买而生成。在另一示例中，支付请求可以作为其他商品或服务的***制备的部分而生成，并且这种***可以容许在商品/服务提供之后支付。该方法可以扩展至两个个人之间的支付，并且在这些情况中，期望来自另一个人的资金的个人将生成支付请求。

如步骤110所示，支付请求能够之后被用于容许交易代码和支付明细生成。

交易代码在该支付方法随后的步骤中自始至终作为对支付交易的参考被大致使用。其始终容许支付在付款方站点、收款方站点和支付处理站点之间被识别，并且帮助任何支付明细和与支付相关联的任何其他信息的传输，以由此容许执行支付。该交易代码可以使用生成算法而生成，其还容许关于付款或收款方的信息被嵌入交易代码内。

支付明细将大致包括容许付款方确认他们希望继续支付的详细信息。例如，支付明细可以包括用于支付的金额以及收款方的身份证明。支付请求可以直接指定支付明细，例如支付金额。然而，在一些情况下，支付请求可能仅仅具有收款方身份证明编码，而付款方通常希望看到收款方的其他详细信息，例如名字。因此，这种支付明细可以与交易代码一起生成，例如，基于收款方的账户详情，其可以根据支付请求中供应的信息而被查找。

其他支付请求参数还可以与交易代码相关联，并且这些可以作为支付请求的部分由收款方供应，例如，以容许它们在交易代码生成时被包含在交易代码中。其他支付请求参数的示例将在适当的时候更详细地描述。

在一个示例中，收款方站点可以向支付处理站点提供支付请求，并且交易代码和支付明细可以随后由支付处理站点生成。通过使支付处理站点生成交易代码和支付明细，这确保了交易代码和支付明细以一致的方式被生成，这一方式由支付服务供应商集中协调。

然而，在替换的示例中，交易代码和支付明细可以在其他位置生成。例如，收款方站点可以在本地生成交易代码和支付明细。在这一情况下，收款方站点将典型地需要通过这种方法生成交易代码而使得不同的收款方站点无法生成相同的交易代码。这可以通过生成交易代码而获得，从而使得由特定收款方生成的每一交易代码中的一部分对于收款方是唯一的。

在任何情况下，交易代码和支付明细已生成时，其能够之后被用于容许付款方授权从付款方的账户支付。典型地，如步骤120所示，交易代码和支付明细将由付款方站点以一些形式获得。应当认识到，交易代码和支付明细能够以多种不同方法获得。

在从客户向商家支付用于在线购买的示例中，交易代码可以通过商家的网站或通过由支付服务供应商提供的独立网站被传输至由客户操作的付款方站点。

在另一示例中，交易代码可以通过将交易代码嵌入条形码或QR码而被提供给付款方。在这种情况下，付款方可以使用付款方站点的图像扫描功能，以扫描条形码或QR码，并且从条形码或QR码提取交易代码。应当认识到，QR码经常通过将统一资源定位符(URL)地址嵌入QR码中而被使用，在QR码被扫描时，该URL地址能够被访问。因此，在一个替换的示例中，交易代码可以被包含在被嵌入QR码中的URL中，并且当所嵌入的URL通过扫描QR码而被确定时，交易代码可以随后从URL被提取。

不论交易代码如何在付款方站点处获得，最终交易代码将被用作参考，以容许付款方授权支付。支付明细(以及其他可选的支付请求参数)可以也通过使用交易代码作为参考而从支付服务供应商获取，并且可以随后被显示给付款方，以容许付款方在提供授权之前确认交易的详细信息。

在步骤130，付款方站点将之后获得认证信息，以由此认证付款方的身份。该认证能够使用本领域中已知的任何合适的认证技术而获得。例如，认证可以包括付款方输入用户名(或其他标识)和密码、个人识别号码(PIN)、生物特征安全方法的使用、被发送给付款方的一次性密码(OTP)的使用等。不论是什么技术，认证信息能够被用于确认付款方的身份。

在步骤140，假定付款方希望继续支付，付款方站点之后从付款方获得授权以作出支付。例如，该授权可以包括付款方确认他们希望将支付金额从指定账户扣除。

在步骤150，付款方站点将随后生成授权指示和认证信息。通常，除非授权指示和认证信息生成，否则支付将不可能继续。就这一点而言，授权指示和认证信息典型地被提供给支付处理***或直接被提供给用户的金融机构，容许支付被授权。

就这一点而言，支付处理站点能够继续执行由付款方授权的支付。因此，在步骤160，支付处理站点通过使资金从付款方转移至收款方而对授权的指示作出响应。

这可能通过支付处理站点对电子资金转移开关发出从付款方的账户向收款方的账户的资金转移的请求而发生。作为这一请求的部分，支付处理***可以提供账户详情和支付明细，以容许该开关来进行转移。支付处理站点可以与该开关一体，但程序将是类似的。

如下文中将进一步描述的，在这一方法中，对于授权指示和认证信息而言，每次从付款方站点向支付处理站点直接流动并不是必要的。例如，授权和认证可以由金融机构通过付款方访问金融机构的网站独立处理，在此之后，金融机构向支付处理站点提供支付将继续的确认。然而，鉴于安全原因，对于支付而言，由付款方以一些方式授权通常是必要的，并且对于付款方的身份而言，在资金能够被转移之前进行认证通常也是必要的。

在支付交易已继续之后，成功或交易的其他方面的通知可以被提供给付款方和收款方。这可以触发进一步可选的动作，例如成功支付被确认后，商品从收款方递送。

在与现有技术进行比较时，上述方法提供多个优点。重要的是，交易代码和支付明细的使用为付款方提供了更好地确认正确的支付将作出的能力。作为授权步骤的部分，付款方能够根据支付明细来确认支付，其中支付明细能够在付款方站点处获得。相反，传统的在线支付***典型地将负担置于用户身上，以确保支付明细输入正确，并且对于付款方而言，通常没有机会确认与支付相关联的支付明细。因此，与传统的在线支付***的这一区别帮助改善客户在支付方法的使用中的信心，并且帮助防止作出错误的支付。

还应当认识到，上述方法容许支付交易过程通过独立第三方(即，支付服务供应商)完全获得便利，而不需要收款方从付款方接收个人账户详情等等。这与现有的在线***支付***等是相反的，并且其在付款方的个人信息的安全性中提供了显著的改善。

上述方法还与其他传统的支付服务供应商产品不同，其他产品中资金通过作为中间步骤的第三方被转移。在本方法中，资金从付款方的账户和收款方的账户能够直接进行转移，而不需要资金由支付服务供应商接收和分送。然而，还是会附加交易费。

应当认识到，与现有技术相比，该支付方法提供作出支付的简易方法。例如，商家等能够通过生成支付请求而开始该支付方法，并且多个支付请求能够通过批次请求或自动处理而被容易地制备并且传输至支付处理站点。

收款方不需要直接向付款方提供账户详情，并且不需要依靠付款方手动正确输入账户详情，以容许作出恰当的支付。而且，收款方不需要是商家以具有通过使用该支付方法而接受支付的能力。这些因素还帮助该支付方法更适于个人之间特定的支付。

在一个示例中，该方法至少部分地使用处理***(例如合适的编程计算机***)而执行。付款方站点和收款方站点中的每一个将典型地包括各自的处理***，其将大致具有通过通信网络等与其他处理***通信的能力。该处理***可以被配置为从各自的用户接收输入指令和数据，并且向各自的用户显示信息。

合适的处理***体系结构的示例将在下文中详细描述，但在一个示例中，至少付款方站点的处理***以台式计算机或移动计算设备(例如智能手机、平板电脑等)被提供，并且付款方站点的功能通过在处理***上执行应用软件而被提供。如下文中将具体描述的，移动计算设备的使用尤其能够大大提高支付***的灵活性。

该方法可以适当地通过作为分布式体系结构的部分的处理***而实施。现将参考图2来描述分布式体系结构的一个示例。

在这一示例中，基站201(例如上述支付处理站点)通过通信网络(例如互联网202和/或多个局域网(LAN)204)被联接至多个终端站点203，其可以包括上述付款方和收款方站点。

例如，终端站点203可以包括客户端站点203.1、商家终端站点203.2、金融机构站点203.3、第二客户端站点203.4、付款方站点203.5、收款方站点203.6(其还可以是以包括智能手机和平板电脑的移动设备的形式)、移动客户端站点203.7和销售点终端站203.8，并且包括这种终端站点203的操作的另外的示例将在适当的时候描述。

在使用中，基站201包括一个或多个处理***210，其能够被用于生成交易代码、存储与交易代码相关联的相关信息用于随后的获取以及使资金从付款方转移至收款方。额外地和/或替换地，例如，终端站点203能够由收款方使用，用于生成支付请求，或者由付款方使用，用于获得交易代码和对支付提供授权。终端站点203根据需要与基站201通信，以传输任何其他执行支付所需的信息。

合适的便携终端站点203能够被利用，以帮助新数据的输入，用于由基站201存储，例如，付款方可以输入支付信息，以将其包括在支付请求中，并且随后与所生成的交易代码相关联并由基站201存储。

由此，在一个示例中，该过程至少部分地使用合适的应用软件来实施，该应用软件能够被加载在每一终端站点203上和/或由处理***210托管(host)。基站201还典型地被用于存储任何需要的数据(例如付款方或收款方账户详细信息、支付金额等等)，以进行实际的资金转移。每一终端站203典型地适于与处理***210通信，容许交易代码和相关联的支付信息根据需要被传输，和/或容许授权、通知等等随着方法进度被发送。然而，这并不是必要的，并且任何合适的布置可以被使用。

合适的处理***210的一个示例在图3中显示。在这一示例中，处理***210包括至少一个处理器300、存储器301、输入/输出设备302(例如键盘和/或显示器)以及外部接口303，它们通过如图所示的总线304相互连接。在这一示例中，外部接口303能够被利用，用于将处理***210连接至***设备(例如通信网络202和204、数据库211、其他存储设备等等)。尽管独立的外部接口303被显示，这仅仅是为了示例目的，并且在实践中，使用各种方法的多个接口(例如，以太网、串口、USB、无线等等)可以被提供。

在使用中，处理器300执行以应用软件形式被存储在存储器301中的指令，以容许过程执行，或者提供对于终端站点203所需要的任何数据的访问。因此，应当认识到，处理***300可以由任何合适的处理***形成，例如适当编程的计算机***、PC、网页服务器、网络服务器等等。

如图4所示，在一个示例中，终端站点203包括至少一个处理器400、存储器401、输入/输出设备402(例如键盘和/或显示器)以及外部接口403，它们通过如图所示的总线404相互连接。在这一示例中，外部接口403能够被利用，用于将终端站点203连接至***设备，例如通信网络202和204、数据库211、其他存储设备等等。尽管独立的外部接口403被显示，这仅仅是为了示例目的，并且在实践中，使用各种方法的多个接口(例如，以太网、串口、USB、无线等等)可以被提供。

如下文中将描述的，在使用中，处理器400执行以应用软件形式被存储在存储器401中的指令，以容许与基站201通信，从而执行支付方法的方面、容许用户与由基站201托管的应用软件交互和/或查看或修改数据。因此，应当认识到，终端站点203可以由任何合适的处理***形成，例如适当编程的PC、互联网终端、膝上型电脑、手提式PC、移动电话或其他通信设备，其典型地操作应用软件。

应当认识到，尤其合适的处理***配置的一个示例将包括作为终端站点203的手提式移动设备的使用，其与基站201无线通信。这一配置容许用户(付款方或收款方)方便地在终端站点203处远程使用支付方法功能，同时履行他们的职责，但存储和繁重的处理任务(例如数据库查询)在基站201处被集中执行。

在一个示例中，基站201是服务器，其包括处理***210和数据库211，并且终端站点203是手提式无线设备(例如智能手机或平板电脑)，其能够通过触屏GUI向用户显示信息并从用户接收输入。尤其，终端站点203运行本地应用软件，以执行用户交互功能，例如向用户呈现供用户选择的选项、接收由用户输入的数据和向用户提供指示。而且，终端站点203与基站201无线通信，以向基站201提供或接收指令、请求或数据。

在一个示例中，终端站点203可以作为计算机终端被提供，以容许其他用户接口(例如键盘和鼠标)的使用和在具有比手提式设备更大尺寸的屏幕上通过网页界面等等向用户显示增加量的信息。在一个示例中，这种计算机终端容许用户对数据库211进行直接的查询。手提式设备和计算机终端的组合可以被用于容许实现每一类型的终端站点203各自的优点。

应当认识到，任何恰当配置的终端站点203可以被用于递送类似的功能，并且这些可以作为成品设备被提供，例如移动电话、PDA、膝上型电脑、平板电脑等等，或作为定制设计的设备被提供。

还应当认识到，根据特定的实施方式，终端站点203和基站201之间功能的划分可以变化。就这一点而言，终端站点203可以被简化，以仅仅提供用户接口，并且在这种情况下，基站201可以操作处理任务的主要内容。另一方面，终端站点203可以装备有实质处理能力，从而使得基站201仅仅起到数据库服务器的作用，用于向终端站点203提供需要的信息用于远程处理。

在任何情况下，上述一般的过程并非由硬件实施方式特定地限定，并且本领域技术人员将理解处理***体系结构的变化是可能的。

在以下特定的示例方法中，假定该方法通过使用终端站点203来执行，终端站点203以计算机终端或移动计算设备的形式，并且对终端站点203的一个或其他类型的特定要求将被认定为对于特定的示例是恰当的。在任何情况下，终端站点203假定为具有根据需要与基站201通信的能力，但终端站点203将能够在不与基站201通信的情况下执行功能中的至少一些，除非另有说明。

然而，应当认识到，为以下示例目的假定的上述配置不是必要的，并且多种其他配置可以被使用。

为说明该支付方法和***的进一步优选特征，现将参考图5A至5K描述用于执行支付的进一步具体的示例方法。

这一示例方法大致涉及执行对在线购买的支付。因此，在这一示例中，收款方将为具有商家网站的商家，其容许作出在线购买，该支付方法被用于帮助支付。商家网站典型地由以网页服务器形式的终端站点203托管，如上所述，其可以起到收款方站点的作用。付款方将为客户，其使用另一终端站点203访问商家网站。客户的终端站点203可以是能够容许客户与商家网站交互并且用于容许在该方法中自始至终根据要求进行其他通信的任何计算设备，并且其可以称为付款方站点。

该方法从步骤500开始，其中客户使用他们的终端站点203，以访问商家网站。根据典型的在线购买程序，在步骤501，客户与商家网站交互，以选择一个或多个商品用于购买。当客户的选择完成时，在步骤502，客户转到商家网站的“结账”页面(或等同位置)，以结束购买。如步骤503所示，在结账页面，商家将典型地确定所选择的商品的总价，并且向客户显示这一总价用于支付。假定客户满意他们的选择和显示的总价，在步骤504，客户之后指示他们希望继续对购买支付。

该方法假定客户已经在商家网站上具有活跃注册，并且由此商家网站已经获知客户信息(例如，递送地址)，以容许支付被确认时，商品被递送。然而，如果不是这种情况，客户可能需要在这一页面上输入这种信息。

应当认识到，该支付方法到目前为止遵循传统的在线购物过程，并且由此该方法可以包括由选择产品用于在线购买的客户执行的其他典型的步骤。然而，用于安排该过程的实际支付的之后的步骤可以来源于这种传统的在线购物过程。

在步骤505，商家向客户显示请求，以选择期望的支付方法。根据本方法，尽管商家可以向客户提供传统的支付方法选项，至少呈现给客户的选项将对应于使用操作一支付处理站点的支付服务供应商来执行支付。因此在步骤506，客户在商家网站上选择选项，以使用支付服务供应商支付。

应当注意，在传统的在线购买中，商家网站通常转向直接从客户请求详细信息，以容许支付作出。例如，商家网站可能促使客户(安全地)输入***详细信息以及其他验证信息，以容许使用***交易来支付。然而，在这一方法中，商家网站不从客户接收这些类型的敏感支付明细。相反，支付将通过支付服务供应商得到帮助。

在步骤507，商家网站生成支付请求，并且将其传输至支付服务供应商。该支付请求将大致包括由客户作出的支付的详细信息，其足以容许支付服务供应商帮助之后的支付步骤，除了在支付已成功执行时向商家提供通知之外，其不需要与商家持续通信。

因此，该支付请求可以包括一系列支付请求参数中的一个或多个，其将大致涉及将被用于生成支付明细的至少一些信息。需要将支付的资金额大致作为支付请求参数的部分，并且这些将反过来形成支付明细的部分，尽管在一些环境中，这可能不需要，例如对于捐赠或自愿支付金额而言。

支付请求参数还可以包括支付作出所指向的商家的账户的身份证明。这可以是完整的账户号码的形式，或者在商家已经在支付服务供应商上注册账户详情的情况下，账户可以以简化形式被识别。作为支付请求参数的部分，商家可以进一步提供用于支付的收款方参考，以容许商家稍后核对支付。与支付相关联的所购买的产品的详细信息还能够被包括在支付请求参数中。

支付请求参数还可以列出支付如何能够实际作出的条件。例如，条件参数可以包括支付是否能够部分作出、支付能否超额支付、支付是否必须在限定期限内作出以及支付是否为重复支付。这些类型的条件将在恰当的时候进行研究。

在这一示例中，商家网站使用安全连接将支付请求传输至由支付服务供应商操作的支付处理站点。例如，传输可以使用HTTP安全POST请求作出。然而，应当认识到，任何合适的传输机制可以被使用并且另外的示例将在恰当的时候指出。

在任何情况下，在收到支付请求时，在步骤508，支付服务供应商使用支付请求，以生成交易代码和支付明细用于购买。交易代码在该支付方法随后的步骤中自始至终作为支付的参考被使用，并且还可以被用于在支付已成功作出时提供接收号码。例如，支付详情可以包括被供应在支付请求参数中的信息的特定部分、或来源于支付请求参数或商家的身份的其他支付的详细信息。

通常，交易代码将包括一串字母数字字符，其将典型地被构造，从而使得交易代码内预先确定的字符位置能够被用于编码关于收款方和支付中的至少一个的至少一些信息。例如，交易代码可以包括字符位置，该字符位置被保留，用于标识收款方位于的国家、与收款方相关联的标识；容许用于支付的目标账户的识别的字符；对于由收款方请求的交易唯一的标识；校验字符等等。

在一个示例中，交易代码使用Base36数字***而生成，其容许给定量字符的改善的信息密度，同时容许典型的***数字0-9和不区分大小写的拉丁字母a-z的使用。交易代码串中字符的数量将取决于将要编码的信息和用于编码该信息的特定方案，并且由此可以基于该方法的特定实施方式而变化。交易代码还可以容许填充字符的使用，例如“破折号”字符，其基于所使用的编码/解码策略可以是有利的。

在已生成交易代码和支付明细的情况下，在步骤509，支付服务供应商将支付明细以及可选的其他支付请求参数与交易代码相关联。这可以通过将交易代码作为支付处理站点的关联数据库等的密钥使用而执行。这容许关于支付的信息根据在整个方法的稍后阶段需要而从支付服务供应商获取，将交易代码作为用于支付的唯一参考使用。

在步骤510，支付服务供应商之后向客户显示新的网页，请求来自客户的支付选项的进一步选择。此时，为客户的利益，支付服务供应商将典型地还向客户显示交易代码和支付明细，并且还可选地显示关于支付请求参数的其他信息。网页可以被呈现在由客户操作的终端站203的网页浏览器的新窗口或标签中，或者可以在相同的窗口/标签中通过从商家网页的重新导向而呈现。

在这一示例中，如步骤511所指示的，支付选项选择网页可以促使客户指示他们是否希望通过使用网上银行作出支付。在客户积极回应的情况下，在步骤512，支付服务供应商将之后继续在网页上显示多个金融机构供客户选择。网上银行不被使用的替换场景将进一步从以下步骤528开始详细描述。

在步骤513，客户选择要使用的金融机构，用于通过网上银行作出支付。在步骤514，支付服务供应商之后通过使所选择的金融机构的网站的登陆页面显示给客户响应这一选择。再次，这可以通过打开新浏览器窗口或标签，或者通过从支付服务供应商的网页重新导向。

假定客户已选择金融机构，客户在该金融机构持有账户，网上银行能够为该账户启用，在步骤515，客户能够之后登陆到所选择的金融机构的网站，并且根据金融机构的要求执行任何认证动作。之后在该方法的这一分支，显然，金融机构(而不是支付服务供应商)将负责认证付款方的身份，并且由此认证方法将取决于由特定的所选择的金融机构要求的那些。

在客户已成功登陆到金融机构之后，步骤516之后涉及金融机构接收用于支付的交易代码。例如，这能够基于金融机构的偏好以及例如支付服务供应商是否具有与金融机构的在先存在关系而以多种方式发生。

在交易代码在支付选项选择网页上被显示给用户并且该网页仍然为动态(active)时，客户可以简单地从支付选项选择网页将交易代码复制粘贴到金融机构网页上的区域(field)。为方便起见，金融机构可以在客户登陆之后直接呈现这种区域。在一个示例中，交易代码可以自动被复制到客户终端站点的“剪贴板”存储器等等，以容许其易于被粘贴到金融机构网页区域，而不需要客户记忆来复制该交易代码。

然而，在另一示例中，作为后台程序，交易代码可以由支付服务供应商供应至金融机构。因此，金融机构可以在客户登陆到金融机构网站上时已拥有交易代码。在这种情况下，在登陆之后直接使金融机构网站向客户突出显示所接收的交易代码可能是方便的，其使得客户直接被导向用于完成支付的下一步骤，而不必须手动导航到金融机构网站的适当部分。

在任何情况下，在金融机构已接收交易代码之后，如步骤517中所示，金融机构将之后使用交易代码作为参考而典型地从支付服务供应商请求其他支付明细。这可以涉及金融机构向支付服务供应商发送请求，用于与交易代码相关联的特定支付明细的提供。可选地，基于金融机构的偏好，其他支付请求参数也可以被请求。

支付服务供应商之后在步骤518通过向金融机构供应与交易代码相关联的所请求的支付明细来响应。金融机构能够之后通过金融机构的网站向客户显示支付明细中的至少一些以及基于支付信息对支付确认的提示。

因此，在步骤519，客户使用金融机构的网站根据支付明细选择用于支付的账户并授权支付。该账户选择可以使用任何便利的基于网络的接口来执行，例如通过使用下拉菜单、选择复选框等等。一旦确认已接收，在步骤520，金融机构向支付服务供应商供应客户的所选账户的详情。

账户详情的供应将有效向支付服务供应商提供继续交易的确认，并且由此在步骤521，支付服务供应商将开始资金从客户的账户向商家的账户的转移。如上所述，这一转移可以通过向电子转账开关提供账户详情和支付明细而恰当地执行，例如，该电子转账开关可以与支付处理站点分离或与之一体。

下一步，在步骤522，支付服务供应商将接收转移结果的指示。这将通常是成功或不成功转移的指示。在任一情况下，该结果将被传输至客户和商家，但之后的步骤将以成功结果为假定。

在步骤523，支付服务供应商通知金融机构该转移结果，在此之后(假定成功结果)，在步骤524，金融机构的网站将显示资金从客户的账户扣除的确认。替换地，在不成功结果的情况下，金融机构将通知客户交易失败，并且提供再次尝试的提示(例如提供改变所选账户的选项)。

在步骤525，支付服务供应商还将通知商家该转移结果。再次假定成功，在步骤526，商家网站将显示支付从客户的账户被接收的确认。如果交易不成功，客户很可能已得到金融机构的通知并且被给予再次尝试的机会，所以商家不必还要通知客户交易失败。

考虑到这一示例方法涉及产品的在线购买，在步骤527，成功支付之后将典型地由商家安排将所购买的产品递送给客户而继续。

尽管这表示该方法的分支的终点，其中，在步骤511，客户选择使用网上银行来支付，还存在其他方法分支，其中客户回应他们不希望使用网上银行，并且这些将从步骤528开始描述(从图5F开始)。

因此，在步骤511客户不使用网上银行的情况下，通常假定客户反而希望通过直接与支付服务供应商互动来作出支付。这一互动能够通过第一终端站点203上的网站(客户在其上选择和确认用于购买的商品)继续，或者通过以客户的移动设备形式的第二终端站点203继续。在步骤528，客户将典型地被促使选择是否使用他们的移动设备来支付。

如果在步骤528客户选择不使用他们的移动设备来支付，该方法将之后继续进行至步骤529，其中支付服务供应商请求客户登陆到在支付服务供应商上注册的账户。这一方法假定客户已经具有这种账户，但如果不是这种情况，客户可以被给予建立新账户的机会。

在任何情况下，在步骤530，客户使用支付服务供应商的网站登陆他们的注册账户。如将认识到的，以下步骤与上述那些当支付使用网上银行作出时的步骤相似，但在这一情况下，客户仅仅应对支付服务供应商，并且不通过独立的金融机构的网站。这意味着对客户的身份认证的责任现落在支付服务供应商身上。

在步骤531，支付服务供应商向客户显示交易代码和支付明细，并且在步骤532，支付服务供应商请求从一个或多个注册支付源选择。通过具有预先注册的支付源，客户能够快速进行支付，但可能存在在这一阶段注册新支付源的选项。在步骤533，客户选择用于作出支付的支付源。

如上所述，支付服务供应商负责认证客户的身份。这将被理解为，对支付方法的整个安全性具有实质的影响，因为客户的身份的强认证将帮助消除执行未经客户授权的交易的风险。认证能够由金融机构等等以本领域中当前使用的任何方式进行。然而，在这一示例中，认证将涉及已知身份的移动设备的使用，其与客户的账户相关联。

在步骤534，客户使用移动设备，并且使用由支付服务供应商提供的应用软件(例如智能手机应用)将认证信息(例如个人识别码(PIN)等等)输入移动设备。

在移动设备上已经认证他们的身份的情况下，在步骤535，客户之后使用移动设备获得授权代码。在为支付提供授权时，这一授权代码最终将被用于确认客户拥有移动设备，作为额外的安全层。

支付服务供应商可以将授权代码发送至客户的注册的移动设备，在这一情况下，支付服务供应商将知晓被发送的授权代码，用于之后确认。替换地，授权代码可以以一次性密码(OTP)的形式，其可以在本地被生成在客户的移动设备上。在这种情况下，尽管OTP不会已经由支付服务供应商提供，但在知晓由移动设备使用的生成算法的情况下，支付服务供应商可以使用OTP确认对支付授权的来源。例如，OTP生成可以使用RSA算法，其中支付服务供应商已知由该特定移动设备生成的OTP代码的解密密钥。

在步骤536，可选地，移动设备还可以向支付服务供应商供应定位信息，以容许对客户进一步的验证。例如，通过使用IP地址或其他定位数据，移动设备的定位可以对照第一终端站点203的定位来检测，客户通过第一终端站点203开始购买。可选地，其他认证手段(例如生物特征认证等)还可以被使用。

在任何情况下，在成功认证后，客户将知晓授权代码。在步骤537，授权代码将由客户使用第一终端站点203输入至支付服务供应商的网站。这一输入有效地确认客户也具有注册的移动设备。

在步骤538，客户能够在支付服务供应商的网站上最终授权支付，并且随后支付服务供应商开始资金从客户的账户向商家的账户的转移。

随后的交易处理步骤将与上述通过网上银行支付的那些步骤相似，但其对于客户的成功通知不同，因为其现将不再涉及金融机构。大致相似的步骤将仅仅简要描述。

在步骤540，支付服务供应商接收转移结果的指示。在该方法的这一分支中，在步骤541，支付服务供应商的网站显示资金从客户的账户被扣除的确认(而不是通过金融机构的网站提供)。

另外，商家终端步骤与上述网上银行选项的步骤相似。在步骤542，支付服务供应商通知商家该转移结果，在此之后，在步骤543，商家网站显示支付被接收的确认，并且在步骤544，商家将之后典型地安排所购买商品的递送。

在之前所述的步骤528中其他选项用于客户，以使用他们的移动设备实际上完成支付步骤。如果在步骤528客户以肯定方式回应，该方法继续至步骤545(如图5I所示)。

在步骤545，支付服务供应商将首先确定客户是否能够从商家供应的信息被识别。换句话说，对于识别信息是否充分以能够容许客户在支付服务供应商上的注册被可靠识别存在检测，从而使得使用客户的注册移动设备的支付能够开始，而不需要来客户的另外的识别数据。

通常，如果客户已在商家网站上输入计费或运送地址信息，并且这一信息被传到支付服务供应商，之后这将足以容许使用移动设备继续支付。然而，可能不总是这种情况，并且客户识别不充分的可能性将在恰当的时候更加具体地展开。

然而，在步骤545，在存在充分的识别信息的情况下，在步骤546，支付服务供应商将能够之后向客户的注册移动设备推送通知，其指示新支付请求已被接收。这一通知可以通过任何合适的手段。例如，文本信息可以被发送至移动设备。另外，弹出式或其他形式的通知对话框可以在移动设备上被触发。这些选项可以利用在移动设备上运行的应用软件。

在任何情况下，通知将通常促使客户访问移动设备上的支付服务供应商的应用软件，其被假定发生在步骤547。该应用可以已在运行或可以在客户响应通知之后自动运行，或者客户可能需要手动运行该应用。

在任何情况下，一旦客户访问支付服务供应商的应用，在步骤548，该应用将接收支付明细并在移动设备上将其显示给客户。这可以通过基于交易代码在支付处理站点查询支付明细来完成，其中交易代码已与通知一起被推送到移动设备。

在步骤549，客户选择在支付服务供应商注册的账户用于在移动设备上作出支付。客户之后在步骤550使用支付服务供应商的应用输入认证信息(例如PIN号码、生物特征数据等等)并确认支付。因此，在该方法的这一分支，客户仅仅使用移动设备完成认证和支付授权步骤，并且不需要使用第一终端站点203将信息另外输入支付服务供应商的网站。这与上述移动设备仅仅用于向客户提供授权代码的可选步骤不同，其用于输入支付服务供应商的网站作为支付授权的部分。

由于移动设备典型地具有相对强的基于硬件的安全机制，用于使用移动设备继续支付的授权能够进一步通过使用那些安全机制来验证。例如，客户的移动设备的注册可以包括硬件识别码的详细信息，其实际上难以欺诈。再次，基于定位的验证还可以被用于与购买开始时的第一终端站点203的原始IP地址比较。

在步骤551，支付服务供应商将之后继续开始从客户的账户向商家的账户的资金的转移，随后在步骤552，转移的结果的指示得到接收。

在步骤553，支付服务供应商的应用在客户的移动设备上显示资金从客户的账户被扣除的确认。这与该方法的网上银行和移动设备授权代码分支是不同的，其中，交易结果的确认通过终端站点203上的网站被递送，购买通过终端站203开始。

另外，商家端步骤还与上述步骤类似。在步骤554，支付服务供应商通知商家转移结果，在此之后，在步骤555，商家网站显示支付被接收的确认，并且商家将之后在步骤556典型地安排所购买商品的递送。

如上在步骤545所述，可能存在用于识别客户信息不充分的情况，并且由此它们的注册移动设备详细信息可以从由商家供应的信息获得。在那些情况中，该方法可以继续至步骤557，其中支付服务供应商的网站显示登录表格和编码该交易代码的条形码。

在步骤558，客户可以简单地通过网站选择登陆进入他们的支付服务供应商账号，在此之后，支付服务供应商现将能够明确地识别客户，从而使得使用移动设备的支付能够之后如前所述从步骤546开始继续。

然而，客户可以选择避免使用终端站点203输入登陆信息的额外步骤，其中客户从终端站点203访问商家网站。相反，在步骤559，客户可以通过使用移动设备上的支付服务供应商的应用扫描条形码。由于条形码编码交易代码，在步骤560，支付服务供应商的应用能够从条形码解码交易代码，以由此直接获得交易代码。由此，在这一情况下，支付服务供应商不需要明确地识别客户以容许与它们的注册移动设备通信。相反，到客户身份的链接通过移动设备被建立，并且该应用能够之后开始与支付处理站点之间的通信。

在步骤561，支付服务供应商的应用将之后请求与交易代码相关联的支付明细。这导致该方法返回之前所述的步骤548，其中支付服务供应商的应用接收支付明细并在移动设备上将其显示给客户，用于随后根据步骤548之后的步骤的支付的账户选择、认证以及授权。

现将描述支付方法的进一步说明性示例，以强调支付方法如何能够也用于作出不必须与在线购买相关联的支付。这一方法利用上述的条形码扫描功能，以容许付款方(例如客户)通过简单地获得和扫描条形码来接收支付明细。

这一示例方法开始于步骤600，其中收款方期望从付款方获得支付。这一支付不需要用于所购买的商品。确实，无论出于任何原因，支付能够简单地为个人之间的资金的转移。支付可以是对慈善团体的捐赠、礼物、已发生债务的解决等等。支付还可以是服务，例如金融或保险服务，其可以响应于例如每月、每季度或每年的账单而支付。

在任何情况下，应当认识到，根据上述一般形式的支付方法，在步骤601，收款方将通过生成支付请求(包括支付请求参数)开始支付方法。收款方之后在步骤602向支付服务供应商供应支付请求。这能够根据在上述示例中描述的类似步骤以类似的方式作出。然而，由于这一方法不必须与在线购买相关联，支付请求可以以除了电子通信(例如，基于网络的通信)之外的方法被供应。然而，使用电子通信方法来供应请求通常是便利的。

在支付涉及由服务供应商等开账单的情况下，可以是服务供应商具有多个不同账单的情况，其需要从不同的个人进行不同的支付。由此收款方可以选择以一批支付请求发送至支付服务供应商来发出多个支付请求。

在收款方为个人期望从另一个人获得支付的情况下，基于个人在支付方法中的角色，每一个人可以使用各自的移动设备，以请求或确认该支付。因此，在这种情况下，收款方可以使用他们的移动设备上的支付服务供应商的应用软件生成支付请求，并且之后通过从移动设备向支付服务供应商的支付处理站点的移动通信供应该支付请求。

在任何情况下，在步骤603，以与该方法的前述形式类似的方式，支付服务供应商将通过使用支付请求而生成交易代码和支付明细来响应该支付请求。随后的步骤604(支付服务供应商将支付明细和其他支付参数与交易代码相关联)也将与前述方法类似。

在交易代码已生成的情况下，支付服务供应商之后在步骤605向收款方供应交易代码。应当认识到，这与前述方法不同，因为对于交易代码而言，被供应给收款方用于使支付进行并不总是必须的。然而，在这一情况中，收款方需要交易代码，以在步骤606生成编码该交易代码的条形码。条形码可以使用任何已知的条形码编码技术而生成。在一个示例中，支付服务供应商的应用软件可以由收款方使用，以生成条形码。这能够帮助确保条形码以一致的方式被编码，从而简化之后的解码。

收款方之后在步骤607将条形码呈现给付款方。呈现条形码的方式将取决于收款方的要求。在一个示例中，条形码可以被打印在支付***等上，以容许支付与***相对应。在一个示例中，收款方可以容许支付期限，支付能够随后在该期限内作出，如果支付未在该支付期限内作出，则应支付罚款。

条形码可以替换地被打印在任何其他物品上，以容许扫描。例如，条形码可以被打印在广告材料上、货架标签上、直接打印在产品或附在产品上的标签上、或以任何其他打印方式被提供。应当认识到，存在众多选项，用于通过这种方法使用条形码，其能够容许多种支付作出。

如上在在线购买方法中所描述的，条形码可以替换地被呈现在由付款方访问的网站上。

在个人对个人支付的情况下，其中收款方和付款方使用各自的移动设备，收款方可以在他们的移动设备上使用支付服务供应商的应用软件生成条形码，并且之后通过将条形码显示在他们的移动设备的显示器上将条形码呈现给付款方，以容许通过付款方的移动设备扫描。

在任何情况下，在步骤608，付款方使用在付款方的移动设备上的支付服务供应商的应用软件扫描条形码。在个人对个人支付的情况下，这将需要收款方和付款方在扫描条形码时处于彼此旁边。然而，其他情况能够容许收款方和付款方被定位为当扫描发生时(例如当条形码被打印在***上时)彼此远离。在步骤609，支付服务供应商的应用解码被编码在条形码中的交易代码。

针对使用移动设备支付，以下步骤将与上述的那些步骤类似。在步骤610，付款方的移动设备上的支付服务供应商的应用从支付服务供应商请求与交易代码相关联的支付明细。在步骤611，应用之后接收支付明细并将这些在付款方的移动设备上显示给付款方。

通过上述以移动设备支付为例描述的类似方式，在步骤612，付款方之后使用移动设备上支付服务供应商的应用来输入认证信息并授权支付。

这一授权在步骤613容许支付服务供应商开始资金从付款方的账户向收款方的账户的转移。在此之后，支付服务供应商接收转移结果的指示。支付服务供应商的应用将之后在步骤615在付款方的移动设备上显示资金从付款方的账户扣除的确认。

在步骤616，支付服务供应商还将通知收款方该转移结果。通常，该通知将以回应(reciprocate)支付请求方法的方式被供应。在收款方使用他们的移动设备请求支付的情况下，这一通知可以通过相同的移动设备被提供。成批的一组支付请求可以触发支付服务供应商以相应的批次提供通知，但随着支付被作出并且在支付作出时提供通知可能是更可取的，以防止提供单独支付的通知中的过分拖延。

根据支付方法的前述形式，收款方可以通过递送产品或提供服务等来响应成功转移的通知。然而，这些步骤在支付并非作为产品或服务的交换的情况下是不需要的。在任何情况下，回执可以作为支付作出的证据被提供，并且该回执可以基于交易代码被生成。

上述示例使用条形码以容许交易代码从收款方被便利地提供给付款方时，应当认识到，收款方可以以其他方法从付款方接收交易代码。

例如，支付方法可以以与上述类似的方式继续，但不是在步骤606使收款方生成编码该交易代码的条形码，而是收款方可以以一些其他形式向付款方提供交易代码。例如，收款方可以简单地使交易代码显示在收款方的移动设备的显示器上，并且付款方可以简单地手动输入交易代码。然而，由于这可能导致交易代码被错误输入，通常期望将交易代码电子传输至付款方。

因此，在一个示例中，在收款方接收交易代码之后，收款方可以之后将交易代码电子传输至付款方的移动设备。这种电子传输可以适当地使用无线通信方法。例如，短距离通信技术(例如蓝牙、近场通信(NFC)等)可以被用于容许交易代码在收款方和付款方的各自的移动设备之间传输。替换地，交易代码可以通过使用移动电话短讯服务(SMS)等被传输更长距离，在这种情况下，所接收的交易代码可以随后由在付款方的移动设备上运行的支付服务供应商的应用软件使用。另外，根据在线购买环境下的以上所描述的移动电话支付方法，交易代码可以被直接发送至付款方的移动设备。

支付方法还可以被用于对销售点(POS)交易作出支付，并且现将参考图7A至7C描述这种情况的一个说明性示例。

在这一示例中，假定支付将针对来自商家的产品的店内购买。因此，该方法在步骤700开始，其中客户在商家的商店中选择用于购买的一个或多个产品。在已选择期望的产品的情况下，客户典型地将产品带到商家的商店中的收银台(如步骤701所示)。

在步骤702，商家之后确定所选择的产品的总价，并向客户指示总价用于支付。通常，商家将询问客户他们想要针对他们的购买如何支付。在这一示例中，在步骤703，客户告知商家他们希望使用支付服务供应商来作出支付。这一方法假定商家有能力接收使用支付服务供应商而作出的支付。

在步骤704，商家生成包括支付参数的支付请求，并将其传输给支付服务供应商。这一请求可以使用位于销售点处的商家的终端站点被合适地生成并传输。例如，商家的终端站点可以是位于商家的商店的收银台处的被连接至收银机的计算机的形式，其中计算机进一步具有与支付服务供应商通信的能力。

接收支付请求时，支付服务供应商通过生成用于购买的交易代码和支付明细来响应(如步骤705所示)。支付服务供应商还将在步骤706将支付明细和其他支付参数与交易代码相关联。

在步骤707，支付服务供应商之后向客户供应交易代码。典型地，交易代码将以支付请求最初被提供至支付服务供应商的相同方法被供应。

商家之后在步骤708向客户提供交易代码，并且在步骤709，客户使用客户的移动设备获得交易代码。交易代码可以使用任何合适的技术(包括以上示例中已描述的那些技术)由商家提供并且由客户获得。

例如，如上所述，交易代码可以通过以下方式被制作为对于客户可获得的：生成编码该交易代码的条形码，并之后通过将其显示在商家的终端站点的屏幕上或将其打印在***上来将其提供给客户，从而使得客户可以扫描条形码，以由此获得交易代码。交易代码可以替换地从商家的终端站点被传输至客户的移动设备，例如通过使用无线通信(例如近场通信(NFC))技术等。

在任何情况下，移动设备上支付服务供应商的应用将最终接收交易代码(如步骤710所示)，并且支付方法将通常以与之前示例中所描述的方式类似的方式进行。

在步骤711，支付服务供应商的应用从支付服务供应商请求与交易代码相关联的支付明细。在步骤712，支付服务供应商的应用之后接收支付明细并在客户的移动设备上将其显示给客户。

客户之后在步骤713使用支付服务供应商的应用输入认证信息并授权支付，并且在步骤714，支付服务供应商将通过开始资金从客户的账户向商家的账户的转移来响应成功认证和支付授权。

根据之前的示例，在步骤715，支付服务供应商将之后接收转移结果的指示，并且如果成功，支付服务供应商之后在步骤716在客户的移动设备上显示资金从客户的账户扣除的确认。

在步骤717，支付服务供应商还通知商家转移结果。这一通知可以包括交易代码以及商家参考号码(如果其作为支付请求的部分被提供过)，从而使得商家能够更加便利地核对支付。

如果支付确实成功，之后商家能够确认所选择的产品已被支付(如步骤718所示)，在此之后，客户可以被容许拥有所购买的产品。这时，商家还可以向客户发放独立的支付回执。

如上示例中所述，支付方法的实施例可以涉及使付款方或收款方在支付服务供应商注册账户，从而使得支付能够使用所注册的账户便利地被作出或接收。因此，用于注册账户的方法的一个示例将参考图8A至8B来描述。

优选地，不考虑账户持有者将作为付款方或收款方，注册过程将是相同的。然而，应当认识到，在一些环境中，账户持有者可能仅仅希望作出支付或接收支付，并且由此注册过程可能特定地适于注册仅仅作为付款方或收款方的账户持有者。

在任何情况下，当账户持有者希望在支付服务供应商注册在金融机构持有的账户时，该方法在步骤800开始。账户持有者将请求金融机构注册他们的账户(如步骤801所示)。

响应于这一请求，在步骤802，根据金融机构的一般账户安全程序，金融机构将典型地验证账户持有者的身份。这一验证将通常是金融机构的责任，并且在验证中使用的方法可以与被用于容许对账户持有者的账户作出改变的方法相同。例如，在按照请求在支付服务供应商注册账户之前，金融机构可以请求100个识别点。

在联合银行账户的情况中，基于对账户的授权协议，金融机构可以要求每一方对账户授权。替换地，对账户的授权可以被委托给另一方。在任何情况下，这通常将根据金融机构的现有方法被处理。

在账户持有者的身份已验证的情况下，为了容许注册进行，金融机构之后请求账户持有者提供配对(pairing)代码(如步骤803所示)。

在步骤804，账户持有者与支付服务供应商通信，以生成对注册的配对请求。账户持有者可以使用任何合适的终端站点与支付服务供应商通信。例如，账户持有者可以登陆到支付服务供应商的网站或使用移动设备上的支付服务供应商的应用软件，以生成配对请求。

在任何情况下，在步骤805，支付服务供应商通过生成配对代码来响应配对请求，并且在步骤806，这一配对代码被提供给账户持有者。配对代码将典型地以与配对请求被提供给支付服务供应商所使用的相同的方式被提供给账户持有者，但这并不是必需的。

已接收配对代码的情况下，在步骤807，账户持有者之后将配对代码提供给金融机构。应当认识到，这能够以很多方法做到。例如配对代码可以被显示在账户持有者的移动设备上并且被显示给金融机构的代表，以容许金融机构将配对代码手动输入由金融机构操作的终端站点。配对代码可以被编码成条形码，用于由金融机构扫描。账户持有者可以使用在金融机构处的按键手动输入该配对代码。替换地，账户持有者可以将配对代码输入金融机构的网站，或以任何其他方式远程供应该配对代码。

金融机构获得配对代码时，金融机构将典型地与支付服务供应商通信，以请求配对校验(如步骤808所示)。在步骤809，支付服务供应商将提供配对校验。这些校验步骤提供额外的安全层，以确保金融机构仅仅响应于真实的配对请求发布账户持有者的账户详情，并且进一步确保正确的账户详情将被发布。

假定校验成功，在步骤810，金融机构之后继续向支付服务供应商提供账户详情。应当注意，基于账户持有者对注册的请求，账户详情能够用于任何数量的账户。在任何情况下，被提供给支付服务供应商的账户详情将典型地是那些使电子资金转移开关获知的账户中的信用/借记资金。

支付服务供应商随后在步骤811存储账户持有者的账户详情。通常，这些账户详情将被安全地存储且仅仅当向账户持有者的注册账户支付或从中支付时被提供给电子资金转移开关。

在步骤812，支付服务供应商通知账户持有者以及金融机构，账户已成功注册。通过使用支付服务供应商，账户持有者现能够从注册账户作出支付或接收支付。

在一个示例中，支付可以部分地作出，例如通过由相同付款方作出的多次分期付款或由不同付款方作出的多个子支付(即，“账单拆分”)。这些情况可能发生在上述示例的环境中，其中每一付款方使用他们各自的移动设备，以作出具有交易代码的支付的一部分。

在账单拆分的情况下，收款方将仍生成与交易代码一起被发出的支付请求，并且生成编码该交易代码的条形码(如上所述)。然而，收款方可以另外在支付请求中包括的支付请求参数中指定，支付能够部分作出或在多个付款方之间拆分。

因此，向支付贡献资金的每一付款方能够扫描条形码并选择将支付的特定金额。在一些情况下，付款方可以选择等分账单，并且所要求的金额可以由在付款方的移动设备中的每一个上以单独的实例(instance)运行的支付服务供应商的应用软件确定。另外，每一付款方可以手动输入将支付的金额。在任何情况下，指定金额的支付将以与上述方式相同的方式进行，其要求用户为每一子支付认证和授权。

作出子支付时，将基于交易代码发给每一付款方接收编码。接收编码可以通过将字符的可扩展部分附到交易代码的字符串上而生成，并且这一可扩展部分可以根据需要被增加或扩展，以容纳向总支付金额作出的子支付的数量。

支付服务供应商将典型地跟踪对支付的资金的成功交易，并且由收款方请求的支付金额被多个付款方共同支付时，对该结果的通知将至少被提供给收款方。在支付上的余额仍未偿付的情况下，这可以被通信给已扫描条形码的付款方。例如，已作出子支付的付款方可以被告知作为进行的子支付的支付的未偿付余额由其他付款方作出。而且，仅仅扫描条形码但尚未支付一定金额的付款方可以被通知支付的未偿付余额，以容许将对总支付金额支付的金额的知情选择。

然而，在一些情况下，付款方可能希望由单个付款方作出总支付，或者法规可能另外不容许各自的支付被拆分，并且这还可以在支付请求中被指明。

在另一示例中，付款方可以在支付请求参数中指定超额支付是容许的。这在由付款方自行决定的设置中可能是有用的，其中除了基本支付金额之外，小费是可接受的。在这种情况中，作为支付授权步骤的部分，付款方可以被促使指定等于或大于所需支付金额的支付金额。

在其他示例中，开放性的支付请求可以由收款方寻求未指定金额的捐赠而生成。在这些情况中，支付详细信息可以限于收款方的身份证明，并且付款方将有自由在授权支付时选择任何支付金额。

支付方法可以进一步被有效地应用于重复支付。尽管上述示例都可以被用于作出一次性支付(例如，用于在线购买)，该方法同样适用于支付以有规律的间隔重复的情形。例如，支付方法可以被用于容许每月保险费、订阅等被便利地支付。

在一个示例中，单一的交易代码响应于支付请求而生成，支付请求指定需要重复支付，但这一交易代码能够被用在多个支付中。付款方可以将交易代码手动输入他们的移动设备，或者可以在每一支付间歇扫描条形码。然而，在每一支付间隔出现时，使支付服务供应商向付款方推送通知是更加便利的，以由此容许付款方在每一重复支付到期时简单地授权每一重复支付。

在相关示例中，交易代码可以被生成用于资金支付，其涉及限时服务(例如沿街停车)，并且支付请求可以指定支付可以被多次作出，以延长持续时间。例如，停车计时器可以被配置为将交易代码呈现给希望在相应停车场停车的付款方。使用该交易代码的支付将对应于预先确定的停车时间。付款方已接收到交易代码时，额外的支付能够被作出，以延长停车时间。例如，如果付款方延迟并需要额外的停车时间，这可以是有用的，因为付款方能够通过使用他们的移动设备补充他们的停车支付，而不需要返回他们的车上。

在另一示例中，支付方法可以容许付款方的账户中的资金在交易后续完成之前被冻结(put on hold)。例如，这在报出酒吧消费(bar tab)或支付押金中是有用的。在酒吧总价的一个说明性示例中，付款方可以向代表收款方的酒吧侍者(即，酒吧所有者)指示用于酒吧总价的期望金额。酒吧侍者可以之后生成支付请求，指明应当在付款方的账户中冻结该金额直到支付请求终结。付款方会获得相应的交易代码并照例将其授权，但支付在这一阶段不会终结。相反，在付款方结算酒吧总价时，酒吧侍者能够更新交易账户并终结支付请求，其将使得酒吧总价的最终金额从付款方的账户被转移至收款方。之前冻结的任何其余资金之后将被释放。

如上所述，交易代码还可以具有有效期，其能够容许商家在限时支付没有对由客户选择用于在线购买的产品作出时管理库存水平等。

根据上述示例方法，用于执行该方法的多个示例装置配置将参考图9至13概述。

图9至11的示例大致相当于参考图5A至5K的上述示例方法的分支。

图9示出了用于使用网上银行对在线购买作出支付的示例装置配置(如上所述)。在这一情况中，客户操作客户终端站点203.1，商家操作商家终端站点203.2，其均为如上所述的合适的终端站点203的一个示例。支付服务供应商操作支付处理站点201，其相当于如上所述的基站201。最后，金融机构操作金融机构站点203.3，其在该示例中充当另一终端站点203。

商家终端站点203.2托管商家的网站，支付处理站点201托管支付服务供应商的网站，并且金融机构站点203.3托管金融机构的网站。

现将描述在执行网上银行支付中各自的终端站点203.1、203.2、203.3以及基站201之间特定的信息传输。

在901，产品详细信息通过商家的网站被提供给客户终端站点203.1。在902，客户选择用于购买的产品，并且商家终端站点203.2接收选择的指示。在903，商家终端站点203.2向客户终端站点203.1提供总价用于支付。在904，客户使用支付服务供应商输入要支付的期望，并且其被提供给商家终端站点203.2。

在905，商家终端站点向支付处理站点201提供支付请求。在906，交易代码和支付明细之后通过支付服务供应商的网站被提供给客户终端站点203.1。在907，客户指示他们希望使用网上银行。在908，支付服务供应商之后与客户终端站点203.1通信，以在909将客户重新导向至金融机构的网站。

在910，客户输入登陆信息以及被供应给金融机构站点的任何其他认证信息。同时，在911，支付处理站点201将交易代码传输至金融机构站点。在912，金融机构请求进一步的支付明细，并且在913，这些被提供给金融机构。在914，支付明细之后通过金融机构的网站被传输至客户。

在915，客户向金融机构提供用于支付的账户选择和授权。响应于此，在916，金融机构将账户详情转给支付服务供应商。

在917，支付服务供应商使得资金转移，并且在确定转移结果之后，通知被发送给金融机构。在918，客户随后从金融机构接收通知。在919，支付服务供应商同样地向商家提供转移结果的通知。最后，在920，客户从商家接收确认，确认支付已被接收并且产品将被运送给客户。

图10示出了用于使用支付服务供应商的网站以及使用客户的移动设备的认证对在线购买作出支付的示例装置配置。在这一情况中，客户操作第一客户终端站点203.1并且还操作第二客户终端站点203.4，即客户的移动设备。如之前的示例，商家操作商家终端站点203.2，并且支付服务供应商操作支付处理站点201。

商家终端站点203.2托管商家的网站，支付处理站点201托管支付服务供应商的网站。第二客户终端站点203.4运行由支付服务供应商提供的应用软件，其容许与支付处理***通信。

将描述在使用支付服务供应商的网站执行支付中各自的终端站点203.1、203.2、203.3、203.4以及基站201之间的信息传输。

根据以上示例，在1001，产品详细信息通过商家的网站被提供给客户终端站点203.1。在1002，客户选择用于购买的产品，并且商家终端站点接收选择的指示。在1003，商家终端站点向客户终端站点提供总价用于支付。在1004，客户使用支付服务供应商输入支付的期望，并且其被提供给商家终端站点203.2。

在1005，商家终端站点向支付处理站点201提供支付请求。在1006，交易代码和支付明细之后通过支付服务供应商的网站被提供给客户终端站点203.1。在1007，客户指示他们希望使用支付服务供应商的网站支付。

在1008，支付服务供应商之后从客户请求登陆详细信息。在1009，客户供应登陆详细信息。在成功登陆之后，在1010，支付服务供应商的网站向第一客户终端站点203.1显示交易代码和支付明细用于确认。

在1011，客户将之后访问第二客户终端站点203.4(客户的移动设备)并输入被提供给支付处理站点201的认证信息。在已认证客户的身份的情况下，支付服务供应商在1012向第二客户终端站点203.4提供授权代码。

已在第二客户终端站点203.4上接收授权代码的情况下，客户将之后将授权代码手动输入第一客户终端站点203.1作为支付应继续的确认。在1013，授权代码的手动传输被指示。在1014，授权代码之后被传输至支付服务供应商。

随着交易现由客户授权，在1015，支付服务供应商之后使得资金转移，并且在确定转移结果之后，通知被发送给客户的第一终端站点203.1。在1016，支付服务供应商同样向商家提供转移结果的通知。最后，在1017，客户从商家接收确认，确认支付已被接收并且产品将被运送给客户。

图11示出了用于对在线购买作出支付的示例装置配置，其主要使用客户的移动设备。根据之前的示例，客户操作第一客户终端站点203.1和第二客户终端站点203.4(客户的移动设备)，商家操作商家终端站点203.2，并且支付服务供应商操作支付处理站点201。

现将描述使用客户的移动设备执行支付中在各自的终端站点203.1、203.2、203.4以及基站201之间的信息传输。

根据上述示例，在1101，产品详细信息通过商家的网站被提供给客户终端站点203.1。在1102，客户选择用于购买的产品，并且商家终端站点接收选择的指示。在1103，商家终端站点向客户终端站点提供总价用于支付。在1104，客户使用支付服务供应商输入支付的期望，并且其被提供给商家终端站点203.2。

在1105，商家终端站点向支付处理站点201提供支付请求。在1106，交易代码和支付明细之后通过支付服务供应商的网站被提供给第一客户终端站点203.1。在1107，客户指示他们希望使用客户的移动设备支付。

假定支付服务供应商已从商家接收充分的信息，以识别客户，在1108，支付处理站点201将交易代码传输至客户的注册移动设备，即第二客户终端站点203.4，并通知客户新的支付。

在1109，客户访问第二客户终端站点203.4并且其触发向支付处理站点请求支付明细。在1110，支付明细随后被提供给第二客户终端站点203.4。

在1111，客户使用第二客户终端站点203.4，以为支付选择账户、输入认证信息并授权支付，并且相关信息被提供给支付处理站点201，以容许支付继续。

随着现在交易被客户授权，支付服务供应商之后使资金转移。在确定转移结果之后，在1112，通知被发送至客户的第二终端站点203.4。在1113，支付服务供应商还向商家提供转移结果的通知。最后，在1114，客户从商家接收确认，确认支付已被接收并且产品将被运送给客户。

图12示出了用于从付款方向收款方作出支付的示例装置配置，其与上述参考图6A至6C的示例方法类似。

付款方操作付款方终端站点203.5，并且收款方操作收款方终端站点203.6。在这一情况下，终端站点203.5和203.6为移动设备，其运行支付服务供应商的应用软件。在这一情况下，付款方终端站点203.5为智能手机，并且收款方终端站点203.6为平板电脑，而应当认识到，具有合适的通信能力的任何移动设备可以被使用。支付服务供应商操作支付处理站点201。

在1201，收款方终端站点203.6向支付处理站点201发出支付请求。响应于此，在1202，支付处理站点生成交易代码和支付明细，并向收款方终端站点203.6供应交易代码。

收款方终端站点203.6之后向付款方呈现交易代码。如上所述的示例，付款方可以以多种方式获得交易代码，但在这一情况下，假定收款方终端站点203.6生成编码该交易代码的条形码，并且将其显示在收款方终端站点203.6的显示器上，从而使得条形码能够由付款方终端站点203.5扫描。在1203，条形码的扫描被指示。

在1204，付款方终端站点203.5上的支付服务供应商的应用之后解码条形码，以获得交易代码，其之后与对支付明细的请求一起被传输至支付处理站点。在1205，支付明细被返回至付款方终端站点203.5。

在1206，付款方之后使用付款方终端站点203.5，为支付选择账户、输入认证信息并授权支付，并且相关信息被提供给支付处理站点201，以容许支付继续。

随着现在交易被客户授权，支付服务供应商之后使资金转移。在确定转移结果之后，在1207，通知被发送至付款方终端站点203.5。在1208，支付服务供应商还向收款方提供转移结果的通知。

图13示出了用于从客户向商家作出销售点支付的示例装置配置，其其与上述参考图7A至7C的示例方法类似。

客户操作移动设备形式的客户终端站点203.7，并且商家操作销售点终端站点203.8，例如与收银机等相连接的计算机等。支付服务供应商操作支付处理站点201。

客户在商家的商店选择用于购买的产品，并且将这些带到商家的收银台，购买详细信息在收银台被输入销售点终端站点203.8。商家将典型地告知客户支付的总价，并且在这一情况下，商家得到客户的通知，他们希望使用他们的客户终端站点203.7(客户的移动设备)上的支付服务供应商的应用软件支付。

在1301，销售点终端站点203.8向支付处理站点201发出支付请求。响应于此，在1302，支付处理站点生成交易代码和支付明细，并向销售点终端站点203.8供应交易代码。

销售点终端站点203.8之后向客户提供交易代码。在这一情况下，假定在1303，客户使用客户终端站点203.7与销售点终端站点203.8之间的无线通信获得交易代码。例如，交易代码可以通过近场通信(NFC)传输。

在任何情况下，在1304，客户终端站点203.7上的支付服务供应商的应用由此获得交易代码，其之后与对支付明细的请求一起被传输至支付处理站点。在1305，支付明细被返回至客户终端站点203.7。

在1306，客户之后使用客户终端站点203.7，以为支付选择账户、输入认证信息并授权支付，并且相关信息被提供给支付处理站201，以容许支付继续。

随着现在交易被客户授权，支付服务供应商之后使资金转移。在确定转移结果之后，在1307，通知被发送至客户终端站点203.7。在1308，支付服务供应商还向商家的销售点终端站点203.8提供转移结果的通知。

商家能够之后向客户确认支付确实已被接收并且产品已被支付并能够被客户带走。

因此，上述过程容许交易执行，而不需要付款方将支付信息输入支付处理站点，相反支付信息由收款方提供。支付处理站点之后生成交易代码，其被用于跟踪每一笔交易，并且直接或者通过付款方的金融机构向付款方终端站点提供支付明细。付款方之后以一些方式被认证，容许付款方的金融机构或支付处理站点确认付款方的身份并且之后基于此执行交易。

因此上述过程显著简化了支付，尤其减少了需要由付款方提供的信息量，该方面反过来减小了错误输入信息的可能性。而且，付款方仅仅需要在支付处理站点或他们自己的金融机构认证自己，这就意味着例如付款方的***详细信息这种信息不再需要被提供给收款方。这反过来帮助了***的进一步增强安全性，容许付款方作出支付，而不需要公开他们的***、银行账户详情等。

现将参考图14描述支付方法的其他方面，其陈述了用于从付款方向收款方执行支付的方法的进一步广义的示例。

在这一示例中，该方法在步骤1401开始，其中对支付的支付请求被接收。典型地，支付请求将由支付服务供应商从收款方接收，尽管支付请求可以从其来源被间接接收，例如通过收款方的金融机构被传输至支付服务供应商。然而，这并非是必要的，并且在一些情况下，支付请求可以由收款方的金融机构接收。

支付请求典型地响应于收款方从付款方请求资金而生成，并且可以具有与之前的示例所描述的形式类似的形式。支付请求可以基于该方法的特定实施方式在不同的位置被生成。例如，支付请求可以在由收款方操作的收款方站点被生成，使用代表收款方操作的在线商家网站被生成，或者在收款方的金融机构被生成。

支付请求将通常包括关于支付的信息，例如支付金额以及收款方的指示，而应当认识到，如之前的示例中所描述的，一系列信息可以被提供在支付请求中。

在步骤1402，交易代码和支付明细使用支付请求而生成。交易代码不仅容许支付被识别，而且能够被用于提供一种灵活的方式：容许付款方接收支付明细，以容许支付被授权。同时，交易代码将与支付请求以及所生成的支付明细相关联，其形式并不是特别限定的。然而，应当注意，优选形式的交易代码已在之前的示例中提供。

支付明细将典型地被生成为包括关于支付的详细信息类型，付款方可能希望在授权支付之前审核该类型的详细信息。通常，其将至少包括支付金额以及收款方的指示，而进一步的详细信息可以被包括，例如支付作出所指向的收款方的账户的身份证明、用于支付的收款方参考、如何能够作出支付的条件以及与支付相关联的产品的详细信息。

交易代码和支付明细可以由支付服务供应商生成，但在一些情况下，交易代码和支付明细可以由收款方的金融机构生成。

在任何情况下，交易代码已生成之后，交易代码将由付款方获得(如步骤1403所示)。如以上具体描述的，交易代码可以由付款方使用一系列不同的技术获得。而且，交易代码可以通过不同方被传输，其可以基于所使用的传输技术。例如，假定交易代码由支付服务供应商生成，其反过来可以被供应给收款方、收款方的金融机构、付款方或付款方的金融机构中的任何一方，并且可以通过那些方的任何一方被传递，直到其最终由付款方获得。

付款方仅仅需要获得交易代码，以容许支付进行，并且由于交易代码能够以其提供的很多方法被递送给付款方，其容许付款方在如何参与支付过程中有很多选择。当付款方希望继续支付时，或者在交易代码被接收或在他们的选择的稍后时间当时，付款方能够使用交易代码，以获得付款方需要的进一步的支付明细，以授权支付。

尤其，收款方将典型地向他们的金融机构或向支付服务供应商提供交易代码，从而使得支付明细能够被获取用于审核。在步骤1404，交易代码从付款方被接收，典型地与对交易代码相关联的支付明细的请求一起被接收。在一些示例中，交易代码可以通过付款方的金融机构被接收。

之后，在步骤1405，响应于接收交易代码，支付明细中的至少一些被提供给付款方。应当认识到，可能仅仅需要支付明细的一个子集，以容许支付由付款方授权，而其通常(最低限度)包括支付金额和收款方的指示。在一些情况下，所有支付明细可以被提供给付款方用于审核，但这并非是必要的。

假定付款方满意被提供用于审核的支付明细并希望完成支付，在步骤1406，付款方授权支付。这可能涉及付款方使用付款方站点确认支付被授权，并且使授权指示生成并提供给负责转移资金的一方。

根据步骤1407，资金能够之后从付款方被转移至收款方，以由此容许支付执行。在一些示例中，资金的转移可以涉及支付服务供应商接收授权指示，并且之后使得资金从付款方转移至收款方(例如通过使用付款方和收款方的注册账户详情)。然而，在其他示例中，付款方的金融机构可以接收授权指示，并直接安排资金从付款方的账户转移，而不需要支付服务供应商的参与。

支付结果的通知可以任选地被提供给收款方、收款方的金融机构、付款方、付款方的金融机构中的一个或多个。例如，其可以被用于确认所购买的商品能够被递送或以其他方式使付款方拥有，和/或容许由收款方生成对支付的回执。

在任何情况下，应当认识到，支付方法的上述示例使用交易代码，以容许支付便利，而不需要任何个人信息在收款方和付款方之间交换。仅仅交易代码需要由付款方获得，以容许其他支付明细被获取，用于授权支付。而且，授权和支付步骤能够通过付款方和他们的金融机构之间的通信或者可信的支付服务供应商被处理，而不需要收款方的任何进一步参与。因此，上述示例提供了用于便利一系列不同支付类型的灵活又安全的方法。

应当理解，上述示例从支付的一个或多个便利因素(例如支付服务供应商)的角度考虑该方法的操作。就付款方所关心的方面而言，这些步骤中的很多可能作为背景技术方法发生。从由付款方操作的付款方站点的角度，上述方法将广义地涉及以下步骤：获得交易代码，向支付服务供应商提供给交易代码，接收与交易代码相关联的支付明细中的至少一些，显示支付明细用于审核，从付款方接收授权以作出支付，以及生成授权指示用于使得资金从付款方转移至收款方，以由此执行支付。

如上所述，金融机构(包括银行等)可以在支付方法中起作用。例如，金融机构可以处理付款方的身份的认证以及对将作出的支付的授权。在另外的示例中，通过起到在收款方或付款方与支付服务供应商之间的中间方的作用，金融机构可以更加直接地涉及到支付过程中。这能够不仅便利前述认证和授权功能，而且能够在请求或作出支付时容许收款方和付款方仅仅需要与他们的金融机构交互。

因此，根据上述过程处理支付的功能可以被并入由银行和其他金融机构为它们的客户提供以执行其他银行业务任务的现有应用软件或网页界面中。由此，支付过程能够作为他们日常银行业务的部分由参与金融机构的客户使用。金融机构将之后具有实施支付方法的灵活性，以适应他们的特定需要和/或使实施方式适应个人客户的需要。

这还能够消除对客户访问用于与支付服务供应商交互的独立应用软件或网页界面的需要。研究表明银行业务客户在他们自己银行的可信环境内交易时通常感觉更加舒适，并且越来越谨慎于与第三方共享保密信息。由此，使银行起到媒介的作用可以改善可能另外提防在第三方支付服务创建新账户来使用支付过程的客户的采用率。在已知且可信的银行接口的背景中，支付服务供应商仍然能够便利资金的实际转移。

一般而言，在银行或另一金融机构起到客户与支付服务供应商之间的中间方的作用的示例中，收款方可能通过他们的常用银行界面请求资金而开始支付方法，并且支付请求将之后被传输至支付服务供应商作为后台程序。用于支付请求的交易代码能够之后通过收款方的银行被返回到收款方，从而使得收款方能够之后将交易代码提供给付款方，以容许支付被作出。

交易代码在收款方站点被接收时，收款方之后能够以任何合适的方式将交易代码提供给付款方。如上所述，付款方可以使用用于在两用户之间传输数据的一系列方法和技术接收交易代码。应当注意，交易代码可以直接在收款方和付款方之间共享，或者通过收款方站点与付款方站点之间的通信接口共享，或者甚至可以在收款方和付款方各自的银行之间共享。因此，交易代码可以使用任何合适的交互可用通信技术(包括近场通信(NFC)双音多频信号传输法(DTMF)、短讯服务(SMS)、电子邮件、即时消息(IM)等等)被传输。替换地，交易代码可以由付款方手动地输入付款方站点。

在任何情况下，付款方站点将典型地以一些方式获得交易代码，并且在此之后，付款方能够与它们自己的银行交互，以完成支付，通常不需要由收款方进行任何进一步的参与。交易代码将被提供给付款方的银行，其将反过来与支付服务供应商在后台通信，以获取支付明细，从而容许付款方通过他们的一般银行界面审核这些明细并授权支付。在容许支付继续之前，付款方的银行还能够在它认为合适时验证支付，例如通过过滤潜在的欺诈性支付请求。付款方的银行能够之后与支付服务供应商再次通信，以确认资金能够被转移。

当转移成功时，支付服务供应商将向银行确认这一事实，并且收款方和付款方可以之后从它们各自的银行接收通知。

现将参考图15A至15C描述涉及作为中间方的金融机构的这一过程的一个示例。这一过程假定收款方操作收款方站点并与收款方金融机构交互，收款方在其金融机构持有至少一个账户，并且付款方类似地操作付款方站点并与付款方金融机构交互。

在步骤1501，典型地响应于收款方操作收款方站点，指示他们希望使用由收款方金融机构提供的应用软件或网页界面在收款方站点上生成请求，收款方站点生成对支付的支付请求。在步骤1502，收款方金融机构接收支付请求，例如通过从收款方站点到收款方金融机构的互联网通信。

在步骤1503，收款方金融机构将支付请求传输至支付服务供应商，典型地通过对支付服务供应商的后端接口。收款方将不必注意这种后台通信，并且从他们的角度，他们只是通过其应用软件或网页界面与收款方金融机构交互。

在步骤1504，支付服务供应商以如上所述的一般方式使用支付请求生成交易代码和支付明细。在步骤1505，收款方金融机构接收交易代码，并且在步骤1506，将其传输至付款方站点，其中在步骤1507，其被接收。在步骤1508，收款方之后能够使用任何合适的手段向付款方提供交易代码。

然而，应当认识到，步骤1506、1507和1508并非是必要的，从而使得付款方不需要通过收款方站点和收款方金融机构接收交易代码。在替换的实施方式中，支付服务供应商可以直接将交易代码提供给收款方站点、付款方站点或付款方金融机构中的任何一方。在任何情况下，付款方将最终获得交易代码。

考虑到以上描述，应当认识到，收款方的金融机构可以通过响应于收款方对支付的请求便利交易代码的提供而参与支付方法。简而言之，金融机构接收支付请求，向支付服务供应商提供支付请求，并且任选地接收由支付服务供应商生成的交易代码和向收款方提供交易代码。

该支付方法将之后过渡至与付款方对所请求支付的授权和资金的实际转移相关联被执行的步骤，并且收款方将通常在这些步骤中没有积极的参与。还应注意，这些步骤不需要在交易代码由付款方获得之后立即进行，因为付款方可以具有在之后更方便的时间完成支付的灵活性。

在步骤1509，交易代码由付款方站点获得。这并不必须需要付款方手动输入交易代码，因为其可以根据被用于将交易代码提供给付款方的技术而直接被传输至付款方站点。在步骤1510，如验证付款方的身份并由此采取措施确保付款方站点不以欺诈手段***作所需要的，付款方站点还可能从付款方获得认证信息。

在步骤1511，付款方金融机构从付款方站点接收交易代码，并且在步骤1512，付款方金融机构随后从支付服务供应商请求与交易代码相关联的支付明细。响应于此，在步骤1513，支付服务供应商向付款方金融机构供应与交易代码相关联的支付明细，其之后在步骤1514被传输至付款方站点。

在步骤1515，付款方站点将支付明细显示给付款方，以由此容许付款方审核支付明细并授权支付。典型地，这将涉及显示支付金额以容许付款方确认金额以及至少还有收款方的指示。进一步的支付明细可以被显示，包括对支付原因的指示或者支付的条件。

在步骤1516，付款方站点从付款方获得授权，以根据支付明细作出支付。响应于此，在步骤1517，付款方站点生成授权指示，其在步骤1518被提供给付款方金融机构。

在步骤1519，付款方金融机构之后有机会根据授权指示批准该支付。在这一阶段，付款方金融机构可以在容许支付完成之前进行进一步的最终审核和过滤活动。假定金融机构没有识别到任何要拒绝支付的理由，在步骤1520，支付服务供应商使资金从付款方转移至收款方，在此之后，收款方和付款方可以得到成功支付的通知。

如前所述，在一些示例中，付款方金融机构可以直接从付款方的账户转移资金，而不需要支付服务供应商的进一步参与。在一个特定的实施方式中，可以通过使支付服务供应商向付款方金融机构供应收款方账户详情并且之后使用所接收的账户详情使付款方金融机构将所需的资金从由付款方在付款方金融机构持有的所选择账户转移至收款方的账户来便利资金的实际转移。

应当认识到，付款方能够选择通过金融机构直接作出支付的账户，而不需要支付服务供应商了解付款方用于作出支付的可用账户。而且，在这一安排下，支付服务供应商不需要接收被选择用于支付的付款方的账户的任何账户详情。

在上述的示例中，收款方的账户详情可以作为收款方的注册详细信息的部分由支付服务供应商存储，或者替换地，这些收款方账户详情可以在支付过程中恰当的阶段处被供应给支付服务供应商。例如，收款方账户详细信息可以与对支付的支付请求一起被供应给支付服务供应商，并且在一些示例中，这些收款方账户详情可以由收款方金融机构供应。

在任何情况下，支付服务供应商能够在支付过程中恰当的阶段处向付款方金融机构提供收款方的账户详情。在步骤1513，将收款方的账户详情与支付明细一起提供是方便的，而应当认识到，在步骤1514，账户详情不必须被转给付款方站点。然而，收款方的账户详情可以在该过程中其他阶段处被提供，例如以下由付款方作出授权的阶段。

总之，由此付款方的金融机构参与从付款方接收交易代码、向支付服务供应商提供交易代码、接收与交易代码相关联的支付明细中的至少一些、向付款方提供支付明细以及从付款方接收授权以作出支付。应当注意，根据之前的示例，不需要将付款方的个人详细信息(例如账户详情)提供给收款方或收款方金融机构来容许支付继续。

考虑到以上示例，应当认识到，利用起到收款方/付款方与支付服务供应商之间的中间接口的作用的金融机构实施支付方法容许金融机构保持对支付方法的控制。而且，收款方/付款方终端用户与支付服务供应商之间的所有通信可以通过金融机构进行，从而使得不需要支付方法的终端用户和支付服务供应商之间任何直接的交互。

这一安排为收款方金融机构提供了在交易代码被生成之前或在支付过程中任何其他之后的时间监控支付请求和拒绝请求的能力。类似地，其为付款方金融机构提供了如果这些未通过审核则防止可疑支付被完成或防止与交易代码相关联的支付明细被转给客户的能力。

因此，现将描述，随着以上支付方法被实施，说明可以由各自的金融机构和支付服务供应商执行的其他潜在操作的进一步具体的示例。

现将参考图16A和16B概述用于生成支付请求和相关联的交易代码的示例方法，包括由收款方金融机构和支付服务供应商作出的支付请求的过滤。

在步骤1600，收款方操作收款方站点，以生成对支付的支付请求，并且在步骤1601，收款方金融机构以上述方式接收支付请求。

在步骤1602，收款方金融机构从收款方获得用户认证信息，以容许在对于支付请求采取任何进一步的行动之前，收款方的身份得到验证。之后，假定收款方验证通过，在步骤1603，收款方金融机构由于支付请求可能是欺诈性质的迹象而过滤该支付请求。

如果在步骤1604，支付请求被怀疑具有欺诈性，在步骤1605，收款方金融机构可以不批准支付请求，其被拒绝。然而，如果支付请求被收款方金融机构批准，支付请求将被容许继续，在这一情况下，在步骤1606，收款方金融机构将支付请求传输至支付服务供应商。

在步骤1607，支付服务供应商接收支付请求，并且在步骤1608，还有机会进行额外的欺诈过滤。如果在步骤1609，支付服务供应商不批准支付请求，在1610，其被拒绝，但在步骤1609支付请求被批准的情况下，在步骤1611，支付服务供应商将使用支付请求通过生成交易代码和相关联的支付明细来继续该过程。替换地，交易代码可以在欺诈过滤之前被生成，并且之后欺诈活动的记录能够由支付服务供应商参考交易代码来跟踪，即使其没有被用于支付。

在这一示例中，为了达到说明收款方金融机构的潜在参与的目的，假定收款方将在交易代码从收款方金融机构被接收之后将交易代码提供给付款方。然而，应当理解为，交易代码可以由付款方使用用于传输交易代码的上述技术中的任一种获得。

在步骤1612，交易代码由收款方金融机构接收，并且在步骤1613，其被供应至收款方站点。在步骤1614，收款方之后使用收款方站点接收交易代码，并且在步骤1615，收款方向付款方供应交易代码。然而，替换地，收款方金融机构能够直接将交易代码传输至付款方或付款方的金融机构(在一些情况下，这可能是相同的金融机构)。

在任何情况下，应当认识到，上述方法容许支付请求被金融机构或支付服务供应商阻拦，并且这能够防止对支付欺诈性的或其他不期望的请求被呈现给潜在的付款方。这能够帮助确保在付款方意识到欺诈性的支付请求之前阻止意图欺诈的活动。

类似的过滤和其他核对也可以作为由付款方对支付的授权的部分而进行，并且现将参考图17A至17D对其进一步的示例进行扩展。

在步骤1700，付款方站点以前述方式中的任一种获得交易代码。在步骤1701，付款方站点还从付款方获得认证信息。在步骤1702，付款方金融机构之后从付款方站点接收交易代码和认证信息，例如通过由付款方站点访问的付款方金融机构的应用软件或网页界面。

在步骤1703，付款方金融机构进行认证信息的验证。在步骤1704，如果认证信息被认定为无效的，则在步骤1705，支付被拒绝。然而，在步骤1704，如果认证信息通过，则在步骤1706，付款方金融机构通过从支付服务供应商请求与交易代码相关联的支付明细而继续。

在步骤1707，支付服务供应商接受交易代码，并且在步骤1708，支付服务供应商可以之后进行交易代码的验证，例如通过查询交易代码记录并确认所接收的交易代码是否有效且未过期。如果交易代码被发现是无效的，在步骤1710，支付过程可能终止，但如果在步骤1709交易代码被确认为有效的，在步骤1711，支付服务供应商将获取并将与交易代码相关联的支付明细供应给付款方金融机构。

现已接收支付明细的情况下，在步骤1712，付款方金融机构能够之后处理支付明细，以确定是否继续支付。这种处理可以包括决策算法的操作，其分析包括支付金额和其他支付参数的支付明细。例如，如果支付请求超出对付款方的账户的预先确定的每日支付限额，付款方金融机构可以决定不继续。

在步骤1713付款方金融机构决定不继续的情况下，在步骤1714，支付被拒绝。然而，如果支付明细是可接受的，在步骤1713，付款方金融机构将继续，并且在步骤1715，付款方金融机构将支付明细传输至付款方站点，其中支付明细能够被呈现给付款方用于授权。

在步骤1716，付款方审核支付明细并确定是否授权支付。在步骤1717，如果支付未被授权，在步骤1718，其被拒绝，但在步骤1717成功授权的情况下，付款方站点将之后获得从付款方获得授权以作出支付并且在步骤1719将其传输至付款方金融机构。

在步骤1720，付款方金融机构将有机会在资金转移被容许发生之前进行经授权的支付的最终验证。在步骤1721，如果付款方金融机构不提供最终批准，则在步骤1722，支付被拒绝。另外，在步骤1721批准的情况下，付款方金融机构生成批准指示并在步骤1723将其传输至支付服务供应商。

在步骤1724，支付服务供应商还可以进行其自己对经批准的支付的最终验证。其可以包括对欺诈性活动迹象的进一步过滤。同时，在交易代码被生成之前，支付请求可能已经被过滤，这种过滤可能明显更早地发生，并且这可能是以下情况：在此期间欺诈性活动的新证据已经累积，使得支付服务供应商考虑到在对支付请求的初始欺诈过滤时不可用的新证据而期望阻拦资金的转移。其他验证也可以进行，以确保经批准的支付将根据支付请求继续。

在步骤1725支付服务供应商决定不继续的情况下，在步骤1726，支付被拒绝。另外，在步骤1725，如果支付服务供应商无法确定停止支付的任何原因，则在步骤1727，支付服务供应商将继续支付并试图使资金从付款方转移至收款方。

在步骤1728，如果转移失败，则在步骤1729，支付被拒绝。然而，在步骤1728转移成功的情况下，则在步骤1730，支付服务供应商生成交易成功指示并将其传输至各自的金融机构。

因此，付款方和收款方均能够得到成功转移的通知。具体而言，在步骤1731，付款方金融机构接收成功指示并将其转至付款方站点，从而使得在步骤1732付款方得到交易完成的通知。类似地，在步骤1733，收款方金融机构接收成功指示，并且在步骤1734，收款方随后通过付款方站点得到交易完成的通知。

在其他示例中，涉及作为中间接口的收款方金融机构和付款方金融机构的类似的过程还可以被应用于如上参考图5A至5K所述的在线购买情况和其他类似交易。

就这一点而言，希望接收在线支付的在线商家可以使他们的商家网站将客户导向支付网关，以容许支付执行用于在线购买。具体而言，支付网关可以便利代表商家的支付请求，并且还在支付最终由客户作出时处理对商家的账单***的通知。

支付网关可以由商家的金融机构托管，并且由此在金融机构自己的品牌和策略下操作，因此可以提升客户在完成支付中的信任。在一些示例中，尽管由商家的金融机构托管，支付网关可以由支付服务供应商提供和维护。因此，支付网关功能可以作为白色标签网关由支付服务供应商供应，以容许金融机构托管与支付服务供应商的流程兼容的支付网关，同时还容许金融机构修改界面用于与它们现有界面相比一致的外观和感觉。尽管支付网关可以由支付服务供应商提供，其可以独立于负责便利资金的实际转移的支付服务供应商和支付处理站点由金融机构托管和操作。

甚至在支付网关由在线商家使用时，所有支付请求可能仍然通过商家的收款方金融机构自己的***发送，以容许如上所述的支付请求的过滤。由此，在疑似欺诈等情况下，通过支付网关开始的支付请求可以由商家的收款方金融机构在任何时候删除。

同样地，支付过程中支付网关的参与可以仅限于简单地为开始支付请求的生成提供常见的客户界面以及为客户提供所接收的交易代码，由此容许通过使用上述的任何方法以客户期望的任何方式在所托管的支付网关环境之外作出支付。支付网关还可以任选地通知客户支付成功，并且由此向客户确认交易已完成。客户不需要通过所托管的支付网关提供任何个人信息(例如银行账户详情)，并且特定的资金转移的交易详细信息不需要通过支付网关发送。

这种托管的支付网关还可以便利批次请求，容许以减小的努力开始多个支付。例如，这在服务供应商需要获得大量周期***的交易代码时是特别有用的。托管的支付网关可以由此容许以批次操作生成多个支付请求，其反过来能够容许多个交易代码被支付服务供应商返回。在这种情况下，支付网关还可以提供应用程序界面(API)，用于容许支付请求的批次上传。

应当认识到，使用支付方法防止敏感个人信息和支付明细在客户之间交换的原则针对该信息的欺诈性使用提供了安全性的基础水平。而且，上述示例过程包括由金融机构和/或支付服务供应商欺诈过滤的可能性。现将描述欺诈防治措施的实施方式的进一步详细信息。

在利用起到中间方作用的金融机构帮助支付请求和交易的情况下，其容许交易每一方的金融机构结合他们自己现有的风险控制措施和监控方案。

支付服务供应商还能够利用复杂的欺诈检测和监测方法，其能够与金融机构的方案一起工作。例如，在支付请求接收或随后的交易代码生成之后，每一请求可以通过过滤器的综合列表并且评分模型可以被应用，其具有标记和删除超出评分基准的支付的能力。

因此，其相对于传统的支付模型提供了以下优点：支付服务供应商能够在其完成之前阻止支付。

欺诈指示器的一些特定示例如下。嵌入交易代码中的支付金额和支付请求的或信息的其他参数之间的匹配可以被执行，并且其还可以容许代码替换或变更的检测。定位核对可以被执行，例如通过将网络IP地址定位和由移动设备检测的实际定位(例如通过使用GPS技术)相比较。收款方作出的支付请求中不正常波动(例如支付请求的数值和/数量上涨或下降)还可能说明欺诈性活动。还可以使用区域过滤。

应当认识到，还可以使用先进的认证方法通过移动设备为支付方法的使用提供额外的保障。可以进行双重认证，并且例如，可以将额外的认证方法引入用于大额交易。声音记录或生物特征信息(例如指纹)也可以被用于验证用户的身份并针对未授权或欺诈性使用提供额外的保护等级。

本领域技术人员将认识到，很多变化和修饰是显而易见的。所有这些对于本领域技术人员显而易见的变化和修饰都应视为落在上述广义上的本发明精神和范围内。

Claims (76)

1.一种用于从付款方向收款方执行支付的方法，其中所述方法包括：

a)接收对支付的支付请求，所述支付请求响应于所述收款方从所述付款方请求资金而生成；

b)使用所述支付请求生成交易代码和支付明细，所述交易代码由所述付款方获得；

c)从所述付款方接收所述交易代码；以及，

d)响应于接收所述交易代码，向所述付款方提供包括支付金额和所述收款方的指示的支付明细中的至少一些，由此容许所述付款方授权支付。

2.根据权利要求1所述的方法，其中所述方法包括从以下对象中的至少一个接收所述支付请求：

a)所述收款方；以及，

b)所述收款方的金融机构。

3.根据权利要求1或2所述的方法，其中所述方法包括向以下对象中的至少一个提供所述交易代码：

a)所述收款方；

b)所述收款方的金融机构；

c)所述付款方；以及，

d)所述付款方的金融机构。

4.根据权利要求1至3中任一项所述的方法，其中所述方法包括从以下对象中的至少一个接收所述交易代码：

a)所述付款方；以及，

b)所述付款方的金融机构。

5.根据权利要求1至4中任一项所述的方法，其中所述方法包括：

a)接收授权指示，所述授权指示响应于所述付款方对所述支付的授权而生成；

b)响应于所述授权指示，使所述资金从所述付款方转移至所述收款方，以由此执行所述支付。

6.根据权利要求5所述的方法，其中所述方法包括使用所述付款方和所述收款方的注册账户详情使所述资金从所述付款方转移至所述收款方。

7.根据权利要求5或6所述的方法，其中所述方法包括向以下对象中的至少一个提供支付结果的通知：

a)所述收款方；

b)所述收款方的金融机构；

c)所述付款方；以及，

d)所述付款方的金融机构。

8.根据权利要求1-7中任一项所述的方法，其中所述方法包括：

a)从所述付款方的金融机构接收所述交易代码；以及，

b)向所述付款方的金融机构提供所述支付明细，由此容许所述付款方通过所述付款方的金融机构授权所述支付。

9.根据权利要求1-8中任一项所述的方法，其中所述方法包括由于欺诈迹象过滤以下对象中的至少一个：

a)所述支付请求；

b)所述交易代码；以及，

c)所述支付明细。

10.根据权利要求1-9中任一项所述的方法，其中所述方法包括在提供所述支付明细中的至少一些之前验证所述交易代码。

11.根据权利要求1-10中任一项所述的方法，其中所述支付请求包括由所述收款方供应的支付请求参数，所述支付明细中的至少一些使用所述支付请求参数而生成。

12.根据权利要求11所述的方法，其中所述支付请求参数包括以下项目中的至少一个：

a)所述支付金额；

b)所述收款方的指示；

c)所述支付作出所指向的所述收款方的账户的身份证明；

d)用于所述支付的收款方参考；

e)所述支付如何能够作出的条件；以及，

f)与所述支付相关联的产品的详细信息。

13.根据权利要求12所述的方法，其中所述条件包括以下条件中的至少一个：

a)所述支付是否能够部分作出；

b)所述支付是否能够超额支付；

c)支付必须作出的期间；以及，

d)所述支付是否为重复支付。

14.根据权利要求1-13中任一项所述的方法，其中所述交易代码包括一串多个字母数字字符。

15.根据权利要求14所述的方法，其中所述交易代码使用Base36数字***而生成。

16.根据权利要求14或15所述的方法，其中所述交易代码内至少一些预先确定的字符位置被用于编码关于所述收款方与所述支付中的至少一个的信息。

17.根据权利要求1-16中任一项所述的方法，其中所述交易代码由多个付款方获得，并且所述方法包括：

a)从所述多个付款方中的每一个接收所述交易代码；

b)向所述多个付款方提供所述支付明细中的至少一些；以及，

c)从所述多个付款方中的每一个接收对所述支付的各自部分的授权，从而使得所述部分的总金额等于或大于由所述收款方请求的所述支付的金额。

18.根据权利要求1-17中任一项所述的方法，其中所述方法包括通过所述付款方的金融机构与所述付款方通信。

19.一种用于提供交易代码的方法，所述交易代码用于在从付款方向收款方执行支付中使用，其中所述方法包括所述收款方的金融机构：

a)从所述收款方接收对支付的支付请求，所述支付请求响应于所述收款方从所述付款方请求资金而生成；

b)向支付服务供应商提供所述支付请求，以容许交易代码和支付明细使用所述支付请求而生成；

c)从所述支付服务供应商接收所述交易代码；以及，

d)向所述收款方提供所述交易代码。

20.根据权利要求19所述的方法，其中所述方法包括由于欺诈迹象所述收款方的金融机构过滤所述支付请求。

21.根据权利要求19或20所述的方法，其中所述方法包括所述收款方的金融机构：

a)从所述收款方获得认证信息；以及，

b)在向所述支付服务供应商提供所述支付请求之前验证所述认证信息。

22.一种用于接收授权的方法，所述授权用于在从付款方向收款方执行支付中使用，其中所述方法包括所述付款方的金融机构：

a)从所述付款方接收交易代码，所述交易代码与用于所述支付的支付明细相关联；

b)向所述支付服务供应商提供所述交易代码；

c)从所述支付服务供应商接收与所述交易代码相关联的所述支付明细中的至少一些，所述支付明细中的所述至少一些包括支付金额和所述收款方的指示；

d)向所述付款方提供所述支付明细中的所述至少一些；以及，

e)从所述付款方接收授权，以根据所述支付明细中的所述至少一些作出支付。

23.根据权利要求22所述的方法，其中所述方法包括由于欺诈迹象所述付款方的金融机构过滤所述支付明细中的所述至少一些。

24.根据权利要求22或23所述的方法，其中所述方法包括所述付款方的金融机构：

a)从所述付款方获得认证信息；以及，

b)验证所述认证信息。

25.根据权利要求22至24中任一项所述的方法，其中所述方法包括所述付款方的金融机构：

a)响应于所述付款方对所述支付的授权，生成授权指示；以及，

b)向所述支付服务供应商提供所述授权指示，以由此容许所述支付服务供应商使所述资金从所述付款方转移至所述收款方，以由此执行支付。

26.根据权利要求22至24中任一项所述的方法，其中所述方法包括所述付款方的金融机构响应于接收所述授权使所述资金从所述付款方转移至所述收款方，以由此执行支付。

27.一种用于从付款方向收款方执行支付的方法，其中所述方法包括：在由所述付款方操作的付款方站点处，

a)获得交易代码，所述交易代码与用于支付的支付明细相关联；

b)向支付服务供应商提供所述交易代码；

c)从所述支付服务供应商接收与所述交易代码相关联的支付明细中的至少一些，所述支付明细中的所述至少一些包括支付金额和所述收款方的指示；

d)显示所述支付明细中的所述至少一些；

e)从所述付款方接收授权，以根据所述支付明细中的所述至少一些作出支付；以及，

f)生成授权指示，用于使所述资金从所述付款方转移至所述收款方，以由此执行支付。

28.根据权利要求27所述的方法，其中所述授权指示被提供给以下对象中的至少一个：

a)所述支付服务供应商；以及，

b)所述付款方的金融机构。

29.根据权利要求27或28所述的方法，其中所述方法包括所述付款方站点接收认证信息，用于容许所述付款方的身份在所述授权之前被验证。

30.根据权利要求29所述的方法，其中所述认证信息被提供给以下对象中的至少一个：

a)所述支付服务供应商；以及，

b)所述付款方的金融机构。

31.根据权利要求27-30中任一项所述的方法，其中所述交易代码由所述付款方站点使用以下方式中的至少一种而获得：

a)短讯服务(SMS)；

b)即时消息(IM)；

c)电子邮件；

d)多音多频信号传输法(DTMF)；

e)无线通信；

f)近场通信(NFC)；

g)条形码；

h)QR码；以及，

i)由所述付款方手动输入。

32.一种用于从操作付款方站点的付款方向操作收款方站点的收款方执行支付的方法，其中所述方法包括：

a)在收款方站点处，生成对所述支付的支付请求；

b)在支付处理站点处：

i)接收所述支付请求；以及，

ii)使用所述支付请求生成交易代码和支付明细；

c)在所述付款方站点处，获得所述交易代码；

d)在所述支付处理站点处：

i)从所述付款方站点接收所述交易代码；以及，

ii)向所述付款方站点提供所述支付明细中的至少一些，所述支付明细中的所述至少一些包括支付金额和所述收款方的指示；以及，

e)在所述付款方站点处：

i)接收所述支付明细中的所述至少一些；以及，

ii)从所述付款方获得授权，以根据所述支付明细中的所述至少一些作出支付。

33.根据权利要求32所述的方法，其中所述方法包括：

a)在所述付款方站点处：

i)响应于来自所述付款方的所述授权，生成授权指示；以及，

ii)向所述支付处理站点提供所述授权指示；以及，

b)在所述支付处理站点处：

i)接收所述授权指示；以及，

ii)响应于所述授权指示，使所述资金从所述付款方转移至所述收款方，以由此执行所述支付。

34.根据权利要求32或33所述的方法，其中所述方法包括所述支付处理站点从以下对象中的至少一个接收所述支付请求：

a)所述收款方站点；以及，

b)收款方金融机构站点。

35.根据权利要求32至34中任一项所述的方法，其中所述方法包括所述支付处理站点向以下对象中的至少一个提供所述交易代码：

a)所述收款方站点；

b)所述收款方金融机构站点；

c)所述付款方站点；以及，

d)付款方金融机构。

36.根据权利要求32至35中任一项所述的方法，其中所述方法包括所述支付处理站点从以下对象中的至少一个接收所述交易代码：

a)所述付款方站点；以及，

b)所述付款方金融机构站点。

37.根据权利要求32至36中任一项所述的方法，其中所述方法包括，在付款方金融机构站点处：

a)从所述付款方站点接收授权指示；以及，

b)向所述支付处理站点提供所述授权指示，以由此使所述资金从所述付款方转移至所述收款方。

38.根据权利要求32至37中任一项所述的方法，其中所述方法进一步包括由于欺诈迹象，由以下对象中的至少一个过滤所述支付请求：

a)所述收款方站点；

b)所述收款方金融机构；以及，

c)所述支付处理站点。

39.根据权利要求32至38中任一项所述的方法，其中所述方法进一步包括由于欺诈迹象，由以下对象中的至少一个过滤所述支付明细中的至少一些：

a)所述付款方站点；

b)所述付款方金融机构；以及，

c)所述支付处理站点。

40.一种用于从操作付款方站点的付款方向操作收款方站点的收款方执行支付的方法，其中所述方法包括：

a)在所述收款方站点处：

i)生成对所述支付的支付请求；以及，

ii)向收款方金融机构提供所述支付请求；

b)在所述收款方金融机构站点处：

i)接收所述支付请求；以及，

ii)向支付处理站点提供所述支付请求；

c)在所述支付处理站点处：

i)接收所述支付请求；以及，

ii)使用所述支付请求生成交易代码和支付明细；

d)在所述付款方站点处：

i)获得所述交易代码；以及

ii)向所述付款方金融机构提供所述交易代码；

e)在所述付款方金融机构站点处：

i)接收所述交易代码；以及，

ii)向所述支付处理站点提供所述交易代码；

f)在所述支付处理站点处：

i)接收所述交易代码；以及

ii)向所述付款方金融机构提供所述支付明细中的至少一些，所述支付明细中的所述至少一些包括支付金额和所述收款方的指示；

g)在所述付款方金融机构站点处：

i)接收所述支付明细中的所述至少一些；以及，

ii)向所述付款方提供所述支付明细中的所述至少一些；

h)在所述付款方站点处：

i)接收所述支付明细中的所述至少一些；以及，

ii)从所述付款方获得授权，以根据所述支付明细中的所述至少一些作出支付；以及，

i)响应于所述授权，使资金从所述付款方转移至所述收款方，以由此执行所述支付。

41.一种用于从操作付款方站点的付款方向操作收款方站点的收款方执行支付的方法，其中所述方法包括：

a)在所述收款方站点处，生成对所述支付的支付请求；

b)在所述付款方站点处：

i)获得交易代码和支付明细，所述交易代码和支付明细使用所述支付请求而生成；

ii)获得认证信息；

iii)从所述付款方获得授权，以根据所述支付明细作出支付；以及，

iv)生成授权指示和认证信息；以及，

c)在支付处理站点处，响应于所述授权指示和认证信息，使资金从所述付款方转移至所述收款方，以由此执行所述支付。

42.根据权利要求41所述的方法，其中所述方法进一步包括，在所述支付处理站点处：

a)从所述收款方站点接收所述支付请求；以及，

b)使用所述支付请求生成所述交易代码和所述支付明细。

43.根据权利要求41所述的方法，其中所述方法进一步包括，在所述收款方站点处，使用所述支付请求生成所述交易代码和所述支付明细。

44.根据权利要求41至43中任一项所述的方法，其中所述支付请求包括由所述收款方供应的支付请求参数，所述支付明细中的至少一些使用所述支付请求参数而生成。

45.根据权利要求44所述的方法，其中所述支付请求参数包括以下项目中的至少一个：

a)所述支付作出所指向的所述收款方的账户的身份证明；

b)用于所述支付的收款方参考；

c)要支付的资金额；

d)所述支付如何能够作出的条件；以及，

e)与所述支付相关联的产品的详细信息。

46.根据权利要求45所述的方法，其中所述条件包括以下条件中的至少一个：

a)所述支付是否能够部分作出；

b)所述支付是否能够超额支付；

c)支付必须作出的期间；以及，

d)所述支付是否为重复支付。

47.根据权利要求41至46中任一项所述的方法，其中所述方法进一步包括：

a)在所述支付处理站点处，将所述支付明细与所述交易代码相关联；以及，

b)在所述付款方站点处：

i)获得所述交易代码；以及，

ii)从所述支付处理站点获得与所述交易代码相关联的所述支付明细，并向所述付款方显示所述支付明细中的至少一些用于授权。

48.根据权利要求41至47中任一项所述的方法，其中所述交易代码包括一串多个字母数字字符。

49.根据权利要求48所述的方法，其中所述交易代码使用Base36数字***而生成。

50.根据权利要求48或49所述的方法，其中所述交易代码内至少一些预先确定的字符位置被用于编码关于所述收款方与所述支付中的至少一个的信息。

51.根据权利要求48至50中任一项所述的方法，其中接收编号在所述支付已执行之后生成，所述接收编号包括用于所述支付的所述交易代码。

52.根据权利要求51所述的方法，其中所述接收编号进一步包括除了交易字符之外的字符的可扩展部分，所述可扩展部分被用在多个支付针对相同的交易代码作出的情况下。

53.根据权利要求41至52中任一项所述的方法，其中所述方法被用于由所述付款方执行支付，用于来自所述收款方的产品的在线购买，所述方法进一步包括，在所述收款方站点处：

a)从付款方接收用于购买的产品的选择，所述付款方使用所述付款方站点以访问由所述收款方站点托管的收款方网站；

b)生成对所述产品的支付的支付请求；

c)将所述支付请求传输至所述支付处理站点；

d)支付已执行时，从所述支付处理站点接收确认；以及，

e)安排产品向所述付款方的递送。

54.根据权利要求41至53中任一项所述的方法，其中所述认证信息和授权指示由持有所述付款方的账户的金融机构站点获得。

55.根据权利要求54所述的方法，其中所述方法进一步包括：

a)在所述金融机构站点处，接收所述交易代码和所述支付明细；

b)在所述付款方站点处，与所述金融机构站点通信，以根据所述支付明细提供认证信息并授权与所述交易代码相关联的所述支付；以及，

c)在所述支付处理站点处，从所述金融机构接收授权指示，并将资金从所述付款方转移至所述收款方，以由此执行所述支付。

56.根据权利要求41至55中任一项所述的方法，其中所述方法包括将所述交易代码嵌入被提供给所述付款方的条形码中，所述付款方站点通过扫描和解码所述条形码获得所述交易代码。

57.根据权利要求56所述的方法，其中所述条形码通过以下方式中的至少一种被提供给所述付款方：

a)将所述条形码打印在***上；

b)将所述条形码显示在所述收款方站点上；

c)将所述条形码显示在所述付款方站点上；

d)将所述条形码打印在物品上。

58.根据权利要求57所述的方法，其中所述付款方操作第一付款方站点和第二付款方站点，所述第二付款方站点为移动计算设备，所述条形码被显示在所述第一付款方站点的显示器上并且由所述第二付款方站点扫描和解码，从而使得所述交易代码由所述第二付款方站点获得。

59.根据权利要求41至58中任一项所述的方法，其中所述付款方操作第一付款方站点和第二付款方站点，所述第二付款方站点为移动计算设备，所述方法进一步包括：

a)在所述第二付款方站点处，向所述付款方提供一次性密码；以及，

b)在所述第一付款方站点处，使所述付款方输入所述一次性密码，以由此获得所述认证信息中的至少一些。

60.根据权利要求41至59中任一项所述的方法，其中所述付款方站点为移动计算设备，其操作应用软件，用于容许与所述支付处理站点安全通信。

61.根据权利要求60中任一项所述的方法，其中所述方法被用于由所述付款方执行对来自所述收款方的产品的购买的销售点支付，所述方法进一步包括：

a)在所述收款方站点处：

i)生成对由所述付款方选择用于购买的产品的支付的所述支付请求；以及，

ii)向所述付款方提供所述交易代码；

b)在所述付款方站点处：

i)获得所述交易代码；

ii)从所述付款方获得认证信息并获得授权；以及，

iii)向所述支付处理站点提供所述授权指示和所述认证信息；以及，

c)在所述收款方站点处：

i)支付已执行时，从所述支付处理站点接收确认；以及，

ii)向所述付款方提供所述产品已支付的确认。

62.根据权利要求61所述的方法，其中所述支付处理站点向所述付款方站点提供所述交易代码。

63.根据权利要求41至62所述的方法，其中所述收款方和所述付款方中的每一个是账户持有者，其在金融机构持有至少一个账户并且具有在所述支付处理站点注册的各自的账户详情。

64.根据权利要求63所述的方法，其中所述账户持有者的账户的注册包括：

a)在所述支付处理站点处：

i)从账户持有者接收配对请求；以及，

ii)生成配对代码并向所述账户持有者提供所述配对代码；

b)在所述金融机构处：

i)接收所述配对代码；

ii)与所述支付处理站点通信，以获得所述配对代码的验证；以及，

iii)向所述支付处理站点提供所述账户持有者的账户详情；以及，

c)在所述支付处理站点处，存储所述账户详情，以由此注册所述账户。

65.根据权利要求41至64中任一项所述的方法，其中所述方法包括使多个付款方作出所述支付的部分，从而使得所述部分的总金额等于或大于由所述收款方请求的所述支付的金额。

66.根据权利要求65所述的方法，其中所述多个付款方中的每一个操作各自的付款方站点，所述方法进一步包括，在每一付款方站点处：

a)获得所述交易代码和支付明细；

b)从所述付款方接收对作出与所述交易代码相关联的所述支付的特定部分的授权；

c)将授权指示传输至所述支付处理站点，以容许所述支付处理站点使资金从所述付款方转移至所述收款方，以由此执行所述支付的所述部分；以及，

d)接收用于所述支付的所述部分的接收编号。

67.根据权利要求66所述的方法，其中由所述收款方请求的所述支付的金额已由所述多个付款方共同支付时，所述支付处理站点向所述收款方提供通知。

68.根据权利要求41至67中任一项所述的方法，其中所述方法包括所述支付处理站点在使所述资金转移之前认证所述付款方的身份。

69.根据权利要求68所述的方法，其中所述认证包括以下方式中的至少一个：

a)要求由所述付款方在所述付款方站点处输入认证代码；

b)要求所述付款方站点具有与注册设备标识匹配的设备标识；以及，

c)要求输入与注册生物特征标识匹配的生物特征标识。

70.一种用于从操作付款方站点的付款方向操作收款方站点的收款方执行支付的方法，其中所述方法包括，在支付处理站点处：

a)从所述收款方站点接收对所述支付的支付请求；

b)使用所述支付请求生成交易代码和支付明细；以及，

c)响应于由所述付款方站点生成的授权指示和认证信息，使资金从所述付款方转移至所述收款方，以由此执行所述支付。

71.一种用于从操作付款方站点的付款方向操作收款方站点的收款方执行支付的方法，其中所述方法包括，在所述付款方站点处：

a)接收使用支付请求生成的交易代码和支付明细，所述支付请求由所述收款方站点生成；

b)显示所述支付明细；

c)响应于所显示的支付明细，从所述付款方接收授权和认证信息；以及，

d)生成授权指示和认证信息用于传输至所述支付处理站点，以容许所述支付处理站点使资金从所述付款方转移至所述收款方，以由此执行所述支付。

72.一种用于从付款方向收款方执行支付的装置，所述装置包括由所述付款方操作的付款方站点、由所述收款方操作的收款方站点、以及由支付服务供应商操作的支付处理站点，其中所述装置用于：

a)在所述收款方站点处，生成对所述支付的支付请求；

b)在所述付款方站点处：

i)获得交易代码和支付明细，所述交易代码和支付明细使用所述支付请求而生成；

ii)获得认证信息；

iii)从所述付款方获得授权，以根据所述支付明细作出支付；以及，

iv)生成授权指示和认证信息；以及

c)在支付处理站点处，响应于所述授权指示和认证信息，使资金从所述付款方转移至所述收款方，以由此执行所述支付。

73.根据权利要求72所述的装置，其中所述付款方站点和收款方站点使用通信网络与所述支付处理站点通信。

74.根据权利要求72所述的装置，其中所述装置用于执行根据权利要求41至69中任一项所述的方法。

75.一种用于从操作付款方站点的付款方向操作收款方站点的收款方执行支付的装置，所述装置包括与所述付款方站点和所述收款方站点通信的支付处理站点，其中所述支付处理站点用于：

a)从所述收款方站点接收对所述支付的支付请求；

b)使用所述支付请求生成交易代码和支付明细；以及，

c)响应于作出与由所述付款方站点生成的所述交易代码和认证信息相关联的支付的来自所述付款方的授权的授权指示，使资金从所述付款方转移至所述收款方，以由此执行所述支付。

76.一种用于从付款方向收款方执行支付的装置，所述装置包括由所述付款方操作的付款方站点、由所述收款方操作的收款方站点、以及由支付服务供应商操作的支付处理站点，其中所述付款方站点用于：

a)接收使用支付请求生成的交易代码和支付明细，所述支付请求由所述收款方站点生成；

b)显示所述支付明细；

c)响应于所显示的支付明细，从所述付款方接收授权和认证信息；以及，

d)生成授权指示和认证信息用于传输至所述支付处理站点，以容许所述支付处理站点使资金从所述付款方转移至所述收款方，以由此执行所述支付。