CN109583860A - 一种基于联合支付的交易变更方法和装置 - Google Patents

Abstract

本申请提供一种基于联合支付的交易变更方法和装置。在联合支付交易完成后可对该已完成的交易提出交易变更，重新选择参与方并自动计算以完成新旧参与方之间的金额转移，避免参与方之间人工一对一进行金额调整，提升用户体验。

Description

一种基于联合支付的交易变更方法和装置

技术领域

本说明书涉及互联网技术领域，尤其涉及一种基于联合支付的交易变更方法和装置。

背景技术

现代生活中，多人进行一次社交的总花费往往需要由大家共同分担，也可以称之为联合支付，以平均分担(AA制)进行举例，当前的电子钱包应用(支付宝钱包，微信支付等)一般都具备AA收款的功能，现有的AA收款功能是由一名用户向商户先支付全量款项，再发起AA收款，由发起方在群组内选择其他响应方并等待其他响应方进行验证确认后将均分后的款项付给自己。

当前方式存在缺点是，参与人员的选择只能进行一次，如果多选或者少选了参与方，则各个参与方支付金额的重新调整会十分麻烦，只能人工一对一进行，用户体验较差。

发明内容

针对上述技术问题，本说明书实施例提供一种基于联合支付的交易变更方法和装置，技术方案如下：

根据本说明书实施例的第一方面，提供一种基于联合支付的交易变更方法，该方法包括：

接收针对已完成联合支付交易的交易变更请求，所述联合支付交易为多个参与方联合平均支付的单笔交易，所述交易变更请求为对所述联合支付交易的参与方变更请求；

获取所述已完成联合支付交易中包含的原参与方，获取所述交易变更请求中包含的新参与方，根据所述原参与方与所述新参与方确定新增参与方，减少参与方和剩余原参与方；

根据预设的分配算法计算所述新增参与方，所述减少参与方和所述剩余原参与方应支付/应退回金额，按照计算结果完成各个参与方之间的金额转移。

根据本说明书实施例的第二方面，提供一种基于联合支付的交易变更装置，该装置包括：

变更请求接收模块：用于接收针对已完成联合支付交易的交易变更请求，所述联合支付交易为多个参与方联合平均支付的单笔交易，所述交易变更请求为对所述联合支付交易的参与方变更请求；

参与方确定模块：用于获取所述已完成联合支付交易中包含的原参与方，获取所述交易变更请求中包含的新参与方，根据所述原参与方与所述新参与方确定新增参与方，减少参与方和剩余原参与方；

金额转移模块：用于根据预设的分配算法计算所述新增参与方，所述减少参与方和所述剩余原参与方应支付/应退回金额，按照计算结果完成各个参与方之间的金额转移。

根据本说明书实施例的第三方面，提供一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其中，所述处理器执行所述程序时实现一种基于联合支付的交易变更方法，应用于电子支付平台，所述方法包括：

接收针对已完成联合支付交易的交易变更请求，所述联合支付交易为多个参与方联合平均支付的单笔交易，所述交易变更请求为对所述联合支付交易的参与方变更请求；

获取所述已完成联合支付交易中包含的原参与方，获取所述交易变更请求中包含的新参与方，根据所述原参与方与所述新参与方确定新增参与方，减少参与方和剩余原参与方；

根据预设的分配算法计算所述新增参与方，所述减少参与方和所述剩余原参与方应支付/应退回金额，按照计算结果完成各个参与方之间的金额转移。

本说明书实施例所提供的技术方案，提供了一种基于联合支付的交易变更方法，在联合支付交易完成后可对该已完成的交易提出交易变更，重新选择参与方并自动计算以完成新旧参与方之间的金额转移，避免参与方之间人工一对一进行金额调整，提升用户体验。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本说明书实施例。

此外，本说明书实施例中的任一实施例并不需要达到上述的全部效果。

附图说明

为了更清楚地说明本说明书实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本说明书实施例中记载的一些实施例，对于本领域普通技术人员来讲，还可以根据这些附图获得其他的附图。

图1是本说明书一示例性实施例示出的基于联合支付的交易变更方法的一种流程图；

图2-3是本说明书一示例性实施例示出的发起方发起联合支付请求的一种示意图；

图4是本说明书一示例性实施例示出的联合支付方法的一种流程图；

图5-6是本说明书一示例性实施例示出的发起方发起联合支付请求的一种示意图；

图7本说明书一示例性实施例示出的基于联合支付的交易变更装置的一种示意图；

图8是本说明书一示例性实施例示出的一种计算机设备的结构示意图。

具体实施方式

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

在本说明书使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本说明书。在本说明书和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本说明书可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本说明书范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

现代生活中，多人进行一次社交的总花费往往需要由大家共同分担，也可以称之为联合支付，以平均分担(AA制)进行举例，当前的电子钱包应用(支付宝钱包，微信支付等)一般都具备AA收款的功能，现有的AA收款功能是由一名用户向商户先支付全量款项，再发起AA收款，由发起方在群组内选择其他响应方并等待其他响应方进行验证确认后将均分后的款项付给自己。

当前方式存在缺点是，需要由一名用户先全量承担全部款项，再向其他AA响应方发起AA收款，而其他AA响应方可能因为各种原因导致确认支付时间较晚，可能对承担款项的用户造成经济负担，且参与人员的选择只能进行一次，如果多选或者少选了参与方，则各个参与方支付金额的重新调整会十分麻烦，只能人工一对一进行，用户体验较差。

针对以上问题，本说明书实施例提供一种基于联合支付的交易变更方法，以及一种用于执行该方法的基于联合支付的交易变更装置，下面对本实施例涉及的基于联合支付的交易变更方法进行详细说明，参见图1所示，该方法应用于电子支付平台，可以包括以下步骤：

S101，接收针对已完成联合支付交易的交易变更请求，所述联合支付交易为多个参与方联合平均支付的单笔交易，所述交易变更请求为对所述联合支付交易的参与方变更请求；

电子支付平台即支付宝钱包，微信钱包等具备电子支付功能的软件，而电子支付平台通常具备通过搜索手机号码，扫描二维码，加入群组等形式使不同用户之间建立联系的功能。本实施例中，发起方和响应方即是互相之间具备联系的电子支付平台用户；

联合支付交易即为选择多个参与人员平均分担一笔交易。在一笔联合支付交易结束后，可能会发现多选或少选了某些参与人员，此时可发起对该已完成联合支付交易的交易变更请求，参见图2和图3，该交易变更请求的操作接口可设置在联合支付交易(AA收款)的已完成订单处，由联合支付的发起者在自身客户端对该接口进行操作以进入新参与方的选择界面，进而重新选择该联合支付交易的参与方。选择完成后，将针对该联合支付交易的，包含新参与方的交易变更请求发送给服务器。

S102，获取所述已完成联合支付交易中包含的原参与方，获取所述交易变更请求中包含的新参与方，根据所述原参与方与所述新参与方确定新增参与方，减少参与方和剩余原参与方；

以图3为例进行说明：假设已完成的联合支付交易中包含的原参与方为用户“高”，“昊”和“浩”，本次交易变更选择的新参与方为用户“高”，“昊”和“鸿”，则新增参与方为“鸿”，减少参与方为“浩”，剩余原参与方为“高”和“昊”。

需要注意的是，在一次交易变更中，可能只存在新增参与方和原参与方，不存在减少参与方，或只存在减少参与方和剩余原参与方，不存在新增参与方。计算各个参与方的应支付/应退回金额时应该对不同情况分别对待。

S103，根据预设的分配算法计算所述新增参与方，所述减少参与方和所述剩余原参与方应支付/应退回金额，按照计算结果完成各个参与方之间的金额转移。

具体地，该计算可分为三种情况，如下所述：

a)当原参与方人数量M人，新增参与方数量N人时，计算每个新增参与方的应支付金额，所述应支付金额＝(M*原人均支付金额)/(M+N)；

计算每个原参与方的应退回金额，所述应退回金额＝((M*原人均支付金额)/(M+N)*N/M。

b)当原参与方人数量M人，减少参与方数量R人时，计算每个减少参与方的应退回金额，所述应退回金额＝原人均支付金额；

计算每个剩余原参与方的额外应支付金额，所述额外应支付金额＝(M*原人均支付金额)/(M-R)-原人均支付金额。

c)当原参与方人数量M人，新增参与方数量N人，减少参与方数量R人时，计算每个减少参与方的应退回金额，所述应退回金额＝原人均支付金额；

计算每个新增参与方的应支付金额，所述应支付金额＝(M*原人均支付金额)/(M-R+N)；

针对剩余原参与方，若原人均支付金额＞(M*原人均支付金额)/(M-R+N)，则计算每个剩余原参与方的应退回金额，所述应退回金额＝(M*原人均支付金额)/(M-R+N)-原人均支付金额；

针对剩余原参与方，若原人均支付金额＜＝(M*原人均支付金额)/(M-R+N)，则计算每个剩余原参与方的额外应支付金额，所述额外应支付金额＝原人均支付金额-(M*原人均支付金额)/(M-R+N)。

另外，为了避免频繁打扰其他用户，可对每个已完成的联合支付交易添加交易变更限制。例如：每一笔已完成的联合支付订单仅允许在24小时之内，进行一次交易变更操作，已经进行过交易变更的交易订单或者超过24小时的交易订单，都不能再进行变更。

下面，对本说明书提到的联合支付交易流程进行具体说明，参见图4所示，该方法应用于电子支付平台，可以包括以下步骤：

S401，接收发起方发起的联合支付请求，所述联合支付请求中至少包括收款方信息，响应方信息与待支付总金额信息；

其中，电子支付平台接收发起方发起的联合支付请求的应用场景通常为：多个参与者通过共同聚餐，游戏等社交活动消费了一笔款项，这笔款项的具体金额即为待支付总金额，有别于现有技术由一名用户全量承担该笔总金额，本实施例可由参与者共同承担。

以通过支付宝钱包进行AA制消费(参与者平摊待支付总金额)为例对发起方发起的联合支付请求的具体过程进行说明：参见图5和图6，发起方通过使用支付宝钱包扫描商户的收款码，或由发起方打开自己的付款码，由商户进行扫描进入付款页面，在付款页面，发起方可以从多种支付方式(如银行卡，信用卡，余额，余额宝，零钱，花呗等等方式)中选择创建AA支付的请求，输入待支付总金额，选择参与成员(响应方)，最后发起联合支付请求；

S402，根据联合平均支付策略计算各个响应方应支付的金额；

S403，对任一响应方进行授权检测，判断所述响应方是否已对发起方进行过联合支付授权？若所述响应方未对发起方进行过联合支付授权，执行步骤S404；若所述响应方已对发起方进行过联合支付授权，执行步骤S405；

S404，向所述响应方发送联合支付请求，在响应方确认支付后从所述响应方的资产余额中转移自身应支付的金额给所述发起方；

S405，从所述响应方的资产余额中自动转移自身应支付的金额给所述发起方；

具体地，若响应方已经提前对发起方进行过联合支付授权，可视为响应方信任发起方，在无需该响应方确认的情况下，从该响应方的资产余额中自动转移自身应支付的金额给所述发起方。

进一步地，可设计一种群组内有效的联合支付授权协议，群组内签署协议的群组成员可视为互相之间进行过联合支付授权。

S406，从所述发起方扣减待支付总金额并支付给所述收款方。

具体地，该支付过程可分为两种情况：

a)所有响应方均已将自身应支付的金额转移给发起方；

b)部分响应方没有将自身应支付的金额转移给发起方。

在具体的联合支付场景下，发起方与响应方的应支付金额均为总金额/参与人数，最理想的情况为所有响应方均进行过联合支付授权且资产余额正常，发起方选择响应方并发起联合支付请求后所有响应方都不需要再进行操作，各自自动转移应支付金额并汇总到发起方处，由发起方补齐自身的应支付金额后将待支付总金额支付给商家。

但响应方可能因为各种原因(网速问题，余额不足，未进行授权且迟迟不确认支付等)没有将自身应支付的金额转移给发起方，因此，本实施例设计使发起方补齐总金额不足部分并向商家支付。

具体地，可向发起方展示总金额与已收金额的差额，在上述第一种情况下，该差额即为发起方的预计应支付金额，在上述第二种情况下，该差额高于发起方的预计应支付金额。在第二种情况下，发起方可选择继续等待以收齐响应方的应付金额，或直接由自己补齐差额先行支付总金额，避免商家和其他参与者的等待。

相应于上述方法实施例，本说明书实施例还提供一种基于联合支付的交易变更装置，参见图7所示，所述装置可以包括：变更请求接收模块710，参与方确定模块720和金额转移模块730。

变更请求接收模块710：用于接收针对已完成联合支付交易的交易变更请求，所述联合支付交易为多个参与方联合平均支付的单笔交易，所述交易变更请求为对所述联合支付交易的参与方变更请求；

参与方确定模块720：用于获取所述已完成联合支付交易中包含的原参与方，获取所述交易变更请求中包含的新参与方，根据所述原参与方与所述新参与方确定新增参与方，减少参与方和剩余原参与方；

金额转移模块730：用于根据预设的分配算法计算所述新增参与方，所述减少参与方和所述剩余原参与方应支付/应退回金额，按照计算结果完成各个参与方之间的金额转移。

本说明书实施例还提供一种计算机设备，其至少包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其中，处理器执行所述程序时实现前述基于联合支付的交易变更方法，所述方法至少包括：

接收针对已完成联合支付交易的交易变更请求，所述联合支付交易为多个参与方联合平均支付的单笔交易，所述交易变更请求为对所述联合支付交易的参与方变更请求；

获取所述已完成联合支付交易中包含的原参与方，获取所述交易变更请求中包含的新参与方，根据所述原参与方与所述新参与方确定新增参与方，减少参与方和剩余原参与方；

根据预设的分配算法计算所述新增参与方，所述减少参与方和所述剩余原参与方的应支付/应退回金额，按照计算结果完成各个参与方之间的金额转移。

图8示出了本说明书实施例所提供的一种更为具体的计算设备硬件结构示意图，该设备可以包括：处理器1110、存储器1120、输入/输出接口1130、通信接口1140和总线1150。其中处理器1110、存储器1120、输入/输出接口1130和通信接口1140通过总线1150实现彼此之间在设备内部的通信连接。

处理器1110可以采用通用的CPU(Central Processing Unit，中央处理器)、微处理器、应用专用集成电路(Application Specific Integrated Circuit，ASIC)、或者一个或多个集成电路等方式实现，用于执行相关程序，以实现本说明书实施例所提供的技术方案。

存储器1120可以采用ROM(Read Only Memory，只读存储器)、RAM(Random AccessMemory，随机存取存储器)、静态存储设备，动态存储设备等形式实现。存储器1120可以存储操作系统和其他应用程序，在通过软件或者固件来实现本说明书实施例所提供的技术方案时，相关的程序代码保存在存储器1120中，并由处理器1110来调用执行。

输入/输出接口1130用于连接输入/输出模块，以实现信息输入及输出。输入输出/模块可以作为组件配置在设备中(图中未示出)，也可以外接于设备以提供相应功能。其中输入设备可以包括键盘、鼠标、触摸屏、麦克风、各类传感器等，输出设备可以包括显示器、扬声器、振动器、指示灯等。

通信接口1140用于连接通信模块(图中未示出)，以实现本设备与其他设备的通信交互。其中通信模块可以通过有线方式(例如USB、网线等)实现通信，也可以通过无线方式(例如移动网络、WIFI、蓝牙等)实现通信。

总线1150包括一通路，在设备的各个组件(例如处理器1110、存储器1120、输入/输出接口1130和通信接口1140)之间传输信息。

需要说明的是，尽管上述设备仅示出了处理器1110、存储器1120、输入/输出接口1130、通信接口1140以及总线1150，但是在具体实施过程中，该设备还可以包括实现正常运行所必需的其他组件。此外，本领域的技术人员可以理解的是，上述设备中也可以仅包含实现本说明书实施例方案所必需的组件，而不必包含图中所示的全部组件。

本说明书实施例还提供一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现前述的基于联合支付的交易变更方法，所述方法至少包括：

接收针对已完成联合支付交易的交易变更请求，所述联合支付交易为多个参与方联合平均支付的单笔交易，所述交易变更请求为对所述联合支付交易的参与方变更请求；

获取所述已完成联合支付交易中包含的原参与方，获取所述交易变更请求中包含的新参与方，根据所述原参与方与所述新参与方确定新增参与方，减少参与方和剩余原参与方；

根据预设的分配算法计算所述新增参与方，所述减少参与方和所述剩余原参与方的应支付/应退回金额，按照计算结果完成各个参与方之间的金额转移。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitorymedia)，如调制的数据信号和载波。

对于装置实施例而言，由于其基本对应于方法实施例，所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本说明书方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本说明书实施例可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本说明书实施例的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本说明书实施例各个实施例或者实施例的某些部分所述的方法。

上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机，计算机的具体形式可以是个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件收发设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任意几种设备的组合。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于装置实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的模块可以是或者也可以不是物理上分开的，在实施本说明书实施例方案时可以把各模块的功能在同一个或多个软件和/或硬件中实现。也可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

以上所述仅是本说明书实施例的具体实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本说明书实施例原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本说明书实施例的保护范围。

Claims (13)

1.一种基于联合支付的交易变更方法，应用于电子支付平台，所述方法包括：

接收针对已完成联合支付交易的交易变更请求，所述联合支付交易为多个参与方联合平均支付的单笔交易，所述交易变更请求为对所述联合支付交易的参与方变更请求；

获取所述已完成联合支付交易中包含的原参与方，获取所述交易变更请求中包含的新参与方，根据所述原参与方与所述新参与方确定新增参与方，减少参与方和剩余原参与方；

根据预设的分配算法计算所述新增参与方，所述减少参与方和所述剩余原参与方的应支付/应退回金额，按照计算结果完成各个参与方之间的金额转移。

2.如权利要求1所述的方法，所述根据预设的分配算法计算所述新增参与方，所述减少参与方和所述剩余原参与方应支付/应退回金额，包括：

当原参与方人数量M人，新增参与方数量N人时，计算每个新增参与方的应支付金额，所述应支付金额＝(M*原人均支付金额)/(M+N)；

计算每个原参与方的应退回金额，所述应退回金额＝((M*原人均支付金额)/(M+N)*N/M。

3.如权利要求1所述的方法，所述根据预设的分配算法计算所述新增参与方，所述减少参与方和所述剩余原参与方应支付/应退回金额，包括：

当原参与方人数量M人，减少参与方数量R人时，计算每个减少参与方的应退回金额，所述应退回金额＝原人均支付金额；

计算每个剩余原参与方的额外应支付金额，所述额外应支付金额＝(M*原人均支付金额)/(M-R)-原人均支付金额。

4.如权利要求1所述的方法，所述根据预设的分配算法计算所述新增参与方，所述减少参与方和所述剩余原参与方应支付/应退回金额，包括：

当原参与方人数量M人，新增参与方数量N人，减少参与方数量R人时，计算每个减少参与方的应退回金额，所述应退回金额＝原人均支付金额；

计算每个新增参与方的应支付金额，所述应支付金额＝(M*原人均支付金额)/(M-R+N)；

针对剩余原参与方，若原人均支付金额＞(M*原人均支付金额)/(M-R+N)，则计算每个剩余原参与方的应退回金额，所述应退回金额＝(M*原人均支付金额)/(M-R+N)-原人均支付金额；

针对剩余原参与方，若原人均支付金额＜＝(M*原人均支付金额)/(M-R+N)，则计算每个剩余原参与方的额外应支付金额，所述额外应支付金额＝原人均支付金额-(M*原人均支付金额)/(M-R+N)。

5.如权利要求1所述的方法，所述联合支付的交易方式，具体为：

接收发起方发起的联合支付请求，所述联合支付请求中至少包括收款方信息，响应方信息与待支付总金额信息，其中，发起方和响应方都为联合支付的参与方，且响应方由发起方选择；

根据联合平均支付策略计算各个响应方应支付的金额；

对任一响应方进行授权检测，若所述响应方已对发起方进行过联合支付授权，则从所述响应方的资产余额中自动转移自身应支付的金额给所述发起方；

从所述发起方扣减待支付总金额并支付给所述收款方。

6.如权利要求5所述的方法，所述分别从各个参与者的资产余额中扣减所述最终支出金额前，还包括：

对任一响应方进行授权检测，若所述响应方已对发起方进行过联合支付授权，则从所述响应方的资产余额中扣减所述最终支出金额时无需进行验证。

7.如权利要求5所述的方法，所述对任一响应方进行授权检测后，还包括：

对任一响应方进行授权检测，若所述响应方没有对发起方进行过联合支付授权，向所述响应方发送联合支付请求，在响应方确认支付后从所述响应方的资产余额中扣减所述最终支出金额。

8.如权利要求5所述的方法，所述发起方与所述响应方为支付平台同一群组的群组成员。

9.如权利要求8所述的方法，所述分别从各个参与者的资产余额中扣减所述最终支出金额前，还包括：

确定所述发起方/响应方所在群组对应的联合支付授权协议，若所述响应方已签署所述联合支付授权协议，则从所述响应方的资产余额中扣减所述最终支出金额时无需进行验证，其中，签署联合支付授权协议的群组成员可视为互相进行过联合支付授权。

10.如权利要求9所述的方法，所述确定所述发起方/响应方所在群组对应的联合支付授权协议后，还包括：

若所述响应方没有签署所述联合支付授权协议，向所述响应方发送联合支付请求，在响应方确认支付后从所述响应方的资产余额中扣减所述最终支出金额。

11.如权利要求9所述的方法，所述向所述响应方发送联合支付请求后，还包括：

向所述响应方发送群内协议签署提醒，以使所述响应方选择是否签署所述群组对应的联合支付授权协议。

12.一种基于联合支付的交易变更装置，应用于电子支付平台，所述装置包括：

变更请求接收模块：用于接收针对已完成联合支付交易的交易变更请求，所述联合支付交易为多个参与方联合平均支付的单笔交易，所述交易变更请求为对所述联合支付交易的参与方变更请求；

参与方确定模块：用于获取所述已完成联合支付交易中包含的原参与方，获取所述交易变更请求中包含的新参与方，根据所述原参与方与所述新参与方确定新增参与方，减少参与方和剩余原参与方；

金额转移模块：用于根据预设的分配算法计算所述新增参与方，所述减少参与方和所述剩余原参与方应支付/应退回金额，按照计算结果完成各个参与方之间的金额转移。

13.一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其中，所述处理器执行所述程序时实现如权利要求1所述的方法。