CN106845966B - 货款信息处理方法及装置 - Google Patents

Abstract

本申请实施例公开了货款信息处理方法及装置，该方法包括：为参加目标活动但未预先支付保证金的第一用户生成保证金订单；接收到针对目标交易订单执行的付款通知后，确定该目标交易订单对应的第一用户，并确定与该第一用户关联的保证金订单；所述目标交易订单为所述目标活动中生成的交易订单；确定针对该保证金订单的累计冻结金额总数是否已达到预置的额度，如果未达到所述预置额度，则触发对该交易订单关联货款的冻结操作。通过本申请实施例，能够通过货款冻结的方式收取第一用户的保证金，提高活动参与度。

Description

货款信息处理方法及装置

技术领域

本申请涉及货款信息处理技术领域，特别是涉及货款信息处理方法及装置。

背景技术

在电子商务交易平台的一些应用场景下，例如“聚划算”等团购性质的活动等，经常需要参加活动的商家向平台缴纳保证金。这是因为，在团购等性质的活动中，商品的价格往往会低于常规价格，有些商家为了追求高收益、高回报，可能会将一些质量较差商品在活动中进行销售。为了避免这种情况的发生，平台可以要求参加活动的商家缴纳保证金，后续一旦发生产品质量问题导致的买家用户投诉等情况，可以利用这种保证金对买家用户进行赔付。可见，保证金相当于是商家对自己售卖的商品对象在品质等方面提供的一种保证，也是对商家行为的一种约束。

现有技术中，商家支付保证金的方式有多种，例如，其中一种方式是商家直接支付保证金，例如，可以在商家账户内一次性冻结一定的金额(例如，50万等)，冻结期可以比较长(例如，一年)，这样，冻结期内参加活动都可以不再缴纳额外的保证金。这种方式比较适用于频繁参加活动，并且资金压力不大的商家。另一种缴纳保证金的方式是商家可以通过保险公司投保，这样，商家只需要需要交纳保费，具体的保证金将由保险公司提供。这种方式下，商家只需要付出小部分的保费，即可换来资金的快速回笼，因此，比较适合于卖家资金压力比较大，急需资金回笼的商家。

但是，无论是商家直接支付保证金，还是通过保险公司购买“保证金险”，都对商家参与活动提出了一定的门槛要求，使得活动的参与度受到影响。

发明内容

本申请提供了货款信息处理方法及装置，能够通过货款冻结的方式收取第一用户的保证金，提高活动参与度。

本申请提供了如下方案：

一种货款信息处理方法，包括：

为参加目标活动但未预先支付保证金的第一用户生成保证金订单；

接收到针对目标交易订单执行的付款通知后，确定该目标交易订单对应的第一用户，并确定与该第一用户关联的保证金订单；所述目标交易订单为所述目标活动中生成的交易订单；

确定针对该保证金订单的累计冻结金额总数是否已达到预置的额度，如果未达到所述预置额度，则触发对该交易订单关联货款的冻结操作。

一种货款信息处理装置，包括：

保证金订单生成单元，用于为参加目标活动但未预先支付保证金的第一用户生成保证金订单；

信息确定单元，用于接收到针对目标交易订单执行的付款通知后，确定该目标交易订单对应的第一用户，并确定与该第一用户关联的保证金订单；所述目标交易订单为所述目标活动中生成的交易订单；

冻结触发单元，用于确定针对该保证金订单的累计冻结金额总数是否已达到预置的额度，如果未达到所述预置额度，则触发对该交易订单关联货款的冻结操作。

根据本申请提供的具体实施例，本申请公开了以下技术效果：

通过本申请实施例，可以通过货款冻结的方式来收取第一用户的保证金，这样，第一用户不需要提前支付任何形式的保证金，就可以直接参加活动，使得第一用户参加活动的门槛降低，有利于提高活动的参与度，也提高系统的服务质量。

另外，对于需要通过多个应用共同完成该服务的分布式环境，还可以通过基于消息通信的方式来实现数据的原子性、一致性，并且可以保证系统的吞吐量，实现较高的系统性能。

当然，实施本申请的任一产品并不一定需要同时达到以上所述的所有优点。

附图说明

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

图1是本申请实施例提供的方法的流程图；

图2是本申请实施例提供的另一方法的流程图；

图3是本申请实施例提供的装置的示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员所获得的所有其他实施例，都属于本申请保护的范围。

在本申请实施例中，考虑到第二用户(例如买家用户等)向第一用户(例如商家、卖家用户等)付款通常也是通过交易平台的支付系统执行，因此，本申请实施例提供了一种新的缴纳保证金的方式，就是货款冻结，在这种方式下，商家前期不需要缴纳保证金，而是在具体产生交易后，第二用户支付的货款并不是直接转给第一用户账户，而是进行冻结，直到冻结的总金额达到保证金额度为止。通过这种方式，可以使得第一用户参加活动的门槛进一步降低，但由于保证金以其他形式进行冻结，因此，同样可以起到监督第一用户商品质量的作用。下面对具体的实现方式进行详细介绍。

参见图1，本申请实施例首先提供了一种货款信息处理方法，包括：

S101：为参加目标活动但未预先支付保证金的第一用户生成保证金订单；

其中，所谓的目标活动可以是聚划算、天猫、淘宝等电商网站上组织的活动。对于已经预先支付保证金的第一用户，可以通过添加标识等方式加以区分，这样，对于其他申请参加活动，但是不带有该标识的第一用户，就可以分别为这些第一用户生成保证金订单。其中，每个保证金订单可以具有自己的主键ID，并且与第一用户ID等标识相对应。另外，每一个保证金订单中还可以记录有对应的额度信息以及累计冻结金额信息，其中，额度信息用于表明一共需要冻结的金额总数，累计冻结金额信息用于表明已经从交易订单的货款中冻结的金额，在初始状态下，该累计冻结金额为零。也就是说，在具体实现时，可以通过以下表1的形式保存各个保证金订单的信息：

表1

保证金订单ID	第一用户ID	保证金额度(元)	累计冻结金额(元)
				200001	100001	10万	0
200002	100002	20万	0
				……	……	……	……

在生成了保证金订单的情况下，第一用户就可以发布其参加活动的具体的商品对象，并且可以设置在活动中的价格、优惠方式等信息，相应的，在活动开始后，第二用户就可以以对应的价格进行商品对象的购买操作，并且可以享受到相应的优惠。

S102：接收到针对目标交易订单执行的付款通知后，确定该目标交易订单对应的第一用户，并确定与该第一用户关联的保证金订单；所述目标交易订单为所述目标活动中生成的交易订单；

在活动开始后，第二用户就可以对第一用户发布的商品对象执行购买操作，相应的，服务器可以为针对该购买操作生成交易订单。之后，第二用户还可以执行为交易订单付款的操作，付款成功后，就可以进入后续的发货流程等。

需要说明的是，在不同的交易平台中，第二用户付款后资金的流向可能会有所不同，例如，在淘宝体系下，第二用户在下单并付款后，相应的货款会暂时保持在支付宝的公共账户中，待第二用户确认收货之后，再从支付宝账户转账给第一用户。其他的交易平台中，第二用户下单并付款后，相应的货款可能会直接进入到第一用户账户，等等。其中，对于第一种情况，该步骤S102中的付款通知可以是在第二用户执行确认收货操作后，或者系统默认的收货时间到期后，需要从支付宝公共账户向第一用户账户转账的时刻。而对于第二种情况，该付款通知可以就是在第二用户下单并付款后接收到的。

另外需要说明的是，在具体应用中，同一第一用户可能有部分商品对象在参加某活动，其他未参加，并且，参加活动的商品对象也可能能够通过其他途径进行购买等等，而通过不同途径进行商品对象购买时，在对应的交易订单中可以保存对应的销售途径的标识，这样，服务器可以通过这种标识区分是否为某目标活动中产生的交易订单。

对于属于某目标活动中产生的交易订单，则在本申请实施例中，并不是直接将货款转到第一用户账户中，而是在确定出对应的第一用户后，首先确定出该第一用户关联的保证金订单。具体的，如表1所示，由于预先保存了第一用户ID与保证金订单ID之间的关联关系，因此，在确定出第一用户之后，就可以根据第一用户ID确定出管理的保证金订单ID。

S103：确定针对该保证金订单的累计冻结金额总数是否已达到预置的额度，如果未达到所述预置额度，则触发对该交易订单关联货款的冻结操作。

在确定出关联的保证金订单后，可以确定针对该保证金订单的累计冻结金额总数是否已达到预置的额度，如果还没有达到该额度，就可以通知支付系统对该交易订单关联的货款进行冻结操作。也就是说，第一用户的保证金是通过第二用户支付的货款累加得到的，在累计到预置的额度之后，就可以不必再进行冻结，直接将第二用户支付的货款转入第一用户账户即可。

可见，通过这种方式，第一用户不需要在参加活动之前提前支付保证金，而是在活动开始之后，从第二用户支付的货款中进行冻结，这样，可以使得第一用户更方便地参加到活动中来，并且，保证金仍然存在，只是以其他形式进行冻结，因此，同样可以起到监督第一用户商品质量的作用。

当然，需要说明的是，在实际应用中，第二用户针对交易订单执行的付款操作可能会存在并发性，尤其是在一些促销等活动期间，交易订单数量很多，这种并发的情况更是常见。例如，在某时刻，某第二用户甲针对其交易订单执行了确认收货操作，服务器在收到该通知后，可以开始执行具体的冻结额度判断、资金冻结等操作。但是，在该针对第二用户甲的冻结操作执行完成之前，可能第二用户乙也对其交易订单执行了确认收货操作，并且这两个交易订单关联了同一第一用户，进而也关联了同一保证金订单，这就可能存在以下情况：针对甲的确认收货操作进行冻结金额判断时，可能累计冻结金额总数尚未达到预置的额度，但在加上该第二用户甲支付的货款后，累计冻结金额总数就达到了预置的额度，也就是说，第二用户乙在后支付的货款不必再执行冻结操作。但是，如果针对甲的货款冻结操作尚未执行完成，则甲的货款尚未累加到累计冻结金额，此时，如果直接进行判断，则也会发现累计冻结金额总数尚未达到预置的额度，于是将乙支付的货款也进行了冻结，这显然是错误的。

为了避免出现这种由于并发导致的出错现象，可以通过以下方式进行：可以为保证金订单设置“同步锁”，每次收到一个针对交易订单的付款通知，并确定出与该第一用户关联的保证金订单后，可以首先判断该保证金订单是否处于锁定状态，如果保证金订单处于未被锁定的状态，则先锁定该保证金订单，之后再执行后续的额度判断、货款锁定等操作，并在操作完成后，再解除对所述保证金订单的锁定。如果发现保证金订单处于锁定状态，则可以先等待，待保证金订单解除锁定后再执行具体的额度判断、货款锁定等操作。

另外，在具体实现时，由于是在交易的过程中进行资金的冻结，因此，服务器需要在处理逻辑上进行配合。其中，在进行资金冻结的过程中，会涉及到交易流程、支付流程等方面的改进，而在实际的应用中，交易系统与支付系统可能是相互独立的系统，甚至支付系统可能还分为代理系统(例如，汇金)以及支付操作执行系统(例如，支付宝)，等等，因此，可能会需要多个系统之间的相互配合才能支持该服务。这种通过多个系统共同完成一项服务的形式，就形成了一种分布式系统。在这种分布式系统中进行数据处理时，通常既要保证数据的原子性以及一致性，又要保证有较高的性能，例如，需要具有较高的吞吐能力，能及时的处理大量的交易订单等。

在交易系统与支付系统独立的情况下，步骤S103中的触发对该交易订单关联货款的冻结操作，具体可以是通知支付系统对该交易订单关联的货款进行冻结操作。具体实现时，可以使用分布式事务来保证数据原子性以及一致性，但是，分布式事务系统涉及多个节点的通信和资源锁定，吞吐量低，性能差，这对于大数据业务处理系统是致命的。例如，在交易系统产生了一笔交易订单后，为了执行货款冻结操作，交易系统需要创建一个事务，然后调用相关的支付系统对该事务进行处理，在支付系统处理事务的过程中，交易系统只能等待，直到返回成功通知后，才能执行其他事务。而一旦支付系统返回操作失败，则需要将与该事务相关的数据删除，重新创建事务，并重新调用支付系统进行处理。

因此，在本申请实施例中，可以采用notify消息通信，来避免各业务耦合，另外，还可以通过消息的重发机制保证数据的最终一致性，并利用业务唯一性id解决消息重复问题，使用乐观锁解决读写一致性，等等。下面对此进行介绍。

具体的，参见图2，在分布式系统的情况下，可以通过以下步骤进行货款信息处理：

S201：为参加目标活动但未预先支付保证金的第一用户生成保证金订单；

S202：接收到针对目标交易订单执行的付款通知后，确定该目标交易订单对应的第一用户，并确定与该第一用户关联的保证金订单；所述目标交易订单为所述目标活动中生成的交易订单；

步骤S201-S202与图1中的S101-S102可以是相同的，这里不再赘述。

S203：判断该保证金订单是否处于锁定状态，如果保证金订单处于未被锁定的状态，则锁定该保证金订单；

S204：确定针对该保证金订单的累计冻结金额总数是否已达到预置的额度，如果未达到所述预置额度，则新增冻结明细记录，所述记录中的内容包括交易订单标识、保证金订单标识以及待冻结的金额；

S205：通过调用支付系统的预置接口，向支付系统发送冻结处理请求消息，以便所述支付系统将对应金额的货款执行冻结操作，所述冻结处理请求消息中携带有所述冻结明细记录中的内容。

也就是说，在本申请实施例中，可以直接通过调用接口发送消息的方式，向支付系统发送冻结处理请求消息，这样，支付系统就可以基于该消息执行相应的冻结操作，在支付系统执行冻结操作的过程中，交易系统可以不必等待，继续执行其他操作即可。后续在支付系统操作完成后，可以向交易系统返回响应消息，通过该响应消息，将处理结果返回给交易系统。

其中，支付系统的响应结果可能有两种，一种是操作成功的响应消息，另一种是操作失败的响应消息，对于前一种，可以直接更新所述冻结明细记录的状态，如果收到操作失败的响应消息，则只要通过重发所述冻结处理请求消息，来重新发起请求，直到接收到操作成功的响应消息。也就是说，在这种基于notify消息通信的方式中，交易系统在向支付系统发送了冻结处理请求消息后，无需等待支付系统，在支付系统返回响应后，如果发现响应失败，只重新发送该消息即可，这样，可以提高系统吞吐量。

其中，如果支付系统分为代理系统以及支付操作执行系统，则交易系统可以首先调用代理系统的接口，由代理系统将冻结处理请求消息发送到支付操作执行系统，支付操作执行系统执行具体的货款冻结操作。此时，代理系统在接口调用后，可以向交易系统返回响应消息，告知调用成功或者失败，在支付操作执行系统进行具体的冻结操作后，也可以向交易系统返回响应消息，告知操作成功或者操作失败等。相应的，对于冻结明细记录而言，可以有三种状态，在冻结明细记录生成之初，也即初始状态下，可以为第一状态(例如，失败)；在收到接口调用成功的响应后，可以更新到第二状态(例如，处理中)，在收到冻结操作成功的响应后，可以更新到第三状态(例如，处理成功)。

其中，如果代理系统返回的响应消息显示接口调用失败，则可以通过重新调用代理系统的接口的方式，重新发送冻结处理请求消息，直到接收到接口调用成功响应。另外，在代理系统向支付操作执行系统发送了冻结处理请求消息后，该支付操作执行系统执行货款冻结操作，并在货款冻结操作成功后，向代理系统返回冻结成功响应，代理系统再向交易系统返回该冻结成功响应，如果支付操作执行系统执行货款冻结操作不成功，则代理系统同样可以通过重新调用支付操作执行系统的接口的方式，重新向其发送冻结处理请求消息，直到接收到所述支付操作执行系统返回的冻结成功响应消息。

需要说明的是，在更新所述冻结明细记录的状态时可以采用乐观锁机制，例如，在将冻结明细记录更新为第二状态时，前提条件必须是，其冻结明细记录的上一状态为第一状态，也即，只有当冻结明细记录的上一状态为第一状态时，才能将其更新为第二状态，只有当冻结明细记录的上一状态为第二状态时，才能更新为第三状态，而不能在上一状态为第一状态时，直接更新为第三状态。这样有利于保证数据的一致性。

另外，在数据一致性问题上，还可能存在以下情况：在本申请实施例中，如果交易系统收到代理系统返回的接口调用失败的响应消息，或者代理系统接收到支付操作执行系统返回的冻结失败的响应消息，都可以通过重新调用接口的方式，重新发送冻结处理请求消息，但是，在实际应用中，有可能是因为网络延迟等现象导致接收方接收到的是调用失败的响应消息，但实际上响应消息的发送方实际上已经执行了相关的操作。例如，代理系统在成功响应了交易系统的接口调用请求后，正常返回了调用成功的响应，并且已经向支付操作执行系统发送冻结处理请求消息。但是，由于网络延迟等因素，导致交易系统实际收到的响应是接口调用失败的响应消息。此时，如果直接重新向代理系统发送冻结处理请求消息，可能会导致代理系统重复执行同一条消息。

针对这种情况，在本申请实施例中，在冻结处理请求消息中还可以包括冻结明细记录的记录标识(例如，冻结明细记录的主键ID等)，这样，代理系统在接收到相应的冻结处理请求消息时，可以利用该冻结明细记录的记录标识，确定该条消息是否已经处理过，并将已经处理过的消息忽略。

最后，在冻结操作执行成功后，还可以记录此次冻结的货款金额，以便更新所述累计冻结金额总数。这样，随着一次次的货款冻结操作，可以逐渐增加对应第一用户的保证金金额，直到达到预置的金额为止。当然，在活动结束后，还可以将冻结的保证金进行解冻，转入到第一用户的账户中。

总之，通过本申请实施例，可以通过货款冻结的方式来收取第一用户的保证金，这样，第一用户不需要提前支付任何形式的保证金，就可以直接参加活动，使得第一用户参加活动的门槛降低，有利于提高活动的参与度，也提高系统的服务质量。

另外，对于需要通过多个应用共同完成该服务的分布式环境，还可以通过基于消息通信的方式来实现数据的原子性、一致性，并且可以保证系统的吞吐量，实现较高的系统性能。

与本申请实施例提供的货款信息处理方法相对应，本申请实施例还提供了一种货款信息处理装置，参见图3，该装置具体可以包括：

保证金订单生成单元301，用于为参加目标活动但未预先支付保证金的第一用户生成保证金订单；

信息确定单元302，用于接收到针对目标交易订单执行的付款通知后，确定该目标交易订单对应的第一用户，并确定与该第一用户关联的保证金订单；所述目标交易订单为所述目标活动中生成的交易订单；

冻结触发单元303，用于确定针对该保证金订单的累计冻结金额总数是否已达到预置的额度，如果未达到所述预置额度，则触发对该交易订单关联货款的冻结操作。

具体实现时，为了防止并发，该装置还可以包括：

锁定单元，用于确定出与该第一用户关联的保证金订单后，判断该保证金订单是否处于锁定状态，如果保证金订单处于未被锁定的状态，则锁定该保证金订单；

解除锁定单元，用于冻结操作成功后，解除对所述保证金订单的锁定。

其中，在分布式系统下，所述冻结触发单元包括：

通知子单元，用于通知支付系统对该交易订单关联的货款进行冻结操作。

其中，所述通知子单元包括：

记录增加子单元，用于新增冻结明细记录，所述记录中的内容包括交易订单标识、保证金订单标识以及待冻结的金额；

接口调用子单元，用于通过调用支付系统的预置接口，向支付系统发送冻结处理请求消息，以便所述支付系统将对应金额的货款执行冻结操作，所述冻结处理请求消息中携带有所述冻结明细记录中的内容。

另外，所述通知子单元还可以包括：

重试子单元，用于接收所述支付系统的响应消息，其中，当收到操作成功的响应消息时，更新所述冻结明细记录的状态，如果收到操作失败的响应消息，则通过重发所述冻结处理请求消息，直到接收到操作成功的响应消息。

其中，所述冻结明细记录在初始状态下为第一状态，所述支付系统包括代理系统以及支付操作执行系统，所述接口调用子单元包括：

代理系统调用子单元，用于通过调用所述代理系统的预置接口，向所述代理系统发送冻结处理请求消息；

第一状态更新子单元，用于如果接收到所述代理系统返回的接口调用成功响应消息，则将所述冻结明细记录的状态更新为第二状态，如果接收到所述代理系统的接口调用失败响应消息，则重新向所述代理系统发送所述冻结处理请求消息，直到接收到接口调用成功响应；所述代理系统在成功响应后，调用所述支付操作执行系统的接口，将所述冻结处理请求消息发送到所述支付操作执行系统，由所述支付操作执行系统执行货款冻结操作；

第二状态更新子单元，用于在接收到所述代理系统返回的冻结成功响应消息后，将所述冻结明细记录的状态更新为第三状态。

所述代理系统如果接收到所述支付操作执行系统返回的冻结失败响应消息，则所述重新调用所述支付操作执行系统的接口，将所述冻结处理请求消息发送到所述支付操作执行系统，直到接收到所述支付操作执行系统返回的冻结成功响应消息。

在更新所述冻结明细记录的状态时采用乐观锁机制。

所述冻结处理请求消息中还包括所述冻结明细记录的记录标识，以便所述代理系统接收到冻结处理请求消息时，利用所述冻结明细记录的记录标识，确定该条消息是否已经处理过，并将已经处理过的消息忽略。

具体实现时，该装置还可以包括：

冻结金额记录单元，用于冻结操作成功后，记录此次冻结的货款金额，以便更新所述累计冻结金额总数。

通过本申请实施例，可以通过货款冻结的方式来收取第一用户的保证金，这样，第一用户不需要提前支付任何形式的保证金，就可以直接参加活动，使得第一用户参加活动的门槛降低，有利于提高活动的参与度，也提高系统的服务质量。

另外，对于需要通过多个应用共同完成该服务的分布式环境，还可以通过基于消息通信的方式来实现数据的原子性、一致性，并且可以保证系统的吞吐量，实现较高的系统性能。

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

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

以上对本申请所提供的货款信息处理方法及装置，进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处。综上所述，本说明书内容不应理解为对本申请的限制。

Claims (20)

1.一种货款信息处理方法，其特征在于，包括：

为参加目标活动但未预先支付保证金的第一用户生成保证金订单；

接收到针对目标交易订单执行的付款通知后，确定该目标交易订单对应的第一用户，并确定与该第一用户关联的保证金订单；所述目标交易订单为所述目标活动中生成的交易订单，所述付款通知依据第二用户的付款操作确定；

确定针对该保证金订单的累计冻结金额总数是否已达到预置的额度，如果未达到所述预置额度，则触发对该交易订单关联货款的冻结操作。

2.根据权利要求1所述的方法，其特征在于，还包括：

确定出与该第一用户关联的保证金订单后，判断该保证金订单是否处于锁定状态，如果保证金订单处于未被锁定的状态，则锁定该保证金订单；

冻结操作成功后，解除对所述保证金订单的锁定。

3.根据权利要求1所述的方法，其特征在于，所述触发对该交易订单关联货款的冻结操作，包括：

通知支付系统对该交易订单关联的货款进行冻结操作。

4.根据权利要求3所述的方法，其特征在于，所述通知支付系统对该交易订单关联的货款进行冻结操作，包括：

新增冻结明细记录，所述记录中的内容包括交易订单标识、保证金订单标识以及待冻结的金额；

通过调用支付系统的预置接口，向支付系统发送冻结处理请求消息，以便所述支付系统将对应金额的货款执行冻结操作，所述冻结处理请求消息中携带有所述冻结明细记录中的内容。

5.根据权利要求4所述的方法，其特征在于，还包括：

接收所述支付系统的响应消息，其中，当收到操作成功的响应消息时，更新所述冻结明细记录的状态，如果收到操作失败的响应消息，则通过重发所述冻结处理请求消息，直到接收到操作成功的响应消息。

6.根据权利要求5所述的方法，其特征在于，所述冻结明细记录在初始状态下为第一状态，所述支付系统包括代理系统以及支付操作执行系统，所述通过调用支付系统的预置接口，向支付系统发送冻结处理请求消息，包括：

通过调用所述代理系统的预置接口，向所述代理系统发送冻结处理请求消息；

如果接收到所述代理系统返回的接口调用成功响应消息，则将所述冻结明细记录的状态更新为第二状态，如果接收到所述代理系统的接口调用失败响应消息，则重新向所述代理系统发送所述冻结处理请求消息，直到接收到接口调用成功响应；所述代理系统在成功响应后，调用所述支付操作执行系统的接口，将所述冻结处理请求消息发送到所述支付操作执行系统，由所述支付操作执行系统执行货款冻结操作；

在接收到所述代理系统返回的冻结成功响应消息后，将所述冻结明细记录的状态更新为第三状态。

7.根据权利要求6所述的方法，其特征在于，所述代理系统如果接收到所述支付操作执行系统返回的冻结失败响应消息，则重新调用所述支付操作执行系统的接口，将所述冻结处理请求消息发送到所述支付操作执行系统，直到接收到所述支付操作执行系统返回的冻结成功响应消息。

8.根据权利要求5所述的方法，其特征在于，在更新所述冻结明细记录的状态时采用乐观锁机制。

9.根据权利要求5所述的方法，其特征在于，所述冻结处理请求消息中还包括所述冻结明细记录的记录标识，以便代理系统接收到冻结处理请求消息时，利用所述冻结明细记录的记录标识，确定该条消息是否已经处理过，并将已经处理过的消息忽略。

10.根据权利要求1至9任一项所述的方法，其特征在于，还包括：

冻结操作成功后，记录此次冻结的货款金额，以便更新所述累计冻结金额总数。

11.一种货款信息处理装置，其特征在于，包括：

保证金订单生成单元，用于为参加目标活动但未预先支付保证金的第一用户生成保证金订单，付款通知依据第二用户的付款操作确定；

信息确定单元，用于接收到针对目标交易订单执行的付款通知后，确定该目标交易订单对应的第一用户，并确定与该第一用户关联的保证金订单；所述目标交易订单为所述目标活动中生成的交易订单；

冻结触发单元，用于确定针对该保证金订单的累计冻结金额总数是否已达到预置的额度，如果未达到所述预置额度，则触发对该交易订单关联货款的冻结操作。

12.根据权利要求11所述的装置，其特征在于，还包括：

锁定单元，用于确定出与该第一用户关联的保证金订单后，判断该保证金订单是否处于锁定状态，如果保证金订单处于未被锁定的状态，则锁定该保证金订单；

解除锁定单元，用于冻结操作成功后，解除对所述保证金订单的锁定。

13.根据权利要求11所述的装置，其特征在于，所述冻结触发单元包括：

通知子单元，用于通知支付系统对该交易订单关联的货款进行冻结操作。

14.根据权利要求13所述的装置，其特征在于，所述通知子单元包括：

记录增加子单元，用于新增冻结明细记录，所述记录中的内容包括交易订单标识、保证金订单标识以及待冻结的金额；

接口调用子单元，用于通过调用支付系统的预置接口，向支付系统发送冻结处理请求消息，以便所述支付系统将对应金额的货款执行冻结操作，所述冻结处理请求消息中携带有所述冻结明细记录中的内容。

15.根据权利要求14所述的装置，其特征在于，所述通知子单元还包括：

重试子单元，用于接收所述支付系统的响应消息，其中，当收到操作成功的响应消息时，更新所述冻结明细记录的状态，如果收到操作失败的响应消息，则通过重发所述冻结处理请求消息，直到接收到操作成功的响应消息。

16.根据权利要求15所述的装置，其特征在于，所述冻结明细记录在初始状态下为第一状态，所述支付系统包括代理系统以及支付操作执行系统，所述接口调用子单元包括：

代理系统调用子单元，用于通过调用所述代理系统的预置接口，向所述代理系统发送冻结处理请求消息；

第一状态更新子单元，用于如果接收到所述代理系统返回的接口调用成功响应消息，则将所述冻结明细记录的状态更新为第二状态，如果接收到所述代理系统的接口调用失败响应消息，则重新向所述代理系统发送所述冻结处理请求消息，直到接收到接口调用成功响应；所述代理系统在成功响应后，调用所述支付操作执行系统的接口，将所述冻结处理请求消息发送到所述支付操作执行系统，由所述支付操作执行系统执行货款冻结操作；

第二状态更新子单元，用于在接收到所述代理系统返回的冻结成功响应消息后，将所述冻结明细记录的状态更新为第三状态。

17.根据权利要求16所述的装置，其特征在于，所述代理系统如果接收到所述支付操作执行系统返回的冻结失败响应消息，则重新调用所述支付操作执行系统的接口，将所述冻结处理请求消息发送到所述支付操作执行系统，直到接收到所述支付操作执行系统返回的冻结成功响应消息。

18.根据权利要求15所述的装置，其特征在于，在更新所述冻结明细记录的状态时采用乐观锁机制。

19.根据权利要求15所述的装置，其特征在于，所述冻结处理请求消息中还包括所述冻结明细记录的记录标识，以便代理系统接收到冻结处理请求消息时，利用所述冻结明细记录的记录标识，确定该条消息是否已经处理过，并将已经处理过的消息忽略。

20.根据权利要求11至19任一项所述的装置，其特征在于，还包括：

冻结金额记录单元，用于冻结操作成功后，记录此次冻结的货款金额，以便更新所述累计冻结金额总数。

Images