CN107067262A

CN107067262A - 业务处理方法、系统及用户终端

Info

Publication number: CN107067262A
Application number: CN201610868041.1A
Authority: CN
Inventors: 石岩; 巢烨; 张玮; 张传奇; 洪倩; 吴艺; 潘俊俊; 郭凯
Original assignee: Alibaba Group Holding Ltd
Current assignee: Alibaba Group Holding Ltd
Priority date: 2015-09-30
Filing date: 2016-09-29
Publication date: 2017-08-18

Abstract

本申请提出一种业务处理方法、系统及用户终端。其中，该方法包括：接收业务处理平台分配的第一业务码，所述第一业务码是根据所述业务处理平台上记录的与第一用户终端相关的业务信息所配置的；根据所述第一业务码获取第一代理设备发送的、用于处理第一业务的第一代理标识；向所述业务处理平台上的第二用户终端发送第一业务请求，所述第一业务请求包括：第一代理标识和待交互的第一业务量；接收所述第二用户终端根据所述第一代理标识发送的所述第一业务量。提高了多系统业务交互的处理效率和灵活性，并且对交互的业务进行风险控制，提高了安全性。

Description

业务处理方法、系统及用户终端

技术领域

本申请涉及数据处理技术领域，尤其涉及一种业务处理方法、系统及用户终端。

背景技术

随着计算机和互联网的发展，用户终端之间基于业务处理平台的线上业务交互已经广泛应用在很多领域，其中，业务交互遵循一定的交互规则。然而，为了更好的扩展业务需求，用户终端经常采用具有一定风险的规则与其他的用户终端，或者其他的数据处理系统进行业务交互，从而导致交互的数据处理系统和处理节点增加，且风险高。

因此，为了控制交互过程中每个处理节点相关业务的风险，又需要涉及更多的数据处理系统进行风险控制和业务处理，从而导致交互的数据处理系统和处理节点越来越多。

上述业务交互过程可以应用到多种类的业务处理领域，以业务处理平台为电子商务平台为例详细说明如下：目前电子商务平台的账期支付是指卖方对于有多次持续交易的买方提供一定额度的延期付款服务，买方在确认收货后，在与卖方约定的账期到期时，买方付款给卖方。若买方不履行到期付款承诺，则由卖方自行催收，若未催收成功则卖方自行承担延期付款的坏账。而线下保险等金融机构，为解决卖方应收账款的坏账风险，通常采用“1个核心供应商+N个买方”的方式来提供信用保证保险。即核心供应商向保险系统提出为自己的买方买信用保证保险，从而账期结束时能够成功收账。保险系统将人工一对一深入贸易背景的真实性，若为真实贸易则对该笔订单承保。

由此可见，一个完整的业务处理过程往往需要涉及多个独立的数据处理系统，处理节点众多，严重降低了处理效率，并且有一定的局限性。

发明内容

本申请旨在至少在一定程度上解决相关技术中的技术问题之一。

为此，本申请的第一个目的在于提出一种业务处理方法，该方法实现了根据业务处理平台上记录的第一用户终端的业务信息配置的第一业务码进行第一业务交互，提高了多系统业务交互的处理效率和灵活性，并且对交互的业务进行风险控制，提高了安全性。

本申请的第二个目的在于提出一种第一用户终端。

为达上述目的，本申请第一方面实施例提出了一种业务处理方法，包括：接收业务处理平台分配的第一业务码，所述第一业务码是根据所述业务处理平台上记录的与第一用户终端相关的业务信息所配置的；根据所述第一业务码获取第一代理设备发送的、用于处理第一业务的第一代理标识；向所述业务处理平台上的第二用户终端发送第一业务请求，所述第一业务请求包括：第一代理标识和待交互的第一业务量；接收所述第二用户终端根据所述第一代理标识发送的所述第一业务量。

本申请实施例的业务处理方法，首先接收业务处理平台分配的第一业务码，所述第一业务码是根据所述业务处理平台上记录的与第一用户终端相关的业务信息所配置的；然后根据所述第一业务码获取第一代理设备发送的、用于处理第一业务的第一代理标识；进而向所述业务处理平台上的第二用户终端发送第一业务请求，所述第一业务请求包括：第一代理标识和待交互的第一业务量；最后接收所述第二用户终端根据所述第一代理标识发送的所述第一业务量。由此，实现了根据业务处理平台上记录的第一用户终端的业务信息配置的第一业务码进行第一业务交互，提高了多系统业务交互的处理效率和灵活性，并且对交互的业务进行风险控制，提高了安全性。

为达上述目的，本申请第二方面实施例提出了一种第一用户终端，包括：第一接收模块，用于接收业务处理平台分配的第一业务码，所述第一业务码是根据所述业务处理平台上记录的与第一用户终端相关的业务信息所配置的；第一获取模块，用于根据所述第一业务码获取第一代理设备发送的、用于处理第一业务的第一代理标识；第一请求模块，用于向所述业务处理平台上的第二用户终端发送第一业务请求，所述第一业务请求包括：第一代理标识和待交互的第一业务量；第二接收模块，用于接收所述第二用户终端根据所述第一代理标识发送的所述第一业务量。

本申请实施例的第一用户终端，通过第一接收模块接收业务处理平台分配的第一业务码，所述第一业务码是根据所述业务处理平台上记录的与第一用户终端相关的业务信息所配置的；通过第一获取模块根据所述第一业务码获取第一代理设备发送的、用于处理第一业务的第一代理标识；通过第一请求模块向所述业务处理平台上的第二用户终端发送第一业务请求，所述第一业务请求包括：第一代理标识和待交互的第一业务量；通过第二接收模块接收所述第二用户终端根据所述第一代理标识发送的所述第一业务量。由此，实现了根据业务处理平台上记录的第一用户终端的业务信息所配置的第一业务码进行第一业务交互，提高了多系统业务交互的处理效率和灵活性，并且对交互的业务进行风险控制，提高了安全性。

本申请的第三个目的在于提出一种业务处理方法，该方法实现了根据业务处理平台上记录的第一用户终端的业务信息配置的第一业务码进行第一业务交互，提高了多系统业务交互的处理效率和灵活性。

本申请的第四个目的在于提出一种第二用户终端。

为达上述目的，本申请第三方面实施例提出了一种业务处理方法，包括：接收第一用户终端发送的第一业务请求，其中，所述第一业务请求包括：第一代理标识和待交互的第一业务量，其中，所述第一代理标识是所述第一用户终端根据所述业务处理平台分配的第一业务码从第一代理设备获取的；根据所述第一代理标识向所述第一用户终端发送所述第一业务量，并接收第一用户终端发送的确认信息。

本申请实施例的业务处理方法，首先接收第一用户终端发送的第一业务请求，其中，所述第一业务请求包括：第一代理标识和待交互的第一业务量，其中，所述第一代理标识是所述第一用户终端根据所述业务处理平台分配的第一业务码从第一代理设备获取的；然后根据所述第一代理标识向所述第一用户终端发送所述第一业务量，并接收第一用户终端发送的确认信息。由此，实现了根据业务处理平台上记录的第一用户终端的业务信息配置的第一业务码进行第一业务交互，提高了多系统业务交互的处理效率和灵活性，并且对交互的业务进行风险控制，提高了安全性。

为达上述目的，本申请第四方面实施例提出了一种第二用户终端，包括：第三接收模块，用于接收第一用户终端发送的第一业务请求，其中，所述第一业务请求包括：第一代理标识和待交互的第一业务量，其中，所述第一代理标识是所述第一用户终端根据所述业务处理平台分配的第一业务码从第一代理设备获取的；交互模块，用于根据所述第一代理标识向所述第一用户终端发送所述第一业务量，并接收第一用户终端发送的确认信息。

本申请实施例的第二用户终端，通过第三接收模块接收第一用户终端发送的第一业务请求，其中，所述第一业务请求包括：第一代理标识和待交互的第一业务量，其中，所述第一代理标识是所述第一用户终端根据所述业务处理平台分配的第一业务码从第一代理设备获取的；通过交互模块根据所述第一代理标识向所述第一用户终端发送所述第一业务量，并接收第一用户终端发送的确认信息。由此，实现了根据业务处理平台上记录的第一用户终端的业务信息配置的第一业务码进行第一业务交互，提高了多系统业务交互的处理效率和灵活性，并且对交互的业务进行风险控制，提高了安全性。

本申请的第五个目的在于提出一种业务处理系统，该系统实现了根据业务处理平台上记录的第一用户终端的业务信息配置的第一业务码进行第一业务交互，提高了多系统业务交互的处理效率和灵活性。

为达上述目的，本申请第五方面实施例提出了一种业务处理系统，包括：业务处理平台和第一代理设备，其中，所述业务处理平台上包括：多个第一用户终端和多个第二用户终端，其中，所述第一用户终端可以采用如上所述的第一用户终端，所述第二用户终端可以采用如上所述的第二用户终端。

本申请实施例的业务处理系统，通过业务处理平台记录的与第一用户终端相关的业务信息为第一用户终端分配第一业务码，第一用户终端根据所述第一业务码获取第一代理设备发送的、用于处理第一业务的第一代理标识，并向第二用户终端发送第一业务请求，所述第一业务请求包括：第一代理标识和待交互的第一业务量；第二用户终端根据所述第一代理标识向第一用户终端发送所述第一业务量。由此，实现了根据业务处理平台上记录的第一用户终端的业务信息配置的第一业务码进行第一业务交互，提高了多系统业务交互的处理效率和灵活性，并且对交互的业务进行风险控制，提高了安全性。

附图说明

本发明上述的和/或附加的方面和优点从下面结合附图对实施例的描述中将变得明显和容易理解，其中：

图1是本申请一个实施例的业务处理方法的流程图；

图2是本申请另一个实施例的业务处理方法的流程图；

图3是基于保险系统进行风险控制的延期付款的交互示意图；

图4是本申请另一个实施例的业务处理方法的流程图；

图5是本申请另一个实施例的业务处理方法的流程图；

图6是基于电子商务平台的应收账款融资的正常交互示意图；

图7是基于电子商务平台的应收账款融资的异常交互示意图；

图8是本申请另一个实施例的业务处理方法的流程图；

图9是基于电子商务平台进行风险控制的应收账款融资的交互示意图；

图10是本申请另一个实施例的业务处理方法的流程图；

图11是基于保险系统进行风险控制的应收账款融资的交互示意图；

图12是本申请一个实施例的第一用户终端的结构示意图；

图13是本申请另一个实施例的第一用户终端的结构示意图；

图14是本申请一个实施例的第二用户终端的结构示意图；

图15是本申请另一个实施例的第二用户终端的结构示意图；

图16是本申请另一个实施例的第二用户终端的结构示意图；

图17是本申请一个实施例的业务处理系统的结构示意图；

图18是本申请另一个实施例的业务处理系统的结构示意图；

图19是本申请再一个实施例的业务处理方法的流程图。

具体实施方式

下面详细描述本申请的实施例，所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，旨在用于解释本申请，而不能理解为对本申请的限制。

下面参考附图描述本申请实施例的业务处理方法、系统及用户终端。

图1是本申请一个实施例的业务处理方法的流程图。

如图1所示，该业务处理方法包括：

步骤101，接收业务处理平台分配的第一业务码，所述第一业务码是根据所述业务处理平台上记录的与第一用户终端相关的业务信息所配置的。

业务处理平台上包括多个第一用户终端和多个第二用户终端，多个第一用户终端和多个第二用户终端在业务处理平台上交互第一业务，其中，第一业务用于标识在业务处理平台上第一用户终端和第二用户终端之间交互的业务类型。其中，第一用户终端为第一业务请求方，第二用户终端为第一业务提供方，需要说明的是，有的用户终端同时具有第一用户终端和第二用户终端的身份。本实施例提供的业务处理方法被配置在业务处理平台的第一用户终端中。

可以理解的是，业务处理平台的应用类型很多，例如包括：电子商务平台、电信商务平台和物流运营平台等，可以理解的是，具有支持多个第一用户终端和第二用户终端之间进行第一业务交互的业务处理平台均可以执行本实施例提供的业务处理方法。

针对业务处理平台上第一用户终端与第二用户终端之间进行第一业务的传统交互流程是：第一用户终端向第二用户终端发送包含待交互的第一业务量和第一业务数据的请求，第二用户终端根据第一业务数据向第一用户终端提供第一业务量。需要解释的是，针对业务处理平台的类型和不同的应用需要，第一业务数据和第一业务量的内容不同。以电子商务平台为例，当第一业务量是第二用户终端向第一用户终端提供的订单时，第一业务数据为第一用户终端向第二用户终端发送的订单货款。

但是，在很多应用中，为了满足第一用户终端其他的业务需求，第一用户终端需要第二用户终端先提供第一业务量，且延期向第二用户终端发送第一业务数据，为了减少第二用户终端的第一业务风险，需要通过第一代理设备控制风险，也就是说，如果到期时第一用户终端没有向第二用户终端发送第一业务数据，则通过第一代理设备向第二用户终端发送第一业务数据。

为了上述目的，首先，业务处理平台根据平台上记录的与第一用户终端相关的业务信息，为第一用户终端分配第一业务码，以使第一代理设备根据该第一业务码确定是否需要为第一用户终端进行第一代理业务，其中，该第一代理业务就是指如果到期时第一用户终端没有向第二用户终端发送第一业务数据，则通过第一代理设备向第二用户终端发送第一业务数据。

需要说明的是，业务处理平台上与第一用户终端相关的业务信息的业务类型很多，可以根据应用需要进行选择，举例说明如下：第一用户终端与业务处理平台上的一个或者多个第二用户终端进行的业务交互；第一用户终端通过业务处理平台与其他的数据处理系统进行的业务交互信息；第一用户终端在业务处理平台上的业务注册信息。针对不同的业务处理平台类型和应用场景，第一业务码的具体表现形式有很多，例如包括：信用积分、授信额度和评价级别，可以根据实际应用需要进行选择，本实施例对此不作限制。

步骤102，根据所述第一业务码获取第一代理设备发送的、用于处理第一业务的第一代理标识。

第一用户终端根据业务处理平台分配的第一业务码与第一代理设备进行数据交互，如果能够从第一代理设备中获取用于处理第一业务的第一代理标识，则说明第一代理设备根据该第一业务码确定为第一用户终端进行第一代理业务，也就是说，第一代理标识表示如果到期时第一用户终端没有向第二用户终端发送第一业务数据，则第一代理设备向第二用户终端发送第一业务数据。

需要说明的是，具有支持第一业务码功能的设备均可以作为第一代理设备执行相关的操作，第一代理设备的类型很多，可以根据实际应用需要进行选择。举例说明如下：

方式一，所述第一代理设备为所述业务处理平台，根据第一业务码获取第一代理标识，包括：

向所述业务处理平台发送包含第一业务码的处理请求；

接收所述业务处理平台根据所述第一业务码返回的第一处理标识，以便应用所述第一处理标识作为第一代理标识处理所述第一业务。

具体地，第一用户终端向业务处理平台发送包含第一业务码的处理请求，业务处理平台根据预设的代理策略判断第一业务码是否满足代理要求，如果满足代理要求，将具体的处理结果存储在业务处理平台，生成与处理结果对应的第一处理标识，并将第一处理标识发送给第一用户终端。如果不满足代理要求，则向第一用户终端发送代理失败响应。

当第一用户终端接收到业务处理平台根据所述第一业务码返回的第一处理标识时，则说明业务处理平台为第一用户终端的第一代理设备，如果到期时第一用户终端没有向第二用户终端发送第一业务数据，则业务处理平台向第二用户终端发送第一业务数据。

从而第一用户终端可以应用业务处理平台返回的第一处理标识作为第一代理标识处理第一业务。

方式二，所述第一代理设备为第一数据系统，根据第一业务码获取第一代理标识，包括：

采用所述业务处理平台与所述第一数据系统之间建立的第一数据交互通道，向所述第一数据系统发送包含第一业务码的处理请求；

接收所述第一数据系统根据所述第一业务码返回的第二处理标识，以便应用所述第二处理标识作为第一代理标识处理所述第一业务。

具体地，第一用户终端采用业务处理平台与第一数据系统之间建立的第一数据交互通道，向第一数据系统发送包含第一业务码的处理请求，第一数据系统根据预设的代理策略判断第一业务码是否满足代理要求，如果满足代理要求，将具体的处理结果存储在第一数据系统，生成与处理结果对应的第二处理标识，并将第二处理标识发送给第一用户终端。如果不满足代理要求，则向第一用户终端发送代理失败响应。

当第一用户终端通过第一数据交互通道接收到第一数据系统根据所述第一业务码返回的第二处理标识时，则说明第一数据系统为第一用户终端的第一代理设备，如果到期时第一用户终端没有向第二用户终端发送第一业务数据，则第一数据系统向第二用户终端发送第一业务数据。

从而第一用户终端可以应用第一数据系统返回的第二处理标识作为第一代理标识处理第一业务。

需要说明的是，针对不同类型的业务处理平台，第一数据系统的类型也不同，以电子商务平台为例，对应的第一数据系统为增信数据系统，其中，增信数据系统的类型很多，第一用户终端可以根据不同的业务进行选择，例如包括：保险系统和担保系统。

步骤103，向所述业务处理平台上的第二用户终端发送第一业务请求，所述第一业务请求包括：第一代理标识和待交互的第一业务量。

步骤104，接收所述第二用户终端根据所述第一代理标识发送的所述第一业务量。

具体的，第一用户终端根据第一业务码从第一代理设备获取第一代理标识后，根据该第一代理标识向业务处理平台上的第二用户终端发送第一业务请求，其中，该第一业务请求包括：第一代理标识和待交互的第一业务量。

第二用户终端对接收到的第一业务请求进行解析，获取第一代理标识和待交互的第一业务量，由于该第一代理标识表示若到期时第一用户终端没有向第二用户终端发送第一业务数据，则根据第一代理标识通过第一代理设备代替第一用户终端向第二用户终端发送第一业务数据。因此，第二用户终端风险得以控制，从而在第一用户终端没有发送第一业务数据的情况下，先向第一用户终端发送第一业务量。

进一步地，基于上述实施例，在步骤104之后，所述方法还包括：

若在预设的第一时间内第一用户终端向第二用户终端发送与第一业务量对应的第一业务数据，第一业务交互结束。

若在预设的第一时间内第一用户终端没有向所述第二用户终端发送与所述第一业务量对应的第一业务数据，则根据第一代理标识通过第一代理设备向所述第二用户终端发送第一业务数据，第一业务交互结束。

本申请实施例的业务处理方法，若在预设的第一时间内第一用户终端向第二用户终端发送与第一业务量对应的第一业务数据，第一业务交互结束；若在预设的第一时间内第一用户终端没有向第二用户终端发送与第一业务量对应的第一业务数据，则根据第一代理标识通过第一代理设备向第二用户终端发送第一业务数据，第一业务交互结束。由此，实现了根据业务处理平台上记录的第一用户终端的业务信息配置的第一业务码进行第一业务交互，提高了多系统业务交互的处理效率和灵活性，并且降低了业务交互的风险。

为了更加清楚地说明图1所示实施例的过程，以图2所示的基于电子商务平台的多系统进行的第一业务交互为例详细说明，本实施例中的第一交互业务为电子商务平台的延期付款业务，具体如下：

图2是本申请另一个实施例的业务处理方法的流程图,基于图1所示实施例，本实施例中的业务处理平台为电子商务平台，第一用户终端为买方，第二用户终端为卖方，第一业务码为授信额度，第一代理设备为第一数据系统中的保险系统，第二处理标识为应付款保证保险保单标识，第一业务量为订单货物；第一业务数据为应收账款；图3是基于保险系统进行风险控制的延期付款的交互示意图。

如图2和图3所示，该业务处理方法包括：

步骤201，买方接收电子商务平台分配的授信额度，所述授信额度是根据所述电子商务平台上记录的与买方相关的业务信息所配置的。

步骤202，买方采用电子商务平台与保险系统之间建立的第一数据交互通道，向保险系统发送包含授信额度的处理请求；

步骤203，买方接收保险系统根据授信额度返回的应付款保证保险保单标识，以便应用应付款保证保险保单标识处理所述第一业务。

步骤204，买方向电子商务平台上的卖方发送第一业务请求，所述第一业务请求包括：应付款保证保险保单标识和待交互的订单货物。

步骤205，买方接收卖方根据应付款保证保险保单标识发送的订单货物。

步骤206，买方若在预设的第一时间内向卖方发送应收账款，则第一业务结束，否则，根据应付款保证保险保单标识通过保险系统向卖方发送应收账款。

具体地，在目前的电子商务平台，买方和卖方之间进行的延期付款业务交易流程通常为第三方担保交易，用户为信用付出的资金成本较高，同时大部分用户为小微企业，难以有成型的核心供应商。本实施例针对上述需求提出新的业务处理方法。

根据买方在电子商务平台的采购行为、在线资产、供应链关系网络、履约行为、经营情况(若同时为电子商务平台的卖方)等数据，通过结合保险系统线下的风控能力，及电子商务平台线上的信用风险模型，建立基于机器学习的风险控制模型来为该买方提供信用评分、评级，并在此基础之上对买方进行准入并分配授信额度。

买方在获得电子商务平台给予的信用评分及授信额度后，根据授信额度通过保险系统以承保的形式获取第一代理标识，(若第一代理设备为电子商务平台，可用通过平台背书的形式获取第一代理标识)。

根据第一代理标识向电子商务平台任一支持延期付款的交易流程的新、老卖方在线采购商品或服务，确认收货时确立应收账款，并在账期到期时付款。买方若在预设的第一时间内向卖方发送应收账款，则第一业务结束，否则，根据应付款保证保险保单标识通过保险系统向卖方发送应收账款。

由此可见，本实施例提供的业务处理方法将电子商务平台上买方的信息流、资金流、物流、商流这四类无形的资产作为风控授信的依据和第二还款来源，实现了将电子商务平台上在线用户数据转变成信用，信用通过与业务处理平台或外部保险系统等增信数据系统，转变成银行或外部出资方认可的授信额度，打破线下通过传统的质押实体不动产或动产的方式进行授信，有助于降低买方采购资金压力，买方无需通过现金交易即可购买货物，扩大买家采购资金规模。

相比于线下的应收账款保证保险在实施时，保险系统或者担保系统需要采用一对一人工审核的方法对贸易真实性进行核保、再由后台风控人员借助第三方评级机构进行评级与授信。本实施提供的业务处理方法，保险系统或担保系统可对接一个电子商务平台，与电子商务平台共建风控模型，通过系统直连的方式，快速(例如，当天)在线完成信用保证险的保险准入、授信、承保、理赔等工作。将原先的“1对1”转变为“1对N”，减少多个环节，通过降维的方式，极大地提升保险或担保增信机构的工作效率、节省人力。同时，对于贸易真实性判定，电子商务平台累积多年的系统+人工的一套“事前、事中、事后”的实时判定方式，极大地提高了贸易真实性判定的效率和准确率。

相比于线下的应收账款保证保险能实现“1个买方+1个核心大卖方”的关系型贸易交易信用成本降低。本实施提供的业务处理方法，买方依托自身在电子商务平台沉淀的在线数据，依靠电子商务平台为其提供的增信渠道，可凭借兑付过的信用额度与新、老卖方进行交易，完全打破原有一对一、关系型贸易的限制，极大地提高了交易的灵活性和贸易对手的覆盖范围，为非关系型贸易提供了保障，降低了交易的信用成本。本实施提供的业务处理方法，也为电子商务平台吸引更多新用户，并增强新用户对平台的粘性，帮助电子商务平台极大地沉淀在线形成的关系型贸易，同时减少关系型贸易向线下转移的情况。

图4是本申请另一个实施例的业务处理方法的流程图。

如图4所示，该业务处理方法包括：

步骤301，接收第一用户终端发送的第一业务请求，其中，所述第一业务请求包括：第一代理标识和待交互的第一业务量，其中，所述第一代理标识是所述第一用户终端根据所述业务处理平台分配的第一业务码从第一代理设备获取的。

步骤302，根据所述第一代理标识向所述第一用户终端发送所述第一业务量，并接收第一用户终端发送的确认信息。

需要说明的是，本实施中各步骤的实施过程可以参见上述实施例所示的业务处理方法，其技术原理和实施过程类似，此处不再赘述。

本申请实施例的业务处理方法，首先接收第一用户终端发送的第一业务请求，其中，所述第一业务请求包括：第一代理标识和待交互的第一业务量，其中，所述第一代理标识是所述第一用户终端根据所述业务处理平台分配的第一业务码从第一代理设备获取的；然后根据所述第一代理标识向所述第一用户终端发送所述第一业务量。由此，实现了根据业务处理平台上记录的第一用户终端的业务信息配置的第一业务码进行第一业务交互，提高了多系统业务交互的处理效率和灵活性，并且对交互的业务进行风险控制，提高了安全性。

图5是本申请另一个实施例的业务处理方法的流程图。

如图5所示，基于图4所示实施例，在步骤302之后，本实施例还可以包括以下步骤：

步骤401，接收所述业务处理平台分配的第二业务码，所述第二业务码是根据所述业务处理平台上记录的与第二用户终端相关的业务信息所配置的。

本实施例提供的业务处理方法被配置在业务处理平台上的第二用户终端中。业务处理平台上的第二用户终端根据第一代理标识与第一用户终端交互第一业务之后，还需要与第二数据系统进行第二业务交互。针对不同的业务处理平台，第二数据系统的具体形式不同，以电子商务平台为例，第二数据系统为融资数据系统，其中，融资数据系统包括：间接融资系统，例如银行系统，以及直接融资系统，例如P2P系统和SPV系统。

可以理解的是，业务处理平台的应用类型很多，例如包括：电子商务平台、电信商务平台和物流运营平台等，可以理解的是，具有支持多个第二用户终端和第二数据系统之间进行第二业务交互的业务处理平台均可以执行本实施例提供的业务处理方法。

针对业务处理平台上第二用户终端与第二数据系统之间进行第二业务的传统交互流程是：第二用户终端在接收第一用户终端发送的第一代理标识和确认信息后，向第二数据系统发送包含确认信息和第一代理标识和待交互的第二业务量的请求，第二用户终端根据第一代理标识和确认信息向第一用户终端提供第二业务量。到期后第一用户终端向第二数据系统发送第二业务数据，如果到期时第一用户终端未向第二数据系统发送第二业务数据，则根据第一代理标识通过第一代理设备向第二数据系统发送第二业务数据。

但是，在很多应用中，当第二数据系统向第二用户终端发送第二业务量之后，第一用户终端与第二用户终端之间的第一业务出现问题导致确认信息和第一代理标识失效，即第一用户终端和第一代理设备免责。也就是说，到期时如果第一用户终端没有向第二数据系统发送第二业务数据，也不能通过第一代理设备向第二数据系统发送第二业务数据。由此可见，第二数据系统具有业务安全风险。

需要解释的是，针对业务处理平台和第二数据系统的类型和不同的应用需要，第二业务数据和第二业务量的内容不同。以电子商务平台与融资系统交互为例，当第二业务量是第二数据系统向第二用户终端提供的融资资金时，第二业务数据为第二用户终端向第二数据系统发送的还款资金。

为了解决上述问题，减少第二数据系统的业务风险，本实施例提供一种业务处理方法。首先，业务处理平台根据平台上记录的与第二用户终端相关的业务信息，为第二用户终端分配第二业务码，以使第二代理设备根据该第二业务码确定是否需要为第二用户终端进行第二代理业务，其中，该第二代理业务就是指如果到期时第一用户终端和第一代理设备都没有向第二数据系统发送第二业务数据，则通过第二代理设备向第二数据系统发送第二业务数据。

需要说明的是，业务处理平台上与第二用户终端相关的业务信息的业务类型很多，可以根据应用需要进行选择，举例说明如下：第二用户终端与业务处理平台上的一个或者多个第一用户终端进行的业务交互；第二用户终端通过业务处理平台与其他的数据处理系统进行的业务交互信息；第二用户终端在业务处理平台上的业务注册信息。针对不同的业务处理平台类型和应用场景，第二业务码的具体表现形式有很多，例如包括：信用积分、授信额度和评价级别，可以根据实际应用需要进行选择，本实施例对此不作限制。

步骤402，根据所述第二业务码从第二代理设备获取用于处理第二业务的第二代理标识。

第二用户终端根据业务处理平台分配的第二业务码与第二代理设备进行数据交互，如果能够从第二代理设备中获取用于处理第二业务的第二代理标识，则说明第二代理设备根据该第二业务码确定为第二用户终端进行第二代理业务，也就是说，第二代理标识表示如果到期时第一用户终端和第一代理设备都没有向第二数据系统发送第二业务数据，则第二代理设备向第二数据系统发送第二业务数据。

需要说明的是，具有支持第二业务码功能的设备均可以作为第二代理设备执行相关的操作，第二代理设备的类型很多，可以根据实际应用需要进行选择。举例说明如下：

方式一，所述第二代理设备为所述业务处理平台，根据第二业务码获取第二代理标识，包括：

向所述业务处理平台发送包含第二业务码的处理请求；

接收所述业务处理平台根据所述第二业务码返回的第三处理标识，以便应用所述第三处理标识作为第二代理标识处理所述第二业务。

具体地，第二用户终端向业务处理平台发送包含第二业务码的处理请求，业务处理平台根据预设的代理策略判断第二业务码是否满足代理要求，如果满足代理要求，将具体的处理结果存储在业务处理平台，生成与处理结果对应的第三处理标识，并将第三处理标识发送给第二用户终端。如果不满足代理要求，则向第二用户终端发送代理失败响应。

当第二用户终端接收到业务处理平台根据所述第二业务码返回的第三处理标识时，则说明业务处理平台为第二用户终端的第二代理设备，如果到期时第一用户终端和第一代理设备都没有向第二数据系统发送第二业务数据，则业务处理平台向第二数据系统发送第二业务数据。

从而第二用户终端可以应用业务处理平台返回的第三处理标识作为第二代理标识处理第二业务。

方式二，所述第二代理设备为第一数据系统(这里所述的第一数据系统可以与图1所述实施例中的第一数据系统相同或者不相同)，根据第二业务码获取第二代理标识，包括：

采用所述业务处理平台与所述第一数据系统之间建立的第一数据交互通道，向所述第一数据系统发送包含第二业务码的处理请求；

接收所述第一数据系统根据所述第二业务码返回的第四处理标识，以便应用所述第四处理标识作为第二代理标识处理所述第二业务。

具体地，第二用户终端采用业务处理平台与第一数据系统之间建立的第一数据交互通道，向第一数据系统发送包含第二业务码的处理请求，第一数据系统根据预设的代理策略判断第二业务码是否满足代理要求，如果满足代理要求，将具体的处理结果存储在第一数据系统，生成与处理结果对应的第四处理标识，并将第四处理标识发送给第二用户终端。如果不满足代理要求，则向第二用户终端发送代理失败响应。

当第二用户终端通过第一数据交互通道接收到第一数据系统根据所述第二业务码返回的第四处理标识时，则说明第一数据系统为第二用户终端的第二代理设备，如果到期时第一用户终端和第一代理设备都没有向第二数据系统发送第二业务数据，则第一数据系统向第二数据系统发送第一业务数据。

从而第二用户终端可以应用第一数据系统返回的第四处理标识作为第二代理标识处理第二业务。

需要说明的是，针对不同类型的业务处理平台，第一数据系统的类型也不同，以电子商务平台为例，对应的第一数据系统为增信数据系统，其中，增信数据系统的类型很多，第二用户终端可以根据不同的业务进行选择，例如包括：保险系统和担保系统。

步骤403，采用所述业务处理平台与第二数据系统之间建立的第二数据交互通道，向所述第二数据系统发送第二业务请求，所述第二业务请求包括：所述确认信息所述第二代理标识、所述第一代理标识，以及待交互的第二业务量。

步骤404，接收所述第二数据系统根据所述确认信息、所述第二代理标识和所述第一代理标识发送的所述第二业务量。

具体的，第二用户终端根据第一用户终端发送的确认信息和第一代理标识，以及根据第二业务码从第二代理设备获取第二代理标识，采用业务处理平台与第二数据系统之间建立的第二数据交互通道，向第二数据系统发送第二业务请求，该第二业务请求包括：确认信息、第二代理标识、第一代理标识，以及待交互的第二业务量。

第二数据系统对接收到的第二业务请求进行解析，获取确认信息、第二代理标识、第一代理标识，以及待交互的第二业务量。由于该确认信息表示第一用户终端到期发送第二业务数据，第一代理标识表示如果到期第一用户终端不发送业务数据，则第一代理设备发送第二业务数据，第二代理标识表示如果到期第一代理设备和第一用户终端都不发送业务数据，则第二代理设备发送第二业务数据，因此，第二数据系统的风险得以控制，从而向第二用户终端发送第二业务量。

本申请实施例的业务处理方法，首先接收业务处理平台分配的第二业务码，所述第二业务码是根据所述业务处理平台上记录的与第二用户终端相关的业务信息所配置的；然后根据所述第二业务码获取第二代理设备发送的、用于处理第二业务的第二代理标识；进而采用业务处理平台与第二数据系统之间的第二数据交互通道向第二数据系统发送第二业务请求，所述第二业务请求包括：确认信息、第一代理标识、第二代理标识和待交互的第二业务量；最后接收所述第二数据系统根据所述确认信息、第一代理标识和第二代理标识发送的所述第二业务量。由此，实现了根据业务处理平台上记录的第二用户终端的业务信息配置的第二业务码进行第二业务交互，提高了多系统业务交互的处理效率和灵活性，并且对交互的业务进行风险控制，提高了安全性。

进一步地，基于上述实施例，在步骤404之后，所述方法还包括：

若在预设的第二时间内根据所述确认信息，通过第一用户终端向第二数据系统发送与第二业务量对应的第二业务数据，第二业务交互结束。

进一步地，若在预设的第二时间内第一用户终端没有向所述第二数据系统发送所述第二业务数据，则根据第一代理标识通过第一代理设备向第二数据系统发送第二业务数据，第二业务交互结束。

进一步地，若在预设的第二时间内第一代理设备也没有向所述第二数据系统发送第二业务数据，则根据第二代理标识通过第二代理设备向第二数据系统发送第二业务数据，第二业务交互结束。

本申请实施例的业务处理方法，若在预设的第二时间内根据确认信息通过第一用户终端向第二数据系统发送第二业务数据，第二业务交互结束；若在预设的第二时间内第一用户终端没有向第二数据系统发送第二业务数据，则根据第一代理标识通过第一代理设备向第二数据系统发送第二业务数据，第二业务交互结束；若在预设的第二时间内第一代理设备没有向第二数据系统发送第二业务数据，则根据第二代理标识通过第二代理设备向第二数据系统发送第二业务数据，第二业务交互结束。由此，实现了根据业务处理平台上记录的第二用户终端的业务信息配置的第二业务码进行第二业务交互，提高了多系统业务交互的处理效率和灵活性，并且降低了业务交互的风险。

为了更加清楚地说明图5所示实施例的过程，下面继续以图2所示的基于电子商务平台对多系统进行的第二业务交互过程进行详细说明，本实施例中的第二交互业务为电子商务平台的应收账款融资业务，具体如下：

首先，通过图6和图7说明电子商务平台上第二用户终端与第二数据系统之间进行应收账款融资业务的风险。其中，图6是基于电子商务平台的应收账款融资的正常交互示意图；图7是基于电子商务平台的应收账款融资的异常交互示意图。

基于图2所示实施例的对应关系，本实施例中的第二数据系统为间接融资系统，例如银行系统，或者直接融资系统，例如P2P系统或者SPV系统(即图6或图7所示的资金方)，第二业务具体为第二用户终端向第二数据系统请求的应收账款融资，确认信息为买方收到订单货款后，发送给卖方的名义应收账款债权，第二业务量为资金方向卖方发送的融资款项，获得名义应收账款债权，第二业务数据为回购名义应收账款债权。

参见图6和图7，具体来说，在目前的电商商务平台，为保证买方体验，在买方确认收货后，仍然能申请退款退货从而无法承诺对卖方的该笔应收账款再无争议，如果达成退货协议，买方付款责任消失；保险系统免责，如果买方卖方处于纠纷阶段，保险系统需要等待判责结果；如果判责结果为卖方责任，则保险系统免赔。

由此可见，卖方应收账款融资期限到期，资金方面临刚性对付要求，而买方和保险系统均无付款义务，必须由卖方回购还款，从而导致卖方及时回购履约风险。为了解决资金方的风险问题，通过图8和图10所示实施例说明如下：

图8是本申请另一个实施例的业务处理方法的流程图,基于图6所示实施例，本实施例中第二业务码为授信额度，第二代理设备为业务处理平台，第二处理标识为担保标识，第二数据系统为间接融资系统例如银行系统。图9是基于电子商务平台进行风险控制的应收账款融资的交互示意图。

如图8和图9所示，该业务处理方法包括：

步骤501，卖方接收电子商务平台分配的授信额度，所述授信额度是根据所述电子商务平台上记录的与卖方相关的业务信息所配置的。

步骤502，卖方向电子商务平台发送包含授信额度的处理请求；

步骤503，卖方接收电子商务平台根据授信额度返回的担保标识，以便应用担保标识进行应收账款融资业务。

步骤504，卖方采用电子商务平台与资金方之间建立的第二数据交互通道向资金方发送第二业务请求，所述第二业务请求包括：名义的应收账款债券、担保标识、应付款保证保险保单标识和待请求的融资。

步骤505，资金方根据名义的应收账款债券、担保标识、应付款保证保险保单标，向卖方发送融资款项。

步骤506，根据名义的应收账款债券，买方若在预设的第二时间内向资金方发送还款资金，则第二业务结束，否则，根据应付款保证保险保单标识通过保险系统向资金方发送还款资金，否则，根据担保标识通过业务处理平台向资金方发送还款资金，则第二业务结束。

由此可见，电子商务平台能够有明确有力的判责依据，同时判责为卖方责任的这类保险系统免赔情况时，买方在确认收货时保留争议权的情形下，资金方也能收回该笔货款。通过电子商务平台，解决了线下保险系统与资金方银行系统之间关于免赔条款常有争议的问题，无形中为卖家贴现增信，将该类应收账款融资业务转变为低风险业务。

图10是本申请另一个实施例的业务处理方法的流程图,基于图6所示实施例，本实施例中第二业务码为授信额度，第二代理设备为第一数据系统中的保险系统，第二处理标识为借款履约保证保险保单标识，第二数据系统为直接融资系统例如P2P系统或者SPV系统，P2P系统或者SPV系统包括多个第三用户终端，即多个出借方。图11是基于保险系统进行风险控制的应收账款融资的交互示意图。

如图10和图11所示，该业务处理方法包括：

步骤601，卖方接收电子商务平台分配的授信额度，所述授信额度是根据所述电子商务平台上记录的与卖方相关的业务信息所配置的。

步骤602，卖方采用电子商务平台和保险系统之间建立的第一数据交互通道，向保险系统发送包含授信额度的处理请求；

步骤603，卖方接收保险系统根据授信额度返回的借款履约保证保险保单标识，以便应用借款履约保证保险保单标识进行应收账款融资业务。

步骤604，卖方采用电子商务平台与资金方之间建立的第二数据交互通道向资金方发送第二业务请求，所述第二业务请求包括：名义的应收账款债券、借款履约保证保险保单标识、应付款保证保险保单标识和待请求的融资。

步骤605，资金方根据名义的应收账款债券、借款履约保证保险保单标识、应付款保证保险保单标，向卖方发送融资款项。

步骤606，根据名义的应收账款债券，买方若在预设的第二时间内向资金方发送还款资金，则第二业务结束，否则，根据应付款保证保险保单标识通过保险系统向资金方发送还款资金，否则，根据借款履约保证保险保单标识通过保险系统向资金方发送还款资金，则第二业务结束。

由于间接融资系统例如银行面签开户等时效十分低下，本实施例通过电子商务平台为卖方引入P2P系统、SPV系统等直接融资渠道，与融资平台系统对接当天融资的方式，避免卖方在通过银行等金融机构间接融资时经历的高准入门槛、多手续流程、线下人工反复调查、授信额度受限、融资成本高昂等问题，提高卖方资金融通效率的同时，极大降低了融资成本。

基于上述各实施例，需要说明的是，本实施例提供的业务处理方法不仅局限于延期付款这类交易模式，可通过对不同的交易环节(下单、支付、发货、确认收货、交易结束)、不同的交易对象植入买方或卖方的信用保证险及交易对象的融资实现对不同的交易流程与场景的信用保险与融资，与交易流程及交易对象可完全解耦，可配置多种信用险和融资的模板。

由此可见，电子商务平台可根据卖方的业务信息，对不同风险的卖方实现分层风险运营和定价。电子商务平台针对卖方和买方的风险控制及运营，形成一套完整的风险可控的电子商务平台业务交互方法。

图12是本申请一个实施例的第一用户终端的结构示意图。

如图12所示，该第一用户终端包括：

第一接收模块11，用于接收业务处理平台分配的第一业务码，所述第一业务码是根据所述业务处理平台上记录的与第一用户终端相关的业务信息所配置的；

第一获取模块12，用于根据所述第一业务码获取第一代理设备发送的、用于处理第一业务的第一代理标识；

第一请求模块13，用于向所述业务处理平台上的第二用户终端发送第一业务请求，所述第一业务请求包括：第一代理标识和待交互的第一业务量；

第二接收模块14，用于接收所述第二用户终端根据所述第一代理标识发送的所述第一业务量。

需要说明的是，前述对业务处理方法实施例的解释说明和技术效果也适用于该实施例的第一用户终端，此处不再赘述。

图13是本申请另一个实施例的第一用户终端的结构示意图，

如图13所示，基于图12所示实施例，

在一个实施例中，当所述第一代理设备为所述业务处理平台时，所述第一获取模块12，包括：

第一发送单元121，用于向所述业务处理平台发送包含第一业务码的处理请求；

第一接收单元122，用于接收所述业务处理平台根据所述第一业务码返回的第一处理标识，以便应用所述第一处理标识作为第一代理标识处理所述第一业务。

在另一个实施例中，当所述第一代理设备为第一数据系统时，所述第一获取模块12，包括：

第二发送单元123，用于采用所述业务处理平台与所述第一数据系统之间建立的第一数据交互通道，向所述第一数据系统发送包含第一业务码的处理请求；

第二接收单元124，用于接收所述第一数据系统根据所述第一业务码返回的第二处理标识，以便应用所述第二处理标识作为第一代理标识处理所述第一业务。

其中，所述第一数据系统为增信数据系统，其中，所述增信数据系统包括：保险系统和担保系统。

进一步地，第一用户终端还包括：

第一处理模块15，用于在预设的第一时间内向所述第二用户终端发送与所述第一业务量对应的第一业务数据。

进一步地，所述第一处理模块15还用于：

若在预设的第一时间内未向所述第二用户终端发送所述第一业务数据，则根据所述第一代理标识通过第一代理设备向所述第二用户终端发送所述第一业务数据。

为了实现上述实施例，本申请还提出一种第二用户终端。

图14是本申请一个实施例的第二用户终端的结构示意图。

如图14所示，该第二用户终端包括：

第三接收模块21，用于接收第一用户终端发送的第一业务请求，其中，所述第一业务请求包括：第一代理标识和待交互的第一业务量，其中，所述第一代理标识是所述第一用户终端根据所述业务处理平台分配的第一业务码从第一代理设备获取的；

交互模块22，用于根据所述第一代理标识向所述第一用户终端发送所述第一业务量，并接收第一用户终端发送的确认信息。

需要说明的是，前述对业务处理方法实施例的解释说明和技术效果也适用于该实施例的第二用户终端，此处不再赘述。

图15是本申请另一个实施例的第二用户终端的结构示意图。

如图15所示，基于图14所示实施例，还包括：

第四接收模块23，用于接收业务处理平台分配的第二业务码，所述第二业务码是根据所述业务处理平台上记录的与第二用户终端相关的业务信息所配置的；

第二获取模块24，用于根据所述第二业务码从第二代理设备获取用于处理第二业务的第二代理标识；

第二请求模块25，用于采用所述业务处理平台与第二数据系统之间建立的第二数据交互通道，向所述第二数据系统发送第二业务请求，所述第二业务请求包括：所述确认信息所述第二代理标识、所述第一代理标识，以及待交互的第二业务量；

第五接收模块26，用于接收所述第二数据系统根据所述确认信息、所述第二代理标识和所述第一代理标识发送的所述第二业务量。

其中，所述第二数据系统为融资数据系统，其中，所述融资数据系统包括：银行系统、P2P系统和SPV系统。

图16是本申请另一个实施例的第二用户终端的结构示意图。

如图16所示，基于图15所示实施例，

在一个实施例中，当所述第二代理设备为所述业务处理平台时，所述第二获取模块24，包括：

第三发送单元241，用于向所述业务处理平台发送包含第二业务码的处理请求；

第三接收单元242，用于接收所述业务处理平台根据所述第二业务码返回的第三处理标识，以便应用所述第三处理标识作为第二代理标识处理所述第二业务。

在另一个实施例中，当所述第二代理设备为第一数据系统时，所述第二获取模块24，包括：

第四发送单元243，用于采用所述业务处理平台与所述第一数据系统之间建立的第一数据交互通道，向所述第一数据系统发送携带第二业务码的处理请求；

第四接收单元244，用于接收所述第一数据系统根据所述第二业务码返回的第四处理标识，以便应用所述第四处理标识作为第二代理标识处理所述第二业务。

进一步地，第二用户终端还包括：

第二处理模块27，用于在预设的第二时间内根据所述确认信息，通过第一用户终端向所述第二数据系统发送与所述第二业务量对应的第二业务数据。

进一步地，所述第二处理模块27，还用于：

若在预设的第二时间内所述第一用户终端未向所述第二数据系统发送所述第二业务数据，则根据第一代理标识通过第一代理设备向所述第二数据系统发送所述第二业务数据。

进一步地，所述第二处理模块27，还用于：

若在所述第二时间内所述第一代理设备未向所述第二数据系统发送所述第二业务数据，则根据所述第二代理标识通过第二代理设备向所述第二数据系统发送所述第二业务数据。

其中，所述第一代理设备包括：第一数据系统和业务处理平台。

图17是本申请一个实施例的业务处理系统的结构示意图。如图17所示，该业务处理系统包括：业务处理平台1和第一代理设备2，其中，所述业务处理平台1上包括：多个第一用户终端3和多个第二用户终端4，其中，所述第一用户终端3可以采用本发明上述实施例提供的第一用户终端3，所述第二用户终端4可以采用本发明上述实施例提供的第二用户终端。

其中，所述业务处理平台包括：电子商务平台、电信商务平台和物流运营平台。

需要说明的是，前述对业务处理方法实施例的解释说明也适用于该实施例的业务处理系统，此处不再赘述。

图18是本申请另一个实施例的业务处理系统的结构示意图。如图18所示，基于图17所示实施例，还包括：第二代理设备5、以及多个第二数据系统6。

所述第二数据系统为融资数据系统，所述融资数据系统包括：间接融资数据系统和直接融资数据系统。

当所述间接融资数据系统为至少一个银行系统时，每个银行系统与所述业务处理平台之间建立第二数据交互通道。

当所述直接融资数据系统为至少一个P2P系统或SPV系统时，每个P2P系统或SPV系统与所述业务处理平台之间建立第二数据交互通道，其中，每个P2P系统或SPV系统包括多个第三用户终端。

本申请实施例的业务处理系统，通过业务处理平台记录的与第二用户终端相关的业务信息为第二用户终端分配第二业务码，第二用户终端根据所述第二业务码获取第二代理设备发送的、用于处理第二业务的第二代理标识，并根据第一用户终端发送的确认信息、第一代理标识、第二代理标识与第二数据系统进行第二业务交互。由此，实现了根据业务处理平台上记录的第一用户终端的业务信息配置的第一业务码进行第一业务交互，以及根据业务处理平台上记录的第二用户终端的业务信息配置的第二业务码进行第二业务交互，提高了多系统业务交互的处理效率和灵活性，并且对交互的业务进行风险控制，提高了安全性。

所述第一代理设备和所述第二代理设备均为所述业务处理平台。或者，

所述第二代理设备为所述业务处理平台，所述第一代理设备为至少一个第一数据系统，其中，每个第一数据系统和所述业务处理平台之间建立第一数据交互通道。或者，

所述第一代理设备为所述业务处理平台，所述第二代理设备为至少一个第一数据系统，其中，每个第一数据系统和所述业务处理平台之间建立第一数据交互通道。其中，所述第一数据系统为增信数据系统，其中，所述增信数据系统包括：保险系统和担保系统。

需要说明的是，基于上述实施例，由于第一代理设备、第二代理设备以及第一数据系统和第二数据系统的类型不同，业务处理系统的结构示意图有很多具体的应用变形，根据具体的应用场景进行选择，本实施例不一一示出。

请参阅图19，本申请还提供了一种业务处理方法。该方法可以包括以下步骤。

步骤1901：接收业务处理平台分配的第一业务码，所述第一业务码是根据所述业务处理平台上记录的与第一用户终端相关的业务信息所配置的。

在本实施方式中，所述业务处理平台可以为电子商务平台、电信商务平台或者物流运营平台等。在该述业务处理平台上的第一用户终端和第二用户终端可以通过该业务处理平台完成具体的业务处理活动。例如淘宝网可以是一个业务处理平台，1688网也可以是一个业务处理平台。

在本实施方式中，所述第一用户终端可以是所述业务处理平台上某个具体业务处理活动中发出具体业务请求的一方。相应地，所述第二用户终端可以是该业务处理平台上在该业务处理活动中接收业务请求，并根据情况决定是否接受业务请求的一方。例如，在淘宝网这个业务处理平台上，在买家B向卖家C购买A商品的交易过程中，第一用户终端就可以为购买A商品的买家B。第二用户终端就可以为出售A商品的卖家C。需要说明的是，第一用户终端和第二用户终端的身份是可以根据具体情况进行相应转换的。例如，在淘宝网中，在卖家C向批发商D批发A商品的交易过程中。卖家C这时就可以是第一用户终端，而批发商D则可以是第二用户终端。

在本实施方式中，所述第一业务码可以为由业务处理平台根据第一用户终端在该业务处理平台上所记录的相关的业务信息所分配给第一用户终端对应的一种标记。其中，上述相关的业务信息具体可以包括：第一用户终端在该业务处理平台上注册登记信息、业务处理活动的记录信息和参与业务处理活动的其他方对第一用户终端的评价信息等。

在本实施方式中，所述接收业务处理平台分配的第一业务码，所述第一业务码是根据所述业务处理平台上记录的与第一用户终端相关的业务信息所配置的。具体可以为，第一用户终端接收业务处理平台分配的第一业务码，其中，上述的第一业务码是业务处理平台根据记录在业务处理平台上的第一用户终端的相关业务信息所分配的。上述相关的业务信息可以包括：第一用户终端在该业务处理平台上注册登记信息、业务处理活动的记录信息和参与业务处理活动的其他方对第一用户终端的评价信息等。例如，在淘宝网中，买家作为第一用户终端，可以接收淘宝网根据买家的相关信息分配给买家的信用评价。即淘宝网可以根据买家注册信息、买家在交易活动中付款情况的记录信息和买家长期进行交易活动中卖家对买家的评价信息，按照淘宝网的评价策略，分配给买家相应的信用评价作为第一业务码。

步骤1902：根据所述第一业务码获取第一代理设备发送的、用于处理第一业务的第一代理标识。

在本实施方式中，所述第一代理设备可以是为业务处理平台上某个业务处理活动进行代理服务的一方。其中，代理服务可以是对业务处理活动的担保，也可以是对业务处理活动的监管等。具体地，上述第一代理设备可以是一个独立的保险系统，也可以是该业务处理平台自身，还可以是银行等。对于第一代理设备，本申请在此不作限定。

在本实施方式中，所述第一业务可以为第一用户终端所要求的商品订单，也可以为第一用户终端所要求的某种服务。对于第一业务的具体内容，本申请不作限定。

在本实施方式中，所述第一代理标识可以为第一代理设备根据第一用户终端的第一业务码向第一用户终端发出的确认提供代理服务的标识。

在本实施方式中，根据所述第一业务码获取第一代理设备发送的、用于处理第一业务的第一代理标识。具体可以为，第一用户终端接收第一代理设备发送的第一代理标识。其中，第一代理标识是第一代理设备根据第一业务码向第一用户终端发送的。例如，1688网的商户E在向批发商T批发商品时，可以请求某保险公司为此次交易担保。某保险公司可以根据商户E的信用评价，决定为本次交易担保，并向商户E发送担保凭证，作为所述的第一代理标识，以证明对此次交易进行担保。

步骤1903：向所述业务处理平台上发送第一业务请求，所述第一业务请求附带有第一代理标识；其中，所述第一代理标识用于提供给第二用户终端。

在本实施方式中，所述第一业务请求可以为第一用户终端向业务平台上的第二用户终端发出的进行第一业务处理活动的请求。其中，该第一业务请求还附带有提供给第二用终端的第一代理标识。第二用户终端可以凭借该第一代理表示，享有第一代理设备提供的相应的代理服务。例如，上述第一业务请求可以是一个订单请求，该订单请求还附带有某保险公司对此次交易活动进行担保的担保凭证。

在本实施方式中，向所述业务处理平台上发送第一业务请求，所述第一业务请求附带有第一代理标识；其中，所述第一代理标识用于提供给第二用户终端。具体可以为第一用户终端将第一业务请求发送到业务处理平台，其中该第一业务请求还附带有第一代理标识。业务处理平台根据该第一业务请求，将附带有第一代理标识的第一业务请求发送至对应的该业务处理平台上的第二用户终端。当然，也可以是第一用户终端，通过业务处理平台提供的通信渠道，直接向第二用户终端发送附带有第一代理标识的第一业务请求。例如，淘宝网中，买家先向淘宝网发送商品A的订单请求，该订单请求附带有保险公司提供的保险凭证。淘宝网再将附带有保险凭证的商品A的订单请求发送到对应的卖家。

步骤1904：接收针对所述第一业务请求的结果信息。

在本实施方式中，所述的结果信息可以是第二用户终端根据附带有第一代理标识的第一业务请求所发出的确认接受第一业务请求的确认信息或者拒绝接受第一业务请求的拒绝信息。也可以是业务处理平台根据第二用户终端的指示，产生的相应的结果信息。其中，如果第二用户终端指示接受第一业务请求，该结果信息可以是业务处理平台生成的接受信息。如果第二用户终端指示拒绝接受第一业务请求，该结果信息可以是业务处理平台生成的拒绝信息。需要说明的是，所述第二用户终端的指示，具体可以是第二用户终端根据第一业务请求和第一代理标识，如果接受第一业务请求，则在业务处理平台的相应的指示页面中点击笑脸图标，如果拒绝接受第一业务请求时，则在业务处理平台相应的指示页面点击哭脸图标。对此，本申请不作限定。

在本实施方式中，接收针对所述第一业务请求的结果信息。具体可以为，第一用户终端接收针对第一业务请求的结果信息。该结果信息可以是接受第一业务请求的确认信息，也可以是拒绝接受第一业务请求的拒绝信息。其中，第一用户终端可以通过业务处理平台接收第二用户终端针对第一业务请求的发出的结果信息。也可以通过业务处理平台接收业务处理平台根据第二用户终端的指示生成的相应结果信息。还可以通过业务处理平台提供的通信渠道直接接收第二用户终端发送的结果信息。对于第一用户终端接收针对第一业务请求的结果信息的具体方式，本申请不作限定。

在一个场景示例中，可以参阅3。应用本申请提供的业务处理方法，1688网上的商户X向批发商Z购买一批商品D的过程可以包括以下步骤。其中，商户X可以为图中的买方，批发商Z可以为图中的卖方，1688网可以为图中的电子商务平台。商户X接收1688网分配的信用评价。其中，根据商户X的注册信息、商户X在1688网中交易活动中的付款情况的记录信息和商户X长期进行交易活动中其他商户对商户X的评价信息，按照相应的信用评价策略，1688网为商户X分配对应的信用评价。根据商户X的信用评价，接收与1688网合作的保险系统发送的担保标识。其中，上述保险系统根据商户X的信用评价，确定是否为商户X进行担保。如果确定为商户X进行担保，向商户X发送担保标识作为保险凭证。商户X通过1688网提供的通信渠道向批发商Z发送附带有保险标识的商品D的订单请求。其中，上述保险标识用于提供给批发商Z。如果商户X到期未支付货款，批发商Z可以根据根据该担保标识从保险系统先获取相应的货款。商户X接收针对商品D的订单请求的结果信息。其中，如果批发商Z根据附带有保险标识的商品D的订单请求，确定接受商户X的商品D的订单请求，承诺在预定期限向商户X发送该订单请求所请求的商品D，并允许商户X在收到商品D后可以延缓预设天数再支付相应货款，批发商Z可以通过点击1688网中的交易指示页面中的笑脸图标，指示确认接受商户X的附带有保险标识的商品D的订单请求。1688网根据批发商Z的指示，向商户X发送对应的确认接受商品D的订单请求的结果信息。通过本申请提供的业务处理方法，提高了交易活动的效率和灵活性，同时降低了交易风险，提高了安全性。

由上述描述可知，本申请提供的业务处理方法，首先接收业务处理平台分配的第一业务码；然后根据第一业务码获取第一代理设备发送的、用于处理第一业务的第一代理标识；进而向所述业务处理平台上的第二用户终端发送第一业务请求，所述第一业务请求附带有第一代理码；接收针对所述第一业务请求的结果信息。通过上述方法解决了现有的业务处理方法中存在的业务处理活动仅能局限于有多次业务处理活动经历的第一用户终端和第二用户终端和第二用户终端之间和业务处理活动风险大的技术问题。实现了根据业务处理平台上记录的第一用户终端的业务信息配置的第一业务码进行第一业务处理，提高了多系统的业务处理的处理效率和灵活性，并且对业务处理活动进行风险控制，降低了业务处理的风险，提高了安全性。

在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本申请的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不必须针对的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。

此外，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。在本申请的描述中，“多个”的含义是至少两个，例如两个，三个等，除非另有明确具体的限定。

流程图中或在此以其他方式描述的任何过程或方法描述可以被理解为，表示包括一个或更多个用于实现特定逻辑功能或过程的步骤的可执行指令的代码的模块、片段或部分，并且本申请的优选实施方式的范围包括另外的实现，其中可以不按所示出或讨论的顺序，包括根据所涉及的功能按基本同时的方式或按相反的顺序，来执行功能，这应被本申请的实施例所属技术领域的技术人员所理解。

在流程图中表示或在此以其他方式描述的逻辑和/或步骤，例如，可以被认为是用于实现逻辑功能的可执行指令的定序列表，可以具体实现在任何计算机可读介质中，以供指令执行系统、装置或设备(如基于计算机的系统、包括处理器的系统或其他可以从指令执行系统、装置或设备取指令并执行指令的系统)使用，或结合这些指令执行系统、装置或设备而使用。就本说明书而言，"计算机可读介质"可以是任何可以包含、存储、通信、传播或传输程序以供指令执行系统、装置或设备或结合这些指令执行系统、装置或设备而使用的装置。计算机可读介质的更具体的示例(非穷尽性列表)包括以下：具有一个或多个布线的电连接部(电子装置)，便携式计算机盘盒(磁装置)，随机存取存储器(RAM)，只读存储器(ROM)，可擦除可编辑只读存储器(EPROM或闪速存储器)，光纤装置，以及便携式光盘只读存储器(CDROM)。另外，计算机可读介质甚至可以是可在其上打印所述程序的纸或其他合适的介质，因为可以例如通过对纸或其他介质进行光学扫描，接着进行编辑、解译或必要时以其他合适方式进行处理来以电子方式获得所述程序，然后将其存储在计算机存储器中。

应当理解，本申请的各部分可以用硬件、软件、固件或它们的组合来实现。在上述实施方式中，多个步骤或方法可以用存储在存储器中且由合适的指令执行系统执行的软件或固件来实现。例如，如果用硬件来实现，和在另一实施方式中一样，可用本领域公知的下列技术中的任一项或他们的组合来实现：具有用于对数据信号实现逻辑功能的逻辑门电路的离散逻辑电路，具有合适的组合逻辑门电路的专用集成电路，可编程门阵列(PGA)，现场可编程门阵列(FPGA)等。

本技术领域的普通技术人员可以理解实现上述实施例方法携带的全部或部分步骤是可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，该程序在执行时，包括方法实施例的步骤之一或其组合。

此外，在本申请各个实施例中的各功能单元可以集成在一个处理模块中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。所述集成的模块如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。

上述提到的存储介质可以是只读存储器，磁盘或光盘等。尽管上面已经示出和描述了本申请的实施例，可以理解的是，上述实施例是示例性的，不能理解为对本申请的限制，本领域的普通技术人员在本申请的范围内可以对上述实施例进行变化、修改、替换和变型。

Claims

1.一种业务处理方法，其特征在于，包括：

接收业务处理平台分配的第一业务码，所述第一业务码是根据所述业务处理平台上记录的与第一用户终端相关的业务信息所配置的；

根据所述第一业务码获取第一代理设备发送的、用于处理第一业务的第一代理标识；

向所述业务处理平台上的第二用户终端发送第一业务请求，所述第一业务请求包括：第一代理标识和待交互的第一业务量；

接收所述第二用户终端根据所述第一代理标识发送的所述第一业务量。

2.如权利要求1所述的业务处理方法，其特征在于，当所述第一代理设备为所述业务处理平台时，所述根据所述第一业务码获取第一代理设备发送的、用于处理第一业务的第一代理标识，包括：

向所述业务处理平台发送包含第一业务码的处理请求；

3.如权利要求1所述的业务处理方法，其特征在于，当所述第一代理设备为第一数据系统时，所述根据所述第一业务码获取第一代理设备发送的、用于处理第一业务的第一代理标识，包括：

4.如权利要求3所述的业务处理方法，其特征在于，所述第一数据系统为增信数据系统，其中，所述增信数据系统包括：保险系统和担保系统。

5.如权利要求1-4任一所述的业务处理方法，其特征在于，所述方法还包括：

在预设的第一时间内向所述第二用户终端发送与所述第一业务量对应的第一业务数据。

6.如权利要求5所述的业务处理方法，其特征在于，所述方法还包括：

7.如权利要求1-4任一所述的业务处理方法，其特征在于，

所述业务处理平台包括：电子商务平台、电信商务平台和物流运营平台；

所述第一业务码包括：信用积分、授信额度和评价级别。

8.一种业务处理方法，其特征在于，包括：

接收第一用户终端发送的第一业务请求，其中，所述第一业务请求包括：第一代理标识和待交互的第一业务量，其中，所述第一代理标识是所述第一用户终端根据所述业务处理平台分配的第一业务码从第一代理设备获取的；

根据所述第一代理标识向所述第一用户终端发送所述第一业务量，并接收第一用户终端发送的确认信息。

9.如权利要求8所述的业务处理方法，其特征在于，所述接收第一用户终端发送的确认信息之后，还包括：

接收所述业务处理平台分配的第二业务码，所述第二业务码是根据所述业务处理平台上记录的与第二用户终端相关的业务信息所配置的；

根据所述第二业务码从第二代理设备获取用于处理第二业务的第二代理标识；

采用所述业务处理平台与第二数据系统之间建立的第二数据交互通道，向所述第二数据系统发送第二业务请求，所述第二业务请求包括：所述确认信息所述第二代理标识、所述第一代理标识，以及待交互的第二业务量；

接收所述第二数据系统根据所述确认信息、所述第二代理标识和所述第一代理标识发送的所述第二业务量。

10.如权利要求9所述的业务处理方法，其特征在于，所述第二数据系统为融资数据系统，其中，所述融资数据系统包括：银行系统、P2P系统和SPV系统。

11.如权利要求9所述的业务处理方法，其特征在于，当所述第二代理设备为所述业务处理平台时，所述根据所述第二业务码获取第二代理设备发送的、用于处理第二业务的第二代理标识，包括：

向所述业务处理平台发送包含第二业务码的处理请求；

12.如权利要求9所述的业务处理方法，其特征在于，当所述第二代理设备为第一数据系统时，所述根据所述第二业务码获取第二代理设备发送的、用于处理第二业务的第二代理标识，包括：

采用所述业务处理平台与所述第一数据系统之间建立的第一数据交互通道，向所述第一数据系统发送携带第二业务码的处理请求；

13.如权利要求12所述的业务处理方法，其特征在于，所述第一数据系统为增信数据系统，其中，所述增信数据系统包括：保险系统和担保系统。

14.如权利要求9-12任一所述的业务处理方法，其特征在于，还包括：

在预设的第二时间内根据所述确认信息，通过第一用户终端向所述第二数据系统发送与所述第二业务量对应的第二业务数据。

15.如权利要求14所述的业务处理方法，其特征在于，还包括：

16.如权利要求15所述的业务处理方法，其特征在于，还包括：

17.如权利要求15或16所述的业务处理方法，其特征在于，所述第一代理设备包括：第一数据系统和业务处理平台。

18.如权利要求9-12任一所述的业务处理方法，其特征在于，

所述第二业务码包括：信用积分、授信额度和评价级别。

19.一种第一用户终端，其特征在于，包括：

第一接收模块，用于接收业务处理平台分配的第一业务码，所述第一业务码是根据所述业务处理平台上记录的与第一用户终端相关的业务信息所配置的；

第一获取模块，用于根据所述第一业务码获取第一代理设备发送的、用于处理第一业务的第一代理标识；

第一请求模块，用于向所述业务处理平台上的第二用户终端发送第一业务请求，所述第一业务请求包括：第一代理标识和待交互的第一业务量；

第二接收模块，用于接收所述第二用户终端根据所述第一代理标识发送的所述第一业务量。

20.如权利要求19所述的第一用户终端，其特征在于，当所述第一代理设备为所述业务处理平台时，所述第一获取模块，包括：

第一发送单元，用于向所述业务处理平台发送包含第一业务码的处理请求；

第一接收单元，用于接收所述业务处理平台根据所述第一业务码返回的第一处理标识，以便应用所述第一处理标识作为第一代理标识处理所述第一业务。

21.如权利要求19所述的第一用户终端，其特征在于，当所述第一代理设备为第一数据系统时，所述第一获取模块，包括：

第二发送单元，用于采用所述业务处理平台与所述第一数据系统之间建立的第一数据交互通道，向所述第一数据系统发送包含第一业务码的处理请求；

第二接收单元，用于接收所述第一数据系统根据所述第一业务码返回的第二处理标识，以便应用所述第二处理标识作为第一代理标识处理所述第一业务。

22.如权利要求21所述的第一用户终端，其特征在于，所述第一数据系统为增信数据系统，其中，所述增信数据系统包括：保险系统和担保系统。

23.如权利要求19-22任一所述的第一用户终端，其特征在于，还包括：

第一处理模块，用于在预设的第一时间内向所述第二用户终端发送与所述第一业务量对应的第一业务数据。

24.如权利要求23所述的第一用户终端，其特征在于，所述第一处理模块还用于：

25.一种第二用户终端，其特征在于，包括：

第三接收模块，用于接收第一用户终端发送的第一业务请求，其中，所述第一业务请求包括：第一代理标识和待交互的第一业务量，其中，所述第一代理标识是所述第一用户终端根据所述业务处理平台分配的第一业务码从第一代理设备获取的；

交互模块，用于根据所述第一代理标识向所述第一用户终端发送所述第一业务量，并接收第一用户终端发送的确认信息。

26.如权利要求25所述的第二用户终端，其特征在于，还包括：

第四接收模块，用于接收业务处理平台分配的第二业务码，所述第二业务码是根据所述业务处理平台上记录的与第二用户终端相关的业务信息所配置的；

第二获取模块，用于根据所述第二业务码从第二代理设备获取用于处理第二业务的第二代理标识；

第二请求模块，用于采用所述业务处理平台与第二数据系统之间建立的第二数据交互通道，向所述第二数据系统发送第二业务请求，所述第二业务请求包括：所述确认信息所述第二代理标识、所述第一代理标识，以及待交互的第二业务量；

第五接收模块，用于接收所述第二数据系统根据所述确认信息、所述第二代理标识和所述第一代理标识发送的所述第二业务量。

27.如权利要求26所述的第二用户终端，其特征在于，所述第二数据系统为融资数据系统，其中，所述融资数据系统包括：银行系统、P2P系统和SPV系统。

28.如权利要求26所述的第二用户终端，其特征在于，当所述第二代理设备为所述业务处理平台时，所述第二获取模块，包括：

第三发送单元，用于向所述业务处理平台发送包含第二业务码的处理请求；

第三接收单元，用于接收所述业务处理平台根据所述第二业务码返回的第三处理标识，以便应用所述第三处理标识作为第二代理标识处理所述第二业务。

29.如权利要求26所述的第二用户终端，其特征在于，当所述第二代理设备为第一数据系统时，所述第二获取模块，包括：

第四发送单元，用于采用所述业务处理平台与所述第一数据系统之间建立的第一数据交互通道，向所述第一数据系统发送携带第二业务码的处理请求；

第四接收单元，用于接收所述第一数据系统根据所述第二业务码返回的第四处理标识，以便应用所述第四处理标识作为第二代理标识处理所述第二业务。

30.如权利要求29所述的第二用户终端，其特征在于，所述第一数据系统为增信数据系统，其中，所述增信数据系统包括：保险系统和担保系统。

31.如权利要求26-30任一所述的第二用户终端，其特征在于，还包括：

第二处理模块，用于在预设的第二时间内根据所述确认信息，通过第一用户终端向所述第二数据系统发送与所述第二业务量对应的第二业务数据。

32.如权利要求31所述的第二用户终端，其特征在于，所述第二处理模块，还用于：

33.如权利要求32所述的第二用户终端，其特征在于，所述第二处理模块，还用于：

34.如权利要求32或33所述的第二用户终端，其特征在于，所述第一代理设备包括：第一数据系统和业务处理平台。

35.一种业务处理系统，其特征在于，包括：业务处理平台和第一代理设备，其中，所述业务处理平台上包括：多个第一用户终端和多个第二用户终端，其中，所述第一用户终端可以采用如权利要求19-24任一所述的第一用户终端，所述第二用户终端可以采用如权利要求25-34任一所述的第二用户终端。

36.如权利要求35所述的业务处理系统，其特征在于，还包括：第二代理设备、以及多个第二数据系统。

37.如权利要求36所述的业务处理系统，其特征在于，所述第二数据系统为融资数据系统，所述融资数据系统包括：间接融资数据系统和直接融资数据系统。

38.如权利要求37所述的业务处理系统，其特征在于，当所述间接融资数据系统为至少一个银行系统时，每个银行系统与所述业务处理平台之间建立第二数据交互通道。

39.如权利要求37所述的业务处理系统，其特征在于，当所述直接融资数据系统为至少一个P2P系统或SPV系统时，每个P2P系统或SPV系统与所述业务处理平台之间建立第二数据交互通道，其中，每个P2P系统或SPV系统包括多个第三用户终端。

40.如权利要求36所述的业务处理系统，其特征在于，所述第一代理设备和所述第二代理设备均为所述业务处理平台。

41.如权利要求36所述的业务处理系统，其特征在于，所述第二代理设备为所述业务处理平台，所述第一代理设备为至少一个第一数据系统，其中，每个第一数据系统和所述业务处理平台之间建立第一数据交互通道。

42.如权利要求36所述的业务处理系统，其特征在于，所述第一代理设备为所述业务处理平台，所述第二代理设备为至少一个第一数据系统，其中，每个第一数据系统和所述业务处理平台之间建立第一数据交互通道。

43.如权利要求41或42所述的业务处理系统，其特征在于，所述第一数据系统为增信数据系统，其中，所述增信数据系统包括：保险系统和担保系统。

44.如权利要求35所述的业务处理系统，其特征在于，所述业务处理平台包括：电子商务平台、电信商务平台和物流运营平台。

45.一种业务处理方法，其特征在于，包括：

向所述业务处理平台上发送第一业务请求，所述第一业务请求附带有第一代理标识；其中，所述第一代理标识用于提供给第二用户终端；

接收针对所述第一业务请求的结果信息。