CN101655950A

CN101655950A - 一种合并支付的实现方法、装置及***

Info

Publication number: CN101655950A
Application number: CN200910150746A
Authority: CN
Inventors: 洪磊; 俞峰
Original assignee: Alibaba Group Holding Ltd
Current assignee: Alibaba Group Holding Ltd
Priority date: 2009-06-30
Filing date: 2009-06-30
Publication date: 2010-02-24

Abstract

本申请公开了一种合并支付的实现方法，该方法为：第三方支付平台接收用户通过电子商务交易平台发送的至少两份不同格式的交易信息文件，将其转化为统一格式的文件并对应于所述用户的用户ID进行存储；在接收到所述用户通过客户端发送的携带用户ID的费用支付请求消息时，将对应该用户ID保存的所述至少两份交易信息文件对应的交易金额进行合并，获得交易总金额，再向银行平台侧发送从用户指定的银行账户中扣除所述交易总金额的指令，以完成合并支付流程。这样，用户通过第三方支付平台仅执行一次合并支付流程，即可以完成针对不同电子商务交易平台的费用支付，这在很大程度上降低了整体支付流程的执行复杂度。本申请同时公开了一种合并支付业务***及装置。

Description

一种合并支付的实现方法、装置及***

技术领域

本申请涉及计算机技术领域，特别涉及一种合并支付的实现方法、装置及***。

背景技术

随着电子商务技术的发展，越来越多的人选择在电子商务交易平台上进行网上购物，涉及买卖的产品越来越丰富，涉及到的电子商务交易平台的数目也越来越多。通常情况下，网上购物的流程是用户在电子商务平台选定要购买的产品，下单后，电子商务网站会形成电子订单，然后用户根据这些订单来完成网上或者线下的支付。

仅就网上支付而言，有多种方法来实现支付，其中有一类支付方法是通过第三方支付平台完成电子支付。所谓第三方支付平台，是专门用于解决网上交易支付问题的电子平台，该等第三方支付平台，通常与若干个电子商务交易平台及若干个银行的电子平台通过互联网或者专线相连，帮助用户在网上完成指定商品的支付流程。通过第三方支付平台完成支付流程，通常具有较高的便捷性及安全性。

实际生活当中，有很多人在网上购物时候会一次性看中很多商品，通常情况下，选购一个商品就会形成一笔订单，多个商品就会形成多个订单。而传统的第三方支付平台往往是针对每一笔订单来完成一次支付，这样多个订单就需要用户完成多次支付过程。

目前，针对上述的问题，第三方支付平台都提供了合并支付或批量支付的方式，即用户只需通过第三方支付平台执行一次支付流程，就可以将在同一商户处购买的所有商品的支付费用结算完毕，这在一次程度上降低了支付流程的繁琐程度，提高了支付流程的执行效率。

然而，以上的合并支付存在一个非常大的缺陷：即传统的合并支付所能一次性完成合并支付的订单必须来自同一个电子商务平台；那么，当用户在不同的电子商务交易平台上进行网上购物时，需要通过第三方支付平台，针对来自不同的电子商务交易平台的订单分别完成支付流程，这样，当用户的商品交易涉及的电子商务交易平台的数目过多时，传统的合并支付便会显现出整体支付流程的执行过于复杂，整体支付流程的执行效率低下，应用场景狭窄等缺陷。因此，需要提供一种新的合并支付方法，以解决上述问题。

发明内容

本申请实施例提供一种合并支付的实现方法、装置及***，以降低涉及多个电子商务交易平台的费用支付流程的执行复杂度。

本申请实施例提供的具体技术方案如下：

一种合并支付的实现方法，包括以下步骤：

第三方支付平台接收并存储用户通过电子商务交易平台发送的至少两份不同格式的交易信息文件；

第三方支付平台将所述至少两份不同格式的交易信息文件转化为统一格式的文件，并对应于所述用户的用户标识信息ID进行存储；

第三方支付平台接收所述用户通过客户端发送的携带用户ID的费用支付请求消息；

第三方支付平台根据所述用户ID获取对应该用户ID保存的所述至少两份交易信息文件，并将所述至少两份交易信息文件对应的交易金额进行合并，获得交易总金额；

第三方支付平台向银行平台侧发送从用户指定的银行账户中扣除所述交易总金额的指令，以完成合并支付流程。

一种合并支付业务***，由若干服务器组成，且通过网络或专线与若干银行平台及电子商务交易平台相连，包括：

存储单元，用于存储用户通过电子商务交易平台发送的至少两份不同格式的交易信息文件；

编译单元，用于将所述至少两份不同格式的交易信息文件转化为指定的统一格式的文件，并对应于所述用户的用户标识信息ID保存在所述存储单元内；

通信单元，用于接收所述用户通过客户端发送的携带用户ID的费用支付请求消息；

合并单元，用于根据所述用户ID获取对应该用户ID保存的至少两份交易信息文件，并将所述至少两份交易信息文件对应的交易金额进行合并，获得交易总金额；

处理单元，用于指示银行平台侧从用户指定的银行账户中扣除所述交易总金额，以完成合并支付流程。

采用本申请实施例提供的上述技术方案，用户可以通过第三方支付平台仅执行一次合并支付流程，即可以完成针对不同电子商务交易平台的费用支付，这在很大程度上降低了整体支付流程的执行复杂度，提高了整体支付流程的执行效率，从而有效提升了用户体验。

附图说明

图1为本申请实施例中网络环境示意图；

图2为本申请实施例中第三方支付平台功能结构图；

图3为本申请实施例中银行平台功能结构图；

图4为本申请实施例中客户端通过电子商务交易平台生成订单流程图；

图5为本申请实施例中客户端通过第三方支付平台对归属于不同电子商务交易平台平台的订单进行合并支付流程图。

具体实施方式

为了降低涉及多个电子商务交易平台的费用支付流程的执行复杂度，本申请实施例中，第三方支付平台接收并存储用户通过电子商务交易平台发送的至少两份不同格式的交易信息文件，并将所述至少两份不同格式的交易信息文件转化为统一格式的文件，再对应于所述用户的用户标识信息ID进行存储；第三方支付平台在接收所述用户通过客户端发送的携带用户ID的费用支付请求消息时，根据所述用户ID获取对应该用户ID保存的所述至少两份交易信息文件，并将所述至少两份交易信息文件对应的交易金额进行合并，获得交易总金额；再向银行平台侧发送从用户指定的银行账户中扣除所述交易总金额的指令，以完成合并支付流程。

其中，由于第三方支付平台处理的交易信息文件归属于至少两个不同电子商务交易平台，而每个电子商务交易平台生成交易信息文件时所采用的格式和传输方式都不尽相同，因此，第三方支付平台在保存用户通过各电子商务平台上传的交易信息文件时，需要将各交易信息文件转化成为统一格式的文件进行保存，而在完成支付流程后，将各交易信息文件对应的支付完成信息再次转换成相应的电子商务平台能够识别的格式，并采用对应的传输方式将各支付完成信息传送回相应的电子商务交易平台。

下面结合附图对本申请优选的实施方式进行详细说明。

参阅图1所示，本申请实施例中，合并支付业务***(以下称为第三方支付平台12)由若干服务器组成，且通过网络或专线与若干银行平台13及电子商务交易平台11相连，参阅图2所示，本申请实施例中，第三方支付平台12是专门用于完成支付行为的电子平台，其有多种构建方式，至少包含以下功能模块：

存储单元120，用于存储用户通过电子商务交易平台发送的至少两份不同格式的交易信息文件；

编译单元121，用于将所述至少两份不同格式的交易信息文件转化为指定的统一格式的文件，并对应于所述用户的用户标识信息ID保存在所述存储单元内；

通信单元122，用于接收所述用户通过客户端发送的携带用户ID的费用支付请求消息；

合并单元123，用于根据所述用户ID获取对应该用户ID保存的至少两份交易信息文件，并将所述至少两份交易信息文件对应的交易金额进行合并，获得交易总金额；

处理单元124，用于指示银行平台侧从用户指定的银行账户中扣除所述交易总金额，以完成合并支付流程。

如图2所示，第三方支付平台12还包含第一定时处理单元125和第二定时处理单元126，其中，第一定时处理单元125用于维护针对每个交易信息文件设置的定时器1，而第二处理单元126用于维护针对每个交易信息文件设置的定时器2，定时器1和定时器2的具体作用将在以下实施例中进行详细介绍。

此外，在完成支付流程后，编译单元121还用于将各交易信息文件对应的支付完成信息再次转换成相应的电子商务交易平台11能够识别的文件格式，并由通信单元122采用对应的传输方式将各支付完成信息传送回相应的电子商务交易平台11。

当然，网络环境的构建方式不止图1中所示的一种方式，图1仅为举例。

参阅图3所示，本实施例中，银行平台侧的各银行平台13，归属于银行***，用于根据第三方支付平台12的指示在各银行平台13之间完成交易金额的扣除和存入。

基于上述网络环境，本实施例中以一个客户端10、两个电子商务交易平台11(以下分别简称为交易平台A和交易平台B)、一个第三方支付平台12、两个银行平台13(以下分别称为银行平台1和银行平台2)为例进行说明。

在实际应用中，用户X通过客户端10分别登录交易平台A和交易平台B，并且在交易平台A和交易平台B内完成商品的选购，生成相应的交易信息文件，本实施例中，将用户X在交易平台A和交易平台B内分别生成的交易信息称为订单A和订单B。那么，参阅图4所示，以交易平台A为例，用户X通过客户端10登录交易平台A后，生成订单A的详细流程如下：

步骤400：用户X通过客户端10向交易平台A发送登录请求消息，在该登录请求消息中携带有用户X的标识信息(以下称为ID X)及用户X的登录密码。

步骤410：交易平台A根据接收的ID X和相应的登录密码，对用户X进行身份验证。

步骤420：交易平台A确定用户X通过身份验证后，向客户端10返回登录响应消息。

步骤430：用户X登录交易平台成功后，通过客户端10呈现的Web页面在交易平台A内进行商品选购。

在选购过程中，上述步骤430可以反复执行多次，每一次选购，客户端10都会将用户X选购的商品类目、交易金额，以及商户标识ID和商户流水号发送至交易平台A。

步骤440：在用户X选购完毕后，交易平台A生成对应于ID X的订单A，该订单A中至少包含用户X在交易平台A内选购的商品类目、每一笔交易的交易金额，以及各商户ID和商户流水号。

步骤450：交易平台A向第三方支付平台12发送保存订单A的请求消息，在该消息中携带ID X。

步骤460：第三方支付平台12对应于ID X对订单A进行保存。

步骤470：第三方支付平台12向交易平台A和客户端10返回订单A保存成功消息。

实际应用中，第三方支付平台12也可以将订单A保存成功消息发送至交易平台A，由交易平台A转发至客户端10，在此不再赘述。

同理，用户X也可以通过步骤400-470记载的技术方案在交易平台B内进行商品选购，并最终生成订单B，以及通过交易平台B将订单B交由第三方支付平台12对应于ID X进行保存，订单B内至少包含用户X在交易平台B内选购的商品类目、每一笔交易的交易金额，以及各商户ID和商户流水号。

实际应用中，交易平台A和交易平台B通常使用不同的文件格式生成的相应的订单A和订单B，那么，第三方支付平台12就需要在接收到订单A和订单B后，将格式不同的订单A和订单B转换成为指定的统一格式的文件，再进行后续的合并支付处理，以下本实施例中，将转换后的文件仍称为订单A和订单B。

基于上述实施例，用户X在交易平台A和交易平台B内分别进行商品选购后，需要登录第三方支付平台12完成费用支付流程，本实施例中，假设用户X的银行帐户归属于银行平台侧的银行平台1，而第三方支付平台12的银行账户归属于银行平台侧的银行平台2，银行平台1和银行平台2可以相同，也可以不同。那么，参阅图5所示，用户X通过第三方支付平台12完成费用支付流程的详细流程如下：

步骤500：用户X通过客户端10登录第三方支付平台12。

步骤501：用户X向第三方支付平台12发送费用支付请求消息，该消息中携带IDX。

步骤502：第三方支付平台12根据接收的ID X，获取对应ID X保存的订单A和订单B。

步骤503：第三方支付平台12将获得的订单A和订单B发送至客房端10，客房端10通过Web页面将订单A和订单B呈现给用户X。

本实施例中，为了提高***处理效率，较佳地，第三方支付平台12对应ID X保存订单A和订单B时，分别为其设置一定时器，若超过定时器设定的时长，用户X仍未发起费用支付流程，那么第三方支付平台12将会删除订单A和订单B。因此，假设第三方支付平台12针对订单A和订单B分别预设一个定时器1，那么，在步骤503中，第三方支付平台12在获取订单A和订单B后，应先判断针对其分别设置的定时器1是否超时，并在确定订单A和订单B对应的定时器1均未超过设定时长时，再将订单A和订单B发送至客户端10以执行后续的合并支付流程。

步骤504：用户X指示第三方支付平台12将支付订单A和订单B进行合并支付。

本实施例中，用户X可以在第三方支付平台12通过客房端10呈现的各个订单中进行选择性支付，例如，仅支付订单A，仅支付订单B，或者，同时支付订单A和订单B(即合并支付)，由于本实施例介绍是跨平台的合并支付，因此，用户X选择的是对订单A和订单B进行合并支付。

步骤505：第三方支付平台12计算出订单A和订单B合并后的交易总金额，以下称为金额Y。

金额Y为订单A和订单B内每一笔交易金额相加后的总金额。

步骤506：第三方支付平台12将金额Y发送至客房端10，以通知用户X。

步骤507：用户X向第三方支付平台12发送费用支付指示消息，该消息中携带有用户X的银行卡账号和银行卡支付密码，以及需要支付的金额Y。

实际应用中，用户X支付金额Y时可以使用多种方法，包括但不限于：使用银行卡账户进行支付、使用第三方支付平台12名下的银行总账户内对应于ID X的银行子账户进行支付或使用***账户进行支付等等；本实施例仅以用户X通过银行卡账户进行支付为例进行说明，若用户X通过第三方支付平台12名下的银行账户内对应于ID X的银行子账户进行支付，则需要在费用支付指示消息中携带对应于上述银行子账户的支付密码，若用户X通过***账户进行支付，则需要在上述费用支付指示消息中携带用于进行***资质与安全认证的相关信息，在此不再赘述。

步骤508：第三方支付平台12根据接收的用户X的银行卡账号和银行卡支付密码，指示银行平台1从用户X的银行卡账号中扣除金额Y。

步骤509：第三方支付平台12指示银行平台2，将银行平台1从用户X的银行卡账号中扣除的金额Y，存入银行平台2内的第三方支付平台12名下的银行总账户中。

步骤510：第三方支付平台12向客户端10返回费用支付响应消息，通过客户端10向用户X呈现显示“合并支付成功”的Web页面，至此，费用合并支付流程结束。

基于上述实施例，在用户X完成费用支付流程后，第三方支付平台12会通知订单A和订单B中涉及的各商户向用户X发送商品，并在确定各商户已将商品通过平邮、快递或者其他方式送出时，为订单A和订单B分别设置一定时器2；定时器2的作用如下：

在定时器2限制的时间范围内，若用户X接收到各商户发送的商品，则用户X通过客户端10通知第三方支付平台12已收到商品，或者，定时器2已超时，而用户X仍未通知第三方支付平台12是否收到商品，那么，第三方支付平台12将从自身名下的银行总账户内获取保存的金额Y，并将金额Y按照订单A和订单B内每一笔交易的交易金额进行划分，以及确定每一笔交易金额对应的各商户ID，接着，第三方支付平台12将划分后的每一笔交易金额，分别存入第三方支付平台12名下的银行总账户内对应于上述各商户ID设置的银行子账户中，至此，订单A和订单B的处理流程完结。

在定时器2限制的时间范围内，若用户X未接收到各商户发送的商品，则用户X通过客户端10通知第三方支付平台12未收到商品，那么，第三方支付平台12将从自身名下的银行总账户内获取保存的金额Y，并将金额Y存入第三方支付平台12名下的银行总账户内对应于ID X设置的银行子账户中，至此，订单A和订单B的处理流程完结。

在定时器2限制的时间范围内，若用户X仅接收到部分商户发送的商品，则用户X通过客户端10通知第三方支付平台12接收到部分商品，那么第三方支付平台12将从自身名下的银行总账户内获取保存的金额Y，并将金额Y按照订单A和订单B内每一笔交易金额进行划分，以及确定每一笔交易金额对应的各商户ID，接着，将用户X接收到的商品对应的每一笔交易金额，存入第三方支付平台12名下的银行总账户内相应的商户ID名下的银行子账户中，同时将用户X未接收到的商品对应的每一笔交易金额存入第三方支付平台12名下的银行总账户内对应于ID X设置的银行子账户中，至此，订单A和订单B的处理流程完结。

通过上述各实施例结束对订单A和订单B的处理后，第三方支付平台12需要将订单A和订单B各自对应的支付完成信息分别转换成交易平台A和交易平台B能够识别的文件格式，并采用对应的传输方式将订单A的支付完成信息传送回交易平台A，以及采用对应的传输方式将订单B的支付完成信息传送回交易平台B。举例来说，交易平台A采用文本格式生成用户在交易平台A内产生的订单A，并采用MD5算法对其进行加密，交易平台B采用web post格式生成同一用户在交易平台B内产生的订单B，并采用RSA算法对其进行加密，交易平台A和交易平台B通过不同的通讯方式分别将加密后的订单A和订单B发送至第三方支付平台，第三方支付平台分别对订单A和订单B进行解密，并将解密后的交易数据按照统一的文件格式(可以根据应用环境自行定义)进行保存，如，订单A的格式保持不变，将订单B的格式转换为文本格式；待合并支付完以后，第三方支付平台再将订单A和订单B各自对应的支付完成信息分别转换为文本格式和web post格式，再分别采用MD5算法和RSA算法进行加密后，返回至交易平台A和交易平台B。

基于上述各实施例，在实际应用中，若用户X在两个以上的电子商务交易平台11内进行商品交易，且在每个电子商务平台11内均生成至少两个订单(可以是相同商户，也可以是不同商户)，则同样可以使用步骤500-步骤510记载的技术方案通过第三方支付平台13对所有的订单进行合并支付，例如，用户X的商品交易涉及的电子商务平台11包括：交易平台A(生成订单A和订单A”)，交易平台B(生成订单B、订单B”和订单B”’)、交易平台C(生成订单C、订单C”和订单C”)………交易平台Z(生成订单Z和订单Z”)，则用户X将上述各订单上交至第三方支付平台11后，同样可以按照步骤500-步骤510记载的技术方案对归属于不同电子商务交易平台的全部或部分订单进行合并支付，在此不再赘述。

另一方面，第三方支付平台12对用户选定的各订单进行合并支付时，该选定的各订单的支付类型可以有多种，例如，订单A的支付模式为“担保模式”，订单B的支付模式为“直接转账模式”，订单C的支付模式为“预授权模式”，这样，第三方支付平台12在对订单A、订单B、订单C进行合并支付时，同样可以通过内部设置的编译器根据订单A，订单B、订单C各自支付模式，计算其应扣除的总金额，并在支付流程完成后，按照订单A、订单B和订单C各自的支付模式回复相应的支付完成信息。

综上所述，本申请实施例中，用户可以通过第三方支付平台12仅执行一次合并支付流程，即可以完成针对不同电子商务交易平台11的费用支付，这在很大程度上降低了整体支付流程的执行复杂度，提高了整体支付流程的执行效率，从而有效提升了用户体验。

显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。

Claims

1、一种合并支付的实现方法，其特征在于，包括以下步骤：

2、如权利要求1所述的方法，其特征在于，所述交易信息文件中至少包括，用户在该交易信息文件归属的电子商务交易平台内选购的商品类目、每一笔交易的交易金额，以及各商户标识ID和商户流水号。

3、如权利要求1所述的方法，其特征在于，所述至少两份不同格式的交易信息文件归属于至少两个不同的电子商务交易平台。

4、如权利要求1所述的方法，其特征在于，所述至少两份不同格式的交易信息文件由同一用户与至少两个不同的商户之间的交易生成。

5、如权利要求1所述的方法，其特征在于，所述至少两份交易信息文件对应至少两种不同的支付模式。

6、如权利要求1-5任一项所述的方法，其特征在于，还包括：第三方支付平台判断所述至少两份交易信息文件存储的时间是否超过预设时长，若均未超过预设时长，则对所述交易信息文件对应的交易金额进行合并。

7、如权利要求1所述的方法，其特征在于，所述第三方支付平台向银行平台侧发送从用户指定的银行账户中扣除所述交易总金额的指令具体为：第三方支付平台指示银行平台侧扣除所述用户指定的银行账户中的交易总金额，并将所述交易总金额存储在第三方支付平台在银行开设的总帐户。

8、如权利要求7所述的方法，其特征在于，还包括：当第三方支付平台接收到用户通过客户端发送的确认收货通知时，根据所述至少两份交易信息文件中对应的每一笔交易金额指示银行平台侧将所述交易总金额进行划分，并分别存储在与用户发生交易的各商户的银行帐户中。

9、如权利要求7所述的方法，其特征在于，还包括：当第三方支付平台超过预设时长仍未收到用户通过客户端发送的确认收货通知时，根据所述至少两份交易信息文件中对应的每一笔交易金额指示银行平台侧将所述交易总金额进行划分，并分别存储在与用户发生交易的各商户的银行帐户中。

10、如权利要求8或9所述的方法，其特征在于，所述各商户的银行帐户为：第三方支付平台在银行开设的对应各商户ID的银行子帐户。

11、如权利要求1-5任一项所述的方法，其特征在于，完成所述合并支付流程后，所述第三方支付平台获得所述至少两份交易信息文件分别对应的至少两种支付完成信息，将所述至少两种支付完成信息转换为其归属的电子商务交易平台支持的文件格式，并将所述至少两种支付完成信息分别发送至其归属的电子商务交易平台。

12、一种合并支付业务***，通过网络或专线与若干银行平台及电子商务交易平台相连，其特征在于，包括：

编译单元，用于将所述至少两份不同格式的交易信息文件转化为统一格式的文件，并对应于所述用户的用户标识信息ID保存在所述存储单元内；

13、如权利要求12所述的业务***，其特征在于，还包括：

第一定时处理单元，用于在所述合并单元获得所述至少两份交易信息文件后，判断针对所述至少两份交易信息文件分别预设的第一定时器是否超时，并在确定所述分别预设的第一定时器均未超时的时候，指示所述合并单元对所述至少两份交易信息文件对应的交易金额进行合并。

14、如权利要求12所述的业务***，其特征在于，进一步包括：

第二定时处理单元，用于在完成所述合并支付流程后，为所述至少两份交易信息文件分别设置一第二定时器，在所述第二定时器限制的时间范围内，若所述通信单元接收到客户端发送的用于指示商品接收结果的通知消息，则由所述处理单元通知银行平台侧从所述银行总账户内获取保存的所述交易总金额，并将所述交易总金额按照所述至少两份交易信息文件内包含的每一笔交易的交易金额进行划分，以及确定每一笔交易金额对应的各商户ID，再指示银行平台侧根据将用户接收到的货物对应的每一笔交易金额，存入所述银行总账户内相应的商户ID名下的银行子账户中，以及将用户未接收到的货物对应的每一笔交易金额存入所述银行总账户内对应于所述用户ID设置的银行子账户中。

15、如权利要求12所述的业务***，其特征在于，完成所述合并支付流程后，所述编译单元获得所述至少两份交易信息文件分别对应的至少两种支付完成信息，并将所述至少两种支付完成信息转换为其归属的电子商务交易平台支持的文件格式，以及由所述通信单元采用对应的传输方式将所述至少两种支付完成信息分别发送至其归属的电子商务交易平台。