具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

本申请实施例提供的基于终端设备的收付款方法，可以适用于如图1所示的应用场景。

在如图1所示的应用场景中，每个用户分别对应一个或多个终端设备，且各终端设备均与服务器连接，各终端设备之间通过服务器实现交互，并实现收付款。

其中，服务器可基于用户标识ID对不同的用户进行区分，且对不同用户对应的一个或多个终端设备进行确定。

例如，若某用户在同一收付款流程中，或者，在同一交互过程中，前后采用多个终端设备，则服务器可以基于该用户的用户标识确定采用多个终端设备的用户为同一用户。

在相关技术中，以群组内的用户参与某聚餐之后，发起收付款为例，群组内的某用户可以通过终端设备询问该次聚餐的消费金额，为该次聚餐支付费用的用户通过终端设备输入相应的金额，其他参与该次聚餐的用户通过终端设备选择付款的业务，输入并发送携带相应金额的支付信息。

然而，为该次聚餐支付费用的用户需要手动的输入相应的金额，其他参与该次聚餐的用户也需要手动的选择付款的业务，并需要手动的输入相应的金额，过程较为繁琐，智能化偏低。

本申请的发明人经过创造性地劳动之后，得到了本申请的发明构思：根据为该次聚餐支付费用的用户的支付信息、群组内的各用户的交互信息以及群组内的各用户的位置信息确定待付款信息，用户无需进行繁琐的操作。

例如，如图2所示，基于该发明构思的方法可以包括：

S01：接收付款方的终端设备发送的询问请求，其中，询问请求用于询问待付款信息。

S02：获取收款方的终端设备的支付信息。

S03：根据支付信息、交互信息和位置信息生成待付款信息，其中，交互信息用于表征收款方和付款方的聊天内容，位置信息用于表征收款方的终端设备和付款方的终端设备各自对应的位置信息。

S04：控制收款方的终端设备输出待付款信息。

下面以具体地实施例对本申请的技术方案以及本申请的技术方案如何解决上述技术问题进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。下面将结合附图，对本申请的实施例进行描述。

根据本申请实施例的一个方面，本申请实施例提供了一种基于终端设备的收付款方法。

请参阅图3，图3为本申请另一实施例的基于终端设备的收付款方法的示意图。

如图3所示，该方法包括：

S101：将付款方的终端设备(下文简称第一终端设备)发送的询问请求，发送至收款方的终端设备(下文简称第二终端设备)，其中，询问请求用于询问待付款信息。

其中，本申请实施例的执行主体可以为服务器，且服务器与多个终端设备连接，用于实现各终端设备之间的信息交互。

其中，“付款方”、“付款方的终端设备”、“收款方”和“收款方的终端设备”是为了便于在同一收付款过程中，对收款方和付款方进行区分，以及对收款方使用的终端设备和付款方使用的终端设备进行区分，而不能理解为对用户本身的限定，以及对终端设备本身的限定。

例如，若某用户为发起收款的用户，则在该环节中，为了对该用户的收款角色与其他用户的付款角色进行区分，可以将该用户称为收款方；若该用户为付款的用户，则为了将该用户的付款角色与其他用户的收款角色进行区分，可以将该用户称为付款方。相应地，当某用户采用终端设备进行收款时，则该终端设备为收款方的终端设备(即第一终端设备)；而当该用户采用终端设备进行付款时，则该终端设备为付款方的终端设备(即第二终端设备)。

其中，终端设备(包括第一终端设备和第二终端设备)可以包括支持聊天应用，且支持收付款应用的包括显示界面的电子设备。

具体地，终端设备可以是无线终端也可以是有线终端。无线终端可以是指向用户提供语音和/或其他业务数据连通性的设备，具有无线连接功能的手持式设备、或连接到无线调制解调器的其他处理设备。无线终端可以经无线接入网(Radio Access Network，简称RAN)与一个或多个核心网设备进行通信，无线终端可以是移动终端，如移动电话(或称为“蜂窝”电话)和具有移动终端的计算机，例如，可以是便携式、袖珍式、手持式、计算机内置的或者车载的移动装置，它们与无线接入网交换语言和/或数据。再例如，无线终端还可以是个人通信业务(Personal Communication Service，简称PCS)电话、无绳电话、会话发起协议(Session Initiation Protocol，简称SIP)话机、无线本地环路(Wireless LocalLoop，简称WLL)站、个人数字助理(Personal Digital Assistant，简称PDA)等设备。无线终端也可以称为系统、订户单元(Subscriber Unit)、订户站(Subscriber Station)，移动站(Mobile Station)、移动台(Mobile)、远程站(Remote Station)、远程终端(RemoteTerminal)、接入终端(Access Terminal)、用户终端(User Terminal)、用户代理(UserAgent)、用户设备(User Device or User Equipment)，在此不作限定。可选的，上述终端设备还可以是智能手表、平板电脑等设备。

在本申请实施例中，主要以终端设备为手机为例，进行示范性地描述。且在一些实施例中，申请实施例的执行主体还可以为设置于终端设备中的收付款装置，且收付款装置可以为芯片。

在本申请实施例中，对付款方的数量不做限定，即付款方的数量可以为1个，也可以多个，且付款方可以为聊天应用中的某群组中的部分用户，也可以为聊天应用中的某群组中的全部用户，且发起询问请求的可以为付款方中的任意一个用户。

如图4所示，在一个共包括5个人的群组中，某一个用户为收款方，其他4个用户为付款方，4个付款方中的某一个用户可以通过与其对应的第一终端设备发起询问请求，以询问待付款信息，即图4中所示的“今天这顿饭多少钱”。

S102：通过第二终端设备的显示界面(下文称为第二显示界面)输出收款总金额。

其中，收款总金额是基于第二终端在预设时间段内的支付金额确定的。

同理，为了对第一终端设备的显示界面与第二终端设备的显示界面进行区分，可以将收款方的终端设备的显示界面称为第二显示界面，而将后文即将出现的付款方的终端设备的显示界面称为第一显示界面。

其中，预设时间段可以聊天记录进行确定，也可以基于需求、经验或者试验进行设定。例如，若通过聊天记录可知聚餐的时间，则根据该聚餐的时间获取相应的支付金额，并将支付金额确定为收款总金额。

也就是说，在一些实施例中，服务器可以通过获取聚餐的时间对应的支付信息，确定收款总金额。

例如，当收款方在第二显示界面上输入“总共”时，服务器确定并通过第二显示界面输出1376元。

当然，在另一些实施例中，服务器通过第二显示界面输出的收款总金额，也可以为收款方输入的。例如，收款方在读取到通过第二显示界面显示的询问请求时，可以在第二显示界面上输入收款总金额。

S103：根据收款总金额和历史记录，确定付款方和付款金额。

其中，历史记录用于表征与收付款相关的聊天内容和位置信息。

也就是说，历史记录可以从两方面体现，一方面为聊天内容的记录，另一方面为终端设备(包括第一终端设备和第二终端设备)的位置信息的记录。

在一些实施例中，S103可以具体包括：

S31：对聊天内容进行监测。

S32：对聊天内容进行解析，判断聊天内容是否涉及收付款的需求，如果是，则执行S33，如果否，则执行S31。

其中，为了能够准确地确定聊天内容是否涉及收付款的需求，可以预先对涉及收付款的需求的聊天内容进行贴标签处理。如基于需求、经验和试验等对于涉及收付款的需求的聊天内容进行贴标签处理，且针对不同的收付款的需求的场景，可以采用不同的标签。

例如，若聊天内容为“一起去XX地方吃饭”，则可对该聊天内容贴上“聚餐”标签；若聊天内容为“一起去XX地春游”，则可对该聊天内容贴上“出游”标签，等等。

值得说明地是，上述示例只是用于示范性地说明可以预先对不同的聊天内容配置不同的标签，而不能理解为对收付款的需求的场景的限定，以及对标签类型的限定。

且在一些实施例中，聊天内容可以为上下文的聊天内容，即结合上下文确定是否涉及收付款的需求，并进行贴标签处理。

且在另一些实施例中，除了如上述示例中，从收付款的需求的场景的维度对聊天内容进行贴标签处理，还可以在此基础上，为聊天内容配置时间和地址的标签。其中，时间的标签包括“明天、后台和具体日期”等；地址的标签包括“某饭店和XX路”等。

S33：确定参与收付款的预计总人数。

值得说明地是，一般而言，如果在群组中，确定出涉及收付款的需求，而没有人提出不同的意见，如不参与某次聚会或出游，则可以将群组的共有人数确定为预计总人数。

例如，基于上述示例，如收款方发起“去XX饭店吃饭”的聚餐建议时，其他用户没有不赞同，则默认为其他用户都赞同收款方的聚餐建议，则预计总人数为5个人。

当然，若在收款方发起“去XX饭店吃饭”的聚餐建议时，有一个用户不赞同，则预计总人数人4个人。当有多个用户不赞同的方法与次类似，此处不再一一列举。

这里需要说明的是，当前并没有聚餐，在该情况下，收款方还是未知，即收款方可以为5个用户中的任意一个，此处是为了便于读者理解，且便于与上下文进行结合，此处假设发起聚餐建议的用户即为收款方用户，当然，发起聚餐建议的用户也可以为其他的用户，其实现的原理相同，此处不再赘述。

S34：判断聊天内容中是否涉及位置信息，如果是，则执行S35；如果否，则执行S36。

S35：确定在某时间段都位于位置信息的用户的数量(为了与否的分支S36的用户的数量进行区分，下文称为第一数量)，并执行S37。

例如，若聊天内容中涉及位置信息，则相当于聊天内容中涉及聚餐的地址，则对5个用户(假设群组的用户都赞同该聚餐建议)在某时间段是否都位于该地址，如果是，则说明5个用户都参与了聚餐，则第一数量为5；如果某部分用户在该时间段不位于该地址，则说明该部分用户没有参与聚餐，则第一数量为在该时间段位于该地址的用户的数量，或者，第一数量为5减去没有参与聚餐的用户的数量。

S36：确定在某时间段位于某相同地址的用户的数量(为了与否的分支S35的用户的数量进行区分，下文称为第二数量)，并执行S37。

例如，若聊天内容中没有涉及位置信息，则相当于聊天内容中没有涉及聚餐的地址，则可以获取各时间段，各用户所处的地址，如果在某一时间段，5个用户都位于同一个地址，则说明5个用户在该地址进行了聚餐，则第二数量为5；如果5个用户中部分用户在该时间段，位于该地址，则说明5个用户中的部分用户参与了聚餐，则第二数量即为在该时间段位于该地址的用户的数量。

S37：判断聊天内容中是否涉及参与收付款的人数，若是，则执行S38；若否，则执行S42。

例如，尽管某部分用户参与了聚餐，但是该部分用户并不需要进行付款。如群组内的4个用户共同请另一个用户吃饭，则参与收付款的人数并不包括被请的用户。因此，为了提高确定出的付款方和付款金额的准确性和可靠性，可先对参与收款方的人数进行确定。

S38：判断参与收付款的人数与确定出的用户的数量是否相同，若是，则执行S39；若否S41，则执行。

S39：将参与付款的人数或者确定出的用户的数量确定为消费用户的数量。

S40：根据收款总金额和消费用户的数量确定各用户(包括付款方和收款方)的付款金额。

S41：将参与付款的人数确定为消费用户的数量，并执行SS40。

S42：将确定出的用户的数量确定为消费用户的数量，并执行S40。

S104：通过第二显示界面显示待付款信息。

其中，待付款信息用于表征付款方的数量的信息和/活代付款金额的信息。

例如，若收款总金额为1376元，付款方的数量为4人，而收款方也是1376元的消费者之一，因此，消费用户的数量为付款方和收款方的和，而在进行付款金额的计算时，应当将收款方也计算在内，即付款金额＝收款总金额1376元/消费用户的数量5人＝275.2元/人。

在一些实施例中，可在第二显示界面上显示消费用户的数量和平均付款金额。其中，平均付款金额即为每个消费用户对应的付款金额。如图5中所示的“4人待付款，每人275.2元”。

当然，在另一些实施例中，在对消费用户的数量和平均付款金额进行显示的同时，还可以在第二显示界面上输出付款方和付款金额。如图6中所示，对4个待付款方的相关信息(包括头像和用户名)进行显示，并显示相应的付款金额。

且在一些实施例中，在通过第二显示界面对付款方和付款方各自对应的付款金额输出的同时，可向收款方发起询问，用于确认显示的信息是否正确，如图6中所示的“确定”。

S105：接收收款方通过第二显示界面输入的确认指令，其中，确认指令用于表征收款方确认付款方和付款金额正确。

S106：根据付款方将携带付款金额的信息发送至第一终端设备。

值得说明地是，为了提高收付款的准确性，可将付款方和付款方各自对应的付款金额在第二显示界面上进行显示，由收款方进行确认。避免遗漏付款方或者添加至没有参与聚餐的付款方。

在一些实施例中，收款方可以对在第二显示界面上显示收款总金额进行点击操作，在接收到收款方的点击操作之后，可以在第二显示界面上显示付款方和付款方各自对应的付款金额。

例如，当第二显示界面如图5所示时，收款方可点击“总共1376元”之后，进入至图6所示的显示界面，且在接收到收款方触发的“确定”后，向第一终端设备将携带付款金额的信息。

也就是说，在本申请实施例中，第二终端设备可以在经收款方确认后，将携带付款金额的信息发送至第一终端设备，也可以直接将携带付款金额的信息发送至第一终端设备。

基于上述示例可知，付款方可能为一个，也可能为多个，在该步骤中，可通过获取各付款方的第二终端设备的标识ID，并基于标识ID向各第二终端设备发送携带付款金额的信息。

S107：通过第一显示界面输出携带付款金额的信息。

结合图7可知，可在第一显示界面上显示“您需要支付275.2元”。

且在一些实施例中，还可以在第一显示界面上显示总金额，如图7中所示的“总共1376元”。

当然，在另一些实施例中，还可以在第一显示界面上显示总付款人数，如“总共1376元，付款人数5人”(图中未示出)。

S108：通过第一显示界面输出携带付款金额的支付界面。

值得说明地是，在一些实施例中，可以直接在第一显示界面上输出支付界面。

在另一些实施例中，用户可通过点击第一显示界面上显示的“您需要支付275.2元”，触发第一线上界面输出支付界面。

其中，支付界面具体可参阅图8。

S109：接第一终端设备发送的支付指令，执行支付操作。

例如，如图8所示，当付款方点击支付界面的“确定”时，第一终端设备向服务器发送指令指令，服务器执行支付操作。

请参阅图9，图9为本申请另一实施例的基于终端设备的收付款方法的示意图。

如图9所示，该方法包括：

S201：将第一终端设备发送购买需求信息发送至第二终端设备。

其中，购买需求信息用于表征付款方购买商品的相关信息，如购买商品的名称、型号和数量等中的一种或多种。

值得说明地是，由于购买需求信息也涉及收付款的需求，而基于上述示例可知，可以对涉及收付款的需求的聊天内容进行贴标签处理，则在本申请实施例中，针对购买商品的场景，可以对聊天内容贴上“代购”标签，等等。同理，也可以为聊天内容配置地址的标签，还可以配置产品的标签，等等。

例如，针对第一终端设备发送的“你要去XX国吗？帮我买XXX灯”，可以将该聊天内容贴上“代购”标签，并配置产品的标签“XXX灯”，并配置地址的标签“XX国”。其中，具体的显示界面可以参阅图10。

S202：通过第二终端设备输出购买反馈信息，其中，购买反馈信息中携带待转换金额。

其中，待转换金额用于表征通过XX国的货币计量单位表示的金额。

例如，若XX国的货币计量单位为美元，则待转换金额为X美元。

基于上述示例可知，在本申请实施例中，购买反馈信息也可以基于第二终端在预设时间段内的支付金额确定。

也就是说，在一些实施例中，服务器可以通过获取收款方的支付信息，确定购买反馈信息。

例如，当收款方在第二显示界面上输入“买到了”时，服务器确定并通过第二显示界面输出42.5美元。具体可参阅图11。

当然，在另一些实施例中，服务器通过第二显示界面输出的收款总金额，也可以为收款方输入的。例如，当收款方为付款方买到XXX灯时，可在第二显示界面上输入购买反馈信息。例如，“我今天买到了，42.5美元”。

S203：获取第二终端设备的位置信息(下文称为第二位置信息)，并获取第一终端设备的位置信息(下文称为第一位置信息)。

其中，第一位置信息和第二位置信息用于，对第一终端设备和第二终端设备的位置进行区分，而不能理解为位置信息本身的限定。

具体地，服务器获取第一位置信息和第二位置信息的方式有多种，本申请不做限定。

以服务器获取第二位置信息为例：

在一些实施例中，服务器可以基于聊天内容确定第二位置信息。如以图10所示的聊天内容为基础，服务器对“你要去XX国吗？帮我买XXX灯。”进行解析可知，第二位置信息为XX国。

在另一些实施例中，服务器可以由设置于第二终端设备上的传感器对第二位置信息进行采集。其中，传感器包括具有定位功能的传感器，如全球定位系统(GlobalPositioning System，GPS)等。

在另一些实施例中，服务器也可以采集收款方的行程信息，并根据行程信息确定第二位置信息。其中，行程信息用于表征收款方出行相关的信息，如行程信息可以包括付款方通过第二终端设备购买的飞机票的信息，也可以包括收款方设置于第二终端设备的出行日志，等等。

例如，若行程信息为付款方通过第二终端设备购买的飞机票的信息，则飞机票的目的地的位置信息即为第二位置信息。

同理，若行程信息为出行日志，则出行日志中的目的地的位置信息即为第二位置信息。

以服务器获取第一位置信息为例：

在一些实施例中，服务器可以基于聊天内容确定第一位置信息。如以图10所示的聊天内容为基础，服务器对“你要去XX国吗？帮我买XXX灯。”进行解析可知，第二位置信息为XX国，而该聊天内容生成的时刻，第二终端设备所处的位置信息即为第一位置信息。

在另一些实施例中，服务器也可以根据行程信息确定第一位置信息。基于上述示例，若行程信息为付款方通过第一终端设备购买的飞机票的信息，则第一位置信息为飞机票的起始地的位置信息。若行程信息为出行日志，则出行日志中的起始地的位置信息即为第一位置信息。

在另一些实施例中，服务器也可以根据在预设时间内的位置信息中，选择停留时间最长的位置信息确定为第一位置信息。

S204：根据第一位置信息和第二位置信息对待转换金额进行转换，生成与第一位置信息对应的待支付金额。

其中，待支付金额用于表征通过第一位置信息所处国的货币计量单位表示的金额。

具体地，服务器可以基于第一位置信息和第二位置信息，获取两个位置信息之间的货币兑换率，并根据货币兑换率对待转换金额进行兑换计算，生成待支付金额。

例如，若第一位置信息所处国的货币计量单位为人民币，则待支付金额为XX元人民币。

在一些实施例中，服务器在确定出待支付金额之后，可以通过第二显示界面对待支付金额进行显示。具体显示界面可参阅图11。

如图11所示，购买反馈信息为“我今天买到了，42.5美元”，“42.5美元”即为待转换金额。第二显示界面在对“我今天买到了，42.5美元”的同时，还可以对待支付金额“275.2元人民币”进行显示。

S205：将携带待支付金额的购买反馈信息发送至第一终端设备。

在一些实施例中，可以在收款方点击第二显示界面上的“我今天买到了，42.5美元”时，服务器将携带待支付金额的购买反馈信息发送至第一终端设备。

其中，购买反馈信息中还可以包括待转换金额，即购买反馈信息中既包括待支付金额，还包括待转换金额。

S206：通过第一显示界面对携带待支付金额的购买反馈信息进行显示。

当然，在一些实施例中，通过第一显示界面对携带待支付金额的反馈信息进行显示时，还可以对待转换金额进行显示。具体可参阅图12，如图12所示，在第一终端设备上，对待支付金额“275.2元人民币”进行显示时，还可以对待转换金额“42.5美元”进行显示。

值得说明地是，本申请对待支付金额的显示位置和待转换金额的显示位置不进行限定，即可以如图12中的显示方式对待支付金额和待转换金额进行显示，也可以将待支付金额和待转换金额的显示位置进行调换。

S207：通过第一显示界面输出携带待支付金额的支付界面。

值得说明地是，在一些实施例中，可以直接通过第一显示界面输出支付界面。

在一些实施例中，付款方可通过点击第一显示界面上输出的“我今天买到了，275.2元”，触发在第一显示界面上输出支付界面。

其中，支付界面具体可参阅图13。

S208：接收第一终端设备发送的支付指令，执行支付操作。

例如，如图13所示，当付款方点击支付界面的“确定”时，服务器执行支付操作。

请参阅图14，图14为本申请另一实施例的基于终端设备的收付款方法的示意图。

如图14所示，该方法包括：

S301：监听第一终端设备发送至第二终端设备的购买需求信息。

基于上述示例可知，购买需求信息可以用于表征付款方的购买商品的相关信息，如购买商品的名称、型号和数量等中的一种或多种。其中，在本申请实施例中，购买需求信息包括购买商品的名称、型号和数量等中的多种，如购买需求信息中既包括购买商品的名称，又包括数量。

值得说明地是，购买需求信息可以包括一次购买经历中的一种或多种购买需求。其中，一次购买经历可以用于表征完成一次购买的时长。也就是说，购买需求信息可以为预设时长内付款方购买的产品的名称和购买产品的数量等的需求。且预设时长可以基于需求、经验和试验等进行设定。

例如，可以设置购买需求信息的购买意图标签，当付款方发起的聊天内容中包括购买意图标签的内容，如“卖”和“多少钱”等，则说明付款方存在购买需求，则第二终端设备对聊天内容开启监听。

如图15所示，当付款方在第一显示界面输入“XX面膜怎么卖”时，服务器确定出该聊天内容中包括购买意图标签的内容，则服务器对聊天内容开启监听。

在一些实施例中，可以将付款结束的时间点作为预设时长的终点时刻，即第二终端设备结束对聊天内容的监听。

在另一些实施例中，也可以将生成待付款金额的时间点作为预设时长的终点时刻，即第二终端设备结束对聊天内容的监听。

S302：通过第一显示界面输出购买需求信息对应的支付信息。

基于上述示例可知，购买需求信息可以为预设时长内，付款方需要购买的产品名称和购买的产品数量等。则在一些实施例中，若购买需求信息为某一种产品的购买需求，且根据购买需求信息确定出的购买数量为1，则服务器获取预存的与购买需求信息的产品名称的价格信息，并将该金额确定为支付信息，并通过第一显示界面输出该支付信息。

在一些实施例中，可以构建商品名称与价格之间的映射关系，和/或，构建商品图片与价格之间的映射关系，当监听到第一终端设备发送的购买需求信息时，根据购买需求信息中的商品名称或者商品图片、与映射关系，确定价格。

例如，基于图15可知，根据购买需求信息客可知，付款方的产品需求为XX面膜，则服务器获取XX面膜的价格信息52.5元一盒，则通过第一显示界面输出52.5元一盒，具体可参阅图16。

当然，另一些实施例中，也可以支付信息也可以为收款方通过第二显示界面输入的。

上述示例示范性地列举了若付款方的购买需求信息包括一种产品，且数量为1个的情况，对购买需求信息包括包括一种产品，且数量为多个，如数量5个为例进行阐述如下。

如图17所述，若付款方在第一显示界面输入“5盒XX面膜多少钱”，则服务器获取XX面膜的单价52.5元，并通过单价52.5元*数量5盒确定支付信息262.5元。且如图17所示，还可对单价进行显示。

S303：接收第一终端设备和/或第二终端设备发送的结算指引信息。

其中，结算指引信息用于表征购买需求信息已经结束，即付款方的购买需求结束。

在一些实施例中，也可以设置购买意图结束的购买结束标签，当付款方和/或收款方输入的聊天内容中包括购买意图结束标签的内容，如“总共”和“共计”等，则说明付款方和/或收款方输入的为结算指引信息。

也就是说，在一些实施例中，结算指引信息可以为如图18所示的“我买五盒面膜，两支洗面奶，总共多少钱”。

在另一些实施例中，结算指引信息可以为如图19所示的“总共”。

S304：根据购买需求信息对应的聊天内容生成待支付金额。

其中，购买需求信息对应的聊天内容用于表征，从服务器收到购买需求信息至第接收到结算指引信息期间的聊天内容。

如图19所示，当收款方输入结算指引信息时，即“总共”时，服务器根据聊天内容计算待支付金额，待支付金额＝52.5*5+38*2＝338.5元。

在本申请实施例中，收款方无需进行计算，由第二终端设备基于聊天内容进行计算，并将计算得到的待支付金额进行显示。

S305：通过第一显示界面对待支付金额进行显示。

在一些实施例中，服务器在生成待支付金额之后，可直接通过第一显示界面进行显示。

在另一些实施例中，服务器在生成待支付金额之后，也可以通过第二显示界面进行显示，并在接收到第二终端设备的“发送”指令时，将待支付金额发送至第一终端设备，并通过第一显示界面进行显示。

其中，显示界面具体可参阅图20。

S306：通过第一显示界面输出携带待支付金额的支付界面。

值得说明地是，在一些实施例中，可以直接通过第一显示界面输出支付界面。

在一些实施例中，付款方可通过点击第一显示界面输出的“总共338.5元”，触发在第一显示界面上输出支付界面。

其中，支付界面具体可参阅图21。

S307：接收第一终端设备发送的支付指令，执行支付操作。

例如，如图21所示，当付款方点击支付界面的“确定”时，第一终端设备向服务器发送指令指令，服务器执行支付操作。

根据本申请实施例的另一个方面，本申请实施例还提供了一种用于执行上述任一实施例所述方法的基于终端设备的收付款装置。

请参阅图22，图22为本申请实施例的基于终端设备的收付款装置的示意图。

如图22所示，该装置包括：

接收模块11，用于接收付款方的终端设备发送的询问请求，其中，所述询问请求用于询问待付款信息；

获取模块12，用于获取收款方的终端设备的支付信息；

第一生成模块13，用于根据所述支付信息、交互信息和位置信息生成所述待付款信息，其中，所述交互信息用于表征所述收款方和所述付款方的聊天内容，所述位置信息用于表征所述收款方的终端设备和所述付款方的终端设备各自对应的位置信息；

第一控制模块14，用于控制所述收款方的终端设备输出所述待付款信息。

在一些实施例中，所述第一控制模块14还用于，控制所述收款方的终端设备输出所述支付信息；

所述第一生成模块13用于，若收到所述收款方的终端设备发送的第一确认消息，则根据所述支付信息、所述交互信息和所述位置信息生成所述待付款信息，其中，所述第一确认消息用于表征所述收款方对所述支付信息的确认。

在一些实施例中，所述第一控制模块14用于，控制所述收款方的终端设备输出所述询问请求；

所述获取模块12用于，若接收到所述收款方的终端设备的第一结算指引指令，则获取所述收款方的终端设备的支付信息，其中，所述第一结算指引指令用于表征所述收款方通过所述收款方的终端设备对待付款信息进行输入。

在一些实施例中，所述第一生成模块13用于，根据所述交互信息确定参与收付款的预计总人数，根据所述预计总人数和所述位置信息确定参与收付款的实际总人数，根据所述支付信息和实际总人数生成所述待付款信息。

在一些实施例中，所述第一生成模块13用于，若所述收款方的终端设备对应的位置信息，与所述付款方的终端设备对应的位置信息，为采用不同货币的两个位置信息，根据所述支付信息转换为所述付款方的终端设备的位置信息的支付信息；

根据所述交互信息和转换后的支付信息生成所述待付款信息；或者，根据所述交互信息、所述支付信息和转换后的支付信息生成所述待付款信息。

结合图22可知，在一些实施例中，所述装置还包括：

所述接收模块11用于，接收所述付款方的终端设备发送的购买需求信息，其中，所述购买需求信息包括包括至少一种商品的购买需求；

第二生成模块15，用于根据所述至少一种商品对应的支付信息生成商品付款信息；

第二控制模块16，用于控制所述收款方的终端设备输出所述商品付款信息。

在一些实施例中，所述接收模块11还用于，若所述购买需求信息为多条，接收所述收款方的终端设备或所述付款方的终端设备发送的第二结算指引指令，其中，所述第二结算指引指令用于表征对多条所述购买需求信息进行总结算；

所述第二生成模块15用于，根据各所述购买需求信息对应的商品付款信息生成所述待付款信息；

所述第二控制模块16用于，控制所述收款方的终端设备输出所述待付款信息。

结合图22可知，在一些实施例中，所述装置还包括：

第三控制模块17，用于控制所述付款方的终端设备输出所述待付款信息。

在一些实施例中，所述第三控制模块17用于，若收到所述收款方的终端设备发送的第二确认消息，控制所述付款方的终端设备输出所述待付款信息，其中，所述第二确认消息用于表征所述收款方对所述付款信息的确认。

在一些实施例中，所述第三控制模块17用于，控制所述付款方的终端设备输出与所述待付款信息对应的支付界面。

根据本申请实施例的另一个方面，本申请实施例还提供了一种芯片，上述基于终端设备的收付款装置也可以理解成是一种芯片。

请参阅图23，图23为本申请实施例的芯片的示意图。

如图23所示，芯片包括：

输入接口31，用于获取付款方的终端设备发送的询问请求；

逻辑电路32，用于执行如上任一实施例所述的方法，得到待付款信息；

输出接口33，用于将所述待付款信息发送至收款方的终端设备。

当然，在一些实施例中，输出接口33还可以用于，将所述待付款信息发送至付款方的终端设备。

根据本申请实施例的另一个方面，本申请实施例还提供了一种计算机程序产品，当所述计算机程序产品在处理器上运行时，上述通信装置对应的方法被执行，或者，如上述网络侧设备对应的方法被执行。

根据本申请实施例的另一个方面，本申请实施例还提供了一种计算机存储介质，所述计算机存储介质上存储有计算机指令，当所述计算机指令在被处理器运行时，如上述通信装置对应的方法被执行，或者，如上述网络侧设备对应的方法被执行。

根据本申请实施例的另一个方面，本申请实施例还提供了一种收付款系统，所述系统包括：

付款方的终端设备，用于向收付款装置发送询问请求，其中，所述询问请求用于询问待付款信息；

所述收付款装置，用于执行上述任一实施例所述的方法；

收款方的终端设备，用于输出待付款信息。

其中，收付款装置即为上述示例中的基于终端设备的收付款装置。

根据本申请实施例的另一个方面，本申请实施例还提供了一种电子设备。

请参阅图24，图24为本申请实施例的电子设备的示意图。

其中，电子设备旨在表示各种形式的数字计算机，诸如，膝上型计算机、台式计算机、工作台、个人数字助理、服务器、刀片式服务器、大型计算机、和其它适合的计算机。电子设备还可以表示各种形式的移动装置，诸如，个人数字处理、蜂窝电话、智能电话、可穿戴设备和其它类似的计算装置。本文所示的部件、它们的连接和关系、以及它们的功能仅仅作为示例，并且不意在限制本文中描述的和/或者要求的本申请的实现。

如图24所示，该电子设备包括：一个或多个处理器501、存储器502，以及用于连接各部件的接口，包括高速接口和低速接口。其中，存储器502和处理器501可以通过接口连接，也可以集成在一起。各个部件利用不同的总线互相连接，并且可以被安装在公共主板上或者根据需要以其它方式安装。处理器可以对在电子设备内执行的指令进行处理，包括存储在存储器中或者存储器上以在外部输入/输出装置(诸如，耦合至接口的显示设备)上显示GUI的图形信息的指令。在其它实施方式中，若需要，可以将多个处理器和/或多条总线与多个存储器和多个存储器一起使用。同样，可以连接多个电子设备，各个设备提供部分必要的操作(例如，作为服务器阵列、一组刀片式服务器、或者多处理器系统)。图24中以一个处理器501为例。

存储器502即为本申请所提供的计算机存储介质。其中，所述存储器存储有可由至少一个处理器执行的指令，以使本申请所提供的基于终端设备的收付款方法被执行。本申请的计算机存储介质存储计算机指令，使得本申请所提供的基于终端设备的收付款方法被执行。

存储器502作为一种计算机存储介质，可用于存储非瞬时软件程序、非瞬时计算机可执行程序以及模块。处理器501通过运行存储在存储器502中的非瞬时软件程序、指令以及模块，从而执行各种功能应用以及数据处理。

存储器502可以包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需要的应用程序；存储数据区可存储根据电子设备的使用所创建的数据等。此外，存储器502可以包括高速随机存取存储器，还可以包括非瞬时存储器，例如至少一个磁盘存储器件、闪存器件、或其他非瞬时固态存储器件。在一些实施例中，存储器502可选包括相对于处理器501远程设置的存储器，这些远程存储器可以通过网络连接至电子设备。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

电子设备还可以包括：输入装置503和输出装置504。处理器501、存储器502、输入装置503和输出装置504可以通过总线或者其他方式连接，图24中以通过总线连接为例。

输入装置503可接收输入的数字或字符信息，以及产生与电子设备的用户设置以及功能控制有关的键信号输入，例如触摸屏、小键盘、鼠标、轨迹板、触摸板、指示杆、一个或者多个鼠标按钮、轨迹球、操纵杆等输入装置。输出装置504可以包括显示设备、辅助照明装置(例如，LED)和触觉反馈装置(例如，振动电机)等。该显示设备可以包括但不限于，液晶显示器(LCD)、发光二极管(LED)显示器和等离子体显示器。在一些实施方式中，显示设备可以是触摸屏。

此处描述的系统和技术的各种实施方式可以在数字电子电路系统、集成电路系统、专用ASIC(专用集成电路)、计算机硬件、固件、软件、和/或它们的组合中实现。这些各种实施方式可以包括：实施在一个或者多个计算机程序中，该一个或者多个计算机程序可在包括至少一个可编程处理器的可编程系统上执行和/或解释，该可编程处理器可以是专用或者通用可编程处理器，可以从存储系统、至少一个输入装置、和至少一个输出装置接收数据和指令，并且将数据和指令传输至该存储系统、该至少一个输入装置、和该至少一个输出装置。

这些计算程序(也称作程序、软件、软件应用、或者代码)包括可编程处理器的机器指令，并且可以利用高级过程和/或面向对象的编程语言、和/或汇编/机器语言来实施这些计算程序。如本文使用的，术语“机器可读介质”和“计算机可读介质”指的是用于将机器指令和/或数据提供给可编程处理器的任何计算机程序产品、设备、和/或装置(例如，磁盘、光盘、存储器、可编程逻辑装置(PLD))，包括，接收作为机器可读信号的机器指令的机器可读介质。术语“机器可读信号”指的是用于将机器指令和/或数据提供给可编程处理器的任何信号。

为了提供与用户的交互，可以在计算机上实施此处描述的系统和技术，该计算机具有：用于向用户显示信息的显示装置(例如，CRT(阴极射线管)或者LCD(液晶显示器)监视器)；以及键盘和指向装置(例如，鼠标或者轨迹球)，用户可以通过该键盘和该指向装置来将输入提供给计算机。其它种类的装置还可以用于提供与用户的交互；例如，提供给用户的反馈可以是任何形式的传感反馈(例如，视觉反馈、听觉反馈、或者触觉反馈)；并且可以用任何形式(包括声输入、语音输入或者、触觉输入)来接收来自用户的输入。

可以将此处描述的系统和技术实施在包括后台部件的计算系统(例如，作为数据服务器)、或者包括中间件部件的计算系统(例如，应用服务器)、或者包括前端部件的计算系统(例如，具有图形用户界面或者网络浏览器的用户计算机，用户可以通过该图形用户界面或者该网络浏览器来与此处描述的系统和技术的实施方式交互)、或者包括这种后台部件、中间件部件、或者前端部件的任何组合的计算系统中。可以通过任何形式或者介质的数字数据通信(例如，通信网络)来将系统的部件相互连接。通信网络的示例包括：局域网(LAN)、广域网(WAN)和互联网。

计算机系统可以包括客户端和服务器。客户端和服务器一般远离彼此并且通常通过通信网络进行交互。通过在相应的计算机上运行并且彼此具有客户端-服务器关系的计算机程序来产生客户端和服务器的关系。

应该理解，可以使用上面所示的各种形式的流程，重新排序、增加或删除步骤。例如，本申请中记载的各步骤可以并行地执行也可以顺序地执行也可以不同的次序执行，只要能够实现本申请的技术方案所期望的结果，本文在此不进行限制。

上述具体实施方式，并不构成对本申请保护范围的限制。本领域技术人员应该明白的是，根据设计要求和其他因素，可以进行各种修改、组合、子组合和替代。任何在本申请的精神和原则之内所作的修改、等同替换和改进等，均应包含在本申请保护范围之内。