CN107203919B - 业务信息的处理方法及装置 - Google Patents

Abstract

本申请提供业务信息的处理方法及装置，该方法应用在业务服务器上，包括：为具有业务关联关系的第一用户和第二用户生成业务表单；获取第一用户在针对业务表单中的目标业务属性进行操作后得到的第一结果信息；判断第一结果信息与第二结果信息是否一致，其中，第二结果信息为第二用户针对目标业务属性进行操作后得到的结果信息；如果第一结果信息与第二结果信息不一致，则输出针对所述目标业务属性的操作提醒。本申请实施例可以在双方用户操作不一致导致业务信息不一致时，通过提示双方用户避免业务处理过程的滞后，从而可以提高业务的完成效率，并且节省因为业务可能长时间存续需要耗费的维护资源和存储资源。

Description

业务信息的处理方法及装置

技术领域

本申请涉及互联网技术领域，特别涉及业务信息的处理方法及装置。

背景技术

随着互联网的发展，越来越多业务的开展，利用了网络的便捷性及其信息交互的及时性。其中，一种典型的业务包括越来越多的用户开始使用的网络购物(简称网购)，但是网络购物过程中带来的信息交互不对等，导致业务停滞的问题越来越多。

以网络购物为例，买家下单成功后，在付款的同时，卖家修改了订单价格，由于付款信息和订单信息不一致，将导致订单状态停滞不前，此时该订单成为脏数据；对于上述订单，只有系统接收到买家投诉或者系统对账订单信息并发现这种情况后，系统才会把买家已支付的金额退还给买家，并且关闭该订单。上述处理方式不仅将导致业务处理过程的滞后，而且在业务存续过程中，大量脏数据的存在可能会极大浪费系统的维护和存储资源。

发明内容

有鉴于此，本申请提供业务信息的处理方法及装置，以解决现有业务处理方式容易导致业务处理过程滞后，且容易浪费系统的维护和存储资源的问题。

本申请通过如下技术方案实现：

第一方面，提供一种业务信息的处理方法，所述方法应用在业务服务器上，所述方法包括：

为具有业务关联关系的第一用户和第二用户生成业务表单；

获取所述第一用户在针对所述业务表单中的目标业务属性进行操作后得到的第一结果信息；

判断所述第一结果信息与第二结果信息是否一致，其中，所述第二结果信息为所述第二用户针对所述目标业务属性进行操作后得到的结果信息；

如果所述第一结果信息与所述第二结果信息不一致，则输出针对所述目标业务属性的操作提醒。

第二方面，提供另一种业务信息的处理方法，所述方法包括：

获取第一用户已支付交易订单的支付金额；

判断所述支付金额与所述交易订单的实际金额是否一致，其中，所述实际金额为与所述第一用户关联的第二用户设定的金额；

如果所述支付金额与所述实际金额不一致，则输出处理所述交易订单的提醒。

可选的，如果所述支付金额与所述实际金额不一致，则输出处理所述交易订单的提醒，包括：

如果所述支付金额小于所述实际金额，则提醒所述第一用户补差额，所述差额为所述实际金额与所述支付金额的差值；或者

如果所述支付金额小于所述实际金额，则提醒所述第二用户修改所述实际金额与所述支付金额一致。

可选的，还包括：

如果确定所述第一用户支付所述差额，或者所述第二用户修改所述实际金额与所述支付金额一致，则标记所述交易订单完成；或者

如果接收到所述第一用户或第二用户发送的终止所述交易的请求，则根据所述请求将所述支付金额退还给所述第一用户，并关闭所述交易订单。

可选的，如果所述支付金额与所述实际金额不一致，则输出处理所述交易订单的提醒，包括：

如果所述支付金额大于所述实际金额，则将差额退还给所述第一用户，其中，所述差额为所述支付金额与所述实际金额的差值。

可选的，还包括：

如果所述支付金额与所述实际金额一致，则提醒所述第一用户和第二用户针对所述交易订单的交易成功。

可选的，所述判断所述支付金额与所述交易订单的实际金额是否一致的步骤在所述第一用户支付所述交易订单之后执行；和/或

所述判断所述支付金额与所述交易订单的实际金额是否一致的步骤在所述第二用户修改所述交易订单之后执行。

第三方面，提供一种业务信息的处理装置，所述装置应用在业务服务器上，所述装置包括：

生成单元，用于为具有业务关联关系的第一用户和第二用户生成业务表单；

获取单元，用于获取所述第一用户在针对所述业务表单中的目标业务属性进行操作后得到的第一结果信息；

判断单元，用于判断所述第一结果信息与第二结果信息是否一致，其中，所述第二结果信息为所述第二用户针对所述目标业务属性进行操作后得到的结果信息；

提醒单元，用于如果所述判断单元的判断结果为所述第一结果信息与所述第二结果信息不一致，则输出针对所述目标业务属性的操作提醒。

第四方面，提供另一种业务信息的处理装置，所述装置包括：

获取单元，用于获取第一用户已支付交易订单的支付金额；

判断单元，用于判断所述支付金额与所述交易订单的实际金额是否一致，其中，所述实际金额为与所述第一用户关联的第二用户设定的金额；

提醒单元，用于在所述判断单元判断所述支付金额与所述实际金额不一致时，输出处理所述交易订单的提醒。

可选的，所述提醒单元包括：

第一提醒单元，用于在所述判断单元判断所述支付金额小于所述实际金额时，提醒所述第一用户补差额，所述差额为所述实际金额与所述支付金额的差值；和/或

第二提醒单元，用于在所述判断单元判断所述支付金额小于所述实际金额时，提醒所述第二用户修改所述实际金额与所述支付金额一致。

可选的，还包括：确定单元和标记单元；和/或，接收单元，第一退还单元和关闭单元，其中，

所述确定单元，用于确定所述第一用户支付所述差额，或者所述第二用户修改所述实际金额与所述支付金额一致；

所述标记单元，用于基于所述确定单元的确定结果，标记所述交易订单完成；

所述接收单元，用于接收所述第一用户或第二用户发送的终止所述交易的请求；

所述第一退还单元，用于根据所述请求将所述支付金额退还给所述第一用户；

所述关闭单元，用于在所述第一退还单元将所述支付金额退还给所述第一用户时，关闭所述交易订单。

可选的，还包括：

第二退还单元，用于在所述判断单元判断所述支付金额大于所述实际金额时，将差额退还给所述第一用户，其中，所述差额为所述支付金额与所述实际金额的差值。

可选的，所述提醒单元包括：

第三提醒单元，用于在所述判断单元判断所述支付金额与所述实际金额一致时，提醒所述第一用户和第二用户针对所述交易订单的交易成功。

可选的，所述判断单元，具体用于在所述第一用户支付所述交易订单之后判断所述支付金额与所述实际金额是否一致；和/或在所述第二用户修改所述交易订单之后判断所述支付金额与所述实际金额是否一致。

本申请实施例中，在为具有业务关联关系的第一用户和第二用户生成业务表单后，业务服务器在判断第一用户在针对业务表单中的目标业务属性进行操作后得到的第一结果信息，与第二用户针对目标业务属性进行操作后得到的第二结果信息不一致时，可以通过调用预设的异步任务输出针对目标业务属性的操作提醒，因此可以在双方用户操作不一致导致业务信息不一致时，通过提示双方用户避免业务处理过程的滞后，从而可以提高业务的完成效率，并且节省因为业务可能长时间存续需要耗费的维护资源和存储资源；另外，应用本申请实施例进行网购交易时，当发生付款和修改价格的并发导致订单金额不一致时，系统可以提醒买家或卖家及时处理该交易订单，即把操作权交还给买卖双方，从而提高交易的达成量。

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

附图说明

图1A是本申请实施例提出的一种业务信息的处理方法的流程图；

图1B是本申请实施例提供的另一种业务信息的处理方法的流程图；

图2是本申请实施例提出的一种业务信息的处理方法的一种应用实例的流程图；

图3是本申请实施例提出的一种业务信息的处理装置所在设备的一种硬件结构图；

图4是本申请实施例提出的一种业务信息的处理装置的结构示意图；

图5是本申请实施例提出的一种业务信息的处理装置的另一结构示意图；

图6是本申请实施例提出的一种业务信息的处理装置的另一结构示意图；

图7是本申请实施例提出的一种业务信息的处理装置的另一结构示意图。

具体实施方式

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

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

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

请参阅图1A，为本申请实施例提出的一种业务信息的处理方法的流程图，该方法可以应用在业务服务器上，包括：

步骤111：为具有业务关联关系的第一用户和第二用户生成业务表单；

本申请实施例中，业务可以指各种利用互联网实现用户之间交互的业务，例如，网络交易业务，即时通信业务等，要使用上述业务的用户可以预先设置业务账户，并通过业务账户登录到业务服务器后，实现相关业务；具有业务关联关系的用户可以指基于同一业务实例产生某种绑定关系的用户，例如，网络交易业务下购买了某种商品的买家，以及出售该商品的卖家。

本步骤中，第一用户和第二用户基于各自业务账户登录业务服务器后，当第一用户和第二用户针对同一业务实例进行了操作，并因此具有了业务关联关系后，业务服务器为第一用户和第二用户生成业务表单，该业务表单中可以包含因为操作该业务实例从而生成的各种业务属性，例如，如果为作为买卖双方的第一用户和第二用户生成了交易订单，则该交易订单中的各种业务属性可以包括：商品信息(例如，名称、规格、数量等)、买家信息(姓名、地址、联系方式等)、卖家信息(姓名、地址、联系方式等)、交易金额、优惠金额等。

步骤112：获取第一用户在针对业务表单中的目标业务属性进行操作后得到的第一结果信息；

结合步骤111，业务表单中可以包含各种业务属性，本步骤中，如果第一用户针对业务表单中的某个业务属性进行了操作，则可以将所操作的这个业务属性称为目标业务属性，其中，该操作可以包括：支付、修改等。在针对目标业务属性进行操作后，得到的操作结果信息称为第一结果信息，例如，如果买家对交易订单中的目标业务属性“交易金额”进行支付，则获取到的第一结果信息可以为支付完成后的支付金额。

步骤113：判断第一结果信息与第二结果信息是否一致，其中，第二结果信息为第二用户针对目标业务属性进行操作后得到的结果；

结合步骤112，由于业务表单同时面向第一用户和第二用户，因此第一用户和第二用户可以具有针对业务表单中的业务属性进行操作的同等权限。当第二用户也针对目标业务属性进行操作后，得到的操作结果信息称为第二结果信息。例如，如果卖家对交易订单中的目标业务属性“交易金额”进行修改，则相应的第二结果信息可以为修改完成后的实际金额。

步骤114：如果第一结果信息与第二结果信息不一致，则输出针对目标业务属性的操作提醒。

结合步骤113，如果第一结果信息与第二结果信息一致，则针对该业务表单的业务进程可以继续，如果第一结果信息与第二结果信息不一致，则为了避免业务停滞，可以输出针对目标业务属性的操作提醒，从而提示第一用户或第二用户通过进一步操作，使得双方针对目标业务属性的操作结果信息达成一致，以保证业务进程的持续。

由上述实施例可见，该实施例可以在第一用户和第二用户针对目标业务属性操作不一致，从而导致业务信息不一致的情况下，通过提示双方用户避免业务处理过程的滞后，从而可以提高业务的完成效率，节省因为业务可能长时间存续需要耗费的维护资源和存储资源。

在一个可选的实现方式中，业务服务器可以通过调用异步任务的方式完成上述业务信息的处理过程，从而可以在不影响现有业务表单的常规处理过程的同时，进一步提升业务服务器的并发处理能力。

请参阅图1B，为本申请实施例提出的另一种业务信息的处理方法的流程图，所述方法包括：

步骤101：获取第一用户已支付的交易订单的支付金额；

第一用户(例如，买家)在网上对购买的商品下订单，并付款成功后，系统会检测到该订单的支付金额。

步骤102：判断所述支付金额与订单实际金额是否一致，其中，所述订单实际金额为第二用户设定的金额；

在该实施例中，第一用户(例如，买家)在付款的同时，第二用户(例如，卖家)有可能正在修改该商品的价格，此时，该订单的实际价格就会发生变化。也就是说，由于买家付款和卖家修改价格并行操作，从而导致该订单的支付金额与实际金额不一致。基于此，本实施例中，在系统检测到该订单的支付金额时，会与该订单的实际金额进行比较，来判断该支付金额与订单实际金额是否一致。

其中，所述订单实际金额为卖家设定的金额，该金额可以由卖家依据需要进行适应性调整。

该实施例中，所述判断所述支付金额与订单实际金额是否一致的步骤可以在所述第一用户支付所述交易订单之后执行；和/或也可以在所述第二用户修改所述交易订单之后执行。

步骤103：如果所述支付金额与所述订单实际金额不一致，则提醒所述第一用户或第二用户处理所述交易订单，以促进所述交易达成。

该步骤中，当系统检测到支付金额与所述订单实际金额不一致时，异步提醒所述第一用户或第二用户处理所述交易订单，主要包括下述几种情况：

第一种情况，如果所述支付金额小于所述订单实际金额，则系统提醒所述第一用户(例如，买家)补差额，所述差额为所述订单实际金额与所述支付金额的差值；

针对这种情况，当系统检测到所述支付金额小于所述订单实际金额时，发出提醒买家补付该订单的差价的请求，该请求中还可以包括提醒买家知晓这种付款和修改价格的并发情况的信息；

买家在接收到补付该订单差价的请求时，一种方式是，买家及时补付该差价，以便于系统在接收到买家补付的差价后，使该订单的状态进入卖家发货状态；另一种方式，买家发出主动终止交易请求，系统在接收到该请求后，将已付款的金额退还给买家，并关闭该订单，即该订单显示为无效。

第二种情况，如果所述支付金额小于所述订单实际金额，则系统提醒所述第二用户(例如，卖家)修改所述订单实际金额与所述支付金额一致；或者提醒第二用户取消上次价格修改。

这种情况下，可以提醒卖家取消上次的改价，从而可以向卖家提供一个入口，让卖家主动把订单金额修改成买家已付金额，促进交易达成。

第三种情况，如果所述支付金额大于所述订单实际金额，则系统主动将差额退还给所述第一用户，其中，所述差额为所述支付金额与所述订单实际金额的差值。当然，该实施例中，除了系统将差额退还给所述第一用户外，还可以采用担保交易或者直接打款等方式，也可以是平台退款或者卖家直接退款等，对此本实施例不做限制。

针对这种情况，系统检测到买家付款金额大于订单实际金额时，提醒买家这种付款和修改价格的并发情况，并自动把差额退换给买家，同时订单进入发货状态。

本申请实施例中，当发生付款和修改价格的并发导致订单金额不一致时，系统提醒买家或卖家及时处理该交易订单，即把操作权交还给买卖双方，以积极促进交易的达成，提高了交易的达成量，减少了买卖双方咨询客服的咨询量，还提高了买卖双方的满意度。进一步，由于系统可以异步准实时监测这种并发情况，没有增加订单关键链路的负担，提升系统的并发处理量。

还请参阅图2，为本申请实施例提供的一种业务信息的处理方法的一种应用实例的流程图，本实施例中，以第一用户为买家，第二用户为卖家，以及系统为执行主体为例，当然在实际应用中可以并不限于此。所述方法包括：

步骤201：系统获取买家已支付的交易订单的支付金额；

该步骤与步骤101同，具体详见上述，在此不再赘述。

步骤202：系统判断所述支付金额与订单实际金额是否一致，其中，所述订单实际金额为卖家设定的金额；如果所述支付金额小于订单实际金额，执行步骤203；如果所述支付金额大于订单实际金额，执行步骤206；如果所述支付金额等于订单实际金额，执行步骤205；

步骤203：系统提醒所述买家补差额，所述差额为所述订单实际金额与所述支付金额的差值；或者提醒所述卖家修改所述订单实际金额与所述支付金额一致；

步骤204：接收所述买家支付的所述交易订单的所述差额，标记所述交易订单完成；转到步骤207；

步骤205：系统提醒所述买家和卖家所述交易订单成功；转到步骤207；

步骤206：系统主动将差额退还给所述买家，其中，所述差额为所述支付金额与所述订单实际金额的差值；转到步骤207；

步骤207：系统等待卖家发货，并在卖家发货后，将订单状态标记为等到买家收货；

步骤208：系统等待买家收货，并在买家收货后，将订单状态标记为完成状态。

本申请实施例中，当发生付款和修改价格的并发导致订单金额不一致时，系统提醒买家或卖家及时处理该交易订单，即把操作权交还给买家或卖家，以积极促进交易的达成，提高了交易的达成量，减少了买家或卖家咨询客服的咨询量，还提高了还提高了买卖双方的满意度。进一步，由于系统是异步准实时监测这种并发情况，没有增加订单关键链路的负担，提升系统的并发处理量。

与前述业务信息的处理方法的实施例相对应，本申请还提供了业务信息的处理装置的实施例。

本申请实施例提供的一种业务信息的处理装置的实施例可以应用在业务服务器上。装置实施例可以通过软件实现，也可以通过硬件或者软硬件结合的方式实现。以软件实现为例，作为一个逻辑意义上的装置，是通过其所在业务服务器的处理器将非易失性存储器中对应的计算机程序指令读取到内存中运行形成的。从硬件层面而言，如图3所示，为本申请实施例提供的业务信息的处理装置所在业务服务器的一种硬件结构图，除了图3所示的处理器、内存、网络接口、以及非易失性存储器之外，实施例中装置所在的业务服务器通常可以根据其实际功能，还可以包括其他硬件，对此不再赘述。

请参考图4，图4为本申请实施例提供的一种业务信息的处理装置的结构示意图，所述装置包括：获取单元41，判断单元42和提醒单元43，其中，

所述获取单元41，用于获取第一用户已支付交易订单的支付金额；

所述判断单元42，用于判断所述支付金额与所述交易订单的实际金额是否一致，其中，所述实际金额为与所述第一用户关联的第二用户设定的金额；

其中，所述判断单元42，可以具体用于在所述第一用户支付所述交易订单之后判断所述支付金额与所述实际金额是否一致；或者在所述第二用户修改所述交易订单之后判断所述支付金额与所述实际金额是否一致。

所述提醒单元43，用于在所述判断单元42判断所述支付金额与所述实际金额不一致时，输出处理所述交易订单的提醒。

可选的，在另一实施例中，所述提醒单元包括：第一提醒单元51和/或第二提醒单元52，具体如图5所示，该图5中以同时包括第一提醒单元和第二提醒单元为例)，其中，

所述第一提醒单元51，用于在所述判断单元42判断所述支付金额小于所述实际金额时，提醒所述第一用户补差额，所述差额为所述实际金额与所述支付金额的差值；

所述第二提醒单元52，用于在所述判断单元42判断所述支付金额小于所述实际金额时，提醒所述第二用户修改所述实际金额与所述支付金额一致。

可选的，在另一实施例中，所述装置还可以包括：确定单元61和标记单元62；和/或，接收单元63，第一退还单元64和关闭单元65，其结构示意图如图6所示，该图6中，以同时包括上述单元为例。其中，

所述确定单元61，用于确定所述第一用户支付所述差额，或者所述第二用户修改所述实际金额与所述支付金额一致；

所述标记单元62，用于基于所述确定单元61的确定结果，标记所述交易订单完成；

所述接收单元63，用于接收所述第一用户或第二用户发送的终止所述交易的请求；

所述第一退还单元64，用于根据所述请求将所述支付金额退还给所述第一用户；

所述关闭单元65，用于在所述第一退还单元将所述支付金额退还给所述第一用户时，关闭所述交易订单。

可选的，在另一实施例中，所述装置还可以包括(图中未示)：

第二退还单元，用于在所述判断单元42判断所述支付金额大于所述实际金额时，将差额退还给所述第一用户，其中，所述差额为所述支付金额与所述实际金额的差值。

可选的，在另一实施例中，所述提醒单元43还可以包括：第三提醒单元(图中未示)，其中，

第三提醒单元61，用于在所述判断单元42判断所述支付金额与所述实际金额一致时，提醒所述第一用户和第二用户针对所述交易订单的交易成功。

请参考图7，图7为本申请实施例提供的一种业务信息的处理装置的另一结构示意图，所述装置包括：生成单元71，获取单元72、判断单元73和提醒单元74。

其中，生成单元71，用于为具有业务关联关系的第一用户和第二用户生成业务表单；

获取单元72，用于获取所述第一用户在针对所述业务表单中的目标业务属性进行操作后得到的第一结果信息；

判断单元73，用于判断所述第一结果信息与第二结果信息是否一致，其中，所述第二结果信息为所述第二用户针对所述目标业务属性进行操作后得到的结果信息；

提醒单元74，用于如果所述判断单元73的判断结果为所述第一结果信息与所述第二结果信息不一致，则输出针对所述目标业务属性的操作提醒。

上述装置中各个单元的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程，在此不再赘述。

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

以上所述仅为本申请的较佳实施例而已，并不用以限制本申请，凡在本申请的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请保护的范围之内。

Claims (14)

1.一种业务信息的处理方法，其特征在于，所述方法应用在业务服务器上，所述方法包括：

为具有业务关联关系的第一用户和第二用户生成业务表单，所述业务表单中包括交易商品的目标业务属性，所述目标业务属性包括交易金额；

获取所述第一用户在针对所述业务表单中的目标业务属性进行支付操作后得到的第一结果信息；

判断所述第一结果信息与第二结果信息是否一致，其中，所述第二结果信息为所述第二用户针对所述目标业务属性进行修改操作后得到的结果信息，所述第二用户针对所述目标业务属性的修改操作在生成所述业务表单之后进行；

如果所述第一结果信息与所述第二结果信息不一致，则输出针对所述目标业务属性的操作提醒。

2.一种业务信息的处理方法，其特征在于，包括：

获取第一用户已支付交易订单的支付金额；

判断所述支付金额与所述交易订单的实际金额是否一致，其中，所述实际金额为与所述第一用户关联的第二用户对所述交易订单对应交易商品的金额进行修改得到，所述第二用户对所述交易商品的金额的修改操作在生成所述交易订单之后进行；

如果所述支付金额与所述实际金额不一致，则输出处理所述交易订单的提醒。

3.根据权利要求2所述的方法，其特征在于，如果所述支付金额与所述实际金额不一致，则输出处理所述交易订单的提醒，包括：

如果所述支付金额小于所述实际金额，则提醒所述第一用户补差额，所述差额为所述实际金额与所述支付金额的差值；或者

如果所述支付金额小于所述实际金额，则提醒所述第二用户修改所述实际金额与所述支付金额一致。

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

如果确定所述第一用户支付所述差额，或者所述第二用户修改所述实际金额与所述支付金额一致，则标记所述交易订单完成；或者

如果接收到所述第一用户或第二用户发送的终止所述交易的请求，则根据所述请求将所述支付金额退还给所述第一用户，并关闭所述交易订单。

5.根据权利要求2所述的方法，其特征在于，如果所述支付金额与所述实际金额不一致，则输出处理所述交易订单的提醒，包括：

如果所述支付金额大于所述实际金额，则将差额退还给所述第一用户，其中，所述差额为所述支付金额与所述实际金额的差值。

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

如果所述支付金额与所述实际金额一致，则提醒所述第一用户和第二用户针对所述交易订单的交易成功。

7.根据权利要求2至5任一项所述的方法，其特征在于：

所述判断所述支付金额与所述交易订单的实际金额是否一致的步骤在所述第一用户支付所述交易订单之后执行；和/或

所述判断所述支付金额与所述交易订单的实际金额是否一致的步骤在所述第二用户修改所述交易订单之后执行。

8.一种业务信息的处理装置，其特征在于，所述装置应用在业务服务器上，所述装置包括：

生成单元，用于为具有业务关联关系的第一用户和第二用户生成业务表单，所述业务表单中包括交易商品的目标业务属性，所述目标业务属性包括交易金额；

获取单元，用于获取所述第一用户在针对所述业务表单中的目标业务属性进行支付操作后得到的第一结果信息；

判断单元，用于判断所述第一结果信息与第二结果信息是否一致，其中，所述第二结果信息为所述第二用户针对所述目标业务属性进行修改操作后得到的结果信息，所述第二用户针对所述目标业务属性的修改操作在生成所述业务表单之后进行；

提醒单元，用于如果所述判断单元的判断结果为所述第一结果信息与所述第二结果信息不一致，则输出针对所述目标业务属性的操作提醒。

9.一种业务信息的处理装置，其特征在于，所述装置包括：

获取单元，用于获取第一用户已支付交易订单的支付金额；

判断单元，用于判断所述支付金额与所述交易订单的实际金额是否一致，其中，所述实际金额为与所述第一用户关联的第二用户对所述交易订单对应交易商品的金额进行修改得到，所述第二用户对所述交易商品的金额的修改操作在生成所述交易订单之后进行；

提醒单元，用于在所述判断单元判断所述支付金额与所述实际金额不一致时，输出处理所述交易订单的提醒。

10.根据权利要求9所述的装置，其特征在于，所述提醒单元包括：

第一提醒单元，用于在所述判断单元判断所述支付金额小于所述实际金额时，提醒所述第一用户补差额，所述差额为所述实际金额与所述支付金额的差值；和/或

第二提醒单元，用于在所述判断单元判断所述支付金额小于所述实际金额时，提醒所述第二用户修改所述实际金额与所述支付金额一致。

11.根据权利要求10所述的装置，其特征在于，还包括：确定单元和标记单元；和/或，接收单元，第一退还单元和关闭单元，其中，

所述确定单元，用于确定所述第一用户支付所述差额，或者所述第二用户修改所述实际金额与所述支付金额一致；

所述标记单元，用于基于所述确定单元的确定结果，标记所述交易订单完成；

所述接收单元，用于接收所述第一用户或第二用户发送的终止所述交易的请求；

所述第一退还单元，用于根据所述请求将所述支付金额退还给所述第一用户；

所述关闭单元，用于在所述第一退还单元将所述支付金额退还给所述第一用户时，关闭所述交易订单。

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

第二退还单元，用于在所述判断单元判断所述支付金额大于所述实际金额时，将差额退还给所述第一用户，其中，所述差额为所述支付金额与所述实际金额的差值。

13.根据权利要求9至12任一项所述的装置，其特征在于，所述提醒单元包括：

第三提醒单元，用于在所述判断单元判断所述支付金额与所述实际金额一致时，提醒所述第一用户和第二用户针对所述交易订单的交易成功。

14.根据权利要求9至12任一项所述的装置，其特征在于，所述判断单元，具体用于在所述第一用户支付所述交易订单之后判断所述支付金额与所述实际金额是否一致；和/或在所述第二用户修改所述交易订单之后判断所述支付金额与所述实际金额是否一致。

Images