CN107251071A - 使用消息传送系统发送和接收支付 - Google Patents

Abstract

本公开涉及提供交易支付系统的系统、方法和装置。具体地，交易支付系统允许消息传送系统的用户将电子支付发送至消息传送系统的其他用户以及接收来自消息传送系统的其他用户的电子支付。在客户端装置上的消息传送应用可以从用于对接收者进行支付的发送者接收支付信息输入(诸如，支付金额和支付方法)。消息传送应用可以向消息传送系统发送包括支付信息的支付消息，并且该消息传送传送系统基于该支付信息协调支付过程。在支付过程期间，消息传送系统可以经由被包含在对应于发送者和接收者的消息线程中的状态消息向支付的发送者和接收者提供状态更新。

Description

使用消息传送系统发送和接收支付

技术领域

一个或多个实施例总体涉及用于提供电子通信系统的系统和方法。更具体地，一个或多个实施例涉及提供在用户之间并入各种形式的电子通信的消息传送系统的系统和方法。

背景技术

由于电子通信的进步，大多数人使用各种形式的电子通信来与其他人通信。此外，移动装置(例如，智能电话、平板电脑)已经日益普及，并允许人们从几乎任何地方发送和接收电子通信。电子通信的普及与移动装置使用量的增加相结合，已产生电子通信技术的额外用途。

例如，电子通信技术的一个这种额外用途包括向用户提供彼此发送和接收电子支付的能力的支付应用。在理论上，在移动装置上使用支付应用进行电子转账的概念提供了在用户之间转账的便利方法。然而，传统的支付应用程序有几个缺点，其往往引起沮丧、混乱，并产生往往比其所值更耗时的支付流程。

许多传统支付应用需要使用连接到另一计算装置(诸如移动装置)的读卡器。使用读卡器的传统支付应用有几个缺点。例如，除了移动装置之外，用户必须携带并且始终具有读卡器以便接收支付。此外，移动装置与读卡器之间的连接和读卡器往往容易发生故障。由于犯罪分子使用读卡器窃取敏感信用卡信息的能力，读卡器也缺乏公信力。此外，需要读卡器的支付应用通常不适合处理远程支付。

其他传统支付应用不使用读卡器，而是单独的支付服务，其中，支付的发送者和接收者都必须专门为该支付服务创建账户。由于传统支付应用在发送和接收支付之外没有其他用途的这一事实，通常情况下，两个人不需要转移没有相同支付服务的账户的支付。因此，对于许多传统支付应用，发送者、接收者或两者都必须经历耗时的建立账户的过程，从而导致支付过程不方便和繁琐。

除了单纯地建立与特定支付应用相关的账户之外，许多传统支付应用使用的支付过程繁琐且复杂。例如，许多传统支付应用通过发送具有链接的一系列电子邮件来处理支付。用户必须点击电子邮件链接以继续支付过程，诸如接受或拒绝支付。因此，支付处理步骤不直观，并且往往引起用户混淆。此外，处理步骤是耗时的，并且在支付过程中引起用户沮丧。

因此，在用户之间发送支付的传统系统和方法存在许多缺点。

发明内容

本文所述的一个或多个实施例利用在用户之间电子发送和接收支付的系统和方法提供了益处和/或解决了本领域中的一个或多个前述或其他问题。具体地，该系统和方法提供与消息传送系统集成的交易支付系统，其允许两个或更多个用户(至少发送者和接收者)经由消息传送系统安全地发送和接收电子支付。例如，该系统和方法可以允许用户经由用于发送传统即时消息(例如，即时消息)的消息传送接口向另一用户发送电子支付。

例如，在一个或多个实施例中，系统和方法可以向发送者用户提供包括向一个或多个接收者发送支付的可选选项的图形界面。发送者可以与可选择的选项交互以访问允许用户输入支付信息并发起支付的一个或多个图形元素。在用户发起支付时，该系统和方法可以使用从用户接收到的支付信息来协调支付过程。支付过程最终可以促成用户和接收者之间的支付。

在一个或多个实施例中，该系统和方法另外在对应于发送者和接收者之间的通信会话的消息传送线程中提供状态消息。状态消息允许发送者和接收者监控支付过程的状态。此外，状态消息可以包括提供关于支付的可选选项的交互元素，诸如允许接收者接受或拒绝支付的选项。因此，本文所述的系统和方法为用户提供了通过方便地使用消息传送用户已经熟悉的消息传送应用来发送和接收支付的能力。

实施例的附加特征和优点将在下面的说明书中阐述，并且部分在说明书中是显而易见的，或可通过实施此些示例性实施例来获悉。此些实施例的特征和优点可借助于在所附权利要求书中特别指出的器具和组合来实现和获得。这些和其他特征应从下面的说明书和所附权利要求中变得更清晰可见，或可通过实施在下文中阐述的这些示例性实施例来获悉。

根据本发明的实施例特别在涉及方法、存储介质、系统和计算机程序产品的所附权利要求中公开，其中，在一项类别的权利要求例如方法中提及的任何特征也可以另一类别的权利要求例如系统中要求保护。在所附的权利要求中的相关性或返回引用仅出于形式上的原因来选择。然而，从对任何在前权利要求的有意返回引用所得的任何主题(特别是多个相关性)也可以被要求保护，以便权利要求及其特征的任何组合被公开并可以要求保护而与在所附权利要求中选择的相关性无关。要求保护的主题不仅包括在附属权利要求中阐述的特征的组合，而且包括在权利要求中的特征的任何其他组合，其中，在权利要求中提及的每个特征可以与权利要求中的任何其他特征或其他特征的组合来组合。此外，本文描述或描绘的任一实施例和特征可以在单独的权利要求中和/或在与本文所述或描绘的任何实施例或特征或与附属权利要求的任一特征的任何组合中要求保护。

在根据本发明的实施例中，一种方法，包括：在具有至少一个处理器的服务器装置接收来自与发送者相关的第一客户端装置的支付消息，该支付消息定义从发送者到接收者的支付；由该服务器装置向与该接收者相关的第二客户端装置提供用于在第二客户端装置上的消息线程内显示的接收者状态消息，该接收者状态消息包括与该支付相对应的接收者交易信息；由该服务器装置向第一客户端装置提供用于在第一客户端装置上的消息线程内显示的发送者状态消息，该发送者状态消息包括与该支付相对应的发送者交易信息；使用该服务器装置的至少一个处理器识别处理从发送者到接收者的支付的交易状态；并且基于识别该交易的状态，向第二客户端装置发送更新该接收者状态消息内的接收者交易信息的状态更新。

在根据本发明的实施例中，该方法可进一步包括：基于交易状态的识别，向第一客户端装置提供更新发送者状态消息内的发送者交易信息的状态更新。

在根据本发明的实施例中，该方法可进一步包括：识别支付消息内的定义从发送者到接收者的支付的支付信息，该支付信息包括发送者标识符、接收者标识符和支付金额。

在根据本发明的实施例中，该方法可进一步包括：在服务器装置并利用至少一个处理器，生成交易标识符；将交易标识符与所识别的支付信息相关；以及在发送者状态消息和接收者状态消息内提供交易标识符。

在根据本发明的实施例中，该方法可进一步包括：发起处理从发送者到接收者的支付的交易，其中，发起交易包括从服务器装置向支付网络发送支付授权请求。

在根据本发明的实施例中，该方法可进一步包括：将支付授权请求与交易标识符相关；并且其中，识别处理从发送者到接收者的支付的交易状态包括基于交易标识符从支付网络检测支付授权响应。

提供给第二客户端装置的状态更新可促使第二客户端装置的消息线程内的接收者状态消息包括接受或拒绝支付的可选选项。

在根据本发明的实施例中，该方法可进一步包括：从第二客户端装置接收已经选择了可选选项以拒绝支付的接收者的指示；以及响应于接收到接收者已选择了可选选项以拒绝支付的指示来取消该交易。

在根据本发明的实施例中，该方法可进一步包括：基于取消交易，向第一客户端装置提供更新发送者状态消息内的发送者交易信息以指示接收者拒绝支付的状态更新。

在根据本发明的实施例中，该方法可进一步包括：从第二客户端装置接收接收者已选择可选选项以接受支付的指示；并向支付网络发送资金授权请求，该请求致使支付金额从发送者账户中扣除并存入接收者账户。

在根据本发明的实施例中，该方法可进一步包括：从支付网络接收指示成功完成交易的资金授权响应；并且基于接收到该资金授权响应，向第二客户端装置发送更新接收者状态消息内的接收者交易信息以指示该支付成功的完成状态更新。

在根据本发明的实施例中，该方法可进一步包括：从支付网络接收指示成功完成交易的资金授权响应；并且基于接收到该资金授权响应，向第一客户端装置发送更新发送者状态消息内的发送者交易信息以指示该支付成功的完成状态更新。

在根据本发明的另一实施例中，一种系统，包括：至少一个处理器；以及存储有指令的至少一个非暂态计算机可读存储介质，当由至少一个处理器执行时，该指令使该系统：从与发送者相关的第一客户端装置接收支付消息，该支付消息定义从发送者到接收者的支付；提供用于在第二客户端装置上的消息线程内显示的接收者状态消息，该接收者状态消息包括与支付相对应的接收者交易信息；提供用于在第一客户端装置上的消息线程内显示的发送者状态消息，该发送者状态消息包括与该支付相对应的发送者交易信息；识别处理从发送者到接收者的支付的交易状态；并且基于交易状态的识别，向第二客户端装置提供更新接收者状态消息内的接收者交易信息的状态更新。

在根据本发明的实施例中，一种系统可包括指令，当由至少一个处理器执行时，该指令使该系统经由支付网络发起交易，其中，支付网络促成从发送者账户扣除支付金额并向接收者账户存入支付金额。

提供给第二客户端装置的更新接收者状态消息内的接收者交易信息的状态更新可致使接收者状态消息包括接收者接受支付的可选选项。

提供给第二客户端装置的更新接收者状态消息内的接收者交易信息的状态更新可致使接收者状态消息包括接收者选择存入支付的一个或多个账户的可选选项。

在根据本发明的实施例中，一种系统可包括指令，当由至少一个处理器执行时，该指令使该系统：促成处理从发送者到接收者的支付的交易，其中，促成该交易包括：发送支付金额从发送者账户中扣除并存入保留在非暂态计算机可读取存储介质上的临时账户的资金请求；并发送将支付金额从临时账户中扣除并以退款的形式存入接收者信用卡账户的退款请求。

在根据本发明的另一实施例中，一种移动装置，包括：至少一个处理器；以及存储有指令的至少一个非暂态计算机可读存储介质，当由该至少一个处理器执行时，该指令使移动装置：经由该移动装置的显示器提供图形用户界面，该图形用户界面包括具有在与移动装置相关的发送者与接收者之间交换多个电子消息的消息线程，该图形用户界面进一步包括可选择的支付元素；并且经由移动装置的显示器响应于发送者与可选择的支付元件交互，提供一个或多个图形元素以允许发送者指定支付信息，该支付信息定义从发送者到接收者的支付；向消息传送系统发送包括定义从发送者到接收者支付的支付信息的支付消息；从消息传送系统接收包括与促成发送者和接收者之间的支付的交易相对应的交易信息的状态消息；并且经由移动装置的显示器来提供在图形用户界面的消息线程内的状态消息。

在根据本发明的另一实施例中，移动装置可包括指令，当由至少一个处理器执行时，该指令使得移动装置经由移动装置的显示器来提供接收者已在接收者计算装置上看到接收者状态消息的指示。

在根据本发明的另一实施例中，移动装置可包括指令，当由至少一个处理器执行时，该指令使得移动装置：从消息传送系统接收指示交易完成的状态更新；并更新状态消息中的交易信息以指示从发送者到接收者的支付完成。

在也要求保护的根据本发明的另一实施例中，一个或多个计算机可读非暂态存储介质实施软件，在该软件被执行时，可操作执行根据本发明或上述实施例中的任一者的方法。

在也要求保护的根据本发明的另一实施例中，系统包括：一个或多个处理器；以及至少一个存储器，其耦接到该处理器并且包括可由该处理器执行的指令，当执行指令时，该处理器可操作执行根据本发明或上述任何实施例的方法。

在也要求保护的根据本发明的另一实施例中，优选地包括计算机可读非暂态存储介质的计算机程序产品在数据处理系统上执行时，可操作执行根据本发明或任何上述实施例的方法。

附图说明

为了描述可获得本公开的以上所列举的及其他的优点和特征的方式，将参考在附图中示出的具体实施例给予以上简要描述的本公开的具体实施方式。应注意，出于说明目的，附图不一定按比例绘制，并且在整个附图中的类似的结构或功能的元件通常由相同的附图标号表示。在下面的附图中，本文使用带有虚线边框(例如，大破折号、小破折号、点划线、点)的带配置文件的文本和块来示出向本公开的实施例添加附加特征的可选特征或操作。然而，在本公开的某些实施方式中，此些符号不应意指这些是仅有的选项或可选择的操作，和/或具有实线边框的块是不可选的。理解这些附图仅仅描绘本公开的典型实施例，因此不应视为限制其范围，本公开将通过使用附图更加具体和详细地描述，其中：

图1示出根据一个或多个实施例的促成支付发送的示例系统的示意图；

图2示出根据一个或多个实施例的促成消息传送系统的两个用户之间的支付发送的示例系统的示意图；

图3A至3B示出根据一个或多个实施例的处理发送者和接收者之间的支付的处理流程图；

图4A至4B示出根据一个或多个实施例的用于处理发送者和接收者之间的支付的另外方式的另一处理流程图；

图5A至5H示出根据一个或多个实施例的用于处理发送者和接收者之间的支付的消息传送图形界面的示例；

图6A至6C示出根据一个或多个实施例的用于处理发送者和接收者之间的支付的消息传送图形界面的附加特征；

图7A至7C示出根据一个或多个实施例的用于处理发送者和接收者之间的支付的消息传送图形界面的附加特征；

图8示出根据一个或多个实施例的处理消息传送系统的用户之间的支付的方法的流程图；

图9示出根据一个或多个实施例的处理消息传送系统的用户之间的支付的另一方法的流程图；

图10示出根据一个或多个实施例的示例性计算装置的框图；以及

图11为根据一个或多个实施例的社交网络系统的示例网络环境。

具体实施方式

本公开的实施例提供了交易支付系统，其增加了在交易的各方之间发送和接收支付的简易性和效率。具体地，一个或多个实施例包括消息系统，用户可以通过该消息系统向和从消息系统的其他用户发送和接收支付。例如，消息系统可以通过发送和接收实时或近实时的电子消息(例如，即时消息传送平台)来向用户提供与其他用户通信的能力。除了提供通信平台之外，消息系统还可以提供支付平台，其允许用户定义要对其他用户进行的支付，并发起支付交易或以其他方式将所定义的支付发送给其他用户。

与传统支付应用相比，交易支付系统的一个或多个示例实施例可以提供许多益处和优点。例如，交易支付系统可以减少或消除发送者填写多个支付字段以请求发送给接收者的支付的需要。例如，消息系统的用户已经具有通过消息系统建立的用户账户，并因此消息系统可以大大增加用户可以彼此发送支付的简易性和速度。具体地，用户希望向其发送支付的特定其他用户也是用户可能已经在消息传送系统内建立了连接的同一特定的其他用户(例如，好友、家人、同事等)。

此外，交易支付系统的一个或多个实施例提供直观的用户体验，其允许用户容易且确信地将支付发送给彼此。例如，发送者可以从也用于发送电子消息的熟悉且直观的图形界面中向接收者发送支付。此外，交易支付系统可以提供交互式状态消息，以允许发送和接收用户与消息传送应用的消息线程内的支付过程进行交互并监控该支付过程。因此，交易支付系统的一个或多个实施例允许用户在消息传送应用的用户友好的用户环境内发起、监控和完成支付交易。

此外，本文描述的交易支付系统的示例实施例消除了对读卡器的需要，并从而最小化危及敏感信用卡或借记卡信息的威胁。另外，交易支付系统的一个或多个实施例可以在处理支付(例如，存储在服务器装置而不是客户端装置上)时智能地和动态地使用集中维护的支付方法信息。因此，由交易支付系统提供的增加的安全性和可靠性因此可以基于客户端装置不需要维护或发送用户的敏感信息来处理支付的这一事实来增加用户信心。

另外，交易支付系统的一个或多个实施例可允许用户发送和接收支付，而无需使用单独的或独立的应用。以此方式，系统的用户不需要购买、下载和/或学习用于发送和接收支付的另一应用。结果是通过交易支付系统更大更快地发送支付，这继而创建了可用于使用单个平台发送和接收支付的大型用户网络。

如本文所使用，术语“消息”或“多个消息”是指两个或更多个计算装置之间的任何形式的电子通信。在一个或多个实施例中，消息为经由即时消息通信系统传送的即时消息。然而，在替代实施例中，消息可以指任何形式的电子通信，诸如SMS消息、电子邮件或社交网络帖子或评论。

此外，术语“支付消息”是指指示允许用户向一个或多个其他用户发送支付的支付信息的消息。例如，支付消息可以包括具有支付金额、发送者、接收者、支付方法以及附加信息的数据包。此外，如本文所使用的术语“支付”是指从一个或多个发送者用户到一个或多个接收者用户的货币转账。例如，支付可以表示货币礼物、债务支付、贷款融资，考虑购买商品和/或服务的支付或任何其他类型的货币转账。此外，可以以一种或多种货币进行支付，并且基于例如至一种或多种其他货币的汇率进行转换。

本文使用的术语“账户”是指现金流资产可转入和转出的金融账户。例如，账户可指用户的银行账户、借记卡账户、现金卡、信用卡账户、在线账户(例如，消息传送账户)、礼品卡账户或可以从中扣除钱的以及可以贷记/存入钱的任何其他账户。鉴于下面的公开内容，上述术语的含义以及附加术语将变得更加明显。

图1示出了根据一个或多个实施例的示例支付交易系统100(以下称为“系统100”)的示意图。如图1所示，用户102a、用户102b以及多达任意数量的用户102n(统称为“用户102”)可以使用系统100。此外，系统100可以包括相应数量的客户端装置104a、104b以及多达任意数量的客户端装置104n(统称为“客户端装置104”)。如图1进一步所示，客户端装置104可以经由网络105与一个或多个服务器装置110(或简称为“服务器装置110”)进行通信。此外，系统100可以包括与网络105通信耦接的支付网络115。尽管图1示出了计算装置104、网络105、服务器装置110和支付网络115的特定布置，但是各种附加布置是可能的。例如，计算装置104可绕过网络105与服务器装置110直接通信。

如上所简述的，图1示出了用户102a和用户102b可以分别使用客户端装置104a和104b经由服务器装置110彼此进行通信。例如，用户102a和用户102b可以交换包括文本、数字内容(例如，音频、图像、视频)、位置信息和其他形式的信息的电子消息。例如，用户102a可以在客户端装置104a上撰写针对用户102b的消息。在撰写消息之后，用户102a可以使客户端装置104a经由网络105将针对用户102b的消息发送至服务器装置110。服务器装置110可以将用户102b识别为预期接收者，并将消息转发至与用户102b相关的客户端装置104b。

除了允许用户102交换消息之外，系统100可以允许用户102彼此发送和接收支付。如下面将详细讨论的，系统100允许用户102发送包括支付信息的支付消息以促成对另一用户的支付。例如，用户102a可以经由服务器装置110向用户102b发送支付。类似地，用户102b可以经由服务器装置110接收支付的通知以及接受或拒绝该支付。如将在下面更详细地解释的，服务器装置110可以与支付网络115进行通信，以协调处理(例如，从发送者账户提取钱并将钱存入接收者账户)支付的交易。

尽管系统100可以促成两个用户102a和102b之间的支付，但是系统100也可以促成多于两个用户之间的支付。例如，用户102a可以支付发送到用户102b至用户102n(其包括任何数量的附加用户)。在一个或多个实施例中，用户102a可以通过定义和发送寻址到多个用户的单个支付消息来在相同的支付交易中向多个用户102发送支付，如将在下面进一步详细讨论的。此外，在一个或多个实施例中，一组用户可以通过系统100向或从其他组或单个用户发送或接收支付。

尽管图1将用户102示为人类用户，但是用户102可包括工商企业、政府机构或其他类型的实体。例如，用户102a可以使用系统100向工商企业提供对于服务或产品的支付。例如，用户102a可以经由服务器装置110向与工商企业相关的客户端装置发送消息来与该工商企业通信。用户102a最终可以决定从工商企业购买商品或服务。用户102b然后可以经由服务器装置110向工商企业发送商品或服务的支付。同样，工商企业可以向其他工商企业或个体发送支付。

如上所述，并且如图1所示，用户102a和102b可以分别与客户端装置104a和104b交互，以经由服务器装置110彼此通信。客户端装置104的示例包括但不限于移动装置(例如，智能电话、平板电脑)、笔记本电脑、台式机或任何其他类型的计算装置。关于客户端装置104的示例实施例的附加信息参见图10。此外并如上所述，客户端装置104可以经由网络105发送和接收电子通信。在一个或多个实施例中，网络105包括因特网或万维网。如下面参考图11进一步描述的，网络105也可以包括使用各种通信技术和协议的一个或多个专用和/或公共网络。

除了促成与用户102相关的客户端装置104之间的消息交换之外，服务器装置110可以协调用户102之间的支付的发送和接收。例如，用户102a可以定义支付并经由服务器装置110将该支付发送给用户102b。例如，用户102a可以向客户端装置104a提供输入以定义支付方法(例如，发送者用户102a的账户)、支付金额、货币、支付描述和/或各种其他支付细节。

例如，从用户102a的角度来看，发送者用户102a可以定义支付并且以类似于通过服务器装置110发送通信消息(例如，即时消息)的方式来经由服务器装置110发送支付。例如，在一个或多个实施例中，用户102a可以通过提供支付信息来定义支付。在定义支付之后，发送者用户102a可以使客户端装置104a向服务器装置110发送支付消息。在接收到支付消息之后，服务器装置110可以协调允许从发送者用户102a的账户到接收者用户102b的账户进行支付的交易。

在一个或多个实施例中，服务器装置110可以经由支付网络来协调发送者用户102a的一个或多个账户与接收者用户102b的一个或多个账户之间的交易。例如，响应于接收到来自发送者用户102a的支付消息，服务器装置110可以传送支付信息以使用支付网络115内的一个或多个组件促成支付。替换地或附加地，服务器装置110可以在服务器装置110内维护一个或多个用户102账户，并因此，服务器装置110可以对于服务器装置110内维护的账户在服务器装置110上直接协调交易或交易的一部分。

如图1所示，支付网络115可以包括支付网关系统118、支付处理系统120、卡网络系统122和发卡银行系统124。然而，在替代实施例中，支付网络115可以包括更多或更少的组件，这取决于系统100的特定实施例。一个或多个计算装置可以执行和/或实施支付网络115的组件。

例如，在一个或多个实施例中，服务器装置110可以与支付网络115通信以授权和处理交易。例如，服务器装置110可以向支付网关系统118发送交易，如图1所示。一旦支付网关系统118接收到交易，支付网关系统118就可以将交易发送给接收者用户102的收单银行使用的处理器(例如，支付处理系统120)。基于支付方法(例如，发送者用户102的账户)，支付处理系统120可以将交易发送至适当的卡网络系统122。在许多情况下，卡网络系统122然后将交易发送至发卡银行系统124。

发卡银行系统124批准或者拒绝交易，并且将决定发回卡网络系统122。然后卡网络122将该决定发送至支付处理系统120。然后支付处理系统120可以将该决定转发至支付网关系统118，并且在一个或多个实施例中，支付网关系统118可以保持与交易和决定相关的细节。支付处理系统120还将决定发送至服务器装置110。

除了授权交易之外，支付网络115也可以执行结算任务。例如，服务器装置110可以与支付网关系统118协调，以经由收单银行的首选支付处理系统120将包括一个或多个捕获的交易的日常结算批次提交给收单银行。然后，支付处理系统120将结算批次发送至收单银行(未示出)的服务器，其将结算批次中的每个交易的存款记录到与支付接收者用户相关的账户。

然后收单银行可以向支付处理系统120发送满足存款金额的资金请求，支付处理系统120将该资金请求传送至适当的卡网络系统122。然后卡网络系统122将资金请求发送至发卡银行系统124。发卡银行系统124可以将交易发布给发送者用户的账户，并将资金的发放传送至卡网络系统122，然后卡网络系统122将资金的发放传送至支付处理系统120并然后传送给收单银行。下面描述与系统100的具体系统、方法、部件和处理相关的附加细节。

图2示出了根据本文所述的一个或多个实施例的支付交易系统200(以下称为“系统200”)的示例实施例的示意图。例如，系统200可以表示上面关于图1所讨论的系统100的一个或多个实施例，并且因此，系统200可以包括如上面关于系统100所讨论的一个或多个组件、功能和/或特性。如图2所示，在一个或多个实施例中，系统200可以包括发送者客户端装置204a、接收者客户端装置204b、一个或多个服务器装置206(或简称为“服务器装置206”)以及支付网络215。一般来说，系统200可以允许发送者客户端装置204a的用户经由服务器装置206向接收者客户端装置204b的用户发送支付。

如图2进一步所示，在一个或多个实施例中，服务器装置206可以提供网络系统208。例如，网络系统208可以为提供在两个或更多个用户之间的全部或部分通信能力的一个或多个服务中的任一者。例如，在一个或多个实施例中，网络系统208为社交网络系统(例如，Facebook(TM))。替换地，网络系统208可以为另一类型的通信系统、通信网络、通信服务或使用用户账户的任何其他类型的系统。

如图2进一步所示，在网络系统208为社交网络系统的情况下，网络系统208可包括用于表示和分析多个用户和概念的社交图谱270。如图2所示，社交图谱270可以包括存储包括用户节点、概念节点和项目节点的信息的节点信息272。此外，社交图谱270可以包括具有在社交网络系统内发生的节点和/或动作之间的关系的边信息274。在下面相对于图11呈现了有关社交网络系统、社交图谱、边以及节点的进一步细节。

如图2所示，网络系统208可以进一步包括消息系统210。例如，消息系统210可以经由服务器装置206管理、协调和促成用户之间的消息的发送和接收。此外，消息系统210可以经由服务器装置206管理、协调和促成用户之间的支付的发送和接收。在一个或多个实施例中，服务器装置206可以简单包括作为独立系统的消息系统210(例如，消息系统210不是更广泛的网络系统的一部分)。下面将讨论消息传送系统210的附加组件和特征。

如图2所示，发送者客户端装置204a和接收者客户端装置204b各自可以包括各种组件。在一个或多个实施例中，发送者客户端装置204a和接收者客户端装置204a具有相似的组件，其单独地或组合地执行关于发送和接收消息以及发送和接收支付的一个或多个功能。尽管图2区分发送者客户端装置204a和接收者客户端装置204b的组件，但是每个客户端装置204的组件基本相同并且基于客户端装置是否与支付的发送者相关或客户端装置是否与支付的接收者相关来执行一个或多个方法、过程或功能。因此，尽管可参考发送者客户端装置204a的组件的特性，但是应当理解，接收者客户端装置204b的相应组件也包括所参考的特性，并且反之亦然。

如图2所示，发送者客户端装置204a可以包括具有用户界面管理器232a、用户输入检测器234a、消息传送处理器236a和支付消息发生器238a的消息传送应用230a。此外，发送者客户端装置204a可以包括维护消息数据242a和支付数据244a的装置存储管理器240a。发送者客户端装置204a的每个组件230a至244a可以使用任何合适的通信技术彼此通信。应认识到，尽管组件230a至244a在图2中被示为是分开的，但组件230a至244a中的任一者可组合成更少的组件，诸如组合成单个设施或模块，或分成用作具体实施例的更多组件。

组件230a至244a可以包括软件、硬件或两者。例如，组件230a至244a可以包括存储在非暂态性计算机可读存储介质上并且可由发送者客户端装置204a的至少一个处理器执行的计算机指令。当在至少一个处理器执行时，计算机可执行指令可以使发送者客户端装置204a执行本文所述的方法和过程。替换地，组件230a至244a可以包括硬件，诸如用于执行某个功能或一组功能的专用处理装置。

在一个或多个实施例中，消息传送应用程序230a可以为安装在发送者客户端装置204a上的本机应用。例如，消息传送应用230a可为在诸如智能电话或平板电脑的移动装置上安装和运行的移动应用。替换地，消息传送应用230a可为桌面应用、小程序或其他形式的本机计算机程序。

此外，消息传送应用230a可为发送者客户端装置204a远程访问的远程应用。例如，消息传送应用230a可为在发送者客户端装置204a的网页浏览器内运行的网页应用。例如，用户102a可使用安装在客户端装置104a上的本机消息传送应用来经由服务器装置110向用户102b发送支付，用户102b可利用安装在客户端装置104b上的web浏览器使用web应用来访问。

如上所述并如图2所示，消息传送应用230a可以包括用户界面管理器232a。用户界面管理器232a可以提供、管理和/或控制图形用户界面(或简称为“用户界面”)，其允许用户使用消息传送应用230a来撰写和发送消息(包括支付消息)。此外，用户界面管理器232a允许用户查看其他用户向该用户发送的消息。例如，用户界面管理器232a可以提供促成消息(诸如即时消息)撰写的用户界面。类似地，用户界面管理器232a可以提供显示从其他用户接收到的消息的用户界面。

更具体地，用户界面管理器232a可以促成(例如，通过与客户端装置204a相关的显示屏)用户界面的显示。例如，用户界面可由允许用户撰写、发送和接收消息的多个图形组件、对象和/或元素组成。更具体地，用户界面管理器232a可使得发送者客户端装置204a显示使得用户能够查看消息线程(参见图5A)的一组图形组件、对象和/或元素，其中，该消息线程包括发送至一个或多个其他用户并从其接收的多个消息。

此外，用户界面管理器232a可使得客户端装置204a显示促成用于撰写和发送消息的用户输入的一个或多个图形对象或元素。为了说明，用户界面管理器232a可提供允许用户向消息传送应用230a提供用户输入的用户界面。例如，用户界面管理器232a可以提供允许用户将一种或多种类型的内容输入到消息中的一个或多个用户界面。如本文所使用的，“内容”是指被包含为消息的一部分的任何数据或信息。例如，本文将使用术语“内容”来大体描述文本、图像、数字媒体、文件、位置信息、支付信息以及可以被包含为消息的一部分的任何其他数据。

如上所述，可以被包含在消息中的内容的一个示例为支付信息(例如，支付消息)。在一个或多个实施例中，用户界面管理器232a可以提供用户界面以允许用户容易且有效地定义和发送定义要对一个或多个其他用户进行支付的支付信息。例如，用户界面管理器232a可以提供一个或多个输入字段和/或用户可以与之交互来创建和发送支付消息的一个或多个用户可选元素。

例如，在一个或多个实施例中，用户界面管理器232a可以提供包括允许用户选择或以其他方式输入一个或多个接收者用户以接收支付的接收者输入字段的用户界面。此外，用户界面管理器232a可以提供允许发送者用户定义待发送给接收者用户的支付金额的支付输入字段。此外，用户界面管理器232a可以提供允许用户选择支付方法并提供支付授权(例如，PIN或密码)的支付方法元素和授权代码输入字段。用户界面管理器232a可以提供包括附加特征和特征的用户界面，其允许用户创建支付消息并向一个或多个用户发送该支付消息，如下面将参考图5B进一步讨论的。

用户界面管理器232a可以进一步促成在用户界面的消息线程内的一个或多个支付状态消息的呈现。例如，响应于用户定义支付并发送支付消息，消息传送系统210可以发送支付状态消息以在发送者客户端装置204a和接收者客户端装置204b两者上的用户界面中的消息线程内显示。支付状态消息可以呈现支付信息、支付状态(例如，支付过程的状态)以及提供与支付相关的一个或多个可选动作(例如，取消选项)。

除了呈现支付状态消息之外，用户界面管理器232a可以从消息传送应用230a的一个或多个组件接收指令或通信，以在支付状态消息中显示更新的支付信息、支付的更新状态和/或更新的可用动作。例如，用户界面管理器232a可以将支付的状态从“发送支付”更新为“支付完成”。

此外，用户界面管理器232a可以基于特定选项在支付过程的特定阶段是否可用来更新支付状态消息内的可用选项。例如，在一个或多个实施例中，在接收者接受支付之前，用户界面管理器232a可以使得发送者客户端装置204a在发送者状态消息内提供可选择的“取消支付”选项。然而，在接收者用户接受支付之后，用户界面管理器232a可以接收指示接收者用户接受的指令或通信，并且作为响应，用户界面管理器232a可以从发送者状态中移除“取消支付”选项信息。用户界面管理器232a可以在发送者状态消息和/或接收者状态消息内添加、移除和/或更新各种其他可选择的选项，如下面将参考图3A至4B进一步讨论的。

如图2进一步所示，消息传送应用230a可以包括用户输入检测器234a。在一个或多个实施例中，用户输入检测器234a可以以任何合适的方式检测、接收和/或促成用户输入。在一些示例中，用户输入检测器234a可被配置成检测关于用户界面的一个或多个用户交互。如本文所述，“用户交互”是指通过一个或多个输入装置从用户接收的单个交互或交互的组合。

例如，用户输入检测器234可检测来自键盘、鼠标、触摸板、触摸屏和/或任何其他输入装置的用户交互。在发送者客户端装置204a包括触摸屏的情况下，用户输入检测器234a可被配置成从形成用户交互的用户检测一个或多个触摸手势(例如，滑动手势、点击手势、捏合势或反向捏合手势)。在一些示例中，用户可以提供与用户界面的一个或多个图形对象或图形元素相关和/或定向的触摸手势。

用户输入检测器234可另外或替换地接收用户互动的数据表示。例如，用户输入检测器234可从用户接收一个或多个用户可配置参数、从用户接收一个或多个用户命令和/或任何其他合适的输入。此外，用户输入检测器234可从消息传送应用230a的一个或多个组件、从发送者客户端装置204a上的存储(例如，装置存储管理器240a)或从一个或多个远程位置(例如，服务器装置206)接收输入数据。

响应于用户输入检测器234a检测到用户输入和/或接收其他输入数据，消息传送应用230a可以执行一个或多个功能。一般来讲，用户可以通过提供用户输入检测器234a可以检测到的一个或多个用户输入来控制、导航和以其他方式使用消息传送应用230a。例如，响应于用户输入检测器234a检测到用户输入，消息传送应用230a的一个或多个组件允许用户选择消息的接收者、撰写消息、选择消息中所包含的内容和/或向接收者发送消息。另外，响应于用户输入检测器234a检测到用户输入，消息传送应用230a的一个或多个组件允许用户通过一个或多个用户界面导航以查看所接收到的消息、联系人等。

在一个或多个实施例中，响应于用户输入检测器234a检测到一个或多个用户输入，消息传送应用230a可以允许用户定义支付并且使得消息传送应用创建促成支付的支付消息并向一个或多个其他用户发送该支付消息。例如，需要向另一用户发送支付的用户可以与在用户界面内的菜单上提供的支付元素交互(参见图5A)。在检测到用户与支付元素的交互之后，用户输入检测器234a可以与用户界面管理器232a协调，以提供一个或多个用户界面元素，用户可以与该元素进行交互以创建支付消息。因此，响应于输入检测器234检测到一个或多个用户输入，消息传送应用230a可以允许用户创建定义待发送给另一用户的支付的定制支付消息。

如图2进一步所示，消息传送应用230a可以包括消息传送处理器236a。一般来讲，消息传送处理器236a管理消息传送应用230a的消息通信。更具体地，消息传送处理器236a可与消息应用230a的一个或多个组件进行协调，以促成消息的发送和接收。例如，消息传送处理器236a可以与用户接口管理器232a和用户输入检测器234a进行交互，以在经由消息系统210发送的消息中协调格式化和打包输入数据以及其他内容。

此外，消息传送处理器236a可以使用适当的通信协议经由一个或多个通信信道发送消息。类似地，消息传送处理器236a可以接收和处理客户端装置204a经由消息系统210从其他用户接收的消息。

除了在消息传送应用230a内提供通信功能之外，消息传送处理器236a可以提供对由消息传送应用使用的消息数据(例如，消息数据242a)的访问。例如，消息传送处理器236a可以访问表示联系人列表或者一或多组联系人的数据，以将其作为接收者包含在消息中。为了说明，消息传送处理器236a可以获得表示联系人列表的数据并向用户界面管理器232a提供该数据，以允许用户搜索和浏览联系人列表并最终选择个人联系人、多个联系人或联系人组以将其包括作为消息的接收者。在一个或多个实施例中，网络系统208(例如，社交网络系统)可以保持远程联系人列表数据(例如，“好友列表”)，并且消息传送处理器236a可以从网络系统208访问联系人列表或请求接收该联系人列表以供在消息传送应用230a内使用。

消息传送处理器236a也可以提供对消息传送应用230a可以用来撰写、发送和接收消息的其他本地或远程数据的访问。例如，消息传送处理器236a可以获得用户可以包含在消息中的文件、图像、音频、视频和其他内容的访问。此外，消息传送处理器236a可以提供对发送者客户端装置204a的一个或多个功能的访问，以向用户提供捕获或创建待包含在消息内的内容的能力。例如，消息传送处理器236a可以激活相机、麦克风或允许用户捕获待包含在消息中的内容的其他功能。

除了发送具有上述内容的消息之外，消息传送处理器236a还可以促成支付消息的发送。具体地，图2示出了消息传送应用230a可以包括可以生成支付消息的支付消息发生器238a。在一个或多个实施例中，支付消息发生器238a可以向消息传送处理器236a提供支付消息，并且消息传送处理器236a可以向消息传送系统210发送支付消息以发起从发送者到接收者的支付过程。

例如，支付消息发生器238a可以创建包括发送者输入到消息传送应用230a中的支付信息的数据包。具体地，用户界面管理器232a可以提供一个或多个用户界面以促成包含在支付消息中的各种类型的支付信息的输入和/或选择。

可以包含在支付消息中的支付消息发生器238a的一种类型的支付信息为支付的接收者。例如，如图2所示，与发送者客户端装置204a相关的发送者可以将与接收者客户端装置204b相关的接收者指定为支付的接收者。另外，在一些示例实施例中，支付消息发生器238a允许发送者指定多个接收者。例如，用户界面管理器232a可以提供用户的联系人列表，发送者可以从该联系人列表中选择一个或多个接收者。

在一个或多个实施例中，类似于指定多个个体用户的发送者，发送者可设置或定义包括多个用户和/或多个用户组的支付组。例如，正如用户可能需要同时向多个用户发送消息一样，用户也可能需要向多个用户发送支付。例如，发送者可基于特定需要来定义支付组以快速且有效的方式(例如，发送具有多个接收者的单个支付消息)来向一群人支付。与其他联系人列表一样，装置存储管理器240a可以基于例如用户输入检测器234a检测到发送者选择一个或多个支付组，来保持以供支付消息发生器238a访问的支付组定义。

消息传送应用230a可以允许用户使用一或多种技术来创建支付组。例如并如上所述，支付组可以为预定义的接收者组。替换地或附加地，发送者可以通过向消息传送会话添加多个接收者来在消息传送应用230a内即时创建支付组。例如，在发送者希望向第一接收者和第二接收者发送支付的情况下，发送者可以发起与第一接收者的消息传送会话，然后将第二接收者添加到消息传送会话中，从而在消息传送应用230a内即时创建支付组。然后，发送者可以创建支付消息，以将组支付发送给包括第一接收者和第二接收者的支付组。

以类似的方式，发送者可以在消息传送应用230a内选择预定义的支付组。然而，在创建支付消息之前，发送者可以进一步向消息传送会话添加一个或多个附加个人接收者和/或一个或多个附加支付组。在发送者将附加接收者添加到消息传送会话后，预定义的支付组将被即时修改以包括该附加接收者。在一个或多个实施例中，消息传送应用230a可以向发送者呈现保存对支付组的修改的选项(例如，支付组将继续包括附加接收者)，或替换地，消息传送应用230a可以在发送支付消息之后的时间点(例如，当发送者关闭与组支付相关的消息传送会话时)从预定义支付组移除附加用户。

在发送者标识多个接收者和/或标识支付组的情况下，发送者可以为每个个体接收者定义支付金额，以允许支付消息发生器238a将支付金额与每个个体接收者相关以将其包含在支付消息内。例如，发送者可指定特定支付组中的接收相同支付金额的每个个体接收者(例如，支付组中的每个用户从发送者接收$30.00)。具体地，用户界面管理器232a可以呈现统一的支付金额可选元素，发送者可以与该元素交互来定义跨单个支付消息中定义的多个用户的统一支付金额。

替换地，发送者可以为每个个体接收者指定不同的支付金额。例如，用户界面管理器232a可以提供包括与支付组内的每个个体接收者相对应的支付金额字段的用户界面。然后用户输入检测器234a检测发送者输入以在对应于每个个体接收者的支付金额字段内定义个性化支付金额。因此，当消息系统210处理支付消息(如将在下面进一步讨论的那样)时，包含在支付消息内的每个接收者将接收个性化的支付金额。

在一个或多个另外的实施例中，发送者也可指定组支付金额。换句话说，发送者可以指定通常分配给支付组的单个支付金额。例如，组支付金额为希望或需要向一组接收者发送支付的用户提供有效且用户友好的体验。

例如，发送者可选择包括五个接收者的支付组，然后撰写包括组支付金额为$100的支付消息并发送该支付消息。在一个或多个实施例中，发送者可以经由用户界面、用户偏好或其他设置来指定支付组内的每个接收者的支付分配比例。例如，作为用于定义支付的过程的一部分，用户界面管理器232a可以向发送者提供可选择的选项，以指定组内的所有接收者之间的相等分配比例。

具体地，参考前面段落中提供的示例，支付消息发生器238a可以将组支付$100分配为五个相等的接收者支付金额(例如，五个接收者中的每一者为$20)。此外，支付消息发生器238a可以将接收者支付金额与每个相应的接收者相关，并且生成包含在支付消息中的支付信息，以用于将支付信息传送给消息系统210的目的。

此外，代替发送者定义一组接收者的支付分配比例，支付组中的一个或多个接收者可定义支付比，以用于将组支付金额分配给组内的接收者的目的。例如，支付组可以定义适用于对该组进行的所有支付的支付分配比例。替换地，支付组可以指定基于一个或多个因素，例如发送者的身份、支付的类型、支付接收的时间段以及基于数据或系统200内的信息的各种其他因素触发的各种支付分配比例。

此外，支付消息发生器238a可以出于特定目的定制支付分配比例。在一些实施例中，支付组内的一个或多个接收者可具有零的支付分配比例。此外，支付组内的接收者可具有1的支付分配比例(例如，100％组支付被分配给唯一接收者)。在支付组中具有与零值支付分配比例相关的一个或多个接收者可以具有优点。

为了说明，工商企业可以在策略上将员工纳入支付组，并为员工分配零的支付分配比例。例如，工商企业可以创建包括商业实体以及工商企业的一个或多个员工的支付组。由于工商企业正在接收支付以换取产品(例如商品和/或服务)，所以工商企业的支付分配比例为1。另一方面，工商企业可能不希望员工获得货币支付。然而，基于员工的工作职责，员工可能需要访问与支付信息相关的支付信息和/或状态消息。因此，工商企业可以为员工分配零的支付分配比例。

为了对工商企业进行支付，客户可以选择与该工商企业相关的支付组。然后，客户可以定义支付，并且向消息系统210发送支付消息。在收到支付消息之后，消息系统210发起交易过程以将支付转移到工商企业的账户(例如，银行账户)中。另外，由于员工与支付组的关系，以及被分配了零的支付分配比例，员工可以在关于工商企业支付的客户端装置上接收支付状态消息。然而，员工在任何时候都无法访问直接向工商企业账户支付的支付资金。

发送多个接收者支付消息的另一说明性示例可以包括发送者使用发送者客户端装置204a上的消息传送应用230a向餐馆发送用于膳食的支付，并且在相同的支付消息内，向服务员发送支付(例如，小费)。例如，餐馆和服务员可以为支付组的一部分，其中，餐馆和服务员中的每者与单独的接收者客户端装置相关。

在定义支付时，发送者可以选择包括餐馆和服务员两者的支付组。此外，发送者可以定义要支付给餐馆和服务员的支付金额。例如，发送者可以定义待以餐馆帐单的金额发送至餐馆的支付金额，并且此外，发送者可以定义向服务员发送小费金额的支付金额。在一个或多个实施例中，用户界面管理器232a可以提供可选择的百分比选项，其可以基于用户选择应用于餐馆费用的支付金额的特定百分比值(例如，20％小费)来自动确定待发送给服务员的支付金额。

在发送者定义了餐馆和服务员的支付金额后，发送者可以选择发送支付消息。如上详细所述，支付消息发生器238a可以生成包括餐馆和服务员两者的支付信息的单个支付消息。然后，消息传送系统210可以处理支付消息，这最终产生存入餐馆账户的支付和存入服务员账户的支付。

除了发送者向多个接收者发送支付之外，接收者也可以从多个发送者请求支付。例如，通过使用本文关于创建支付消息的一或多种技术，接收者可以指定请求从其支付的一个或多个发送者。如在当发送者创建待向支付组发送的支付消息的情况下，接收者也可以创建从预定义的发送者组请求支付的支付消息和/或接收者可以通过向消息传送会话添加多个发送者及时创建支付组。

因此，由于支付消息发生器238a促成多个接收者支付以及个性化的支付金额这一事实，所以系统200提供了有效且用户友好的支付机制，同时系统200也提供可以执行广泛的金融交易的支付机制。

除了促成多个接收者支付之外，一个或多个实施例可以包括多个发送者支付。例如，作为定义支付的过程的一部分，发送者也可定义另一发送者来贡献支付金额。消息系统210可以执行关于其他发送者的支付验证过程，以验证实际上其他发送者希望对支付做出贡献以及允许其他发送者定义支付方法。例如，消息传送系统可以向其他发送者发送支付状态消息(在下面更详细地讨论)，其包括可选择的选项以验证参与、选择支付方法、提供授权码并提供其他信息。

在另外的发送者提供所请求的信息之后，另外的发送者可以与状态消息进行交互，以使支付消息发生器238向消息传送系统210发送另外的支付消息。然后，消息系统可以将来自第一发送者的支付信息与来自第二发送者的支付信息相结合，并相应地处理支付，使得接收者从两个发送者中的每一者接收支付。系统200的多个发送者能力提供了有效的支付机制，其允许两个发送者在组合的支付过程中向接收者支付。多发送者支付能力提供了比传统支付系统更有效和直观的支付系统，在传统支付系统中，一个发送者必须向接收者支付总支付金额，然后第二发送者将必须发起另一支付交易来向第一个发送者偿还第二发送者的部分。

除了定义发送者和/或接收者被包含在支付消息中之外，发送者还可以提供支付消息发生器238a用于生成包含在支付消息中的支付信息的另外输入。如上所简述，发送者可以选择或输入作为定义支付过程的一部分的支付方法。在一个或多个实施例中，发送者可向消息传送系统210预先注册一或多种支付方法。例如，发送者可能已经注册了银行借记卡和信用卡。支付方法的其他示例包括礼品卡、与消息系统210相关的在线账户以及允许电子转帐进出账户的其他账户。

装置存储管理器240a可以在发送者客户端装置204a上维护表示支付数据244a内的注册支付方法的数据。用户界面管理器232a可以访问表示所注册的支付方法的数据，并将所注册的支付方法呈现为用户界面内的可选选项。在一个或多个实施例中，用户必须在发送支付之前注册支付方法。在发送者尚未注册支付方法的情况下，用户界面管理器232a可以提供可选选项，以允许发送者发起注册支付方法的过程。

替换地，在一个或多个实施例中，系统可以允许发送者以支付为基础的支付(例如，不使用支付注册过程)来提供支付方法。在一个或多个实施例中，用户界面管理器232a可以提供允许用户定义支付方法的支付方法字段。例如，支付方法字段可以提示用户提供支付类型、帐号、授权代码、到期日期、帐单地址信息和定义支付方法的其他信息。

除了一或多种支付方法之外，支付消息发生器238a可以将另外的支付信息合并到支付消息中。例如，用户界面管理器232a可以允许用户选择或以其他方式定义支付货币。具体地，系统200可以允许在美国使用发送者客户端装置204a的发送者使用向在巴黎使用接收者客户端装置204b的接收者以欧元发送支付。

发送者可以定义支付的另一种方式是定义支付时间表。例如，消息传送应用230a可以允许用户向一个或多个接收者设置定期安排支付。例如，发送者可能希望一季度一次、一个月一次、一周一次或另一定期日程表向接收者发送所定义的支付金额。此外，发送者可能希望在每年的特定日期向接收者发送所定义的支付金额。例如，发送者可能希望以接收者的生日的生日礼物的形式发送支付金额。

在用户定义支付计划之后，支付消息发生器238a可以生成支付消息。然而，代替向消息传送处理器236a提供支付消息以发送至消息系统210，支付消息发生器238a可以使装置存储管理器240a维护支付消息直到预定的时间为止。在预定时间的收费之后，消息处理器236a可以自动地将预定的支付消息发送至消息传送系统210，以向接收者发起支付过程。替换地，消息传送处理器236a可以与用户界面管理器232a协调，以提供请求确认发送者希望向接收者发送预定支付金额的通知(例如，弹出窗口)。

在一个或多个实施例中，预定支付的通知作为消息线程内的消息泡来提供。例如，消息处理器236a可以使用户接口管理器232a创建包括预定支付的通知的新消息线程。消息泡也可包括一个或多个可选选项，其允许发送者确认预定的支付或取消预定的支付。在确认预定支付后，消息处理器236a将预定的支付消息发送至消息传送系统210以处理该支付。

除了定义支付计划之外，发送者可以通过提供自定义消息来进一步定义至接收者的支付。具体地，由于系统200采用消息系统210来促成用户之间的支付，所以发送者可以容易地输入对于接收者的自定义消息。具体地，并如关于图5A至7C详细所示，用户界面管理器232a将以与用户消息(例如，内容泡)相同的形式呈现支付状态消息。因此，包含在支付状态消息内的消息增加了用户体验的一致性和享受性。此外，自定义消息允许发送者向接收者解释支付，再次增加使用系统200发送和接收支付的直观性质。

一般来说，除了上述类型的支付信息之外，支付消息可以包括支付金额、一个或多个发送者标识符、一个或多个接收者标识符、一或多种支付方法、授权信息、货币信息、消息或支付描述和/或可能有助于促成从发送者至接收者的支付的任何其他数据。支付消息发生器238a可以将支付消息传送至消息传送处理器236a，以将支付消息发送至消息传送系统210。

在一个或多个实施例中，支付消息发生器238a可以使用与发送者相关的默认支付信息。例如，消息传送应用230a可以允许发送者输入并保存与预定义支付信息相关的一个或多个支付简档。支付简档可以允许发送者更容易地和有效地定义和发送支付。

在一个或多个实施例中，当使用默认支付方法或预定义的支付简档时，消息传送应用230a可以允许发送者以最小的用户交互来向接收者发送支付。例如，用户输入检测器234a可以检测到发送者对于用户界面内的支付元件提供用户交互。作为响应，用户界面管理器232a可以提供预先填充有默认支付信息(包括支付金额(例如，支付金额可基于发送给同一接收者的过去支付金额)和授权信息)的用户界面。

在发送者目视确认支付信息之后，发送者提供关于可选发送选项的用户交互，并且支付消息发生器238a生成消息处理器236a然后将其发送至消息系统210的支付消息。因此，从消息传送应用230a内，发送者可以以少至两个用户交互的方式向接收者发送支付。在一个或多个替代实施例中，发送者可以预定义包括所有必要支付信息的支付简档。在此实施例中，发送者仅需要提供在用户界面内选择支付元素的单个用户交互，以使支付消息发生器238a生成支付消息，并且消息传送处理器236a将支付消息发送至消息系统210。

在一个或多个实施例中，支付消息发生器238a可以访问支付消息内的令牌并提供该令牌。例如，在发送者提供授权密码之后，支付消息发生器可以生成令牌以包含在支付消息中，该令牌验证发送者和/或发送者客户端装置204a是被授权进行支付。例如，令牌可以包括标识信息，其指示使用相同支付方法的来自发送者的先前支付是成功的。关于发送者、发送者客户端装置204a和/或发送者的支付历史的其他标识信息可以用令牌来指示以增加支付消息的安全性。

如上述讨论所提及，发送者客户端装置204a可以包括如图2所示的装置存储管理器240a。装置存储管理器240a可以维护消息数据242a，其表示在用户和一个或多个其他用户之间撰写、发送和接收消息所结合使用的数据。例如，消息数据242a可以包括消息记录、联系人列表、内容、过去通信以及消息传送应用230a可以提供用户使用消息传送应用230a通信的能力而结合使用的其他类似类型的数据。

装置存储管理器240a也可以维护表示用于生成支付消息的信息的支付数据244a。例如，支付数据244a可包括支付方法数据、发送者账户数据(例如，银行或信用卡账户数据)、密码、PIN、授权码和安全令牌。此外，支付数据244a可以包括支付偏好(例如，默认支付方法或支付简档)。一般来讲，支付数据244a可以包括支付消息发生器238a生成支付消息而可以结合使用的任何数据。

如上所简述，除了发送者客户端装置204a之外，系统200可以进一步包括与发送者/接收者客户端装置204a和204b以及支付网络215通信的消息系统210，如图2所示。另外，图2示出了消息系统210可以包括各种组件，其允许发送者经由消息系统210向接收者发送支付。

如图2所示，消息系统210可以包括但不限于通信管理器250、状态管理器252、支付管理器254、支付网络协调器256和存储管理器258。消息系统210的每个组件250至258可使用任何合适的通信技术彼此通信。应认识到，尽管组件250至258在图2中被示为是分开的，但组件250至258中的任一者可组合成更少的组件，诸如组合成单个设施或模块，或分成可用于具体实施例的更多组件。此外，组件250至258可以包括软件、硬件或硬件和软件的组合。

为了与消息系统210之外的系统和装置通信，消息系统210可以包括通信管理器250。在一个或多个实施例中，通信管理器250可以发送电子信息至客户端装置204和接收来自自客户端装置204的电子信息。例如，通信管理器250可以在发送者客户端装置204a和接收者客户端装置204b之间接收和转发通信消息。另外，通信管理器250可以在支付过程中从发送者客户端装置204a接收支付消息以及发送和/或接收支付状态消息、状态更新和用户动作，以及可在客户端装置204和消息传送系统210之间通信的其他信息。

如图2进一步所示，消息系统210可以包括状态管理器254。状态管理器254可以监控、确定或以其他方式标识在客户端装置204上的用户状态。具体地，状态管理器254可以监控用户在客户端装置204上的动作以确定用户是否存在和/或可用于通信。例如，状态管理器252可以(例如，通过使用从位于客户端装置上的数码相机被动收集的图像数据)确定用户正在使用特定应用、经由一个或多个通信平台进行通信或者查看客户端装置的画面。应认识到，状态管理器254可以使用各种其他方法来确定客户端装置上的用户的存在或可用性状态。

除了监控和确定用户的状态之外，状态管理器252可以向通信管理器250提供用户的状态，并且通信管理器250可以将用户的状态信息分发给消息系统210的各个其他用户。例如，发送者可以导航到发送者客户端装置204a上的消息传送应用230a内的一个或多个用户界面(例如，消息线程、联系人列表和/或支付界面)以查看接收者的状态。状态管理器252可以基于接收者在接收者客户端装置204b上的动作来确定接收者的状态，以及通信管理器250可以将接收者的状态发送至发送者客户端装置204a以在消息传送应用230a内呈现。

与传统支付系统不同，系统200允许发送者在发送支付之前确认接收者是否存在并且可用。允许发送者确认接收者是否存在并且可用以对支付做出反应降低了支付混淆的可能性。此外，接收者存在的事实可以增加发送者对接收者实际收到支付的信心，因为接收者可以在接收者收到支付时作出反应。

在一个或多个实施例中，消息传送应用230a可以被配置成(例如，发送者选择用户偏好设置)仅当接收者可用时才向接收者发送支付。例如，发送者可以定义至接收者的支付并提供用于发送支付消息的交互。然而，消息传送处理器236a可以识别出接收者当前不可用，并且作为响应，消息传送处理器236a可以保存支付消息直到接收者的状态改变为可用为止。在一个或多个实施例中，在接收者的状态改变为可用时，无论发送者的状态如何(例如，发送者的状态已经从可用状态改变为不可用)，发送支付消息。替换地，在接收者的状态改变为可用之前，发送者的状态变为不可用的情况下，消息传送处理器236a可以保存支付消息直到接收者和发送者均可用为止。

如图2进一步所示，消息传送系统210可以包括支付管理器254。一般来讲，支付管理器254可以响应于消息传送系统210从发送者客户端装置204a接收到支付消息来发起支付过程。例如，通信管理器250可以接收支付消息、检测消息为支付消息并将该支付消息收传送至支付管理器254。在收到支付消息时，支付管理器154发起促成便于在支付消息的支付信息内定义的支付的支付过程。

在一个或多个实施例中，支付过程可以包括支付管理器254，其解析支付消息以识别或以其他方式提取支付信息。基于支付信息，支付管理器154可以向支付网络协调器256提供具有发起交易的指令的支付信息。支付网络协调器256可以在支付网络215内发起交易以完成在支付信息中定义的支付(例如，使货币从发送者账户转出并存入接收者账户)。

支付管理器154进一步监控支付过程并协调关于支付网络协调器256、通信管理器250、发送者客户端装置204a和接收者客户端装置204b之间的支付过程的通信。例如，支付管理器254可以从支付网络协调器256接收交易的状态。响应于接收到状态，支付管理器254可以命令通信管理器250将更新的状态通信发送至发送者客户端装置204a和/或接收者客户端装置204b以更新发送者状态消息和/或接收者状态消息。

除了协调支付过程状态信息之外，支付管理器252还可以协调客户端装置204在支付过程期间可发送的信息的通信。例如，通信管理器250可以在支付过程期间从发送者客户端装置204a和/或接收者客户端装置204b接收信息。具体地，通信管理器250可以从发送者客户端装置204a或接收者客户端装置204b接收指示发送者或接收者、状态消息内选择动作的信息。例如并如上所述，发送者可以与发送者状态消息交互以选择取消动作。

在一个或多个实施例中，通信管理器250可以从发送者客户端装置204a接收取消信息并向支付管理器254提供该取消信息。作为响应，支付管理器254然后可以使通信管理器250向接收者客户端装置204b发送状态更新。例如，在接收到状态更新之后，消息传送处理器236b可以与用户界面管理器232b协调来更新接收者状态消息中的支付状态，以允许接收者看到支付被取消。

此外，响应于接收到取消信息，支付管理器254可以使支付网络协调器256取消支付通信网络215内的交易。作为交易取消过程的一部分，支付管理器254可以验证交易被取消、更新交易数据库264并关闭消息传送系统210内的支付实例。因此，支付管理器254管理发送者客户端装置204a、接收者客户端装置204b和支付网络协调器256之间的支付过程。

支付管理器254可以执行各种其他附加步骤和方法以便有效地管理支付过程。例如，在一个或多个实施例中，在接收到支付消息之后，支付管理器254可以生成交易标识符(或简称为“交易ID”)并将该交易标识符与支付消息和/或该支付消息内的支付信息相关。例如，在生成交易ID之后，交易数据库264可以维护交易ID和相关的交易(例如，支付)信息266。交易数据库264可以包括根据交易ID存储交易信息的数据表或类似的数据矩阵。

在一个或多个实施例中，在支付管理器254将交易ID与特定支付消息相关之后，交易ID可以被包含或嵌入系统200内关于特定支付的基本上所有的通信中。因此，交易ID允许支付管理器254以有组织的方式管理和处理大量的支付。例如，支付管理器254可以包括将交易ID包含在发送至客户端装置204的任何信息中的指令。继而，消息传送处理器236也可以将交易ID包含在从客户端装置204发送的任何信息中，以允许支付管理器254有效和可靠地识别该信息对应的特定交易。

如上所简述，支付网络协调器256可以与支付管理器254协作以协调对应于在支付消息中定义的支付的交易。如上所述，支付网络协调器256可以经由支付网络215协调与支付消息对应的交易、监控交易的状态并将有关交易的状态信息提供给支付管理器254。更具体地，支付网络215可以授权交易、为交易拨款和/或结算单个交易或批处理交易，如上面参考图1所述。在一个或多个实施例中，支付网络协调器256可以使用一个或多个应用编程接口(API)以通过支付网络215传送相关信息。

为了完成交易，支付网络协调器256获得接收者存款账户信息，以便向接收者提供支付。支付网络协调器256可以使用各种方法获得接收者的存款账户信息。在一个示例实施例中，接收者可以经由消息系统210注册一个或多个存款账户。在用户注册存款账户时，存储管理器258可以维护在用户简档数据库260中的存款账户信息(例如，帐号、路由编号)。

在支付网络协调器256从支付管理器254接收到支付信息之后，支付网络协调器256可以识别支付信息内的接收者。支付网络协调器256可以在用户简档数据库260中查找接收者以确定接收者是否已经注册了存款账户。如果接收者的简档包括存款账户信息，则支付网络协调器256提取存款账户信息并将其与所识别的接收者的相应支付信息相关。此时，支付网络协调器256可以发起交易。

在接收者的用户简档不包括存款账户信息的情况下，支付网络协调器256可以向支付管理器254通知不足之处。在一个或多个实施例中，支付管理器可以命令通信管理器252向接收者发送提示接收者注册存款账户的消息。例如，该消息可通过在消息内提供允许接收者提供存款账户详细信息的一个或多个交互字段来提示接收者注册存款账户。例如，该消息可包括路由编号字段、帐号字段、银行名称字段和用于从消息线程内直接发送存款账户信息的可选选项。因此，接收者可以直接在消息传送应用230b内注册存款账户，并且具体地，接收者可以从与发送者对应的消息传送线程内注册存款账户。替换地，消息可包括指向允许用户注册存款账户的注册网页的超链接。

另外或替换地，在确定接收者未注册存款账户之后，支付网络协调器可以在消息系统210内生成临时存款账户。具体地，临时存款账户允许支付网络协调器256立即执行处理交易，而无需从发送者或接收者的角度延迟支付过程。在一个或多个实施例中，支付网络协调器256可以生成帐号并将帐号与接收者的用户简档相关。在一个或多个实施例中，接收者可能已经具有临时账户，并因此，支付网络协调器256可以使用先前创建的临时账户来完成交易。

在交易完成后，支付网络协调器256将支付金额存入临时存款账户。在一个或多个实施例中，支付管理器254可以使通信管理器250向接收者发送提供超链接和/或将资金从临时账户转移到已登记的存款账户的指令的消息。替换地，如果接收者不想注册存款账户，则消息系统可以提供接收者指令以从临时账户中提取资金。

除了经由支付网络215协调交易之外，支付网络协调器256还可以协调关于一个或多个系统用户账户的交易。在一个或多个实施例中，消息传送系统210可以支持用户现金账户，诸如礼品卡账户、现金卡账户或类似类型的用户账户。发送者可以将发送者的用户现金账户指定为支付方法，并且类似地，接收者可以将接收者的用户现金账户设置为已注册的存款账户。因此，在至少一些实施例中，可以在消息系统210内处理整个交易或基本上整个交易。

在一个或多个实施例中，系统200也可以允许接收者将信用卡账户注册为存款账户。例如，支付网络协调器256可以格式化交易以从发送者账户扣除支付金额并存入支付金额或将支付金额提供给接收者的信用卡账户。更具体地，在确认了发送者的支付账户的授权之后，支付网络协调器256可以发送一个退款请求，以将支付金额存入接收者的信用卡账户。

在一个或多个实施例中，退款请求可以包括未引用的退款请求。未引用的退款请求为未附加到用户的信用卡账户的以前的转账交易的退款请求。大多数信用卡提供商允许对未引用的退款请求进行处理，从而产生将退款请求的金额提供给接收者的信用卡账户。例如，在接收者在信用卡账户上有负余额的情况下，退款请求金额可能会提供给该负余额。同样地，在接收者在信用卡账户上有零余额的情况下，退款请求金额将产生收款人可以再次开销的正信用卡账户余额。

在一个或多个实施例中，支付网络协调器256可以组织和处理批量的信用卡转账请求和批量的信用卡退款请求。具体地，由于与信用卡交易相关的各种费用结构，支付网络协调器256可以处理批量的信用卡转账和退款请求以最小化潜在的费用。

如先前在上述讨论中提及并且如图2所示，消息系统210可以包括存储管理器258。如前所述，存储管理器258可以包括交易数据库264，其维护经由发送者客户端装置204a接收的每个支付消息的交易信息266。例如，交易信息266可以包括与一个或多个发送者标识符、接收者标识符、支付金额、支付方法(例如，发送者账户)、存款方法(例如，接收者账户)、交易历史、当前交易状态，以及其他交易信息相关的交易ID。

在一个或多个实施例中，以与交易相关的任何动作更新的一个或多个图形对象的形式来维护交易信息。例如，对于消息系统210接收到的每个支付消息，支付管理器254可以创建维护关于所接收到的支付消息的相关数据和信息的图形对象。在继续支付过程时，支付管理器254可以用更新的信息和数据来更新图形对象，使得图形对象经由消息系统210一致地反映当前的支付状态。

除了交易信息266之外，交易数据库264可以包括一或多种类型的临时账户268。临时账户268可以用作“热钱包账户”，其在从发送者账户结算或实际转账之前提供资金以存入接收者账户。例如，通过使用一些支付方法，支付的转账过程可能需要几个小时甚至几天才能从发送者的账户中扣钱。然而，支付授权请求可以验证并预留资金以满足支付。因此，在收到对支付授权请求的成功响应之后，支付网络协调器256可以从临时账户268中为支付金额提供资金，以便提供更短时间的到达接收者账户的支付(例如，几秒钟)。一旦从发送者账户支付资金，临时账户就将更新支付金额，从而减少任何适用的费用。

如图2进一步所示，存储管理器258也可以包括用户信息数据库262。更具体地，用户可以在消息传送系统210内创建支付简档，以允许用户通过消息传送系统210发送和接收支付。一般来讲，支付简档可以包括已验证的用户账户、账户信息、授权数据(PIN和/或密码)以及用户定义的默认支付方法。每种支付方法包括诸如帐号、到期日期、安全代码、银行信息、路由和转移号等的支付细节。用户支付简档可以进一步包括电子邮件地址、物理地址和一或多种支付方法。

如上所述，参考图1至2讨论的系统和组件可以允许消息系统的用户经由消息系统容易、有效并且安全地发送和接收支付。图3A至4B示出了由上述系统100和/或200实现的过程的一个或多个示例实施例的示例过程图。具体地，图3A至4B示出了交易支付系统可以用于促成消息系统的用户之间的支付的过程和方法的非限制性示例。

与系统200一致，图3A至4B示出了具有消息传送应用230a的发送者客户端装置204a、具有消息传送应用230b的接收者客户端装置204b、提供消息系统210的服务器装置206、和支付网络215。除了下面所述的特性、功能和/或特征之外，发送者/接收者客户端装置204a/204b、服务器装置206和支付网络215中的每者还可以包括上面参考图1至2所述的一个或多个特性、功能和/或特征。为了便于说明，图3A至4B示出了在先前在消息传送系统210内设置支付账户的用户之间进行支付的过程。

在一个或多个实施例中，用户经由消息系统210向另一用户发送支付的过程可以从与发送者客户端装置204a相关的发送者用户(或简称为“发送者”)开始，发送者客户端装置204a向消息传送应用230a提供用户输入以生成支付消息302。具体地并如上所述，发送者可以访问一个或多个用户界面，其允许发送者定义对接收者用户(或简称为“接收者”)进行的支付。另外，如图3A所示，消息传送应用230a可以使发送者客户端装置204a向消息系统210发送支付消息304。

消息系统210可以接收支付消息，并且消息系统210可以使用一个或多个组件(如上所述)来识别支付消息内的授权信息以授权支付306，如图3A所示。在一个或多个实施例中，支付消息可以包含发送者在消息传送应用230a内输入的授权码。消息传送系统210可以识别支付消息内的授权码，并验证该授权码与用户简档内的验证码相匹配。

另外或替换地，消息传送系统210可以通过验证其他类型的数据，例如发送者客户端装置204a ID、用户ID、支付方法凭证或其他验证数据(例如，从发送者客户端装置204a上的指纹读取器获得的数字指纹数据)来授权支付。尽管图3A示出了消息系统210授权支付306，但是在一个或多个实施例中，发送者客户端装置204a可以在发送支付消息之前授权支付306。例如，消息传送应用230a可以在发送支付消息之前验证授权码，或者与远程服务通信以验证授权码。

在消息系统210未授权支付的情况下，例如，授权码不能被验证，消息系统210可以向发送者客户端装置204a发送通信，以使消息传送应用230a向发送者呈现指示支付无法授权的错误消息。在一个或多个实施例中，错误消息可以包括用于发送者重新输入授权信息的提示，之后发送者客户端装置204a可以向消息系统210发送具有重新输入的授权码的修改的支付请求。然后，消息系统210可以尝试利用重新输入的授权码来授权支付。如果消息系统210无法授权支付，则支付过程终止。

在消息传送系统210授权支付306之后，消息系统210可以生成交易ID 308，如图3A所示。如上所述，消息传送系统210将唯一的交易ID与接收到的每个支付消息相关，并且可以将该交易ID包含在各种文件、对象、消息和其他信息内，以允许消息系统210有效地识别并处理消息、状态更新以及关于经由消息系统210进行的每次支付的其他信息。例如并如上所述，消息系统210可以将交易ID与维护与处理支付消息相对应的信息的图形对象相关。

如图3A进一步示出，消息系统210可以向发送者客户端装置204a提供发送者状态消息310。例如，发送者状态消息310可以包括对应于支付过程的特定状态的发送者消息和/或可用发送者动作。此外，消息系统210可以向接收者客户端装置204b发送接收者状态消息312。接收者状态消息312可以包括对应于支付过程的特定状态的接收者消息和/或可用接收者动作。

在发送者客户端装置204a和接收者客户端装置204b从消息系统210接收到状态消息之后，每个装置可以呈现状态消息。具体地，图3A示出了发送者客户端装置204a可以在发送者状态消息314中呈现“取消”选项以及标识支付信息的一个或多个部分的其他信息。例如并如下面参考图5A至7C进一步解释的那样，第二客户端装置204a可以在与接收者的消息传送会话相对应的消息线程内呈现发送者状态消息314。状态消息中的“取消”选项允许发送者在支付过程的各个阶段取消支付。一般来讲，支付完成之前，发送者可以使用“取消”选项。

另外，图3A示出了接收者客户端装置204b可以在接收者状态消息316内呈现“处理”消息以及识别支付信息的一个或多个部分的其他信息。“处理”消息向接收者指示支付正在进行。具体地，在消息传送系统210与支付网络215通信以授权支付时，“处理”消息是相关的。如同发送者状态消息，接收者客户端装置204b可以在接收者客户端装置204b上的消息线程中呈现接收者状态消息，该消息对应于与发送者的消息传送会话。

除了提供发送者和接收者状态消息之外，消息系统210可以向支付网络215发送支付授权请求318。如上所详细描述的，支付授权请求包括允许支付网络215验证发送者被指定为支付方法的支付账户的支付信息。此外，支付网络215可以验证支付账户具有足够的资金以提供支付金额，以及请求保持应付给支付账户的支付金额的资金。在一个或多个实施例中，支付授权请求318也可以包括使支付网络215验证接收者账户可用于接受支付的支付信息。

如参考图1所详述，支付网络215可以授权支付。在授权支付之后，支付网络215可以向消息系统210发送指示支付被授权的支付授权响应320，如图3A所示。替换地，在支付网络215未能授权支付的情况下，支付网络215可以向消息传送系统210发送指示支付未被授权的支付授权响应320。

当支付网络215无法授权支付时，消息传送系统210可以向发送者客户端装置204a和接收者客户端装置204b发送指示支付失败的状态更新。状态更新可以包括指示支付失败原因以及允许发送者或接收者在可能的情况下纠正失败原因的一个或多个选项的数据。例如，当支付网络215由于与发送者的支付账户相关的问题而无法授权支付时，发送者状态更新可以包括发送者的支付账户的问题的描述。在此情况下，发送到接收者客户端装置204b的状态消息可能不包括对问题的描述，以保护发送者的信息和信誉(例如，当支付失败的原因是由于发送者支付账户中的资金不足时)。

返回到图3A，当支付授权响应指示支付被授权时，消息传送系统210可以向接收者客户端装置204b发送“接受/拒绝”状态更新。在接收到状态更新之后，接收者客户端装置204b更新接收者状态消息324以包括接受或拒绝支付的可选选项。在接收者与可选选项交互以接受支付之后，接收者客户端装置204b可以向消息系统210发送接受响应326。作为图3A所示过程的替代方案，该过程可不包括允许接收者接受或拒绝支付的所示步骤。相反，该过程可以直接发送转账请求以促成支付，而无需来自接收者的任何另外的用户交互。

继续图3A，在消息系统210从接收者客户端装置204b接收到接受响应之后，消息系统210然后可以向支付网络115发送转账授权请求328以处理支付的转账。具体地，转账授权请求可以提供支付信息和指令以从发送者的支付账户向接收者的存款账户转移支付金额，如参考图1所述。根据支付类型(例如，支付金额类型)和存款账户类型，支付转账可采用各种形式。图4A至4B讨论了用于转账支付的另外过程并将在下面讨论。

在转账支付之后，支付网络215可以向消息系统210发送转账授权响应330，如图3A所示。具体地，转账授权响应330可以指示支付的转账是成功的。消息系统210然后可以向发送者客户端装置204a发送支付完成状态更新332，这使得发送者客户端装置204a利用“支付完成”消息336来更新发送者状态消息。同样地，消息系统210向接收者客户端装置204b发送支付请求的状态更新334，这使得接收者客户端装置204b利用“要求支付”消息338来更新接收者状态消息。至此，支付过程完成。

图3B示出了在接收者拒绝支付的情况下的示例处理流程。具体地，图3B所示的处理流程在图3A的点A恢复，或者换句话说，在消息传送系统210已经接收到支付授权响应之后。如上所述，在接收到支付授权响应之后，消息系统210可以发送接受/拒绝更新322，这使得接收者客户端装置利用接受或拒绝支付324的可选选项来更新接收者状态消息。

如图3B进一步所示，接收者客户端装置204b可以在接收者选择拒绝选项之后向消息传送系统210发送拒绝响应。消息系统210可以在从接收者客户端装置204b接收到拒绝响应之后开始支付取消过程。具体地，消息系统210可以向支付网络215发送包括取消所批准的授权请求的消息和指令的取消支付授权请求342。例如，支付网络215可以去除任何资金持有或取消由授权请求引起的任何其他待处理项。然后，支付网络215可以向消息系统210a发送支付网络215取消了支付授权请求344的确认。

另外，在从接收者接收到拒绝响应之后，消息系统210也可以向接收者客户端装置204b发送拒绝状态更新346，这使得接收者客户端装置204b利用“您拒绝了此支付”消息348或其他类似的语言来更新接收者状态消息。消息系统210也可以向发送者客户端装置204a发送支付拒绝状态更新350，这使得发送者客户端装置204a利用“接收者拒绝该支付”消息352或其他类似语言来更新发送者状态消息。在支付过程完成之前，会发生在发送者选择取消支付的情况下的类似过程。

消息系统210也可以采取另外的步骤来取消消息传送系统210内的支付过程。具体地，消息系统210可以更新或删除任何交易信息354。例如，消息系统210可以删除或存档支付信息以及与取消支付相对应的任何其他数据或信息。

图4A至4B示出了支付过程的另外示例，以及具体地，允许消息系统210使用各种各样的支付方法和存款账户来处理支付的转账流程的另外示例。图4A示出了单独处理从发送者账户的转账请求并将支付存入接收者账户的示例流程。例如，在一个或多个实施例中，发送者账户可在第一支付网络上访问，而接收者的账户在第二支付网络上可用。在此情况下，为了处理支付，消息系统210可以充当处理支付的中间体。

图4A所示的处理流程在图3A的点A恢复，或者换句话说，在消息系统210已经接收到支付授权响应之后。如上所述，在接收到支付授权响应之后，消息系统210可以发送接受/拒绝状态更新402，这使得接收者客户端装置利用接受或拒绝支付404的可选选项来更新接收者状态消息。响应于接收者选择接受支付选项，客户端装置204b可以向消息系统210发送接受响应406。

一旦接收者接受该支付，消息系统210就可以向支付网络215发送转账请求408，其请求从发送者的账户中扣除支付金额并将其发送至消息系统210。作为响应，支付网络215可以通过电子方式将钱从发送者的账户转移到消息系统210来从发送者账户410提供该支付。在接收到电子转账时，消息系统210可将支付应用于临时账户412。在一个或多个实施例中，消息系统210可以创建用于应用支付的新账户。替换地，消息系统210可以向包括由与每个支付相关的唯一交易ID组织和标识的各种其他支付的主临时账户应用支付。

消息系统210然后可以将支付存入接收者的存款账户。具体地且如图4A所示，消息系统210可以经由支付网络215或另一支付网络通过电子方式将支付转移至接收者的账户414。在将支付成功地存入接收者账户之后，支付网络215向消息系统210发送转账确认416。在接收到转账确认416之后，消息系统然后从临时账户418扣除支付金额418，并从而相对于支付调整临时账户。

为了完成支付过程，消息系统210可以向发送者客户端装置204b发送支付完成状态更新420和向接收者客户端装置204b发送支付请求的状态更新422。另外，发送者客户端装置204a利用“支付完成”消息424来更新发送者状态消息，而接收者客户端装置204b利用“要求支付”消息426来更新接收者状态消息，如图4A所示。

图4B示出了用于促成从发送者到接收者的支付的支付转账流程的又一示例。具体地，图4B示出了当发送者选择具有缓慢或延迟的转账流程的支付方法时，消息传送系统210可以使用的示例转账流程。一般来说，支付系统的用户由于缓慢的支付流程而变得沮丧。因此，图4B示出了提供快速支付过程的示例过程，即使当支付方法具有缓慢或延迟的转账过程时。

图4B所示的处理流程在图3A的点A恢复，或者换句话说，在消息系统210已经接收到支付授权响应之后。如上所述，在接收到支付授权响应之后，消息系统210可以发送接受/拒绝状态更新402，这使得接收者客户端装置利用接受或拒绝支付404的可选选项来更新接收者状态消息。响应于接收者选择接受支付选项，客户端装置204b可以向消息系统210发送接受响应406。

基于指示缓慢的转账流程的支付方法的类型，消息系统210可以在消息系统210内维护的临时账户428中扣除支付金额，并通过电子方式经由支付网络215将支付转移至接收者账户430。支付网络215可以发送指示成功转移的转移确认432。因此，基于接收到对支付授权请求的成功响应(参见图3A)，在从发送者的账户实际扣除支付金额之前，消息系统210将支付预付给接收者的账户。

此时，消息传送系统可以向发送者客户端装置204a和接收者客户端装置204b发送指示支付过程完成并且接收者已要求该支付的状态更新，如上面参考图4A所述。发送者客户端装置204a和接收者客户端装置204b可以更新发送者状态消息和接收者状态消息以指示支付过程完成，并且尽管从技术上讲，支付还没有转账，但是从发送者和接收者的角度来看支付过程已完成。

如图4B进一步所示，消息系统210可以准备结算包434。例如，在一个或多个实施例中，由于支付方法的缓慢特性，消息系统210可累积相同类型的多个支付以包含在单个结算交易中处理多个支付的结算包中。接下来，消息系统210可以向支付网络215发送转账请求436，以及支付网络215可以通过电子方式将转账请求的金额的资金转移到消息系统210来转账请求438提供资金。然后，消息系统210可以通过协调临时账户440，或者换句话说，添补临时账户来完成支付过程。

图5A至7C示出了消息系统可以提供的以允许用户发送至其他用户和从其他用户接收支付的图形界面的一个或多个实施例。尽管图5A至7C示出了移动装置上的图形界面的示例实施例，但是图形界面特性和特征可以应用于各种其他客户端装置上以提供相同或相似的功能和用户体验。

图5A至5C和5H示出了发送者的移动装置500a，以及图5D至5G示出了接收者的移动装置500b。一般来讲，每个移动装置500a和500b包括呈现具有相同或相似特征的图形界面504的触摸屏502。此外并如图5A所示，图形界面504可以包括但不限于导航栏505，包括一个或多个消息508的消息传送线程506，输入区域510，包括支付元素514、发送元素516的可选元素的菜单512，以及输入键盘518、所有这些都可以响应于经由触摸屏502检测到的用户交互。下面将更详细地讨论上述每个图形界面504的特征和特性。

如上所述，图5A示出了导航栏505可以包括发送者与之通信的用户的名称或身份。为了方便起见，发送者的移动装置500a将接收者的名称简单地指示为“接收者名称”，以及同样地，接收者的移动装置500b将发送者的名称简称为“发送者名称”。在通信会话包括多于两个的用户的情况下，导航栏505可以包括与参与通信会话的多个用户相对应的多个名称或身份。

除了用户的名称或身份之外，图5A示出了导航栏505可以包括位于名称下方的状态指示符。如所示，状态指示符可以允许发送者用户知道接收者在接收者的移动装置500b上是否活跃。此外，状态指示器可以指示接收者如何处于何种活动状态(例如，消息传送、电话、网页浏览器)。因此，发送者可以在发送支付之前验证接收者是否可以接收支付。

导航栏505可以进一步包括提供导航功能的各种其他可选元素。例如，如图5A所示，导航栏505可以包括导航到消息应用中的联系人列表或其他界面的“后退”导航按钮。此外，导航栏505可以包括可选的电话元素，其允许发送者在消息传送应用内直接呼叫接收者。导航栏505可以包括各种其他特征和特性。

如前所述，图形界面504可以包括具有一个或多个消息508的消息传送线程506，如图5A所示。在一个或多个实施例中，消息线程506可以组织消息508以区分所发送的消息和所接收到的消息。例如，图5A示出了所接收的消息左对齐并且处于第一阴影中，而所发送的消息右对齐并处于第二阴影中。另外，如图5A所示，所接收到的消息可以对应于消息线程内的用户图标，该用户图标进一步指示发送消息的用户的身份。

为撰写和发送消息，发送者可以与键盘518交互以向输入区域510提供用户输入。例如，如图5A所示，发送者已将文本输入到输入区域510中。为了发送消息，用户然后可以与发送元素516交互。除了输入文本之外，发送者也可以与菜单512上的一个或多个元素进行交互以将其他类型的内容添加到消息中。例如，图5A示出了菜单512可以允许用户导航到一个或多个界面特征，这允许用户发送文本、捕获和发送新图像/视频、从图册发送所保存的图像/视频、发送一个或多个符号或表情符号。

除了上述可选的元素之外，菜单512可以包括可选的支付元素514，如图5A所示。发送者可以与支付元素进行交互，以向接收者发送支付。在一个或多个实施例中，发送者可以包括具有支付的消息。例如，发送者可以将文本输入到输入区域，而不是与发送元素516交互，发送者可以向支付元素514提供交互(例如，轻击手势)，如图5A所示。在用户选择支付元素514时位于输入区域510内的文本(或其他内容，例如图像、视频、音频、表情符号或其他符号)可被包含在支付消息内以及发送者和接收者支付状态消息内(参见图5C和5D)。

在一个或多个实施例中，响应于发送者与支付元素514交互，移动装置500a上的消息传送应用可以与消息系统进行通信以确定发送者是否与该消息传送系统内的注册支付账户相关。在发送者不与所注册的支付账户相关的情况下，消息传送应用程序可以呈现允许发送者注册支付账户(例如，如上详述提供支付信息)的图形界面。替换地或附加地，图形界面可以呈现一次性支付选项，其允许用户输入支付信息以促成一次性支付(例如，输入借记卡或信用卡号)，而无需发送者创建账户。

如图5B所示，如果发送者已利用消息传送系统设置了支付账户，则响应于发送者与支付元素514交互，消息传送应用可以转换图形界面504以允许发送者定义支付。例如，导航栏505可以从呈现接收者名称改变为呈现文本“发钱”或另一类似的消息或符号，以指示发送者可以经由图形界面504定义支付。另外并如图5B所示，导航栏505可以包括可选的取消选项，发送者可以与该取消选项来交互以返回到消息线程508而无需定义和/或发送支付。

图形界面504可以进一步包括允许发送者定义支付的各种输入字段。例如且如图5B所示，图形界面504可以包括但不限于接收者输入字段520、支付输入字段522、授权代码输入字段524、支付方法选择器526和发送支付元素528。另外，图形界面504可以包括数字键盘530。发送者可以与每个字段、选择器和/或元素交互以快速并有效地定义支付。

在一个或多个实施例中，一个或多个字段和/或选项被预填充/预选。例如，图5B示出了接收者输入字段520基于发送者选择与接收者相对应的消息线程内的支付元素514(参见图5A)预填充有接收者名称。在消息传送线程对应于多个接收者的情况下，接收者输入字段520可预填充有多个接收者中的每者。另外，发送者可以与接收者输入字段520交互以添加或删除接收者。例如，发送者可以相对于接收者输入字段520提供点击手势，并且作为响应，消息传送应用可以呈现发送者可以选择性地添加或移除接收者的其他用户联系人列表(例如，发送者的好友列表)。

如图5B进一步所示，发送者可以经由支付输入字段522和数字键盘530输入支付金额。在多个接收者的情况下，支付输入字段可包括与多个接收者中的每者相对应的输入区域。支付输入字段也可包括各种其他图形特征以提供一个或多个另外的支付金额选项(例如，组支付选项)，如上面参考图2所述。类似地，发送者可以使用数字键盘530经由授权码输入字段524提供授权码。

如上所述，在一个或多个实施例中，发送者可以定义用于支付的默认支付方法。然而，发送者可以与支付方法选择器526交互以改变不同的支付方法。例如，在与支付方法选择器526交互时，消息传送应用可以呈现其他已注册支付方法的列表并且呈现添加新的支付方法的选项。然后，发送者可与一个或多个其他支付方法交互以定义支付方法。图形界面504可以包括另外的图形元素和特征，其允许发送者使用本文所述的一或多种方法或过程进一步定义支付。

在发送者定义支付之后，发送者然后可以与发送支付元素528交互，如图5B所示。如上所述，在发送者与发送支付元素528交互时，消息传送应用可以使得移动装置500a将具有已定义的支付信息的支付消息发送至消息传送系统。消息传送系统然后可以执行支付过程，包括与发送者的移动装置500a和接收者的移动装置500b交换各种电子通信。

例如，如图5C所示，在接收到支付消息之后，消息系统可以通过向发送者的移动装置500a发送发送者状态消息550来响应。移动装置500a上的消息传送应用可以将发送者状态消息550添加到消息线程506以作为发送者所发送的消息。具体地，即使消息传送系统生成并发送了发送者状态消息550，因为源自发送者的支付，发送者状态消息显示为发送者的消息。

如上所述，发送者状态消息550可以包括在发送支付消息之前发送者输入到输入区域510中的内容。例如，图5C示出了发送者状态消息550，其包括在图5C的输入区域510中示出的文本消息。另外或替换地，发送者状态消息可以包括标识支付的默认文本(例如，“您正在向接收者发送支付”)。在有多个接收者的情况下，发送者状态消息可包括每个接收者的名字和对应于每个接收者的支付金额。替换地，消息系统可为多个接收者中的每者发送单独的发送者状态消息。

如简要提到的，发送者状态消息550可以包括支付金额(例如，$30.00)。在一个或多个实施例中，支付金额可以为允许发送者直接在消息线程506内修改支付金额的可选元素。例如，发送者可发送金额为$30.00的支付。作为响应，接收者可向发送者发送即时消息，其解释了支付是错误的金额。发送者可与支付金额可选元素交互并修改支付金额。在修改支付金额之后，移动装置500a向消息传送系统发送通信，该消息传送系统然后用新的支付金额来更新支付信息。

发送者状态消息550可进一步包括与支付相关的一个或多个可选元素。例如，图5C示出了发送者状态消息550包括可选的取消元素552。如上所详述，发送者可以与取消元素552进行交互，以在支付过程中的各个点取消支付。

图5D示出了接收者的移动装置500b。具体地，图5D示出了在接收者的移动装置500b在发送者发送支付消息时从消息传送系统接收到的接收者状态消息560。如同发送者状态消息550，接收者状态消息560可以包括内容(例如，文本)和支付金额。接收者状态消息560可以包括与上文关于发送者状态消息550所述的相同或相似的特征。

此外，接收者状态消息560可以包括指示支付状态的状态指示符562。例如，在最初接收到接收者状态消息560时，消息传送系统可以尝试授权支付(参见图3A)。当授权过程正在进行时，接收者状态消息560可以包括通知接收者支付正在处理的状态指示符562。

进一步参考图5E至4G，消息传送系统可以向接收者的移动装置500b发送状态更新，以利用接受元素564和拒绝元素566来更新接收者状态消息560，这意味着消息系统成功地授权支付。接受元素564和拒绝元素566向接收者提供接受或拒绝支付的机会。在一个或多个实施例中，支付过程继续进行而无需向接收者提供接受或拒绝支付的选项。

如图5E所示，在接收到接受指示符564的选择之后，消息传送系统可以提供状态更新以使得接收者状态消息560包括通知接收者支付过程正在进行的状态指示符568。例如并如图5F所示，状态指示符568可以包括诸如“处理交易”之类的文本状态。其他语言、符号、图形或动画可以指示交易的处理资金。例如，在一个或多个实施例中，在消息传送系统正在处理资金时，发送者和/或接收者状态消息可以包括指示钱从发送者转移到接收者的动画。示例动画可包括在支付金额上的现金的动画计数，说明在消息传送系统完成转账流程时支付过程的直接性质并娱乐用户。

如图5G所示，在完成转账流程后，来自消息系统的状态更新可使得接收者状态消息560包括指示接收者成功接收到支付的状态指示符570。类似地，如图5H所示，来自消息系统的状态更新可以使得发送者状态消息550包括指示成功完成支付的状态指示符572。

在一个或多个实施例中，发送者和接收者可以在整个支付过程中持续交换消息。在发送者和接收者状态消息550、560发送之后发送的消息可以出现在消息线程506中的最新消息位置或低于状态消息的位置(例如，在添加新消息时更旧消息在消息线程506中向上移动)。在一些示例实施例中，当接收到与支付相关的状态更新时，消息传送应用将消息线程506内的状态消息550、560的位置重新分配到最新消息位置。类似地，消息传送应用可以以与通知发送者和接收者新消息相同的方式向发送者和接收者通知状态更新。以此方式，发送者和接收者可以在支付过程中实时地持续通信并监控支付过程的进程。

此外，在成功完成支付后，发送者状态消息550和接收者状态消息560可包括对支付细节的链接或其他引用。例如，发送者可以向指示支付成功的发送者状态消息560提供交互(例如，触摸和保持手势)。作为响应，消息传送应用可以检索和呈现另外的支付细节，例如交易ID、支付方法和任何其他支付信息。类似地，接收者可以与完成的接收者状态消息交互以获得另外的支付细节，例如，接收者存款账户名称或其他支付信息。

图6A至6C示出了当接收者拒绝支付时发送者状态消息550和接收者状态消息560的示例实施例。例如，如图6A所示，当接收者选择拒绝元素574时，来自消息传送系统的状态更新可使得接收者状态消息560指示支付已被拒绝，例如如图6B中所示，“您拒绝了该支付”。同样地，从消息传送系统到发送者移动装置500a的状态更新可以使得图6C所示的发送者状态消息550通知发送者该接收者拒绝支付，例如“接收者拒绝了该支付”。

图7A至7C示出了当发送者取消支付过程时发送者状态消息550和接收者状态消息560的示例实施例。如图7A所示，发送者可以选择取消元件552以取消支付。作为响应，消息传送系统可以取消支付过程，并向发送者的客户端装置500a发送状态更新。如图7B所示，状态更新可使得发送者状态消息550指示取消，例如“您取消了该支付”。同样地并如图7C所示，从消息传送系统到接收者的客户端装置的状态更新可以更新接收者状态消息560以指示已取消支付，例如“发送者取消了该支付”。

图1至7C、对应的文本和示例提供了用于经由消息传送系统发送支付的许多不同的系统、过程和装置。除了前述之外，一个或多个实施例也可根据流程图来描述，该流程图包括用于实现特定结果的方法中的动作和步骤。例如，图8至9示出了根据一个或多个实施例的示例性方法的流程图。

图8示出了用于在消息传送系统的两个用户之间发送支付的示例性方法800的流程图。方法800可包括从与发送者相关的第一客户端装置204a接收支付消息的动作802，支付消息定义从发送者到接收者的支付。具体地，动作802可以包括在具有至少一个处理器的服务器装置206接收来自与发送者相关的第一客户端装置204a的支付消息，该支付消息定义从发送者到接收者的支付。例如，发送者可使用消息传送应用230a来定义对接收者的支付，并作为响应，消息传送应用230a可以生成支付消息并向支持消息系统210的服务器装置206发送该支付消息。

方法800也可包括提供用于在第二客户端装置204b上的消息线程506内显示的接收者状态消息560的动作804，接收者状态消息560包括接收者交易信息。具体地，动作804可以包括由服务器装置206向与接收者相关的第二客户端装置204b提供用于在第二客户端装置204b上的消息线程508内显示的接收者状态消息560，接收者状态消息包括与支付相对应的接收者交易信息。在一个或多个实施例中，接收者交易信息可以包括如上详述的支付金额、支付发送者、支付状态和附加支付信息。

方法800可进一步包括提供用于在第一客户端装置204a上的消息线程506内显示的发送者状态消息550的动作806，发送者状态消息550包括发送者交易信息。具体地，动作806可以包括由服务器装置向第一客户端装置204a提供用于在第一客户端装置204a上的消息线程508内显示的发送者状态消息550，发送者状态消息550包括对应于支付的发送者交易信息。在一个或多个实施例中，发送者交易信息可以包括如上详述的支付金额、接收者、支付状态和附加信息。

此外，方法800可包括识别交易状态的动作808，通过该动作，处理从发送者到接收者的付款。具体地，动作808可以包括使用服务器装置206的至少一个处理器识别交易状态，通过该动作，处理从发送者到接收者的支付。例如，消息系统210可以与支付网络215通信以识别交易的一个或多个阶段或交易过程的状态。

方法800也可包括向第二客户端装置204b提供状态更新的动作810，其更新接收者状态消息560内的接收者交易信息。具体地，动作810可以包括，基于识别交易的状态，向更新接收者状态消息560中的接收者交易信息的第二客户端装置204b发送状态更新。例如，在一个或多个实施例中，消息系统210可以在支付过程期间，在授权支付、转账支付、取消付款、识别错误和/或任何可识别的事件时发送状态更新。

图9示出了用于在消息传送系统的两个用户之间发送支付的示例性方法900的流程图。方法900可包括提供包括消息线程506和可选支付元素514的图形用户界面504的动作902。具体地，动作902可以包括经由移动装置550a的显示器提供包括消息线程506的图形用户界面504，消息线程506具有在与移动装置500a相关的发送者与接收者之间交换的多个电子消息508，图形用户界面504进一步包括可选支付元素514。在又一实施例中，消息传送应用230a可以提供图形用户界面504。

另外，方法900可包括提供一个或多个图形元素520至526以允许发送者定义待发送至接收者的支付的动作904。具体地，动作904可以包括经由移动装置500a的显示器并且响应于发送者与可选的支付元素514交互来提供一个或多个图形元素520至526，以允许发送者指定定义从发送者到接收者的支付的支付信息。例如并如上所详述，图形用户界面504可以包括图形元素以允许用户定义一个或多个接收者、支付金额、支付方法等。

此外，方法900可包括发送包括定义支付的支付信息的支付消息的动作906。具体地，动作906可以包括向消息系统发送包括定义从发送者到接收者的支付的支付信息的支付消息。例如，消息传送应用230a可以生成包括由发送者指定的支付细节的支付消息。

方法900也可包括接收状态消息550的动作908，状态消息550包括对应于促成从发送者和接收者的支付的交易的交易信息。具体地，动作908可以包括从消息系统210接收包括与促成发送者和接收者之间的支付的交易相对应的交易信息的状态消息。在一个或多个实施例中，消息传送应用230a可以生成包括由发送者指定的支付细节的支付消息。

方法900也可包括在图形用户界面504的消息线程506内提供状态消息550的动作910。具体地，动作910可以包括经由移动装置550a的显示器来提供图形用户界面504的消息线程506内的状态消息550。例如，状态消息550可以包括上面详述的支付金额、用户定义消息、可选元素和其他支付信息。

一个或多个实施例可包括或利用专用或通用计算机，其包括计算机硬件，诸如例如一个或多个处理器和系统存储器，如下面更详细论述的。实施例也可包括物理的和其他的计算机可读介质，其用于携带或存储计算机可执行指令和/或数据结构。具体地，本文所述的一个或多个过程可至少部分实现为在非暂态计算机可读介质中实施并可由一个或多个计算装置执行的指令(例如，本文所述的介质内容访问装置中的任一者)。一般来说，处理器(例如，微处理器)从非暂态计算机可读介质(例如，存储器等)接收指令并执行这些指令，从而执行一个或多个过程，其包含本文所述过程中的一或多者。

计算机可读介质可为由通用或专用计算机系统可访问的任何可用介质。存储计算机可执行指令的计算机可读介质为非暂态计算机可读存储介质(装置)。携带计算机可执行指令的计算机可读介质为传输介质。因此，例如但不限于，示例实施例可以包括至少两种明显不同种类的计算机可读介质：非易失性计算机可读存储介质(装置)和传输介质。

非易失性计算机可读存储介质(装置)包含RAM、ROM、EEPROM、CD-ROM、固态驱动器(“SSD”)(例如，基于RAM)、闪存、相变存储器(“PCM”)、其他类型的存储器、其他光盘存储、磁盘存储或者其他磁存储装置或者能用于以计算机可执行指令或者数据结构的形式存储所需程序代码装置并且可由通用或者专用计算机访问的任何其他介质。

“网络”被定义为允许在计算机系统和/或模块和/或其他电子装置之间传输电子数据的一个或多个数据链路。当通过网络或者另一通信连接(或者硬连线、无线、或者硬连线或无线的组合)将信息传送或提供至计算机时，计算机，计算机将该连接适当地视为传输介质。传输介质可以包括能用于以计算机可执行指令或数据结构的形式传送期望程序代码装置并且可由通用或专用计算机访问的网络和/或数据链路。还应在计算机可读介质的范围内包括以上内容的组合。

此外，当到达各种计算机系统组件时，具有计算机可执行指令或数据结构形式的程序代码装置可从传输介质自动传送到非暂态计算机可读存储介质(装置)(或反之亦然)。例如，通过网络或数据链路接收的计算机可执行指令或数据结构可以被缓存在网络接口模块(例如，“NIC”)内的RAM中，并且然后最终传送到计算机系统RAM和/或在计算机系统的更少的易失性计算机存储介质(装置)。因此，应理解，非暂态计算机可读存储介质(装置)可以被包含在也(或者甚至主要)利用传输介质的计算机系统组件中。

计算机可执行指令包括例如当在处理器被执行时，使通用计算机、专用计算机、或者专用处理装置来执行特定功能或功能组的指令和数据。在一些实施例中，在通用计算机上执行计算机可执行指令以将通用计算机变成实现本公开的要素的专用计算机。计算机可执行指令可为例如二进制的、中间格式指令，诸如汇编语言或者甚至源代码。尽管本主题以结构特征和方法行为专用的语言来描述，但是应理解，在所附权利要求内限定的主题不必局限于上述的特征或动作。确切地说，公开了所描述的作为实现权利要求的示例形式的特征和行为。

本领域的技术人员应理解，可在具有许多类型的计算机系统配置的网络计算环境中实施本公开，该计算机系统配置包括个人计算机、台式计算机、便携式计算机、消息处理器、手持式装置、多处理器系统、基于微处理器或可编程消费电子、网络PC、微型计算机、大型计算机、移动电话、PDA、平板计算机、传呼机、路由器、交换机等等。本公开也可在分布式系统环境中实施，其中，通过网络链接(或者通过硬连线数据链路、无线数据链路或者通过硬连线和无线数据链路的组合)的本地和远程计算机系统两者均执行任务。在分布式系统环境中，程序模块可位于本地和远程存储器存储装置两者中。

本公开的实施例也可以在云计算环境中实现。在本说明书以及所附的权利要求中，“云计算”被定义为使其能够对可配置的计算资源的共享池进行按需网络访问的模型。例如，可以在市场中采用云计算来提供方便而普遍存在的对可配置的计算资源的共享池的按需访问。可配置的计算资源的共享池可以通过虚拟化快速地供应并且用较少的管理工作或服务提供者交互来释放，并且规模相应地缩小。

云计算模型可由各种特征组成，诸如，按需获取自助式服务、广阔的互联网访问、资源池、快速伸缩和可度量的服务等等。云计算模型也可以暴露各种服务模型，诸如，软件即服务(“SaaS”)、平台即服务(“PaaS”)、以及基础结构即服务(“IaaS”)。也可以使用不同的部署模型诸如私有云、社区云、公共云、混合云等来部署云计算模型。在该说明书和权利要求中，“云计算环境”是采用云计算的环境。

图10示出可被配置成执行上述过程中的一或多者的示例性计算装置1000的框图形式。应理解，客户端装置104和204、服务器装置110和/或206的服务器装置以及支付网络115和/或215的服务器装置可各自包括数据计算装置1000的实施方案。如图10所示，计算装置可以包括处理器1002、内存1004、存储装置1006、I/O接口1008和通信接口1010。尽管在图10中示出了示例性的计算装置1000，但图10中所示的组件并不是限制性的。在其他实施例中，可使用另外的或替代组件。此外，在某些实施例中，计算装置1000可以包括比图10所示更少的组件。现在将更详细地描述图10所示的计算装置1000的组件。

在具体实施方式中，处理器1002包括用于执行诸如构成计算机程序的指令的硬件。例如但不限于，为执行指令，处理器1002可从内部寄存器、内部高速缓存、内存1004或存储装置1006检索(或读取)指令并解码和执行该指令。在具体实施例中中，处理器1002可包括用于数据、指令或地址的一个或多个内部高速缓存。例如但不限于，处理器1002可包括一个或多个指令高速缓存、一个或多个数据高速缓存以及一个或多个转换后备缓冲器(TLB)。在指令高速缓存中的指令可为在内存1004或存储1006中的指令的副本。

计算装置1000包括耦接至处理器1002的内存1004。内存1004能用于存储数据、元数据、以及由处理器执行的程序。内存1004可包含一个或多个易失性存储器和非易失性存储器，诸如，随机存取存储器(“RAM”)、只读存储器(“ROM”)、固态磁盘(“SSD”)、闪存、相变存储器(“PCM”)、或其他类型的数据存储。内存1004可为内部存储器或分布式存储器。

计算装置1006包括存储装置，其包括用于存储数据或指令的存储。例如但不限于，存储装置1006可以包括如上所述的非暂态存储介质。存储装置1006可包含硬盘驱动器(HDD)、软盘驱动器、闪存、光盘、磁光盘、磁带、或者通用串行总线(USB)驱动器或者它们中两个或更多的组合。在适当的情况下，存储介质1006可包括可移除的或者不可移除的(或固定的)介质。存储装置1006可在计算装置1000内部或外部。在具体实施例中，存储装置1006为非易失性固态存储器。在具体实施例中，存储1006包括只读存储器(ROM)。在适当的情况下，该ROM可为掩码编程ROM、可编程ROM(PROM)、可擦除PROM(EPROM)、电可擦除PROM(EEPROM)、电可改写ROM(EAROM)或闪存或这些的两个或更多个的组合。

计算装置1000也包括一个或多个输入或输出(“I/O”)装置/接口1008，这些装置/接口1008被设置成允许用户向计算装置提供输入、接收输出以及至和自计算装置1000传送数据。I/O装置/接口1008可包括鼠标、小键盘或键盘、触摸屏、相机、光学扫描仪、网络接口、调制解调器、其他已知的I/O装置或此些I/O装置/接口1008的组合。可以用触控笔或手指激活触摸屏。

I/O装置/接口1008可包括用于向用户呈现输出的一个或多个装置，包括但不限于，图形引擎、显示器(例如，显示屏)、一个或多个输出驱动器(例如，显示驱动器)、一个或多个音频扬声器和一个或多个音频驱动器。在某些实施例中，装置/接口1008被配置成向用于向用户呈现的显示器提供图形数据。图形数据可表示一个或多个图形用户界面和/或可用于具体实施的任何其他图形内容。

计算装置1000可进一步包括通信接口1010。通信接口1010可以包括硬件、软件或者这两者。通信接口1010可以提供用于在计算装置900和一个或多个其他计算装置或网络之间通信的一个或多个接口(诸如例如，基于包的通信)。作为实例并非限制性方式，通信接口1010可包括用于与以太网或其他基于有线网络通信的网络接口控制器(NIC)或网络适配器，或用于与无线网络(诸如WI-FI网络)通信的无线NIC(WNIC)或无线适配器。

本公开内容考虑了任何合适的网络和它的任何合适的通信接口1010。例如但不限于，计算装置1000可与自组织网络、个人局域网(PAN)、局域网(LAN)、广域网(WAN)、城域网(MAN)或互联网的一个或多个部分或它们的两个或更多个的组合通信。这些网络中的一或多者的一个或多个部分可以是有线或无线的。作为实例，计算机系统1100可与无线PAN(WPAN)(诸如，BLUETOOTH WPAN)、WI-FI网络、WI-MAX网络、蜂窝电话网络(诸如，全球移动通信系统(GSM)网络)或其他合适的无线网络或者这些的组合通信。在适当情况下，计算装置1000可包括用于这些网络中的任何一个的任何合适的通信接口1010。

计算装置1000可进一步包括总线1012。总线1012可包括将计算装置1000的组件彼此耦接的硬件、软件或这两者。例如但不限于，总线1012可包括加速图形端口(AGP)或其他图形总线、增强工业标准架构(EISA)总线、前侧总线(FSB)、HYPERTRANSPORT(HT)互连、工业标准结构(ISA)总线、INFINIBAND互连、低引脚数(LPC)总线、存储器总线、微通道架构(MCA)总线、外围部件互连(PCI)总线、PCI-Express(PCIe)总线、串行高级技术附件(SATA)总线、视频电子标准协会局部(VLB)总线、或者另一合适的总线或他们的组合。

如上所述，消息系统210可以被集成为社交网络系统的一部分。社交网络系统可允许其用户(诸如个人或组织)与系统互动以及彼此互动。利用来自用户的输入，社交网络系统创建与用户相关的用户简档并在社交网络系统中存储该用户简档。用户简档可包括人口统计信息、通信信道信息和关于用户的个人兴趣的信息。通过用户输入，社交网络系统也可形成和储存该用户与该社交网络系统的其他用户之间的关系的记录，并且为促成两个用户或多个用户之间的交互提供服务(例如，海报、照片共享、活动组织、即时消息、游戏或广告)。

社交网络系统可在社交图谱中存储用户的记录和用户之间的关系，该社交图谱包括多个节点和连接该节点的多个边。节点可包括多个用户节点和多个概念节点。社交图谱的用户节点可对应于社交网络系统的用户。用户可为个体(个人用户)、实体(例如，企业、工商企业或第三方应用)或组织(例如，个体或实体)。对应于用户的用户节点可包括由用户提供的信息和由包括社交网络系统的各种系统采集的信息。

例如，用户可提供他或她的姓名、简档照片、居住城市、联系信息、出生日期、性别、婚姻状况、家庭状况、就业、教育背景、喜好、兴趣以及被包含在用户节点中的其他人口统计信息。社交图谱的每个用户节点可具有对应的网页(通常被称为简档页)。响应于包括用户姓名的请求，社交网络系统可以访问对应于用户姓名的用户节点并构建包括姓名、简档图片和与用户相关的其他信息的简档页。第一用户的简档页可向第二用户显示基于第一用户的一个或多个私有设置的第一用户的全部或部分信息以及第一用户和第二用户之间的关系。

概念节点可对应于社交网络系统的概念。例如，概念可以表示真实世界实体，诸如电影、歌曲、运动队、名人、群体、餐厅或一个地方或位置。对应于概念的概念节点的管理用户可通过提供概念的信息(例如，通过填写在线表格)来创建或更新该概念节点，从而促使社交网络系统将该信息与概念节点相关。例如但不限于，与概念相关的信息可以包含名字或头衔、一个或多个图像(例如，书的封面的图像)、网站(例如，URL地址)或联系信息(例如，电话号码、电子邮件地址)。社交图谱的每个概念节点可对应于网页。例如，响应于包含名称的请求，社交网络系统可访问对应于名称的概念节点，并且构成包含名称和与概念相关的其他信息的网页。

在一对节点之间的边可表示该对节点之间的关系。例如，两个用户节点之间的边可以表示两个用户之间的友谊。又如，社交网络系统可构建概念节点(例如，餐厅、名人)的网页(或构建的文档)，其在网页中并入一个或多个可选按钮(例如，“喜欢”、“登记”)。用户可以使用由用户的客户端装置托管的网页浏览器来访问网页并选择可选择按钮，从而促使客户端装置向社交网络系统传送在用户的用户节点和概念的概念节点之间创建边的请求，由此指示在用户和概念之间的关系(例如，用户登记到餐厅或用户“喜欢”名人)。

例如，用户可提供(或改变)他或她的居住城市、从而促使社交网络系统在对应于该用户的用户节点和对应于用户申报的他或她的居住城市的城市的概念节点之间创建边。此外，在任何两个节点之间的分开程度被定义为社交图谱从一个节点穿越到另一个节点所需的最少数量的跳跃。在两个节点之间的分开程度可以被认为是由社交图谱中的两个节点表示的用户或概念之间的相关性的量度。例如，具有由边直接连接的用户节点(即，为第一程度节点)的两个用户可被描述为“连接的用户”或“好友”。同样，具有仅通过另一用户节点连接的用户节点(即，为第二程度节点)的两个用户可被描述为“好友的好友”。

社交网络系统可支持各种应用，诸如照片共享、在线日历和事件、游戏、即时消息和公告。例如，社交网络系统也可包含媒体共享功能。而且，社交网络系统可允许用户向用户的简档页或相册中张贴照片和其他多媒体文件(通常被称为“海报”或“时间轴帖子”)，根据用户的配置私人设置，该照片和其他多媒体文件可由社交网络系统的其他用户访问。社交网络系统也可允许用户配置事件。例如，第一用户可配置具有包括事件时间和日期、事件的位置和与该事件相关的其他用户的属性的事件。邀请用户可接受事件的邀请并作出响应(诸如接受邀请或谢绝该邀请)。此外，社交网络系统可允许用户保持个人日历。类似于事件，日历条目可包括时间、日期、位置和其他用户的身份。

图11示出了社交网络系统的示例网络环境。在具体实施例中，社交网络系统1100可包括一个或多个数据存储。在具体实施例中，社交网络系统1100可存储社交图谱，其包括用户节点、概念节点和在较早描述的节点之间的边。每个用户节点可包括对应于与用户相关或描述用户的信息的一个或多个数据对象。每个概念节点可包括对应于与概念相关的信息的一个或多个数据对象。一对节点之间的每个边线可包括对应于与对应于一对节点的用户之间(或者用户与概念之间或者概念之间)的关系相关的信息的一个或多个数据对象。

在具体实施例中，社交网络系统1100可包括一个或多个托管涉及社交网络系统的操作的功能的计算装置(例如，服务器)。社交网络系统1100的用户可使用客户端装置(诸如，客户端装置1106)来访问社交网络系统1100。在具体实施例中，客户端装置1106可以通过网络1104与社交网络系统1102交互。

客户端装置1106可为台式计算机、便携式计算机、平板计算机、个人数字助理(PDA)、车内或车外导航系统、智能电话或其他蜂窝或移动电话或移动游戏装置、其他移动装置或其他合适的计算装置。客户端装置1106可执行一个或多个客户端应用，诸如网页浏览器(例如，微软视窗互联网浏览器、Mozilla Firefox、苹果的Safari、谷歌Chrome、Opera等)或通过网络1104访问和查看内容的本机或专用客户端应用(例如，用于iPhone或iPad的Facebook，用于Android的Facebook等)。

网络1104可表示网络或者网络的集合(诸如因特网、企业内部网、虚拟专用网(VPN)、局域网(LAN)、无线局域网(WLAN)、蜂窝网络、广域网(WAN)、城域网(MAN)或者两种或多种此类网络的组合)，通过该网络，客户端装置1106可访问社交网络系统1100。

尽管这些方法、系统和用户界面利用公共可用信息以及由社交网络系统的用户提供的信息这两者，但总体上此类信息的所有使用要明确服从所涉及用户的所有的隐私设置和社交网络系统的隐私政策。

在前述说明书中，本公开已参考其特定示例性实施例进行了描述。参考本文中论述的细节描述本发明的各种实施例和方面，并且附图示出各种实施例。以上的说明书和附图是本发明的例示性说明并且不应视为限制本发明。描述了很多细节以提供对本公开的各种实施例的透彻理解。

本公开可以以其他特殊形式实施而不脱离其精神和基本特征。从所有方面来看，所描述的实施例仅被视为说明性的而非限制性的。例如，可以用较少或较多的步骤/动作执行本文中描述的方法或者可以不同的顺序执行步骤/动作。此外，在此描述的步骤/行为可被重复或彼此并行执行或者与相同或类似步骤/行为的不同情况并行执行。因此，由所附权利要求而不是上述说明书指出本发明的范围。所有在含义内的变化和权利要求的等效范围均包含在它们的范围内。

Claims (26)

1.一种方法，包括：

在具有至少一个处理器的服务器装置处，接收来自与发送者相关的第一客户端装置的支付消息，所述支付消息定义从所述发送者到接收者的支付；

由所述服务器装置向第二客户端装置提供用于在所述第二客户端装置上的消息线程内显示的接收者状态消息，所述第二客户端装置与所述接收者相关，所述接收者状态消息包括与所述支付相对应的接收者交易信息；

由所述服务器装置向所述第一客户端装置提供用于在所述第一客户端装置上的消息线程内显示的发送者状态消息，所述发送者状态消息包括与所述支付相对应的发送者交易信息；

使用所述服务器装置的所述至少一个处理器识别交易的状态，通过所述交易的状态，处理从所述发送者到所述接收者的所述支付；以及

基于识别所述交易的状态，向所述第二客户端装置发送更新所述接收者状态消息内的所述接收者交易信息的状态更新。

2.根据权利要求1所述的方法，进一步包括：基于识别所述交易的状态，向所述第一客户端装置提供更新所述发送者状态消息内的所述发送者交易信息的状态更新。

3.根据权利要求1所述的方法，进一步包括：识别所述支付消息内的定义从所述发送者到所述接收者的支付的支付信息，所述支付信息包括发送者标识符、接收者标识符和支付金额。

4.根据权利要求3所述的方法，进一步包括：

在所述服务器装置处并利用所述至少一个处理器生成交易标识符；

使所述交易标识符与所识别的支付信息相关；以及

在所述发送者状态消息和所述接收者状态消息内提供所述交易标识符。

5.根据权利要求4所述的方法，进一步包括：发起处理从所述发送者到所述接收者的支付的交易，其中，发起所述交易包括从所述服务器装置向支付网络发送支付授权请求。

6.根据权利要求5所述的方法，进一步包括：

使所述支付授权请求与所述交易标识符相关；以及

其中，所述识别交易的状态，通过所述交易的状态，处理从所述发送者到所述接收者的所述支付包括：基于所述交易标识符检测来自所述支付网络的支付授权响应。

7.根据权利要求6所述的方法，其中，提供给所述第二客户端装置的状态更新促使所述第二客户端装置的消息线程内的所述接收者状态消息包括接受或拒绝所述支付的可选选项。

8.根据权利要求7所述的方法，进一步包括：

从所述第二客户端装置接收所述接收者已选择所述可选选项以拒绝所述支付的指示；以及

响应于接收到所述接收者已选择所述可选选项以拒绝所述支付的指示，取消所述交易。

9.根据权利要求8所述的方法，进一步包括：基于取消所述交易，向所述第一客户端装置提供更新所述发送者状态消息内的所述发送者交易信息以指示所述接收者拒绝所述支付的状态更新。

10.根据权利要求7所述的方法，进一步包括：

从所述第二客户端装置接收所述接收者已选择所述可选选项以接受所述支付的指示；以及

向所述支付网络发送促使所述支付金额从发送者账户扣除并存入接收者账户的转账授权请求。

11.根据权利要求10所述的方法，进一步包括：

从所述支付网络接收指示成功完成所述交易的转账授权响应；以及

基于接收到所述转账授权响应，向所述第二客户端装置发送更新所述接收者状态消息内的所述接收者交易信息以指示所述支付成功的完成状态更新。

12.根据权利要求10所述的方法，进一步包括：

从所述支付网络接收指示成功完成所述交易的转账授权响应；以及

基于接收到所述转账授权响应，向所述第一客户端装置发送更新所述发送者状态消息内的所述发送者交易信息以指示所述支付成功的完成状态更新。

13.一种系统，包括：

至少一个处理器；以及

存储有指令的至少一个非暂态计算机可读存储介质，当由所述至少一个处理器执行时，所述指令促使所述系统：

接收来自与发送者相关的第一客户端装置的支付消息，所述支付消息定义从所述发送者到接收者的支付；

提供用于在第二客户端装置上的消息线程内显示的接收者状态消息，所述接收者状态消息包括与所述支付相对应的接收者交易信息；

提供用于在所述第一客户端装置上的消息线程内显示的发送者状态消息，所述发送者状态消息包括与所述支付相对应的发送者交易信息；

识别交易的状态，通过所述交易的状态，处理从所述发送者到所述接收者的所述支付；以及

基于识别所述交易的状态，向所述第二客户端装置提供更新所述接收者状态消息内的所述接收者交易信息的状态更新。

14.根据权利要求13所述的系统，进一步包括当由所述至少一个处理器执行时使所述系统进行以下各项的指令：经由支付网络发起所述交易，其中，所述支付网络促成从发送者账户扣除支付金额并向接收者账户存入所述支付金额。

15.根据权利要求13所述的系统，其中，提供给所述第二客户端装置的更新所述接收者状态消息内的所述接收者交易信息的所述状态更新促使所述接收者状态消息包括接收者接受所述支付的可选选项。

16.根据权利要求13所述的系统，其中，提供给所述第二客户端装置更新所述接收者状态消息内的所述接收者交易信息的所述状态更新促使所述接收者状态消息包括选择存入所述支付的一个或多个账户的接收者可选选项。

17.根据权利要求13所述的系统，进一步包括当由所述至少一个处理器执行时使所述系统进行以下各项的指令：

促成处理从所述发送者到所述接收者的所述支付的所述交易，其中，促成所述交易包括：

发送使支付金额从发送者账户扣除并存入在所述非暂态计算机可读存储介质上维护的临时账户的转账请求；以及

发送使所述支付金额从所述临时账户扣除并以退款的形式存入接收者信用卡账户的退款请求。

18.一种移动装置，包括：

至少一个处理器；以及

存储有指令的至少一个非暂态计算机可读存储介质，当由所述至少一个处理器执行时，所述指令促使所述移动装置：

经由所述移动装置的显示器提供包括消息线程的图形用户界面，所述消息线程具有在与所述移动装置相关的发送者与接收者之间交换的多个电子消息，所述图形用户界面进一步包括可选支付元素；

经由所述移动装置的显示器并且响应于所述发送者与所述可选支付元素交互来提供一个或多个图形元素，以允许所述发送者指定定义从所述发送者到所述接收者的支付的支付信息；

向消息系统发送包括定义从所述发送者到所述接收者的所述支付的所述支付信息的支付消息；

从所述消息传送系统接收包括与促成所述发送者和所述接收者之间的所述支付的交易相对应的交易信息的状态消息；以及

经由所述移动装置的显示器来提供在所述图形用户界面的所述消息线程内的所述状态消息。

19.根据权利要求18所述的移动装置，进一步包括当由所述至少一个处理器执行时使所述移动装置进行以下各项的指令：经由所述移动装置的显示器来提供所述接收者已在接收者计算装置上看到接收者状态消息的指示。

20.根据权利要求19所述的移动装置，进一步包括当由所述至少一个处理器执行时使所述移动装置进行以下各项的指令：

从所述消息传送系统接收指示所述交易完成的状态更新；以及

更新所述状态消息中的所述交易信息以指示从所述发送者到所述接收者的所述支付完成。

21.一种方法，包括：

在具有至少一个处理器的服务器装置处，接收来自与发送者相关的第一客户端装置的支付消息，所述支付消息定义从所述发送者到接收者的支付；

由所述服务器装置向第二客户端装置提供用于在所述第二客户端装置上的消息线程内显示的接收者状态消息，所述第二客户端装置与所述接收者相关，所述接收者状态消息包括与所述支付相对应的接收者交易信息；

由所述服务器装置向所述第一客户端装置提供用于在所述第一客户端装置上的消息线程内显示的发送者状态消息，所述发送者状态消息包括与所述支付相对应的发送者交易信息；

使用所述服务器装置的所述至少一个处理器识别交易的状态，通过所述交易的状态，处理从所述发送者到所述接收者的所述支付；以及

基于识别所述交易的状态，向所述第二客户端装置发送更新所述接收者状态消息内的所述接收者交易信息的状态更新。

22.根据权利要求21所述的方法，进一步包括：基于识别所述交易的状态，向所述第一客户端装置提供更新所述发送者状态消息内的所述发送者交易信息的状态更新。

23.根据权利要求21或22所述的方法，进一步包括：识别所述支付消息内的定义从所述发送者到所述接收者的支付的支付信息，所述支付信息包括发送者标识符、接收者标识符和支付金额；

优选进一步包括：在所述服务器装置处并利用所述至少一个处理器生成交易标识符；

使所述交易标识符与所识别的支付信息相关；以及

在所述发送者状态消息和所述接收者状态消息内提供所述交易标识符；

优选进一步包括：发起交易以处理从所述发送者到所述接收者的所述支付，其中，发起所述交易包括从所述服务器装置向支付网络发送支付授权请求；

优选进一步包括：使所述支付授权请求与所述交易标识符相关；以及

其中，识别所述交易的状态，通过所述交易的状态，处理从所述发送者到所述接收者的所述支付包括：基于所述交易标识符检测来自所述支付网络的支付授权响应。

24.根据权利要求23所述的方法，其中，提供给所述第二客户端装置的状态更新促使所述第二客户端装置的消息线程内的所述接收者状态消息包括接受或拒绝所述支付的可选选项。

25.根据权利要求24所述的方法，进一步包括：

从所述第二客户端装置接收所述接收者已选择所述可选选项以拒绝所述支付的指示；以及

响应于接收到所述接收者已选择所述可选选项以拒绝所述支付的指示，取消所述交易；

优选进一步包括：基于取消所述交易，向所述第一客户端装置提供更新所述发送者状态消息内的所述发送者交易信息以指示所述接收者拒绝所述支付的状态更新。

26.根据权利要求24所述的方法，进一步包括：

从所述第二客户端装置接收所述接收者已选择所述可选选项以接受所述支付的指示；以及

向所述支付网络发送促使所述支付金额从发送者账户扣除并存入接收者账户的转账授权请求；

优选进一步包括：从所述支付网络接收指示成功完成所述交易的转账授权响应；以及

基于接收到所述转账授权响应，向所述第二客户端装置发送更新所述接收者状态消息内的所述接收者交易信息以指示所述支付成功的完成状态更新；

优选进一步包括：从所述支付网络接收指示成功完成所述交易的转账授权响应；以及

基于接收到所述转账授权响应，向所述第一客户端装置发送更新所述发送者状态消息内的所述发送者交易信息以指示所述支付成功的完成状态更新。