一种业务处理方法、装置及系统与流程

本申请涉及互联网数据处理技术领域，尤其涉及一种业务处理方法、装置及系统。

背景技术：

为了提高第一用户对在线业务对象的购物体验，可以将第二用户的业务对象首先入驻到物流服务提供方提供的仓库，这里为确保给第二用户提供较好的物流服务体验，物流服务提供方的每个仓库都有自己的配送覆盖范围，然后第二用户将业务对象入库到物流服务提供方提供的仓库。在第一用户查看业务对象详情信息(detail)页面和购买(buy)页面中展示的业务对象时，电子商务系统根据第一用户所在的地址匹配物流服务提供方提供的仓库的覆盖区域范围，若匹配上，则会将仓库中的库存量展示给消费者；电子商务系统在确定第一用户付款下单后，会生成一个物流订单，按照物流订单对业务对象进行发货，而后第一用户的业务对象经过一系列的配送环节派送到第一用户所在地址。

上述针对用户下单的业务对象的业务处理方法适用于普通的销售方式，这种普通的销售方式是指业务对象已经存放在仓库中，第一用户随时购买随时发货，一次付完全款。然而，当前第二用户需求非常灵活的销售方式，例如：负卖预售下沉、负卖预售非下沉、非负卖预售下沉、非负卖预售非下沉等等，其中，负卖预售是指销售的业务对象提前预售了，但是预售完之后，业务对象还没有真实库存，需要等有库存才可以完成发货；非负卖预售是指预售期内货品已经存储在仓库里，只是销售方式是二阶段付款，分为定金阶段和尾款阶段；下沉指的是在定金阶段将业务对象存储到离消费者最近的网点中。上述每一种销售方式对于物流信息及相应的物流履行的要求是不同的，例如：对于负卖预售下沉的交易订单，就需要在定金阶段生成预发货单；而对于负卖预售非下沉 的交易订单就不需要在定金阶段生成预发货单。

目前，对上述销售方式的进行支持的业务处理方式中，将差异化的物流属性(也即物流信息及相应的物流履行的要求)分散在构成电子商务系统的各个处理节点上，每实现对一种新的销售方式的支持，均需要按照该销售方式要求的物流属性对各处理节点进行业务逻辑的重新开发，非常不利于系统维护以及扩展。

技术实现要素：

本申请实施例提供一种业务处理方法、装置及系统，用以解决现有的业务处理方式存在的不利于系统维护的问题。

基于上述问题，本申请实施例提供的一种业务处理方法，包括：

业务服务器接收支付服务器针对当前订单状态为待支付的交易订单发送的支付成功消息，所述交易订单中包括业务对象的标识和第一订单属性，所述第一订单属性包括构成线上销售方式的维度中的部分或全部维度；

根据所述第一订单属性，确定所述业务对象的发货模式信息；

针对所述交易订单，根据确定出的发货模式信息，通知执行系统执行相应的发货阶段的物流信息处理操作。

此外，本申请实施例还提供的一种业务处理装置，包括：

接收单元，用于接收支付服务器针对当前订单状态为待支付的交易订单发送的支付成功消息，所述交易订单中包括业务对象的标识和第一订单属性，所述第一订单属性包括构成线上销售方式的维度中的部分或全部维度；

确定单元，用于根据所述第一订单属性，确定所述业务对象的发货模式信息；

通知单元，用于针对所述交易订单，根据确定出的发货模式信息，通知执行系统执行相应的发货阶段的物流信息处理操作。

本申请实施例还提供的一种业务处理系统，包括：业务服务器、支付服务 器和执行系统；其中：

支付服务器，用于向业务服务器针对当前订单状态为待支付的交易订单发送支付成功消息；

业务服务器，用于接收支付服务器针对当前订单状态为待支付的交易订单发送的支付成功消息，所述交易订单中包括业务对象的标识和第一订单属性，所述第一订单属性包括构成线上销售方式的维度中的部分或全部维度；根据所述第一订单属性，确定所述业务对象的发货模式信息；针对所述交易订单，根据确定出的发货模式信息，通知执行系统执行相应的发货阶段的物流信息处理操作；

执行系统，用于在接收到业务服务器的执行相应的发货阶段的物流信息处理操作的通知后，执行相应的发货阶段的物流信息处理操作。

在本申请实施例的方案中，在交易订单中标示出了包括构成销售方式的维度的第一订单属性，对发货模式信息和发货阶段的物流信息处理操作进行了对应关系的创建，一种发货模式对应相应的发货阶段的物流信息处理操作，随后在用于实现针对各种销售方式的业务处理过程中，统一先根据第一订单属性对发货模式信息进行了确定，之后再依照确定的发货模式执行相应的发货阶段的物流信息处理操作，由于统一对各种发货模式进行确定，不同的发货模式，相应的发货阶段的物流信息处理操作是独立的，因此，有利于系统的维护；此外，后续在新增销售方式时，只需在第一订单属性中增加新的维度，重新建立发货模式信息和发货阶段的物流信息处理操作的对应关系即可，该种业务处理方法统一确定各种发货模式并进行相应的处理，实现了对新的销售方式的支持，有利于系统的扩展。

附图说明

图1为本申请实施例提供的业务处理系统的结构示意图之一；

图2为本申请实施例提供的业务处理方法的流程图之一；

图3为本申请实施例提供的业务处理方法的流程图之二；

图4为本申请实施例提供的业务处理方法的流程图之三；

图5为本申请实施例提供的业务处理方法的流程图之四；

图6为本申请实施例提供的业务处理方法的流程图之五；

图7为本申请实施例提供的业务处理系统的结构示意图之二；

图8为本申请实施例提供的业务处理方法涉及到的类图；

图9为本申请实施例提供的业务处理装置的结构示意图。

具体实施方式

为了解决现有的业务处理方式存在不利于系统维护的问题，本申请施例提供了一种业务处理方法，该方法中，根据交易订单，统一对发货模式进行确定，针对确定出的不同的发货模式，通知执行系统执行与该发货模式相对应的发货阶段的物流信息处理操作。由于业务服务器统一对发货模式进行了确定，并依据发货模式通知执行系统执行与确定出的发货模式相对应的发货阶段的物流信息处理操作，可以很方便地将各个发货模式下的物流处理操作隔离开来，因此，有利于系统的维护。

为了清楚地理解本申请实施例的方案，下面先对线上销售方式以及可以实施本申请实施例的业务处理系统进行说明。

线上销售方式：在网络上进行业务对象的销售使用的销售方式。通常可由多个维度的组合构成，多个维度可以包括：是否预售、是否下沉、是否负卖、是否分销等等。将多个维度进行组合，可得到以下销售方式：非负卖预售下沉分销、负卖预售非下沉非分销、负卖预售非下沉分销、负卖预售下沉分销等等。分销还可以细分为b2c(企业对客户)分销，b2b(企业对企业)分销；其中，负卖是指第二用户的销售行为已经进行，但由于货源库存等问题，货物并没有交付给第一用户，只是给与第一用户承诺，并在承兑时限内交货。分销是指一种商业关系，第一用户或第二用户在分销商那里购买商品之后，分销商需要从 供货商那里购买业务对象，支付成功后才给第一用户或第二用户发货，也就是说分销商没有业务对象。

如图1所示，其为本申请实施例的业务处理系统的结构示意图，包括：支付服务器11、业务服务器12和执行系统13；其中：

支付服务器11，用于向业务服务器针对当前订单状态为待支付的交易订单发送支付成功消息；

业务服务器12，用于接收支付服务器针对当前订单状态为待支付的交易订单发送的支付成功消息，所述交易订单中包括业务对象的标识和第一订单属性，所述第一订单属性包括构成线上销售方式的维度中的部分或全部维度；根据所述第一订单属性，确定所述业务对象的发货模式信息；针对所述交易订单，根据确定出的发货模式信息，通知执行系统执行相应的发货阶段的物流信息处理操作；

执行系统13，用于在接收到业务服务器的执行相应的发货阶段的物流信息处理操作的通知后，执行相应的发货阶段的物流信息处理操作。

以下结合说明书附图对本发明的优选实施例进行说明，应当理解，此处所描述的优选实施例仅用于说明和解释本发明，并不用于限定本发明。并且在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。

本申请实施例提供的一种业务处理方法，其流程图如图2所示，包括以下步骤：

步骤201：业务服务器接收支付服务器针对当前订单状态为待支付的交易订单发送的支付成功消息。

第一用户在电子商务平台进行下单，电子商务平台即生成交易订单，随后，第一用户对该交易订单进行支付操作，在支付成功时，支付服务器即向业务服务器发送支付成功消息。

所述交易订单中可包括业务对象的标识、第一订单属性和交易订单号；所述第一订单属性包括构成线上销售方式的维度中的部分或全部维度；

现有的构成线上销售方式的维度包括以下维度中的部分或全部：是否预售、是否负卖、是否下沉和是否分销。

在有新的销售方式出现时，可以对该销售方式进行维度的划分，找出与上述维度不同的维度，可将该新的维度作为交易订单的第一订单属性。

这里，业务服务器在接收到支付成功消息，即确认交易订单已成功支付，可以修改所述交易订单的当前订单状态为已支付，方便后续的业务处理。

步骤202：根据所述第一订单属性，确定所述业务对象的发货模式信息。

其中，一种发货模式对应各阶段的物流信息处理操作。这里的发货模式信息可以简单地理解为各阶段的物流信息处理操作的总标识。

这里，一种发货模式信息作为各个阶段的物流信息处理操作的总标识，业务服务器具体可以结合接收到的具体信息，结合该总标识，确定具体需要执行哪个阶段的物流信息处理操作。

具体可以利用事先设置的订单属性代码，将第一订单属性进行组合，得到业务对象的发货模式信息。

假设第一订单属性包括三个维度的信息：是否负卖(假设用1表示负卖；用2表示非负卖)、下沉(假设用1下沉；用2表示非下沉)、分销(假设用1表示分销b2b；用2表示非分销；用3表示分销b2c)。则由第一订单属性的不同，确定出的不同发货模式信息(这里为发货模式代码)可以如表一所示。

表一

考虑到一些订单属性并不能在创建交易订单的时候确定，因此，本申请实施例中将能在创建交易订单的时候确定的订单属性作为第一订单属性，不能在创建交易订单的时候确定的订单属性作为第二订单属性，此时，可由业务服务器基于交易订单中的信息和存储的与订单属性相关的信息进行第二订单属性的确定。

具体的，所述第一订单属性包括是否预售和/或是否分销；所述交易订单还具有第二订单属性，所述第二订单属性包括：是否负卖和/或是否下沉；

此时，本步骤202具体包括：根据所述第一订单属性和/或所述第二订单属性，确定所述业务对象的发货模式信息。

这里第一订单属性和第二订单属性可构成交易订单的全部订单属性，根据交易订单的全部订单属性，即可确定业务对象的发货模式信息。

具体的，所述交易订单中还包括：发货仓的标识；发货仓的标识可依据第一用户填写的收货地址来进行确定，将距离收货地址最近的仓库的标识作为发货仓的标识，可通过以下步骤11和步骤12确定交易订单的第二订单属性包括的是否下沉：

步骤11：判断所述业务对象的标识是否存在于预先存储的业务对象下沉列表；

可事先在支付服务器中存储业务对象下沉列表，该业务对象下沉列表中记录了需要下沉的业务对象的标识。

步骤12：若判断结果为存在，则确定所述交易订单的第二订单属性包括下 沉，反之，则包括非下沉。

可通过以下步骤21和步骤22确定交易订单的第二订单属性包括的是否负卖：

步骤21：从存储的仓库的标识与仓库类型之间的对应关系中，查询所述发货仓的标识对应的仓库类型，所述仓库类型包括实仓和虚仓；

其中，实仓表示仓库中存储有业务对象，虚仓表示仓库中没有存储业务对象。

步骤22：若查询到的仓库类型为虚仓，则确定所述业务对象的第二订单属性包括负卖，若查询到的仓库类型为实仓，则确定所述交易订单的第二订单属性包括非负卖。

步骤203：针对所述交易订单，根据确定出的发货模式信息通知执行系统执行相应的发货阶段的物流信息处理操作。

通过进行发货阶段的物流信息处理操作，配合人工的配送，推动业务对象的物流流转，可将业务对象送达第一用户下单时填写的收货地址。

这里，发货模式信息对应的发货阶段的物流信息处理操作是根据第一订单属性中的各个维度对物流履行的要求确定的。例如：针对是否下沉这一维度，在下沉时，要求执行系统生成预发货单。在预售下沉时，要求执行系统在定金阶段生成预发货单。针对是否负卖这一维度，在负卖时需要保持物流订单，直至确定业务对象入库到仓库中；针对是否分销这一维度，在分销时，需要生成两段物流订单，第一段物流订单发给分销商，之后，分销商到经销商处采购业务对象，采购之后，再生成第二段物流订单。

考虑到第一用户在业务服务器确定了业务对象的发货模式之后，可能会进行退款，为了方便确定第一用户的业务对象的发货模式信息，进行发货阶段的物流信息处理的拦截，在上述步骤202之后，就需要建立所述交易订单号和确定的所述发货模式信息之间的对应关系并存储。

针对第一用户需要退款时，本申请实施例的业务处理方法的流程如图3所 示，包括以下步骤：

步骤301：接收用户终端发送的针对当前订单状态为已支付的交易订单的退款请求，所述退款请求中携带有交易订单号；

步骤302：从存储的交易订单号和发货模式信息之间的对应关系中，查找所述退款请求中携带的交易订单号对应的发货模式信息；

步骤303：根据查找到的发货模式信息通知执行系统执行相应的退款阶段的物流信息处理操作。

这里退款阶段的物流信息处理操作可以看做是发货阶段的物流信息处理操作的逆操作，也即对发货阶段的物流信息处理操作的撤回。

上述方案对发货阶段的业务处理流程和退款阶段的业务处理流程进行了描述，下面通过第一订单属性中包括预售属性的交易订单对上述方案进行具体的描述。

通常对于预售的业务对象进行下单后，对产生的交易订单的支付可以是分成两段的，一段是定金支付，一段是尾款支付，此时的物流信息处理操作也可以分为两段，定金支付后可以进行定金发货阶段的物流信息处理操作，尾款支付后，可以进行尾款发货阶段的物流信息处理操作。相应的，由于是两次支付，因此，在退款时，也有两种情况，一种是用户在支付了定金之后(还未支付尾款)，需要进行退款，另一种情况是用户支付了尾款之后需要进行退款。此时，用户发出退款请求时，需要分情况进行退款阶段的物流信息处理操作，一种是定金退款阶段的物流信息处理操作，另一种是尾款退款阶段的物流信息处理操作。

如图4所示，其为本申请实施例提供的业务处理方法的流程图之三，包括以下步骤：

步骤401：支付服务器接收支付服务器针对当前订单状态为待支付定金的交易订单发送的支付成功消息；

针对预售的需要进行分两个阶段付款的业务对象，第一用户在电子商务平 台进行下单，电子商务平台即生成交易订单，随后，第一用户对该交易订单进行定金支付操作，在支付成功时，支付服务器针对当前订单状态为待支付定金的交易订单向业务服务器发送支付成功消息。

本步骤401中所述的交易订单的第一订单属性包括：预售和是否分销。

这里第一订单属性即为包括预售和分销，或者包括预售和非分销。

步骤402：支付服务器根据所述预售和是否分销，确定所述业务对象的发货模式信息。

步骤403：针对所述交易订单，根据确定出的发货模式信息通知执行系统执行相应的定金发货阶段的物流信息处理操作。

在第一用户在支付定金后，可能会进行尾款的支付操作，此时，需要完成尾款发货阶段的物流信息处理操作，也可能不进行尾款的支付，而是发出了退款请求，需要进行定金退款阶段的物流信息处理操作，为了方便后续尾款发货阶段或者定金退款阶段的处理，此时，在步骤401后，需要修改所述交易订单的当前订单状态为待支付尾款，在步骤402之后，需要建立所述交易订单号和确定的所述发货模式信息之间的对应关系并存储，以便于后续进行查找，确定当前订单状态为待支付尾款的交易订单的发货模式信息。

若第一用户在支付定金后，进行了尾款的支付，此时的业务处理方法可以包括以下步骤404至步骤406：

步骤404：接收支付服务器针对当前订单状态为待支付尾款的交易订单发送的支付成功消息；

针对预售的需要进行分两个阶段付款的业务对象，第一用户在对交易订单进行了定金支付后，随后进行尾款的支付，在尾款支付成功时，支付服务器针对当前订单状态为待支付尾款的交易订单向业务服务器发送支付成功消息。

步骤405：从存储的交易订单号和发货模式信息之间的对应关系中，查找确定的成功支付尾款的交易订单的交易订单号对应的发货模式信息；

步骤406：根据查找到的发货模式信息通知执行系统执行相应的尾款发货 阶段的物流信息处理操作。

若第一用户在支付定金但未支付尾款发起退款请求，此时的业务处理方法的流程图可以如图5所示，包括以下步骤：

步骤501：接收用户终端发送的针对当前订单状态为待支付尾款状态的交易订单的退款请求，所述退款请求中携带有交易订单号；

步骤502：从存储的交易订单号和发货模式信息之间的对应关系中，查找所述退款请求中携带的交易订单号对应的发货模式信息；

步骤503：根据查找到的发货模式信息通知执行系统执行相应的定金退款阶段的物流信息处理操作。

考虑到第一用户户完成了尾款支付后，也有可能发起退款请求，为了方便第一用户获知当前交易订单的状态，需要在上述步骤404之后，支付服务器修改所述交易订单的当前订单状态为待发货，后续针对当前订单状态或历史订单状态为待发货进行退款请求的发送。由于用户可能是在当前订单状态为待发货后发起的退款请求，也可能是在签收到业务对象之后发起了退款请求，还可以是在当前订单状态为待发货后至签收到这中间发起了退款请求，因此，这里描述为针对针对当前订单状态或历史订单状态为待发货进行退款请求的发送。

若第一用户在支付尾款后发起了退款请求，此时的业务处理方法的流程图可以如图6所示，包括以下步骤：

步骤601：接收用户终端发送的针对当前订单状态或历史订单状态为待发货的交易订单的退款请求，所述退款请求中携带有交易订单号；

步骤602：从存储的交易订单号和发货模式信息之间的对应关系中，查找所述退款请求中携带的交易订单号对应的发货模式信息；

步骤603：根据查找到的发货模式信息通知执行系统执行相应的全款退款阶段的物流信息处理操作。

由于执行系统执行无论是上述发货阶段的物流信息处理操作(在分定金和尾款进行支付时，可细分为定金发货阶段的物流信息处理操作和尾款发货阶段 的物流信息处理操作)、退款阶段的物流信息处理操作(在分定金和尾款进行支付时，可细分为定金退款阶段的物流信息处理操作和尾款退款阶段的物流信息处理操作)均是根据发货模式来执行的，发货模式对应的不同阶段的物流信息处理操作可依据第一订单属性以及第二订单属性中的各个维度对物流履行的要求确定，可以依据实际需要进行灵活的物流信息处理操作，其并不是本申请的发明点，因此，这里不进行详细的描述，仅以如图7所示的负卖预售下沉费分销这一销售方式下的发货模式对应的定金发货阶段的物流信息处理操作进行示意。图7中包括交易中心服务器(tc)、垂直行业解决方案服务器(vsp)、物流中心服务器(lc)、仓储中心服务器(cc)和结算中心。

可见，图7中将本申请的业务服务器的功能作为vsp的一部分功能，图7中的tc具有本申请的支付服务器的功能，vsp、lc、cc和结算中心具有本申请的执行系统的功能。

如图8所示，其为本申请实施例提供的业务处理方法在具体的程序代码实现的类图。具体解释如下：

首先，可根据表一中的发货模式代码，调用processfactory类里的factory方法；

其次，调用factory方法后获得一个策略类(也即各个阶段的物流信息处理操作)的实例，比如betraynosinkmodestrategy；

最后，执行获得到的策略类的示例，例如：执行betraynosinkmodestrategy实例。

图8中，在各个不同的阶段：定金阶段、尾款阶段、退款阶段、自动路由、自动发货这五个阶段都会调用不同的方法。由于所有的策略类都会实现iprocessstrategy，从而能够动态绑定到不同的执行路径中。

上述实现过程采用的是简单工厂+策略模式的设计思路，简单方便地将各个业务流程隔离开来，并且具备很好的可扩展性。

基于同一发明构思，本申请实施例还提供了一种业务对象处理装置，由于 该业务对象处理装置所解决问题的原理与前述业务对象处理方法相似，因此该终端的实施可以参见前述方法的实施，重复之处不再赘述。

如图9所示，本发明实施例提供的一种业务处理装置，包括：接收单元91、确定单元92和通知单元93，其中：

接收单元91，用于接收支付服务器针对当前订单状态为待支付的交易订单发送的支付成功消息，所述交易订单中包括业务对象的标识和第一订单属性，所述第一订单属性包括构成线上销售方式的维度中的部分或全部维度；

确定单元92，用于根据所述第一订单属性，确定所述业务对象的发货模式信息；

通知单元93，用于针对所述交易订单，根据确定出的发货模式信息，通知执行系统执行相应的发货阶段的物流信息处理操作。

较佳的，构成线上销售方式的维度包括：是否预售、是否负卖、是否下沉和是否分销。

较佳的，所述第一订单属性包括是否预售和/或是否分销；所述交易订单还具有第二订单属性，所述第二订单属性包括：是否负卖和/或是否下沉；

所述确定单元92，具体用于根据所述第一订单属性和/或所述第二订单属性，确定所述业务对象的发货模式信息。

较佳的，所述交易订单中还包括：发货仓的标识；

所述确定单元92，还用于通过以下方式确定交易订单的第二订单属性包括的是否下沉：判断所述业务对象的标识是否存在于预先存储的业务对象下沉列表；若判断结果为存在，则确定所述交易订单的第二订单属性包括下沉，反之，则包括非下沉；通过以下方式确定交易订单的第二订单属性包括的是否负卖：从存储的仓库的标识与仓库类型之间的对应关系中，查询所述发货仓的标识对应的仓库类型，所述仓库类型包括实仓和虚仓；若查询到的仓库类型为虚仓，则确定所述业务对象的第二订单属性包括负卖，若查询到的仓库类型为实仓，则确定所述交易订单的第二订单属性包括非负卖。

较佳的，发货模式信息对应的发货阶段的物流信息处理操作是根据第一订单属性中的各个维度对物流履行的要求确定的。

较佳的，所述交易订单中还包含交易订单号；所述装置还包括：

修改单元94，用于在接收单元接收支付服务器针对当前订单状态为待支付的交易订单发送的支付成功消息之后，修改所述交易订单的当前订单状态为已支付；

建立单元95，用于在确定单元根据所述第一订单属性，确定所述业务对象的发货模式信息之后，建立所述交易订单号和确定的所述发货模式信息之间的对应关系并存储；

所述接收单元91，还用于接收用户终端发送的针对当前订单状态为已支付的交易订单的退款请求，所述退款请求中携带有交易订单号；

查找单元96，用于从存储的交易订单号和发货模式信息之间的对应关系中，查找所述退款请求中携带的交易订单号对应的发货模式信息；

所述通知单元93，还用于根据查找到的发货模式信息通知执行系统执行相应的退款阶段的物流信息处理操作。

较佳的，所述第一订单属性包括：预售和是否分销，所述交易订单中还包含交易订单号；

所述接收单元91，具体用于接收支付服务器针对当前订单状态为待支付定金的交易订单发送的支付成功消息；

所述通知单元93，具体用于针对所述交易订单，根据确定出的发货模式信息，通知执行系统执行相应的定金发货阶段的物流信息处理操作。

较佳的，所述装置还包括：

修改单元94，用于在接收单元接收支付服务器针对当前订单状态为待支付定金的交易订单发送的支付成功消息之后，修改所述交易订单的当前订单状态为待支付尾款；

建立单元95，用于在确定单元根据所述第一订单属性，确定所述业务对象 的发货模式信息之后，建立所述交易订单号和确定的所述发货模式信息之间的对应关系并存储；

所述接收单元91，具体用于接收支付服务器针对当前订单状态为待支付尾款的交易订单发送的支付成功消息；

查找单元96，用于从存储的交易订单号和发货模式信息之间的对应关系中，查找确定的成功支付尾款的交易订单的交易订单号对应的发货模式信息；

通知单元93，具体用于根据查找到的发货模式信息，通知执行系统执行相应的尾款发货阶段的物流信息处理操作。

较佳的，所述修改单元94，还用于在接收单元接收支付服务器针对当前订单状态为待支付尾款的交易订单发送的支付成功消息之后，修改所述交易订单的当前订单状态为待发货；

所述接收单元91，还用于接收用户终端发送的针对当前订单状态或历史订单状态为待发货的交易订单的退款请求，所述退款请求中携带有交易订单号；

所述查找单元96，还用于从存储的交易订单号和发货模式信息之间的对应关系中，查找所述退款请求中携带的交易订单号对应的发货模式信息；

所述通知单元93，还用于根据查找到的发货模式信息，通知执行系统执行相应的全款退款阶段的物流信息处理操作。

较佳的，所述装置还包括：

修改单元94，用于在接收单元接收支付服务器针对当前订单状态为待支付定金的交易订单发送的支付成功消息之后，修改所述交易订单的当前订单状态为待支付尾款；

建立单元95，用于在确定单元根据所述第一订单属性，确定所述业务对象的发货模式信息之后，建立所述交易订单号和确定的所述发货模式信息之间的对应关系并存储；

所述接收单元91，还用于接收用户终端发送的针对当前订单状态为待支付尾款状态的交易订单的退款请求，所述退款请求中携带有交易订单号；

查找单元96，用于从存储的交易订单号和发货模式信息之间的对应关系中，查找所述退款请求中携带的交易订单号对应的发货模式信息；

所述通知单元93，还用于根据查找到的发货模式信息通知执行系统执行相应的定金退款阶段的物流信息处理操作。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到本发明实施例可以通过硬件实现，也可以借助软件加必要的通用硬件平台的方式实现。基于这样的理解，本发明实施例的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是cd-rom，u盘，移动硬盘等)中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述的方法。

本领域技术人员可以理解附图只是一个优选实施例的示意图，附图中的模块或流程并不一定是实施本发明所必须的。

本领域技术人员可以理解实施例中终端中的模块可以按照实施例描述进行分布于实施例的终端中，也可以进行相应变化位于不同于本实施例的一个或多个终端中。上述实施例的模块可以合并为一个模块，也可以进一步拆分成多个子模块。

上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。

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