结账时接受发行方凭证的制作方法

相关申请的交叉引用

本申请是根据PCT的国际专利申请，本申请要求2017年1月27日提交的美国非临时专利申请序列号15/418,552的优先权，该申请又要求2016年1月27日提交的美国临时专利申请序列号62/287,754的优先权，通过引用将该文献的公开内容全文并入本文。

技术领域

本发明涉及用于在结账时接受发行方凭证的系统和方法。

背景技术：

现有的用于接受支付的系统效率低下，而且给消费者带来了摩擦。

附图说明

通过结合附图参考详细描述可以更好地理解本发明。附图中的部件不一定按比例绘制，而是将重点放在说明本发明的原理上。在附图中，在整个不同的图中类似的附图标记表示相应的部件。

图1示出了说明根据示例性实施方案的系统的各个示例性方面的方框图。

图2A-B示出了根据示例性实施方案的示例性商家结账图形用户界面。

图3A示出了根据示例性实施方案的用于确定处理器结账程序的合格性(eligibility)的流程图，图3B示出了用于根据示例性实施方案的用于将用户注册到结账程序和在线发行方平台内的流程图。

图4示出了根据示例性实施方案的方法的流程图。

本领域的普通技术人员将理解，为了简单和清晰起见而示出了附图中的元件，因此并非已经示出了所有的连接和选项以避免模糊本发明的各方面。例如，在商业上可行的实施方案中有用或必需的常见但很好理解的元件不经常被描绘，以助于对本公开的这些各种实施方案的较少阻碍的观察。将进一步理解，可以以特定的发生顺序描述或描绘某些动作和/或步骤，而本领域的技术人员将理解，实际上不需要关于序列的此种特异性。还将理解，本文中所用的术语和表达将针对它们相应的各自的询问和研究领域来定义，除非其中在本文中已经另外阐述了特定含义。

具体实施方式

现在将参考附图来更全面地描述本发明，附图形成本发明的一部分并且附图以说明的方式示出了通过其可以实践本发明的具体示例性实施方案。这些图示和示例性实施方案被提供的同时应理解，本公开是对一个或多个发明的原理的举例说明，而无意将任何一个发明限制于所图示的实施方案。本发明可以以许多不同的形式体现，并且不应被理解为限于本文所阐述的实施方案；而是提供这些实施方案，以使得本公开将是透彻和完整的，并且将向本领域的技术人员充分地传达本发明的范围。除其他之外，本发明可以体现为方法、系统、计算机可读介质、装置或设备。因此，本发明可采取完全硬件实施方案、完全软件实施方案或组合软件和硬件方面的实施方案的形式。因此，以下详细描述不应被视为是限制性的。

应当理解，不管是在科学领域，还是在社会科学研究、制造等领域当中，所有学科的分析者总是面临着有过多的数据需要识别和处理的问题。这些分析的部分是由不同的数据集生成洞察力。方案有很多，但是其中的一种是识别数据集之间的相关性。在这样的尝试当中，可以执行对存储在数据库存储器或数据库结构当中的两个或更多数据集执行联合操作。“联合”操作可以是数据库编程的部分，并且这样的操作通常包括针对如数据库服务器的面向数据库的计算机的语法和一组所需参数，以运行并生成结果。在数据集小时，所述联合操作不会用很长时间，因而结果通常是即时提供或生成的。但是，随着数据集的尺寸呈指数级增长，所述联合操作将面临重大困难。这是因为所述联合操作在生成具有联合结果的输出数据集之前需要在目标数据集中存储和搜索相关数据字段。

示例性实施方案涉及接受用户的别名和凭证而非个人账户号，以批准在线交易。在示例中，商家的结账图形用户界面可以具有嵌入于其内的在不同的时间上向支付处理器和发行方传送信息的多个微件(widget)。在高层次上，商家的结账图形用户界面可以在结账时接受发行方凭证，促进发行方对所述发行方凭证进行认证，并且响应于成功认证，处理器可以为商家提供支付令牌以作为对正在从商家购买的物品的支付。

图1示出了说明根据示例性实施方案的系统100的方框图。系统100可以包括经由一个或多个计算机网络108(例如，局域网、广域网、无线网络、有线网等和/或它们的组合)相互通信耦接以及通信耦接至至少一个用户设备110的商家服务器102、支付处理器服务器104和至少一个发行方服务器106。描绘了发行方服务器106-1-106-n，其中，n是正整数。

用户设备110可以与商家服务器102交互，以获得商家的图形用户界面，从而查看销售物品(例如，商品、服务等)并向商家购买。商家的图形用户界面(GUI)的一个示例是网页。作为商家服务器102的替代或者除了商家服务器102之外，非商家服务器102的第三方服务器可以向用户提供商家的GUI。商家可以不直接收取来自用户的支付，相反商家可以利用支付处理器和/或发行方提供的技术来收取支付。有利地，根据文中描述的实施方案，商家可以将无支付风险转移给发行方，与商家相比，发行方往往处于更高的对风险进行评估的地位上。

为了提供这一风险转移优势，商家可以将微件集成到商家的GUI内。在一个示例中，支付处理器微件可以控制用户体验，并且可以促进与发行方的认证微件的交互，以检验用户提供的凭证是否能够用于成功地对用户进行认证。

在一些示例中，用户可以预先在支付处理器结账程序内进行注册，从而将用户在发行方那里建立的账户与在支付处理器处建立的结账账户关联起来。发行方可以是联合特定支付处理器(例如，VISA)向用户发行信用卡或借记卡的银行。商家可以在支付处理器的结账程序当中进行注册，使得顾客在进行在线购买时能够简单地输入别名和凭证而非个人账户号(例如，信用卡号)。对于顾客而言，与记住个人账户号相比，记住别名和凭证(例如，用户名和口令)通常更简单一些，从而使顾客更易于进行在线购买，而且使顾客更有可能实际完成购买。

用户可以向发行方确立允许该用户获得对发行方账户的在线访问的别名和凭证。例如，发行方可以提供在线银行业务平台，并且用户可以输入用于认证的别名和凭证(例如，口令)，以访问发行方账户和/或使用发行方账户实施交易。用户可以选择别名和凭证，或者发行方可以分配别名和凭证。如果用户具有向不同发行方开具的账户，那么用户可以使用相同的户名和凭证对，或者可以针对每一发行方分配特有的别名和凭证。别名可以是用于识别用户的信息。别名的示例可以包括用户名、电子邮件地址、电话号码和设备标识符(例如，计算机、膝上型电脑、智能电话、平板电脑等的标识符)等。凭证可以是用于在使用发行方账户实施交易之前用于对用户进行认证的信息。凭证的示例是口令和生物测定信息(例如，拇指指纹)等。用户在希望使用发行方账户实施交易，例如，在在线银行业务平台当中访问该用户的账户时，可以提供户名和凭证。

发行方服务器106和支付处理器服务器104可以通过交换oAuth式令牌而将发行方账户与结账账户联系起来，使得用户为了在线访问发行方账户而建立的别名/凭证组合同样还可以在通过所述结账账户向商家实施购买时使用。有利地，用户在实施在线购买时向商家的GUI提供相同的别名/凭证组合而非个人账户号(例如，信用卡号、借记卡号等)。

在预注册之后，用户可以在希望购买物品时访问参与了所述结账程序的商家的图形用户界面。在一个示例中，用户可以选择一个或多个物品，并将其添加到虚拟购物车内。在用户希望进行购买时，用户可以在商家GUI上选择结账图标。响应于所述选择，商家服务器102可以在用户设备110的显示屏上呈现商家结账GUI。在一个示例中，商家GUI可以列举正在被购买的一个或多个物品、每一物品的费用和总费用等。商家结账GUI还可以包括一个或多个微件。微件可以是从商家服务器102下载并存储在用户设备110的存储器内的计算机代码。所述计算机代码在受到执行时可以使用户设备110访问另一计算机、设备或服务，以处理接收到的用户输入。例如，微件可以是用于将另一文档嵌入到HTML文档当中的内联框架(iframe)的计算机代码。

在一个示例中，所述微件中的第一微件可以是与支付处理器相关联的支付处理器微件或者结账微件(下文统称为结账微件)。在顾客抵达商家GUI时或者在任何其他时间上，结账微件可以识别用户的别名(例如，基于cookie、设备/浏览器指纹等)或者顾客可以向商家GUI提供其别名(例如，用户名、电子邮件、移动电话号码等)。结账微件可以使用户设备110将所述别名发送给支付处理器服务器104，以确定用户具有关于一个或多个发行方的什么账户。一旦做出确定，结账微件就可以使商家结账GUI显示对应于用户所具有的关于一个或多个发行方的账户的一个或多个可选择图形。每一可选择图形可以是具有卡片艺术的带有品牌的结账按钮。例如，用户可以具有美国银行发行的Visa物理信用卡，所述信用卡带有描绘大海和沙滩的背景图案，因而所述带有品牌的结账按钮可以包括描绘同样的大海和沙滩的信用卡形状的图像。

为了确定用户向哪些发行方开具了账户，结账微件可以将用户标识信息，例如，基于设备的信息和/或基于别名的信息传送给支付处理器服务器104，以查找用户的发行方附属情况。基于设备的信息的示例包括浏览器cookie、设备指纹、广告商标识符(例如，Android)和平台合作关系(例如，MSFT、Mozilla、WC3)等。基于别名的信息的示例包括用户电子邮件地址和/或电话号码、用户输入的电子邮件地址以及用户输入的移动用户名等的散列。

支付处理器服务器104可以对用户标识信息，例如，基于设备的信息和/或基于别名的信息进行处理，以确定用户具有关于一个或多个不同发行方的账户。支付处理器服务器104可以为针对该用户的对应账户检索带有品牌的结账按钮和关联卡片艺术，并发送至结账微件。所述结账微件可以更新商家结账GUI，以显示每一发行方的带有品牌的结账按钮。用户可以从带有品牌的结账按钮中选择其想要针对其进行认证的一个按钮。在图2A中，例如，商家结账GUI 112可以显示结账微件202、针对与发行方服务器106-1相关联的发行方“MyBank”的第一品牌化结账按钮204A以及针对与发行方服务器106-n相关联的发行方“2dBank”的第二品牌化结账按钮204B。用户可以在第一或第二品牌化结账按钮之间进行选择，以指示用户希望用哪一账户做出支付。例如，用户可以在用户设备110的触摸屏上使其手指在预期品牌化结账按钮的顶上从左到右扫动，以选择使用哪一发行方账户。也可以采用其他用户选择方式。在所描绘的示例中，用户可以将其手指置于MyBank卡图像204A之上，并使其手指在短语“支付处理器结账”顶上从左到右滑动。

响应于用户选择，结账微件202可以更新商家结账GUI 112，以显示或者触发对应于所选择的发行方账户的第二微件，以收取来自用户的凭证。第二微件可以被称为认证微件206，并且可以与所选择的发行方账户的发行方服务器106-1交互。例如，发行方服务器106-1可以在作为javascript的用户界面软件开发工具包的结账微件202内托管口令字段。认证微件206可以提示用户输入针对该发行方账户的凭证，并将输入的凭证传送至发行方服务器106-n，以供认证。在一个示例中，认证微件206被配置为接收来自所显示的文本输入字段的输入，并且结账微件202可以控制商家结账GUI的其余部分的出现。结账微件202可以将所述商家结账GUI112的部分渲染为具有用于认证微件206的标准化尺寸和品牌化规格(branding specification)，以填充口令字段。结账微件202还可以将别名和元数据(例如，数额、商家类别、商家标识符等)传送给发行方。

图2B描绘了包括结账微件202和认证微件206的商家结账GUI 112的示例。在所描绘的示例中，认证微件206是“MyBank口令微件，”其提示用户输入与用户向发行方“MyBank”开具的MyBank账户相关联的口令。为了对用户做出有关所述发行方账户的提醒，结账微件202可以更新商家结账GUI 112，使之包括所选择的发行方发给用户的物理信用卡的卡片艺术208以及该用户的别名的至少部分。在所描绘的示例中，结账微件202更新商家结账GUI 112，以呈现用户的“MyBank卡”的卡片艺术。商家结账GUI 112可以提示用户输入与MyBank账户相关联的口令。在示例中，结账微件202可以使商家结账GUI 112显示与发行方账户相关联的用户别名的至少部分，以辅助用户。此外，结账微件202可以更新商家结账GUI 112，从而允许用户在其希望使用备选账户实施支付时选择不同的卡。

响应于用户输入凭证(例如，并且敲击“Go”按钮210)，认证微件206可以使用户设备110将所述凭证转发至特定发行方服务器106。在这一示例中，所述凭证被转发至MyBank发行方服务器106-1。认证微件206还可以将语境信息转发给特定发行方服务器106，以评估用户不是善意账户持有者的风险。所传达的信息的类型可以基于预期的认证水平而变化。认证水平取决于语境、责任渠道和风险，可以取决于用户提供认证的渠道(例如，口令、一次性口令、拇指指纹等)，并且可以取决于录入用户提供的信息的域或窗口。在一些示例中，认证方法可以具有渠道(例如，web vs.短消息服务vs.移动app)相关性。此外，消费者偏好、局域网规则或者商家偏好也可以是认证因素。在示例中，语境信息可以包括用户设备110的电话号码、用户设备110的当前地理位置、浏览器/设备指纹和元数据等。

发行方服务器106-1可以对接收到的凭证和/或语境信息进行处理，并尝试对用户进行认证。如果凭证不正确并且/或者如果在所述语境信息的基础上所述购买是不寻常的，那么发行方服务器106-1可以以指示用户未提供正确凭证的认证响应消息做出响应。在一些示例中，用户设备110可以通知用户所提供的凭证不正确，并为用户提供一次或多次额外的尝试，以便其提供正确凭证。

如果凭证正确并且/或者语境信息未被认为存在异常，那么发行方服务器106-1可以将具有指示成功认证的成功认证指示符的认证响应消息传达给支付处理器服务器104。使发行方而非商家对用户进行认证的优点在于将认证风险从商家转移给了发行方。在很多情况下，发行方具有更好的资源，而且其处境更有利于判断交易是否呈现异常。典型地，发行方有权访问用户的购买历史和顾客购买行为的典型地理位置等，以评估购买是否呈现异常。响应于接收到用户受到成功认证的指示，支付处理器服务器104可以将支付令牌传达给商家服务器102，以便被用作支付。之后，商家服务器102可以更新用户设备110上的商家结账GUI 112，以指示用户的购买已获批准。

在一些示例中，在用户已经被发行方认证并且特定交易已经被批准之后，支付处理器服务器104可以对未来的类似交易授权而不要求发行方再次认证该用户。在一个示例中，支付处理器服务器104可以存储用户的交易历史以及发行方服务器106先前对用户做出了认证的交易的相关语境信息，并且支付处理器服务器104可以批准将来的类似交易，而不需要发行方再次认证该用户。例如，用户可能频繁地在特定的地理位置(例如，加利福尼亚的旧金山)通过特定用户设备(例如，移动电话)从特定网站购买总额不超过$150的化妆品。只要与后续购买相关联的语境信息与至少一次先前购买的语境信息一致，支付处理器服务器104就可以批准后续购买，并生成支付令牌，而不要求发行方在批准该交易之前对用户进行认证。在这样的情形当中，结账微件202可以收集来自用户的别名/凭证，并将所述别名/凭证发送给支付处理器服务器104，以判断所述别名/凭证是否与用户先前在更早的交易当中提供的别名/凭证匹配。如果匹配，那么支付处理器服务器104可以生成支付令牌并将其传达给商家服务器102，以便对交易授权并实施支付。

在另一示例中，系统100可以在用户正在结账时在支付处理器结账程序当中注册先前未注册的用户，因而不要求用户如上文所述进行预先注册。参考图3A，商家服务器102可以提供商家结账GUI 112，以供经由用户设备110呈现给用户。如上文所述，商家结账GUI 112可以包括结账微件202。在结账期间，结账微件202可以提示用户输入个人账户号(PAN)(例如，信用卡号)以便用于支付，并且可以使用户设备110将所述个人账户号转发给支付处理器服务器104。支付处理器服务器104可以对所述账户号进行处理，以判断(1)发行方是谁，(2)发行方是否提供在线认证，以及(3)用户是否具有关于所述发行方的有效别名和凭证(例如，是否已经设定了在线银行业务用户名和口令)。如果全都是“是，”那么支付处理器服务器104可以判断用户是否有资格向所述结账程序进行注册，并因而可以使用有效别名和凭证来进行在线购买，而不是必须提供个人账户号。在示例中，为了做出这些判断，支付处理器服务器104可以(1)对存储在数据库中的高速缓存的批量表格进行搜索以取得所述账户号，(2)执行对发行方的实施呼叫，和/或(3)判断所述个人账户号在发行方投放的cookie当中是否可得。

如果发行方提供了在线用户认证并且用户具有有效的别名和凭证，那么支付处理器服务器104可以将结账合格消息发送给发行方服务器106。作为响应，发行方服务器106可以将认证微件206传达给用户设备110。在一些示例中，认证微件206可以包括别名(例如，用户名)。认证微件206可以使商家结账GUI 112显示出所述别名的至少部分，并提示用户输入与发行方相关联的凭证。认证微件206可以将所述凭证传达给发行方服务器106，从而按照上文所述的方式对用户进行认证。如果认证成功，那么发行方服务器106可以通知支付处理器服务器104认证已成功，并且支付处理器服务器104可以生成支付令牌并将其传达给商家服务器102，如上文所述。商家服务器102可以使商家结账GUI 112通知用户支付已成功，并且已在支付处理器结账程序中注册。为了实施后续购买，结账微件202可以显示所述别名的至少部分，并且认证微件206可以与发行方服务器106交互，从而对用户进行认证。因而，用户可以不用必须记住或者输入个人账户号才能进行购买，而是可以简单地提供凭证和/或别名。在其他示例当中，支付处理器服务器104可以基于语境信息批准交易，而不需要发行方服务器106所做的单独用户认证，如上文所述。

在另一示例中，用户可以向结账程序进行注册，但是其可能尚未建立用于对发行方的在线平台(例如，在线银行业务平台)进行在线访问的别名和凭证。在注册过程中，结账微件202可以单独或者与支付处理器服务器104和/或发行方服务器106协作确定用户输入的个人账户号与发行方账户相关联，但是用户尚未建立用于访问发行方的在线平台的别名和凭证。如果尚未建立，那么结账微件202可以呈现认证微件206，以显示用于提示用户提供别名并创建凭证的字段(例如，“您似乎尚不具有MyBank口令，现在请创建一个，并且将来用它在mybank.com上结账以及对您的账户进行管理”)。认证微件206可以使用户设备110将所述别名和用户创建的凭证传送给发行方服务器106，以供存储，如图3B所示。在一些示例中，认证微件206可以直接将所述别名和用户创建凭证传送给发行方服务器106，而不传送给支付处理器服务器104，支付处理器服务器104可以既不察觉也不存储用户创建的凭证。支付处理器服务器104还可以将有关用户的额外信息(例如，家庭住址、电话号码、个人账户号以及社保号等)传送给发行方服务器106，以提供该用户的关于所述发行方的账户的简档。在示例中，发行方可以使用所述简档将该用户注册到在线平台内，并使用所述别名/凭证访问发行方的在线平台。支付处理器服务器104还可以发送与发行方同品牌的欢迎消息(例如，电子邮件)，从而告知用户如何使用针对所述结账程序创建的相同别名/凭证通过发行方的在线平台访问该用户的发行方账户。在一些示例中，用户在首次使用发行方的在线平台时可能仍然必须同意某些条款或者执行某些次要设置步骤，但是用户用于所述发行方在线平台的口令可以与用来通过所述结账程序实施购买的口令相同。

示例性实施方案可以进一步提供在结账时提醒用户向发行方的在线平台和所述结账程序进行注册的功能。在示例中，发行方可以将结账微件202(例如，javascript的软件开发工具包)嵌入到发行方的在线银行业务浏览器/app渠道当中，以俘获基于设备的识别(例如，cookie/设备指纹等)。通过浏览器或app，发行方可以呈现邀请用户现在注册或者“以后提醒我”的启动画面。例如，结账微件202可以呈现动态按钮，其利用设备识别提供带有发行方品牌的按钮，以诱使未注册用户点击。如果接收到点击，那么结账微件202可以使用户设备110呈现同品牌显示，以欢迎新用户，并提示用户输入别名/凭证并同意支付处理器的条款。一旦同意，结账微件202就可以通过跨渠道连接卡应用编程接口供应结账账户。这一示例性实施方案可以提供很多好处，包括识别在发行方的在线银行业务平台中注册过的客户，为用户提供具有发行方品牌的动态按钮以诱使其点击以及做出新注册，以及与其他系统相比有助于有机地获取用户。

图4示出了根据示例性实施方案的方法的流程图。所述流程图可以由系统、计算机、服务器或设备实施。流程图中所示的每个框可以重复一次或多次，可以修改一个或多个框，并且可以省略一个或多个框。该方法可以作为计算机可执行指令存储在非暂时性计算机可读介质上。计算机可执行指令在由至少一个处理器执行时可以致使至少一个计算机或其他设备执行作为方法步骤的框一次或多次。所述流程图可以是开始于块402。

在块402中，所述方法可以包括呈现与支付处理器微件相关联的商家结账图形用户界面。在一个示例中，支付处理器服务器104可以定义具有一个或多个用于与用户的交互的图形用户界面单元的结账微件。

在块404中，所述方法可以包括通过支付处理器微件确定与用户相关联的关于多个发行方的多个账户，其中，每一账户具有用户向其发行方设定的别名和凭证。

在块406中，所述方法可以包括通过商家结账图形用户界面呈现至少一个可选择图形，所述至少一个可选择图形被配置为接收对所述可选择图形的选择，其中，所述至少一个可选择图形与所述多个发行方中的一个特定发行方相关联，并且包括具有该特定发行方的品牌表示的图像。

在块408中，所述方法可以包括响应于接收到对所述可选择图形的选择而在结账图形用户界面内呈现用于接收来自所述用户的与所述特定发行方的认证微件相关联的凭证的字段。

在块410中，所述方法可以包括由所述认证微件将所述凭证传达给特定发行方，以供对用户进行认证。

在块412中，所述方法可以包括响应于接收到来自特定发行方的成功认证指示符而显示表明交易已被批准的消息。

图4的方法可以结束，重复一次或多次，或者可以返回至前述块中的任何块。

有利地，所述示例性实施方案可以提供很多好处。所述示例性实施方案可以安全地保护用户PAI和个人可识别信息(PII)，可以不要求用户为结账程序和发行方在线平台的每者建立单独口令，可以减少语境切换和用户体验摩擦，可以具有灵活性，并且可以支持对不同使用情况的分层认证选项。

此外，所述示例性实施方案可以限制用户必须提供凭证的次数。例如，只有对仅出现一次的(one-off)交易才需要凭证，例如，与新商家或商家app的首次交易，或者只有在请求将责任从商家转移给发行方(或者从支付处理器转移给发行方)时才需要凭证。

在一些使用情况下，示例性实施方案可以提供基于风险的认证，并且允许在商家的结账GUI中进行一触式结账，其借助了责任转移而不要求用户输入凭证。所述示例性实施方案还可以支持卡存档商家使用案例(采取商家责任)。

但是，所述示例性实施方案可以为技术难题提供技术解决方案。在尝试实施在线购买时，现有系统不能协调支付处理器和发行方，因而给客户带来了不必要摩擦，从而减少了商家的销售。所述示例性实施方案通过将支付处理器的结账账户与用户向发行方的在线平台确立的发行方账户关联起来而提供了针对这些技术难题的技术解决方案。这样做允许用户使用相同的别名和凭证向商家实施购买以及访问发行方的在线平台。

图1中的计算机和服务器可以是通用计算机，其尤其可以具有微处理器(例如，来自Intel Corporation、AMD或Motorola)；易失性和非易失性存储器；一个或多个大容量存储设备(即，硬盘驱动器)；各种用户输入设备，诸如鼠标、键盘或传声器；以及视频显示系统。图1中的计算机和服务器可以在许多操作系统中的任何一个上运行，其包括但不限于WINDOWS、UNIX、LINUX、MAC OS或Windows(XP、VISTA等)。然而可以考虑，任何合适的操作系统均可以用于本发明。图1中的计算机和服务器可以是Web服务器集群，这些Web服务器可以各自基于LINUX并由负载均衡器支持，该负载均衡器基于可用服务器的当前请求负载来决定Web服务器群集中的哪个Web服务器应当处理请求。

图1中的计算机和服务器被示为由线互连。所述线可以代表网络，包括因特网、WAN、LAN、Wi-Fi、其他计算机网络(现在已知的或未来发明的)和/或前述各项的任意组合。本领域的普通技术人员在熟悉本说明书、附图和权利要求书后应理解，网络可以通过有线和无线渠道的任何组合来连接各种部件，包括铜线、光纤、微波以及其他形式的射频通信技术、电通信技术和/或光学通信技术。还应当理解，任何网络可以以不同的方式连接到任何其他网络。系统100中计算机和服务器之间的互连是示例。图1中所描绘的任何设备都可以经由一个或多个网络与任何其他设备通信。

系统100可以包括超出所示的那些设备和网络的附加设备和网络。此外，描述为由一个设备执行的功能可以由两个或更多个设备分布和执行。也可以将图1中所示出的多个设备结合成单个设备，该单个设备可以执行所合并的各个设备的功能。

本文所描述的各种参与者和元件可以操作一个或多个计算机装置以利于本文所述的功能。上述附图中的任何元件，包括任何服务器、用户终端或数据库，可以使用任何适当数量的子系统来促进本文所描述的功能。

本申请中描述的任何软件组件或功能可以实现为可以由至少一个处理器使用任何适当计算机语言(诸如，例如Java、C++或Perl)、使用例如传统的或面向对象的技术执行的软件代码或计算机可读指令。

软件代码可以存储为非暂态计算机可读介质(诸如随机存取存储器(RAM)、只读存储器(ROM)、磁介质(诸如硬盘或软盘)或光介质(诸如CD-ROM))上的一系列指令或命令。任何这种计算机可读介质还可以驻存在单个运算装置上或驻存在单个运算装置内，并且可以位于系统或网络中的不同运算装置或在系统或网络中的不同运算装置上。

应当理解，如上文描述的本发明可以使用计算机软件以控制逻辑的形式以模块化或集成方式来实施。基于本文中提供的公开和教导，本领域的普通技术人员可以明白并认识到使用硬件、软件、或硬件和软件的组合实现本发明的其他方式和/或方法。

以上描述是示意性的不是限制性的。在本领域技术人员阅读了本公开之后，本发明的许多变体对于他们会变得显而易见。因此，本发明的范围不应该参考上面的描述来确定，而是应该参考待决的权利要求及其完整范围或等同物来确定。

在不偏离本发明的范围下，任何实施方案的一个或多个特征可以与任何其他实施方案的一个或多个特征组合。除非明确指示有相反的意思，否则“一个”、“一种”或“该/所述”的叙述旨在表示“一个/种或多个/种。”“和/或”的叙述旨在表示术语的最具包容性的意义，除非有相反的特别指示。

本系统的一个或多个元件可被要求作为完成特定功能的手段。在使用此类手段加功能元件来描述所要求的系统的某些元件的情况下，具有本说明书、附图和权利要求书在他们眼前的本领域的普通技术人员应当理解，相应结构是通用计算机、处理器或微处理器(视情况而定)，其被编程为使用在没有特殊编程的任何通用计算机中存在的功能来执行特别叙述的功能和/或通过实现一种或多种算法来实现所述功能。如本领域的普通技术人员将理解的，算法可以在本公开中表达为数学公式、流程图、叙述式和/或向本领域的普通技术人员提供足够的结构以实现所述过程及其等同物的任何其他方式。

虽然本公开可以以许多不同的形式体现，但是附图和讨论被提供的理解是，本公开是一个或多个发明的原理的说明，并不意图将任何一个发明限制于所示实施方案。

本公开提供了上述长期需要的解决方案。具体而言，文中描述的系统和方法可以被配置为对支付处理器和发行方进行协调，以便将账户联系起来，从而经由商家结账图形用户界面接受支付。对于本领域技术人员来说，上述系统和方法的其他优点和修改将是容易发生的。因此，本公开在其更广泛的方面不限于具体细节、代表性系统和方法以及上述示出和描述的说明性示例。在不脱离本公开的范围或精神的情况下，可以对上述说明书进行各种修改和变化，并且本公开旨在涵盖所有此类修改和变化，前提条件是它们在所附权利要求书及其等同物的范围内。