CN112884483B - 一种担保方法、装置及设备 - Google Patents

Abstract

本说明书实施例公开了一种担保方法、装置及设备。该方法包括：获取目标订单的总价款信息；基于总价款信息，确定服务提供机构需提供的目标担保金额；获取所述服务提供机构的用于表示可用担保金额的剩余额度的状态信息；根据该状态信息以及目标担保金额，判断该目标订单是否在服务提供机构的可担保范围内，当目标订单在所述服务提供机构的可担保范围内时，允许执行所述目标订单对应的操作。

Description

一种担保方法、装置及设备

技术领域

本申请涉及计算机技术领域，尤其涉及一种担保方法、装置及设备。

背景技术

信用原意指在为人处事及各种社会交往中，人们必须遵守的“诚实、守信”的道德规范和行为准则。在经济范畴中，信用是一种建立在对受信人在特定期限内付款或还款承诺信任的基础上的能力，也可以是受信人无须付现就可以获取商品、服务或资金的能力。信用是市场经济的通行证。现代市场经济是建立在法制基础上的信用经济。

随着计算机和互联网技术的迅速发展，很多业务都可以在网络上进行，给用户带来了极大的便利。与此同时，业务提供方也承担了很多的风险，具体地，一些用户可以是恶意的，若业务提供商在没有防范措施的情况下直接接受这些用户的业务，可能遭受损失。因此，在实际应用中，用户与商家可以基于信用进行交易。在交易过程中，商家具有良好的信用，可以具有更高的曝光率；用户具有良好的信用，可以享受更好的服务。

因此，如何提供一种更为可靠的担保方案，以保障用户与商家之间的交易安全。

发明内容

本说明书实施例提供一种担保方法、装置及设备，以保障订单交易的安全性。

为解决上述技术问题，本说明书实施例是这样实现的：

本说明书实施例提供的一种担保方法，包括：

获取目标订单的总价款信息；

基于所述总价款信息，确定服务提供机构需提供的目标担保金额；所述目标担保金额用于为所述服务提供机构提供的服务提供担保；

获取所述服务提供机构的可用担保金额的状态信息；所述状态信息用于表示所述可用担保金额的剩余额度；

根据所述状态信息以及所述目标担保金额，判断所述目标订单是否在所述服务提供机构的可担保范围内，得到判断结果；

当所述判断结果表示所述目标订单在所述服务提供机构的可担保范围内时，允许执行所述目标订单对应的操作。

本说明书实施例提供的一种担保装置，包括：

总价款信息获取模块，用于获取目标订单的总价款信息；

目标担保金额确定模块，用于基于所述总价款信息，确定服务提供机构需提供的目标担保金额；所述目标担保金额用于为所述服务提供机构提供的服务提供担保；

可用担保金额状态信息获取模块，用于获取所述服务提供机构的可用担保金额的状态信息；所述状态信息用于表示所述可用担保金额的剩余额度；

判断模块，用于根据所述状态信息以及所述目标担保金额，判断所述目标订单是否在所述服务提供机构的可担保范围内，得到判断结果；

操作执行指令模块，用于当所述判断结果表示所述目标订单在所述服务提供机构的可担保范围内时，允许执行所述目标订单对应的操作。

本说明书实施例提供的一种担保设备，包括：

至少一个处理器；以及，

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够：

获取目标订单的总价款信息；

基于所述总价款信息，确定服务提供机构需提供的目标担保金额；所述目标担保金额用于为所述服务提供机构提供的服务提供担保；

获取所述服务提供机构的可用担保金额的状态信息；所述状态信息用于表示所述可用担保金额的剩余额度；

根据所述状态信息以及所述目标担保金额，判断所述目标订单是否在所述服务提供机构的可担保范围内，得到判断结果；

当所述判断结果表示所述目标订单在所述服务提供机构的可担保范围内时，允许执行所述目标订单对应的操作。

本说明书实施例提供的一种计算机可读介质，其上存储有计算机可读指令，所述计算机可读指令可被处理器执行以实现一种担保方法。

本说明书一个实施例实现了能够达到以下有益效果：通过获取目标订单的总价款信息；基于总价款信息，确定服务提供机构需提供的目标担保金额；获取所述服务提供机构的用于表示可用担保金额的剩余额度的状态信息；根据该状态信息以及目标担保金额，判断该目标订单是否在服务提供机构的可担保范围内，当目标订单在所述服务提供机构的可担保范围内时，允许执行所述目标订单对应的操作。通过上述方法，能够担保在交易过程中的交易安全性。

附图说明

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

图1为本说明书实施例中一种担保方法的场景示意图；

图2为本说明书实施例提供的一种担保方法的流程示意图；

图3为本说明书实施例提供的装修担保方法的流程示意图；

图4是本说明书实施例提供的一种担保装置的结构示意图；

图5是本说明书实施例提供的一种担保设备的结构示意图。

具体实施方式

为使本说明书一个或多个实施例的目的、技术方案和优点更加清楚，下面将结合本说明书具体实施例及相应的附图对本说明书一个或多个实施例的技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本说明书的一部分实施例，而不是全部的实施例。基于本说明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本说明书一个或多个实施例保护的范围。

以下结合附图，详细说明本说明书各实施例提供的技术方案。

信用评分：信用评分可以指运用统计方法，基于历史数据，对消费者或中小企业未来信用风险的综合评估。信用评分应当忠实于过去的历史数据来推测未来，信用评分主要用于授信额度较小、调查成本较高的领域，如信用卡领域，在自动、批量发放信贷时，信用评分的作用非常重要。信用评分在不同的应用场景中可以包括风险评分、收益评分、响应度评分、客户流失(忠诚度)评分、催收评分、信用卡发卡审核评分、房屋按揭贷款发放审核评分、信用额度核定评分等。

装修担保金：装修公司交由支付宝管理的用以保障买方用户合法权益的担保形式。

现有技术中，以装修场景为例，室内装修行业市场缺乏一定规范性，买方用户与装修公司之间的合同纠纷频发，导致双方合作缺乏基本的信用基础。目前，市场主流装修付款方式是买方用户先付款再施工，这导致买方用户在实际装修过程中处于维权劣势，无法对装修公司形成制约；同时买方用户在选择装修公司时没有相对透明的参考标准，无法辨别获得信息的真伪，容易被不良商家以营销手段诱骗最终受到损失。

因此，市场亟需一个可行度高的交易支付第三方平台和新的支付方式。

现有技术中，也有类似的平台，但是这些平台大多只为装修公司服务，仍然没有解决买方用户与装修公司之间的信用问题。装修公司的真实服务水平无法得到公正的评价，买方用户在选择装修公司时仍然没有参考标准。第三方平台对装修公司的约束力有限，需要足够的装饰公司做支撑，更多的是作为中间商的角色，为装修公司提供买方用户信息。没有长久的信用积累机制，无法调动装修公司自身提高服务水平的积极性。

为了解决现有技术中的缺陷，本方案给出了以下实施例：

图1为本说明书实施例中一种担保方法的场景示意图。如图1所示，包括买方用户110、第三方平台120以及服务提供机构130，在订单执行过程中，买方用户110选择服务提供机构130，向第三方平台120发送订单信息，并通过第三方平台120向服务提供机构130支付订单金额；服务提供机构130需要在第三方平台120的中间账户中存入担保金额，如果订单执行过程中，买方用户110存在损失，第三方平台120会为买方用户110进行损失赔偿，在订单完成，且接收到买方用户110的确认操作之后，将买方用户110支付的订单金额存入服务提供机构130的账户中。订单完成后，对买方用户110以及服务提供机构130进行信用反馈。

接下来，将针对说明书实施例提供的一种担保方法结合附图进行具体说明：

图2为本说明书实施例提供的一种担保方法的流程示意图。从程序角度而言，流程的执行主体可以为搭载于应用服务器的程序或应用客户端。在本实施例中，执行主体可以是一个第三方的网络交易平台/系统，该第三方平台可以为商家及用户提供交易的第三方平台。在下列实施例中，为了描述方便，可以将执行主体用系统/平台代替。

如图2所示，该流程可以包括以下步骤：

步骤210：获取目标订单的总价款信息。

目标订单可以指的是系统当前接收到的订单信息。该目标订单中可以包括服务提供机构需要提供的服务、用户享受该服务需要支付的金额、服务提供机构提供流程、用户针对该服务的申诉流程等等信息。总价款信息可以表示的是用户享受该服务需要支付的总金额。

步骤220：基于所述总价款信息，确定服务提供机构需提供的目标担保金额；所述目标担保金额用于为所述服务提供机构提供的服务提供担保。

服务提供机构可以是商品卖家、装修公司、家政服务公司等，服务提供机构可以表示能为用户提供服务的机构，服务类型可以根据实际情况进行设定，在本实施例中对此不作具体限定。

为了保障用户能够享受到目标订单中的业务，系统可以提供担保机制，由服务提供机构提供担保金额以保障服务的提供，一旦服务提供机构没有按照目标订单中的要求为买方用户提供服务，就会从服务提供机构提供的担保金额中扣除相应金额以补偿买方用户。

在实际应用中，每个服务提供机构需要提供的总的担保金额由服务提供机构的信用分数决定，总的担保金额在一定时间内保持不变，例如：装修公司A对应的信用分数为600分，根据该信用分数可以确定该装修公司需要提供的总担保金额为2万。则该装修公司A需要提供2万存入第三方平台的中间账户中，以作为装修公司A接收买方用户的订单，为买方用户提供服务的担保。

需要说明的是，在风控策略下确保装修公司承接的订单量和每一个订单对应的单价在总担保金额能承受的范围内。例如：该装修公司提供的总担保金额为10万，可以允许该装修公司接15万的订单。

该步骤中的目标担保金额可以表示的是该笔目标订单对应的担保金额。例如：目标订单的总价款为2万，对应的目标担保金额可以为1万。每一笔订单都有对应的目标担保金额，以担保服务提供机构按照目标订单为买方用户提供相应的服务。

步骤230：获取所述服务提供机构的可用担保金额的状态信息；所述状态信息用于表示所述可用担保金额的剩余额度。

系统在接收到新的目标订单时，可以先确定服务提供机构提供的担保金额的剩余额度，来判断能否为该服务提供机构接该笔目标订单。该步骤中的状态信息可以表示的是服务提供机构提供的担保金额的剩余额度，需要注意的是，这里的剩余额度可以表示的担保金额中所剩的具体金额，即服务提供机构提供的可用担保金额的剩余额度。

步骤240：根据所述状态信息以及所述目标担保金额，判断所述目标订单是否在所述服务提供机构的可担保范围内，得到判断结果。

需要说明的是，该步骤中的可担保范围可以指的是服务提供机构被允许承接的订单量，例如：允许服务提供机构承接50笔订单。也可以表示服务提供机构被允许承接的订单总价款，例如：允许服务提供机构承接15万的订单。在实际应用中，根据服务提供机构的可用担保金额的剩余额度以及当前目标订单对应的目标担保金额，可以判断该笔目标订单是否在服务提供机构的可担保范围内，例如：服务提供机构的可用担保金额的剩余额度为3万，对应的可担保范围为5万，当前目标订单对应的目标担保金额为2万，此时，可以确定当前目标订单在服务提供机构的可担保范围内。

在实际应用中，服务提供机构提供的总担保金额与该服务提供机构的可担保范围之间可以具有设定比例，当然，在实际应用中，也可以根据担保金额的剩余额度来确定可担保范围，例如：剩余2万，可以担保3万的订单。

具体地，确定服务提供机构的可担保范围时，可以采用以下方式实现：

所述根据所述状态信息以及所述目标担保金额，判断所述目标订单是否在所述服务提供机构的可担保范围内，得到判断结果之前，还可以包括：

获取所述服务提供机构的第二信用分数；

基于所述第二信用分数以及所述服务提供机构的机构规模，确定所述服务提供机构预先需要存入中间账户的总担保金额；所述机构规模至少包括所述服务提供机构的员工数量、资产总额；

基于所述总担保金额以及预设比例，确定所述服务提供机构的可担保范围。

对于服务提供机构来说，服务提供机构提供的担保金额的多少也可以根据服务提供机构的信用分数、机构规模来决定，例如：机构A和机构B的信用分数相同，但是机构A的机构规模远远大于机构B的机构规模，那么，机构A的总担保金额与机构B的总担保金额是不同的，在订单单价相同的情况下，机构A能够承接的订单量是远远大于机构B能够承接的订单量的。或者机构A能够承接的订单价款总额远远大于机构B能够承接的订单价款总额。另外，信用分数、公司规模与总担保金额之间的对应比例可以根据实际应用场景进行设定，在本说明书实施例中对此不作具体限定。

服务提供机构提供的总担保金额为恒定数额，信用分数越高，存入第三方平台的担保金额越少。以装修公司为例，担保金额可以是现金或银行保函的形式。

步骤250：当所述判断结果表示所述目标订单在所述服务提供机构的可担保范围内时，允许执行所述目标订单对应的操作。

目标订单对应的操作可以包括第三方平台对服务提供机构进行的操作以及第三方平台对买方用户的终端所进行的操作。具体地，执行目标订单对应的操作可以包括以下两种方式：

方式一、第三方平台对买方用户执行的操作。

所述当所述判断结果表示所述目标订单在所述服务提供机构的可担保范围内时，允许执行所述目标订单对应的操作之后，还可以包括：

将所述状态信息发送给买方用户的终端；

获取所述买方用户对于所述目标订单对应的预付金额的支付信息。

在实际应用中，如果确定目标订单的目标担保金额在服务提供机构的可担保范围之内时，可以将服务提供机构的可用担保金额的剩余额度显示给买方用户，买方用户在确定该服务提供机构具有对应的担保额度时，买方用户可以对该目标订单对应的预付金额进行支付。

需要说明的是，终端可以包括手机、平板电脑、可穿戴智能设备、车载移动台、个人计算机、计算机集群机器等。

在实际应用场景中，为了保障买方用户在交易中的经济安全性，可以设置用户先支付一部分价款，待目标订单对应的服务提供完成后，再支付剩余的价款。例如：目标订单对应的总价款为6万，根据用户自己的信用分数，可以先要求卖方用户支付2万，剩余的4万可以等到服务提供完成再支付。其中，该例子中要求用户预先支付的2万可以称为预付金额，剩余的4万可以称为尾款金额。

需要进一步说明的是，买方用户支付多少预付金额，可以由用户的信用分数决定，具体地，可以采用以下方式进行实现：

所述获取所述买方用户对于所述目标订单对应的预付金额的支付信息之前，还可以包括：

获取所述买方用户的第一信用分数；

基于所述第一信用分数以及所述总价款信息，确定所述目标订单对应的预付金额。

买方用户的第一信用分数可以表示具体的信用评分分值，例如：300分、570分、700分等。根据买方用户的信用分数以及目标订单对应的总价款信息，可以确定该目标订单对应的预付金额。总价款中，除了预付金额之外，剩下的就是尾款金额，因此，也可以理解为根据买方用户的信用分数，确定目标订单的尾款金额。

通过上述方式，对于买方用户采用“信用决定尾款额度”的方式，买方用户提高信用积分可以获得更高的尾款额度，为订单执行过程的自身权益维护获得更多保障。

方式二、第三方平台对服务提供机构执行的操作。

所述当所述判断结果表示所述目标订单在所述服务提供机构的可担保范围内时，允许执行所述目标订单对应的操作之后，还可以包括：

向所述服务提供机构发送服务执行指令；所述服务执行指令用于指示所述服务提供机构按照所述目标订单为所述买方用户提供服务。

第三方平台执行目标订单对应的操作还可以包括第三方平台向服务提供机构发送指令，指示服务提供机构按照目标订单为买方用户提供对应的服务。以装修场景为例，第三方平台可以向装修公司发送服务执行指令，装修公司在接收到服务执行指令之后，按照目标订单为买方用户提供装修服务。

应当理解，本说明书一个或多个实施例所述的方法其中部分步骤的顺序可以根据实际需要相互交换，或者其中的部分步骤也可以省略或删除。

图2中的方法，通过获取目标订单的总价款信息；基于总价款信息，确定服务提供机构需提供的目标担保金额；获取所述服务提供机构的用于表示可用担保金额的剩余额度的状态信息；根据该状态信息以及目标担保金额，判断该目标订单是否在服务提供机构的可担保范围内，当目标订单在所述服务提供机构的可担保范围内时，允许执行所述目标订单对应的操作。通过上述方法，能够担保在交易过程中的交易安全性。

基于图2的方法，本说明书实施例还提供了该方法的一些具体实施方案，下面进行说明。

可选的，所述预付金额可以包括首款金额以及暂存金额。在实际应用中，预付金额可以指的是买方用户需要提前支付的金额，但是预付金额并不会直接打入服务提供机构。买家用户预先支付的预付金额，一部分存入服务提供机构的账户中，一部分预留在中间账户中。其中，中间账户可以表示的是第三方平台对应的账户。待服务完成，买家用户确认之后，第三方平台再将暂存金额存入服务提供机构的账户中。具体可以包括以下步骤：

所述支付信息包括第一支付信息以及第二支付信息；所述获取买方用户对于所述目标订单对应的预付金额的支付信息，具体可以包括：

获取所述第一支付信息；所述第一支付信息表示所述首款金额已存入所述服务提供机构的账户；

获取所述第二支付信息；所述第二支付信息表示所述暂存金额已存入中间账户。

可选的，服务提供机构存入中间账户的总担保金额在一定时间内是恒定不变的，但是当服务提供机构的信用分数变化较大时，可以根据服务提供机构变化后的信用分数重新确定总担保金额。在实际应用中，一般情况下，服务提供机构的总担保金额是恒定不变的。在实际场景中，对于每一笔订单的担保金额需要根据当前订单的总价款来进行确定，即对于每一笔订单，需要有相应的担保金额来针对性地对该笔订单对应的服务提供保障。因此，第三方平台每接收到一笔订单信息，需要在总担保金额中，对该笔订单信息对应的担保金额进行锁定，以保障该笔订单对应的服务。具体可以包括以下步骤：

所述将所述状态信息发送给所述买方用户之后，还可以包括：

从所述剩余额度中，锁定所述目标担保金额；

待所述目标订单对应的操作执行完毕后，获取所述买方用户的确认操作；

基于所述确认操作，解锁所述目标担保金额。

在总担保金额中，对每一笔订单对应的担保金额进行锁定之后，只有在相应的订单被执行完毕，接收到该买家用户的确认操作的情况下，才会解锁被锁定的担保金额。例如：总担保金额为10万，第一笔订单对应的担保金额为2万，第二笔订单对应的担保金额为1万，此时，第三方平台为第一笔订单，从10万担保金额中锁定2万，为第二笔订单从剩余的8万担保金额中锁定1万，此时，可用担保金额的剩余额度时7万。这7万对应的可担保范围可以由第三方平台根据实际情况进行设定。

通过上述方法，第三方平台针对每一笔订单，将对应的目标担保金额进行锁定，可以为每一笔订单提供相应的服务保障。

在实际应用场景中，对于订单的执行，若服务提供机构在提供服务的过程中存在问题，导致买房用户对于服务提供机构提供的服务不满意，或者买房用户与服务提供机构在交易过程中存在问题时，都可以通过第三方平台发送相应的请求信息，从而对相应的问题进行处理。而对于第三方平台来说，关于尾款金额的结算，需要根据服务提供机构或用户的请求来进行。

在实际应用中，当买方用户遭受损失时，买方用户可以通过第三方平台提出损失补偿请求，即买方终端可以通过终端向第三方平台发送损失补偿请求信息。其中，损失补偿请求信息中可以包括请求补偿的损失金额、请求补偿的原因，事项等等信息。在具体应用中，损失金额可以由买方用户与服务提供机构共同协商核定，也可以由第三方平台按照核酸原则进行计算确定。

在确定了损失金额之后，对买方用户进行损失补偿的方式可以包括以下几种方式：

方式一、补偿金额从买家用户存入中间账户中的暂存金额中进行抵扣。

方式二、补偿金额从买方用户的账户中的尾款金额中进行抵扣。

方式三、第三方平台从中间账户中的目标担保金额中扣除补偿金额，存入买方用户的账户。

需要说明的是，补偿金额在进行赔付时，上述三种方式可以组合实现，也可以选择至少一种方式进行实现。在本实施例中，进一步地，扣除补偿金额时，可以按照以下顺序实现：暂存金额→尾款金额→担保金额→第三方平台兜底。即可以先从暂存金额中抵扣，暂存金额抵扣完之后，可以从尾款金额中抵扣，尾款金额抵扣完还不能达到补偿金额时，从中间账户的担保金额中扣除，担保金额扣除完还不够的话，剩下的由第三方平台来赔付。

因此，在确定了损失金额之后，可以先确定损失金额是否超出暂存金额，未超出时，直接从暂存金额中抵扣，如果超出暂存金额，超出部分从尾款金额中抵扣，如果尾款金额不够抵扣，抵扣完尾款金额后的超出金额从担保金额中扣除，如果担保金额全部扣除后，还不够损失金额，将扣除担保金额后还欠的金额，由第三方平台承担。具体可以通过以下方式实现：

可选的，所述向所述服务提供机构发送服务执行指令之后，还可以包括：

接收所述买方用户发送的损失补偿请求信息；

基于所述损失补偿请求信息，确定损失金额；

当所述损失金额未超出所述暂存金额时，从所述中间账户的所述暂存金额中扣除所述损失金额返回所述买方用户的账户中，并确定所述暂存金额在扣除所述损失金额后，得到的目标暂存金额；

在接收到清算请求信息时，将所述目标暂存金额以及买方用户账户中的预计尾款金额存入所述服务提供机构的账户中，完成清算。

需要说明的是，如果暂存金额就能够抵扣全部的损失金额，那么暂存金额中扣除损失金额后剩下的部分，待订单全部执行完毕，收到用户的确认操作之后，基于清算请求信息，可以将剩下的部分以及尾款金额存入服务提供机构的账户中。其中，清算请求信息可以由服务提供机构提出，也可以由买方用户提出。

可选的，所述接收买方用户发送的损失补偿请求信息之后，还可以包括：

当所述损失金额超出所述暂存金额时，将所述暂存金额返回所述买方用户的账户中，并确定超出金额；

从所述预计尾款金额中扣除所述超出金额，得到扣除所述超出金额后的目标尾款金额；

在接收到清算请求信息时，将所述目标尾款金额存入所述服务提供机构的账户中，完成清算。

可选的，所述接收买方用户发送的损失补偿请求信息之后，还可以包括：

当所述损失金额超出所述暂存金额与所述预计尾款金额之和时，从所述中间账户的目标担保金额中扣除所述超出金额，将扣除的所述超出金额存入所述买方用户的账户中。

尾款金额可以在用户账户中进行保留，也可以由第三方平台的中间账户

为了更加清楚地说明上述几种赔偿损失金额的方式，可以采用例子作进一步说明。例如：订单1，对应的目标担保金额为2万，预付金额为5000，尾款金额10000，其中，暂存金额为2000，在执行订单1的过程中，买方用户遭受损失，损失金额为1000，此时，由于损失金额未超出暂存金额，因此，从暂存金额中扣除1000，存入买方用户的账户中，在接收到清算请求信息时，将剩余的暂存金额1000以及尾款金额尾款金额10000存入服务提供机构的账户中，并将中间账户中锁定的2万目标担保金额解锁。

再比如：订单2，对应的目标担保金额为2万，预付金额为5000，尾款金额10000，其中，暂存金额为2000，在执行订单2的过程中，买方用户遭受损失，损失金额为15000，此时，由于损失金额超出了暂存金额，因此，暂存金额2000返回买方用户的账户中，此时，损失金额还差13000，已超出尾款金额，抵扣完尾款金额10000后，损失金额还欠3000，接着从目标担保金额中扣除3000，存入买方用户的账户。第三方平台在接收到清算请求信息时，由于暂存金额以及尾款金额都已经被抵扣完，因此，不需要向服务提供机构的账户中进行金额存储。

通过上述方式，当买方用户遭受损失时，可以对买方用户进行合理赔付，保障用户的经济利益。

当然，在实际应用中，如果服务提供机构遭受损失，例如：订单对应的服务执行完毕后，买方用户拒绝结算尾款金额时，也可以向第三方平台发送补偿请求信息，以保障自身利益。

可选的，所述从所述中间账户的目标担保金额中扣除所述超出金额之后，还可以包括：

生成第一提示信息；所述第一提示信息用于提示所述服务提供机构将所述总担保金额补足。

在本说明书实施例中，当中间账户中的担保金额存在扣除情况时，第三方平台可以向服务提供机构发送第一提示信息。其中，第一提示信息可以表示用于提示服务提供机构补足总担保金额的提示信息。例如：在某一笔订单中，担保金额被扣除1000元，此时，第三方平台会向服务提供机构发送第一提示信息，提示服务提供机构向中间账户中存入1000元，服务提供机构需要补足担保金额之后才能继续承接新订单。在所述总担保金额被补足之前，拒绝在交易第三方平台展示所述服务提供机构的信息。

当然，在实际应用中，也可以不强制让服务提供机构补足总担保金额，在一种实施方式中，当服务提供机构的总担保金额存在扣除情况时，可以根据剩余的担保金额，重新确定该服务提供机构的可担保范围。例如：重新确定该服务提供机构目前剩余的担保金额能够承接多少订单量或者能承接多少金额的订单。具体地，可以采用以下步骤：

所述从所述中间账户的目标担保金额中扣除所述超出金额之后，还可以包括：

确定所述中间账户中的剩余担保金额；

基于所述剩余担保金额，重新确定当前所述服务提供机构的剩余担保金额对应的可担保范围；

生成提示信息；所述提示信息用于提示所述服务提供机构其自身对应的重新确定的可担保范围。通过上述方法，可以督促服务提供机构为用户提供高质量服务，对服务提供机构起到良好的约束作用，调动服务提供机构提高自身服务水平，提升企业信用评分。

可选的，所述完成清算之后，还可以包括：

对所述买方用户进行信用反馈；

对所述服务提供机构进行信用反馈。

需要说明的是，第三方平台针对每一笔订单的完成情况，可以对该笔订单的买方用户以及服务提供机构进行信用反馈。

信用反馈可以包括进行信用评分、原因说明、提供建议等。

可选的，所述对所述买方用户进行信用反馈，具体可以包括：

对所述买方用户进行第一信用评分处理；所述第一信用评分处理包括加分处理或减分处理；

针对所述第一信用评分处理生成第二提示信息；所述第二提示信息包括针对所述第一信用评分的处理结果进行原因描述的信息；

所述对所述服务提供机构进行信用反馈，具体可以包括：

对所述服务提供机构进行第二信用评分处理；所述第二信用评分处理包括加分处理或减分处理；

针对所述第二信用评分处理生成第三提示信息；所述第三提示信息包括针对所述第二信用评分的处理结果进行原因描述的信息。

其中，信用评分处理可以包括对买方用户以及服务提供机构进行加分处理、减分处理或重新打分处理等。

原因描述信息可以包括不按照目标订单提供服务、逾期不结算尾款，逾期未补足担保金额等等。

可选的，所述服务提供机构可以是买方用户选择的服务提供机构。

所述获取所述服务提供机构的第二信用分数之前，还可以包括：

获取各个服务提供机构的信用分数；

基于所述信用分数，将满足预设信用分数阈值的服务提供机构的信息展示给所述买方用户。

预设信用分数阈值可以根据实际情况进行设定。

可选的，所述将满足预设信用分数阈值的服务提供机构展示给所述买方用户，具体可以包括：

根据所述信用分数，按照从高到低的顺序展示预设数目个服务提供机构的信息。

在实际应用中，第三方平台可以按照服务提供机构的信用评分，将满足信用评分阈值的服务提供机构，从高到低为用户显示服务提供机构，例如：按照从高到低的顺序，显示前20个服务提供机构。

可选的，所述基于所述第一信用分数以及总价款，确定所述买方用户的预付金额，具体可以包括：

获取所述买方用户的第一信用分数对应的预付金额比例；

根据所述总价款以及所述预付金额比例，确定所述买方用户的预付金额。

预付金额与信用分数之间可以具有预设比例，在确定买方用户的第一信用分数之后，按照预设比例，可以确定买方用户应付的预付金额。

在实际应用中，买方用户和服务提供机构可以通过第三方平台签署相应的协议文件，该协议文件中可以规定买家用户的支付流程、服务提供机构提供服务的质量、以及流程等。买方用户和服务提供机构可以按照协议文件中的协议内容执行相应操作。协议文件可以为买方用户与服务提供机构共同签署的文件。例如：在装修场景中，协议文件可以是装修合同。

有了协议文件之后，在订单执行过程中，双方的纠纷问题可以依照协议文件来认定错误方以及赔偿建议。具体地，可以按照以下步骤进行：

接收问题处理请求信息；所述问题处理请求信息由所述买方用户或所述服务提供机构发送；

根据所述问题请求信息确定需要处理的问题内容；

根据所述问题内容，基于所述协议文件，生成处理建议信息；所述处理建议信息中至少包括责任划分信息以及赔偿金额信息。

可选的，服务提供机构的第二信用分数可以根据服务提供机构的特征信息进行计算；服务提供机构的特征信息可以包括所述服务提供机构的身份特征信息，以及所述服务提供机构的历史行为特征信息，其中，身份特征信息可以包括服务提供机构的资产状况、公司规模以及运营状态等等；历史行为特征信息可以包括历史订单的买方用户对该服务提供机构的评价信息以及该服务提供机构对于合同的历史履行情况信息等等。

买方用户的第一信用分数也可以根据买方用户的特征信息来计算，买方用户的特征信息可以包括买方用户的身份特征信息以及所述买方用户的历史行为特征信息；其中，买方用户的身份特征信息可以包括买方用户的学历、职业、单位、籍贯、居住地、资产状况以及社交关系等信息。买方用户的历史行为特征信息可以包括还款历史、消费状况、行为偏好、逾期情况，合约履行情况等信息。

图3为本说明书实施例提供的装修担保方法的流程示意图。

如图3所示，以装修场景为例，涉及的交互方有买方用户、第三方平台以及装修公司。上述实施例中的方案可以采用以下步骤进行实现：

步骤302：获取买方用户选择的装修公司。

步骤304：获取装修公司的信用分数。

步骤306：基于装修公司的信用分数以及机构规模，计算装修公司需要存入中间账户的总担保金额。

步骤308：获取买方用户的信用分数。

步骤310：基于买方用户的信用分数，计算买方用户的预付金额；

步骤312：获取装修公司的担保金额存入信息；

步骤314：获取买方用户的预付金额支付信息；

步骤316：生成订单的状态信息；该状态信息用于表示该订单在装修公司的可担保范围内；

步骤318：买方用户以及装修公司通过第三方平台签订装修合同；

步骤320：装修公司按照装修合同为买方用户提供装修服务；

步骤322：买方用户验收合格，发送确认信息，买方用户支付尾款金额，订单执行完毕；

步骤324：买方用户验证不合格。

步骤326：平台处理问题，给出赔偿建议，赔偿结束后，订单执行完毕。

步骤328：第三方平台对买方用户以及服务提供机构进行信用评分反馈。

上述实施例中的方法步骤，可以实现以下技术效果：

1)有效解决买方用户与服务提供公司之间的信用问题。利用企业信用评分，服务提供公司的真实服务水平得到公正的评价，买方用户在选择服务提供机构时有明确的参考标准。

2)平台通过设定担保金额的方式，对服务提供机构起到良好的约束作用。

3)平台本身有强大的公信力，将成为买方用户选择服务提供公司的方式，因此也会吸引更多的服务提供机构加入平台中。

4)充分利用平台信用积累机制，调动服务提供机构努力提高自身服务水平，提升企业信用评分，继而获得更多业务。可以促使服务提供机构努力提升服务品质，提高信用分，减少押金数额，降低资金成本；同时在平台上也可以通过信用的积累，形成品牌优势，获得更多业务。

5)从用户利益出发，打破现有服务提供公司的主导地位，形成双方平等透明的交易平台，帮助买方用户更放心地去选择装修公司。

6)采用“信用分数决定尾款额度”的方式，买方用户提高信用积分可以获得更高的尾款额度，为自身权益维护获得更多保障。

基于同样的思路，本说明书实施例还提供了上述方法对应的装置。图4是本说明书实施例提供的一种担保装置的结构示意图。如图4所示，该装置可以包括：

总价款信息获取模块410，用于获取目标订单的总价款信息；

目标担保金额确定模块420，用于基于所述总价款信息，确定服务提供机构需提供的目标担保金额；所述目标担保金额用于为所述服务提供机构提供的服务提供担保；

可用担保金额状态信息获取模块430，用于获取所述服务提供机构的可用担保金额的状态信息；所述状态信息用于表示所述可用担保金额的剩余额度；

判断模块440，用于根据所述状态信息以及所述目标担保金额，判断所述目标订单是否在所述服务提供机构的可担保范围内，得到判断结果；

操作执行指令模块450，用于当所述判断结果表示所述目标订单在所述服务提供机构的可担保范围内时，允许执行所述目标订单对应的操作。

基于图4的装置，本说明书实施例还提供了该方法的一些具体实施方案，下面进行说明。

可选的，所述装置，还可以包括：

状态信息发送模块，用于将所述状态信息发送给买方用户的终端；

预付金额支付信息获取模块，用于获取所述买方用户对于所述目标订单对应的预付金额的支付信息。

可选的，所述装置，还可以包括：

服务执行指令发送模块，用于向所述服务提供机构发送服务执行指令；所述服务执行指令用于指示所述服务提供机构按照所述目标订单为所述买方用户提供服务。

可选的，所述装置，还可以包括：

第一信用分数获取模块，用于获取所述买方用户的第一信用分数；

预付金额确定模块，用于基于所述第一信用分数以及所述总价款信息，确定所述目标订单对应的预付金额。

可选的，所述预付金额可以包括首款金额以及暂存金额；所述支付信息可以包括第一支付信息以及第二支付信息；所述预付金额支付信息获取模块，具体可以包括：

第一支付信息获取单元，用于获取所述第一支付信息；所述第一支付信息表示所述首款金额已存入所述服务提供机构的账户；

第二支付信息获取单元，用于获取所述第二支付信息；所述第二支付信息表示所述暂存金额已存入中间账户。

可选的，所述装置，还可以包括：

目标担保金额锁定模块，用于从所述剩余额度中，锁定所述目标担保金额；

买方用户确认模块，用于待所述目标订单对应的操作执行完毕后，获取所述买方用户的确认操作；

解锁模块，用于基于所述确认操作，解锁所述目标担保金额。

可选的，所述装置，还可以包括：

第二信用分数获取模块，用于获取所述服务提供机构的第二信用分数；

总担保金额确定模块，用于基于所述第二信用分数以及所述服务提供机构的机构规模，确定所述服务提供机构预先需要存入中间账户的总担保金额；所述机构规模至少包括所述服务提供机构的员工数量、资产总额；

可担保范围确定模块，用于基于所述总担保金额以及预设比例，确定所述服务提供机构的可担保范围。

可选的，所述装置，还可以包括：

损失补偿请求信息接收模块，用于接收所述买方用户发送的损失补偿请求信息；

损失金额确定模块，用于基于所述损失补偿请求信息，确定损失金额；

目标暂存金额确定模块，用于当所述损失金额未超出所述暂存金额时，从所述中间账户的所述暂存金额中扣除所述损失金额返回所述买方用户的账户中，并确定所述暂存金额在扣除所述损失金额后，得到的目标暂存金额；

第一清算模块，用于在接收到清算请求信息时，将所述目标暂存金额以及买方用户账户中的预计尾款金额存入所述服务提供机构的账户中，完成清算。

可选的，所述装置，还可以包括：

超出金额确定模块，用于当所述损失金额超出所述暂存金额时，将所述暂存金额返回所述买方用户的账户中，并确定超出金额；

目标尾款金额确定模块，用于从所述预计尾款金额中扣除所述超出金额，得到扣除所述超出金额后的目标尾款金额；

第二清算模块，用于在接收到清算请求信息时，将所述目标尾款金额存入所述服务提供机构的账户中，完成清算。

可选的，所述装置，还可以包括：

超出金额扣除模块，用于当所述损失金额超出所述暂存金额与所述预计尾款金额之和时，从所述中间账户的目标担保金额中扣除所述超出金额，将扣除的所述超出金额存入所述买方用户的账户中。

可选的，所述装置，还可以包括：

第一提示信息生成模块，用于生成第一提示信息；所述第一提示信息用于提示所述服务提供机构将所述总担保金额补足。

可选的，在所述总担保金额被补足之前，拒绝在交易第三方平台展示所述服务提供机构的信息。

可选的，所述装置，还可以包括：

第一信用反馈模块，用于对所述买方用户进行信用反馈；

第二信用反馈模块，用于对所述服务提供机构进行信用反馈。

可选的，所述第一信用反馈模块，具体可以包括：

第一信用评分处理单元，用于对所述买方用户进行第一信用评分处理；所述第一信用评分处理包括加分处理或减分处理；

第二提示信息生成信息，用于针对所述第一信用评分处理生成第二提示信息；所述第二提示信息包括针对所述第一信用评分的处理结果进行原因描述的信息；

所述第二信用反馈模块，具体可以包括：

第二信用评分处理单元，用于对所述服务提供机构进行第二信用评分处理；所述第二信用评分处理包括加分处理或减分处理；

第三提示信息生成单元，用于针对所述第二信用评分处理生成第三提示信息；所述第三提示信息包括针对所述第二信用评分的处理结果进行原因描述的信息。

可选的，所述服务提供机构可以为所述买方用户选择的服务提供机构；

所述装置，还可以包括：

信用分数获取模块，用于获取各个服务提供机构的信用分数；

展示模块，用于基于所述信用分数，将满足预设信用分数阈值的服务提供机构的信息展示给所述买方用户。

可选的，所述展示模块，具体可以包括：

展示单元，用于根据所述信用分数，按照从高到低的顺序展示预设数目个服务提供机构的信息。

可选的，所述预付金额确定模块，具体可以包括：

预付金额比例获取单元，用于获取所述买方用户的第一信用分数对应的预付金额比例；

预付金额确定单元，用于根据所述总价款以及所述预付金额比例，确定所述买方用户的预付金额。

基于同样的思路，本说明书实施例还提供了上述方法对应的设备。

图5是本说明书实施例提供的一种担保设备的结构示意图。如图5所示，设备500可以包括：

至少一个处理器510；以及，

与所述至少一个处理器通信连接的存储器530；其中，

所述存储器530存储有可被所述至少一个处理器510执行的指令520，所述指令被所述至少一个处理器510执行，以使所述至少一个处理器510能够：

获取目标订单的总价款信息；

基于所述总价款信息，确定服务提供机构需提供的目标担保金额；所述目标担保金额用于为所述服务提供机构提供的服务提供担保；

获取所述服务提供机构的可用担保金额的状态信息；所述状态信息用于表示所述可用担保金额的剩余额度；

根据所述状态信息以及所述目标担保金额，判断所述目标订单是否在所述服务提供机构的可担保范围内，得到判断结果；

当所述判断结果表示所述目标订单在所述服务提供机构的可担保范围内时，允许执行所述目标订单对应的操作。

基于同样的思路，本说明书实施例还提供了上述方法对应的计算机可读介质。计算机可读介质上存储有计算机可读指令，所述计算机可读指令可被处理器执行以实现以下方法：

获取目标订单的总价款信息；

基于所述总价款信息，确定服务提供机构需提供的目标担保金额；所述目标担保金额用于为所述服务提供机构提供的服务提供担保；

获取所述服务提供机构的可用担保金额的状态信息；所述状态信息用于表示所述可用担保金额的剩余额度；

根据所述状态信息以及所述目标担保金额，判断所述目标订单是否在所述服务提供机构的可担保范围内，得到判断结果；

当所述判断结果表示所述目标订单在所述服务提供机构的可担保范围内时，允许执行所述目标订单对应的操作。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于设备实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

在20世纪90年代，对于一个技术的改进可以很明显地区分是硬件上的改进(例如，对二极管、晶体管、开关等电路结构的改进)还是软件上的改进(对于方法流程的改进)。然而，随着技术的发展，当今的很多方法流程的改进已经可以视为硬件电路结构的直接改进。设计人员几乎都通过将改进的方法流程编程到硬件电路中来得到相应的硬件电路结构。因此，不能说一个方法流程的改进就不能用硬件实体模块来实现。例如，可编程逻辑器件(Programmable Logic Device,PLD)(例如现场可编程门阵列(Field ProgrammableGateArray，FPGA))就是这样一种集成电路，其逻辑功能由买方用户对器件编程来确定。由设计人员自行编程来把一个数字符系统“集成”在一片PLD上，而不需要请芯片制造厂商来设计和制作专用的集成电路芯片。而且，如今，取代手工地制作集成电路芯片，这种编程也多半改用“逻辑编译器(logic compiler)”软件来实现，它与程序开发撰写时所用的软件编译器相类似，而要编译之前的原始代码也得用特定的编程语言来撰写，此称之为硬件描述语言(Hardware Description Language，HDL)，而HDL也并非仅有一种，而是有许多种，如ABEL(Advanced Boolean Expression Language)、AHDL(Altera Hardware DescriptionLanguage)、Confluence、CUPL(Cornell University Programming Language)、HDCal、JHDL(Java Hardware Description Language)、Lava、Lola、MyHDL、PALASM、RHDL(RubyHardware Description Language)等，目前最普遍使用的是VHDL(Very-High-SpeedIntegrated Circuit Hardware Description Language)与Verilog。本领域技术人员也应该清楚，只需要将方法流程用上述几种硬件描述语言稍作逻辑编程并编程到集成电路中，就可以很容易得到实现该逻辑方法流程的硬件电路。

控制器可以按任何适当的方式实现，例如，控制器可以采取例如微处理器或处理器以及存储可由该(微)处理器执行的计算机可读程序代码(例如软件或固件)的计算机可读介质、逻辑门、开关、专用集成电路(Application Specific Integrated Circuit，ASIC)、可编程逻辑控制器和嵌入微控制器的形式，控制器的例子包括但不限于以下微控制器：ARC 625D、AtmelAT91SAM、Microchip PIC18F26K20以及Silicone Labs C8051F320，存储器控制器还可以被实现为存储器的控制逻辑的一部分。本领域技术人员也知道，除了以纯计算机可读程序代码方式实现控制器以外，完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件，而对其内包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至，可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。

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

为了描述的方便，描述以上装置时以功能分为各种单元分别描述。当然，在实施本申请时可以把各单元的功能在同一个或多个软件和/或硬件中实现。

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

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

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本申请，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。

以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。

Claims (25)

1.一种担保方法，包括：

获取目标订单的总价款信息；

基于所述总价款信息，确定服务提供机构需提供的目标担保金额；所述目标担保金额用于为所述服务提供机构提供的服务提供担保；

获取所述服务提供机构的可用担保金额的状态信息；所述状态信息用于表示所述可用担保金额的剩余额度；

根据所述状态信息以及所述目标担保金额，判断所述目标订单是否在所述服务提供机构的可担保范围内，得到判断结果；

当所述判断结果表示所述目标订单在所述服务提供机构的可担保范围内时，允许执行所述目标订单对应的操作；所述可担保范围表示服务提供机构被允许承接的订单量或被允许承接的订单总价款；

获取买方用户的第一信用分数；

基于所述第一信用分数以及所述总价款信息，确定所述目标订单对应的预付金额。

2.根据权利要求1所述的方法，所述当所述判断结果表示所述目标订单在所述服务提供机构的可担保范围内时，允许执行所述目标订单对应的操作之后，还包括：

将所述状态信息发送给买方用户的终端；

获取所述买方用户对于所述目标订单对应的预付金额的支付信息。

3.根据权利要求2所述的方法，所述当所述判断结果表示所述目标订单在所述服务提供机构的可担保范围内时，允许执行所述目标订单对应的操作之后，还包括：

向所述服务提供机构发送服务执行指令；所述服务执行指令用于指示所述服务提供机构按照所述目标订单为所述买方用户提供服务。

4.根据权利要求2所述的方法，所述获取所述买方用户对于所述目标订单对应的预付金额的支付信息之前，还包括：

获取所述买方用户的第一信用分数；

基于所述第一信用分数以及所述总价款信息，确定所述目标订单对应的预付金额。

5.根据权利要求2所述的方法，所述预付金额包括首款金额以及暂存金额；所述支付信息包括第一支付信息以及第二支付信息；所述获取买方用户对于所述目标订单对应的预付金额的支付信息，具体包括：

获取所述第一支付信息；所述第一支付信息表示所述首款金额已存入所述服务提供机构的账户；

获取所述第二支付信息；所述第二支付信息表示所述暂存金额已存入中间账户。

6.根据权利要求2所述的方法，所述将所述状态信息发送给所述买方用户之后，还包括：

从所述剩余额度中，锁定所述目标担保金额；

待所述目标订单对应的操作执行完毕后，获取所述买方用户的确认操作；

基于所述确认操作，解锁所述目标担保金额。

7.根据权利要求1所述的方法，所述根据所述状态信息以及所述目标担保金额，判断所述目标订单是否在所述服务提供机构的可担保范围内，得到判断结果之前，还包括：

获取所述服务提供机构的第二信用分数；

基于所述第二信用分数以及所述服务提供机构的机构规模，确定所述服务提供机构预先需要存入中间账户的总担保金额；所述机构规模至少包括所述服务提供机构的员工数量、资产总额；

基于所述总担保金额以及预设比例，确定所述服务提供机构的可担保范围。

8.根据权利要求3所述的方法，所述向所述服务提供机构发送服务执行指令之后，还包括：

接收所述买方用户发送的损失补偿请求信息；

基于所述损失补偿请求信息，确定损失金额；

当所述损失金额未超出暂存金额时，从中间账户的所述暂存金额中扣除所述损失金额返回所述买方用户的账户中，并确定所述暂存金额在扣除所述损失金额后，得到的目标暂存金额；

在接收到清算请求信息时，将所述目标暂存金额以及买方用户账户中的预计尾款金额存入所述服务提供机构的账户中，完成清算。

9.根据权利要求8所述的方法，所述接收买方用户发送的损失补偿请求信息之后，还包括：

当所述损失金额超出所述暂存金额时，将所述暂存金额返回所述买方用户的账户中，并确定超出金额；

从所述预计尾款金额中扣除所述超出金额，得到扣除所述超出金额后的目标尾款金额；

在接收到清算请求信息时，将所述目标尾款金额存入所述服务提供机构的账户中，完成清算。

10.根据权利要求9所述的方法，所述接收买方用户发送的损失补偿请求信息之后，还包括：

当所述损失金额超出所述暂存金额与所述预计尾款金额之和时，从所述中间账户的目标担保金额中扣除所述超出金额，将扣除的所述超出金额存入所述买方用户的账户中。

11.根据权利要求10所述的方法，所述从所述中间账户的目标担保金额中扣除所述超出金额之后，还包括：

生成第一提示信息；所述第一提示信息用于提示所述服务提供机构将总担保金额补足。

12.根据权利要求11所述的方法，在所述总担保金额被补足之前，拒绝在交易第三方平台展示所述服务提供机构的信息。

13.根据权利要求8或9所述的方法，所述完成清算之后，还包括：

对所述买方用户进行信用反馈；

对所述服务提供机构进行信用反馈。

14.根据权利要求13所述的方法，所述对所述买方用户进行信用反馈，具体包括：

对所述买方用户进行第一信用评分处理；所述第一信用评分处理包括加分处理或减分处理；

针对所述第一信用评分处理生成第二提示信息；所述第二提示信息包括针对所述第一信用评分的处理结果进行原因描述的信息；

所述对所述服务提供机构进行信用反馈，具体包括：

对所述服务提供机构进行第二信用评分处理；所述第二信用评分处理包括加分处理或减分处理；

针对所述第二信用评分处理生成第三提示信息；所述第三提示信息包括针对所述第二信用评分的处理结果进行原因描述的信息。

15.根据权利要求7所述的方法，所述服务提供机构为所述买方用户选择的服务提供机构；

所述获取所述服务提供机构的第二信用分数之前，还包括：

获取各个服务提供机构的信用分数；

基于所述信用分数，将满足预设信用分数阈值的服务提供机构的信息展示给所述买方用户。

16.根据权利要求15所述的方法，所述将满足预设信用分数阈值的服务提供机构展示给所述买方用户，具体包括：

根据所述信用分数，按照从高到低的顺序展示预设数目个服务提供机构的信息。

17.根据权利要求4所述的方法，所述基于所述第一信用分数以及总价款，确定所述买方用户的预付金额，具体包括：

获取所述买方用户的第一信用分数对应的预付金额比例；

根据所述总价款以及所述预付金额比例，确定所述买方用户的预付金额。

18.一种担保装置，包括：

总价款信息获取模块，用于获取目标订单的总价款信息；

目标担保金额确定模块，用于基于所述总价款信息，确定服务提供机构需提供的目标担保金额；所述目标担保金额用于为所述服务提供机构提供的服务提供担保；

可用担保金额状态信息获取模块，用于获取所述服务提供机构的可用担保金额的状态信息；所述状态信息用于表示所述可用担保金额的剩余额度；

判断模块，用于根据所述状态信息以及所述目标担保金额，判断所述目标订单是否在所述服务提供机构的可担保范围内，得到判断结果；

操作执行指令模块，用于当所述判断结果表示所述目标订单在所述服务提供机构的可担保范围内时，允许执行所述目标订单对应的操作；所述可担保范围表示服务提供机构被允许承接的订单量或被允许承接的订单总价款；

第一信用分数获取模块，用于获取买方用户的第一信用分数；

预付金额确定模块，用于基于所述第一信用分数以及所述总价款信息，确定所述目标订单对应的预付金额。

19.根据权利要求18所述的装置，所述装置，还包括：

状态信息发送模块，用于将所述状态信息发送给买方用户的终端；

预付金额支付信息获取模块，用于获取所述买方用户对于所述目标订单对应的预付金额的支付信息。

20.根据权利要求19所述的装置，所述预付金额包括首款金额以及暂存金额；所述支付信息包括第一支付信息以及第二支付信息；所述预付金额支付信息获取模块，具体包括：

第一支付信息获取单元，用于获取所述第一支付信息；所述第一支付信息表示所述首款金额已存入所述服务提供机构的账户；

第二支付信息获取单元，用于获取所述第二支付信息；所述第二支付信息表示所述暂存金额已存入中间账户。

21.根据权利要求19所述的装置，所述装置，还包括：

目标担保金额锁定模块，用于从所述剩余额度中，锁定所述目标担保金额；

买方用户确认模块，用于待所述目标订单对应的操作执行完毕后，获取所述买方用户的确认操作；

解锁模块，用于基于所述确认操作，解锁所述目标担保金额。

22.根据权利要求18所述的装置，所述装置，还包括：

第二信用分数获取模块，用于获取所述服务提供机构的第二信用分数；

总担保金额确定模块，用于基于所述第二信用分数以及所述服务提供机构的机构规模，确定所述服务提供机构预先需要存入中间账户的总担保金额；所述机构规模至少包括所述服务提供机构的员工数量、资产总额；

可担保范围确定模块，用于基于所述总担保金额以及预设比例，确定所述服务提供机构的可担保范围。

23.根据权利要求22所述的装置，所述服务提供机构为所述买方用户选择的服务提供机构；

所述装置，还包括：

信用分数获取模块，用于获取各个服务提供机构的信用分数；

展示模块，用于基于所述信用分数，将满足预设信用分数阈值的服务提供机构的信息展示给所述买方用户。

24.一种担保设备，包括：

至少一个处理器；以及，

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够：

获取目标订单的总价款信息；

基于所述总价款信息，确定服务提供机构需提供的目标担保金额；所述目标担保金额用于为所述服务提供机构提供的服务提供担保；

获取所述服务提供机构的可用担保金额的状态信息；所述状态信息用于表示所述可用担保金额的剩余额度；

根据所述状态信息以及所述目标担保金额，判断所述目标订单是否在所述服务提供机构的可担保范围内，得到判断结果；

当所述判断结果表示所述目标订单在所述服务提供机构的可担保范围内时，允许执行所述目标订单对应的操作；所述可担保范围表示服务提供机构被允许承接的订单量或被允许承接的订单总价款；

获取买方用户的第一信用分数；

基于所述第一信用分数以及所述总价款信息，确定所述目标订单对应的预付金额。

25.一种计算机可读介质，其上存储有计算机可读指令，所述计算机可读指令可被处理器执行以实现权利要求1至17中任一项所述的担保方法。

Images