CN113298604A

CN113298604A - 商品对象结算处理方法、装置及电子设备

Info

Publication number: CN113298604A
Application number: CN202011410815.9A
Authority: CN
Inventors: 徐玲; 赵双婵
Original assignee: Alibaba Group Holding Ltd
Current assignee: Alibaba Singapore Holdings Pte Ltd
Priority date: 2020-12-04
Filing date: 2020-12-04
Publication date: 2021-08-24
Also published as: WO2022116954A1

Abstract

本申请实施例公开了商品对象结算处理方法、装置及电子设备，所述方法包括：确定待结算的多个商品对象，其中至少两个商品对象的价格属性信息关联不同的第一货币种类；确定执行支付操作时所需使用的第二货币种类；根据所述多个商品对象创建至少两个交易订单，并确定所述至少两个交易订单分别对应的结算结果信息，所述结算结果信息通过所述第二货币种类进行描述；提供合并支付操作选项，以用于对所述至少两个交易订单进行合并支付。通过本申请实施例，针对多币种报价、多币种支付的场景，能够简化用户操作。

Description

商品对象结算处理方法、装置及电子设备

技术领域

本申请涉及信息处理技术领域，特别是涉及商品对象结算处理方法、装置及电子设备。

背景技术

在通过商品对象信息服务系统进行线上的商品对象浏览以及交易的过程中，买家用户经常会将多个商品对象加入“购物车”，然后统一进行结算并下单处理。“购物车”的存在，使得多个商品对象可以合并下单，降低买家用户的操作成本。

但是，在跨境商品对象信息服务系统中，卖家用户和买家用户都有可能来自多个不同的国家，这样，“购物车”中的多个不同商品对象也可能对应于来自不同国家的卖家用户。而卖家用户在发布商品对象并进行报价时，通常是使用自己所在国家的币种进行报价，这就使得不同国家的卖家用户发布的商品对象通常会对应不同的报价币种。而买家用户在下单并支付时，也通常是使用自己所在国家的发定币种进行支付。因此，这就存在多币种报价、多币种支付的问题。

现有技术中，在需要对多个不同的商品对象进行结算，并且不同的商品对象对应不同的报价币种时，通常需要为不同的报价币种生成不同的订单，并且需要用户分别对不同的订单进行支付。例如，某用户将四件商品对象加入“购物车”，这四件商品对象对应两个卖家用户，这两个卖家用户来自不同的国家，使用不同的报价币种进行的报价，例如，一个是用美元报价，另一个是用欧元报价，等等。此时，系统需要拆分成两个订单，相应的，买家用户需要执行两次支付操作，才能够完成对两个订单的下单处理。这就使得“购物车”的作用难以有效的发挥出来。

因此，针对多币种报价、多币种支付的场景，如何简化用户操作，成为需要本领域技术人员解决的技术问题。

发明内容

本申请提供了商品对象结算处理方法、装置及电子设备，针对多币种报价、多币种支付的场景，能够简化用户操作。

本申请提供了如下方案：

一种商品对象结算处理方法，包括：

确定待结算的多个商品对象，其中至少两个商品对象的价格属性信息关联不同的第一货币种类；

确定执行支付操作时所需使用的第二货币种类；

根据所述多个商品对象创建至少两个交易订单，并确定所述至少两个交易订单分别对应的结算结果信息，所述结算结果信息通过所述第二货币种类进行描述；

提供合并支付操作选项，以用于对所述至少两个交易订单进行合并支付。

一种订单信息处理方法，包括：

接收服务端提供的交易订单信息，所述交易订单时根据第二用户对多个商品对象执行结算操作后生成的，其中至少两个商品对象的价格属性信息关联不同的第一货币种类；所述交易订单信息包括所述交易订单的应收金额信息以及在用户权益下的优惠额信息，所述应收金额信息以及所述优惠额信息通过对应的第一货币种类进行描述；

对所述交易订单信息进行展示。

一种商品对象结算处理装置，包括：

商品对象确定单元，用于确定待结算的多个商品对象，其中至少两个商品对象的价格属性信息关联不同的第一货币种类；

货币种类确定单元，用于确定执行支付操作时所需使用的第二货币种类；

订单创建单元，用于根据所述多个商品对象创建至少两个交易订单，并确定所述至少两个交易订单分别对应的结算结果信息，所述结算结果信息通过所述第二货币种类进行描述；

合并支付单元，用于提供合并支付操作选项，以用于对所述至少两个交易订单进行合并支付。

一种订单信息处理装置，包括：

订单信息接收单元，用于接收服务端提供的交易订单信息，所述交易订单时根据第二用户对多个商品对象执行结算操作后生成的，其中至少两个商品对象的价格属性信息关联不同的第一货币种类；所述交易订单信息包括所述交易订单的应收金额信息以及在用户权益下的优惠额信息，所述应收金额信息以及所述优惠额信息通过对应的第一货币种类进行描述；

订单展示单元，用于对所述交易订单信息进行展示。

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

通过本申请实施例，针对待结算的多个商品对象，如果其中至少两个商品对象的价格属性信息关联不同的第一货币种类，则可以根据所述多个商品对象创建至少两个交易订单，并确定所述至少两个交易订单分别对应的结算结果信息，所述结算结果信息通过所述第二货币种类进行描述。之后，可以提供用于对所述多个交易订单进行合并支付的操作选项，这样，使得用户可以对至少两个交易订单进行合并支付。这样，即使至少两个交易订单关联的商品对象对应不同的第一货币种类，第二用户也只需要执行一次支付操作，即可实现对至少两个交易订单的合并支付，因此，可以简化用户操作，提升用户体验。

其中，在具体确定交易订单的结算结果信息时，可以以商品对象为单位分别进行应付金额信息的计算，这样，也可以便于在后续的逆向售后链路中进行退款等事宜的处理。

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

附图说明

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

图1是本申请实施例提供的系统架构的示意图；

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

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

图4是本申请实施例提供的第一装置的示意图；

图5是本申请实施例提供的第二装置的示意图；

图6是本申请实施例提供的电子设备的示意图。

具体实施方式

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

在本申请实施例中，针对多币种报价、多币种支付的场景，如果用户将多个不同的商品对象加入“购物车”，并选择对这些商品对象进行结算，但是这些商品对象对应着不同的报价币种，此时，在本申请实施例中，可以在服务端进行具体的订单拆分、金额计算等处理，但是，在前端的客户端，可以提供用于对这些订单进行合并支付的操作选项。这样，使得用户可以通过该操作选项实现合并支付，也即，即使其选择结算的多个商品对象对应多个不同的报价币种，并需要生成多个不同的交易订单，也只需要支付一次即可，而不需要用户感知后台的订单拆分等处理。通过这种方式，可以简化用户的操作，便于促进交易的达成。

其中，在具体提供合并支付功能的过程中，还可以考虑到对后续可能发生的逆向售后链路的支持。其中，在逆向售后链路中，通常是允许用户以商品对象为单位发起退款、退货、换货等售后链路的，因此，在对用户选中的多个商品对象进行结算时，通常需要以商品对象为单位进行结算，分别确定出每个商品对象对应的金额等信息，以便在后续的逆向售后链路中确定需要给用户进行退款的金额，等等。尤其是在涉及到命中用户权益(例如，红包、优惠券等)的情况，如果多个商品对象命中同一用户权益，则还需要计算多个商品对象对用户权益的分摊金额，进而确定出每个商品对象的实际应付金额信息。因此，在本申请实施例中，具体在对包含多个报价币种的多个商品对象进行结算时，可以以商品对象为单位，进行汇率转换以及用户权益信息计算，得到通过具体支付货币进行描述的应付金额信息。之后，通过对多个商品对象的应付金额进行相加，可以得到总的应付金额，然后提供用于进行合并支付的操作选项，用户通过该操作选项即可完成具体的合并支付操作。也就是说，对于包含有多个不同报价币种的多个待结算商品对象而言，也不再需要用户分别针对不同的报价币种执行多次支付操作，而是仅支付一次即可，因此，可以简化用户的操作。

从系统架构角度而言，参见图1，本申请实施例主要涉及商品对象的客户端以及服务端，其中，客户端主要可以包括面向卖家用户/商家用户(在本申请实施例中可以称为第一用户)的第一客户端，以及面向买家用户/消费者用户(在本申请实施例中可以称为第二用户)的第二客户端。其中，具体服务端中的商品对象可以是由第一用户发布的，第一用户可以来自于多个不同国家，因此，对应的报价币种(在本申请实施例中可以称为第一货币种类)也会有多种。第二用户可以通过第二客户端对具体的页面进行访问，对于感兴趣的商品对象，可以添加到“购物车”等待结算集合中，之后，可以从该集合中选择多个商品对象，发起具体的结算请求。如果用户选择的多个商品对象涉及到多个不同的第一货币种类，则服务端可以按照本申请实施例提供的方案，进行具体货币种类的汇率转换，用户权益的计算(包括分摊、反算等)，订单的生成等一系列的后台处理，确定出多个商品对象的对应的总的应付金额信息。之后，第二客户端可以对结算结果信息页面进行展示，并在其中提供所述总的应付金额信息，以及用于进行合并支付的操作选项，第二用户可以通过该操作选项执行对多个交易订单的合并支付操作。这样，可以通过一次的支付操作，完成对对应多种不同第一用户对应的多个不同交易订单的支付，虽然后台服务端可能仍然需要生成多个订单，并分别计算各自的应付金额、用户权益分摊金额等信息，但是，用户可以不必感知具体的分单过程。

下面对本申请实施例通过的具体技术方案进行详细介绍。

实施例一

首先，该实施例一从服务端的角度，提供了一种商品对象结算处理方法，参见图2，该方法具体可以包括：

S201：确定待结算的多个商品对象，其中至少两个商品对象的价格属性信息关联不同的第一货币种类。

具体的，待结算的多个商品对象可以是由第二用户通过其第二客户端进行确定的。例如，具体实现时，用户可以通过第二客户端对各种信息页面进行浏览，浏览的过程中，可以将感兴趣的、可能需要购买的商品对象添加到“购物车”等待结算集合中。在完成浏览之后，可以进入到“购物车”页面中，对需要结算的商品对象进行选择，此时，所选择的商品对象就可能是多个。完成选择之后，可以通过“购物车”页面中的“去结算”等操作选项，发起结算请求。之后，第二客户端便可以将具体的的结算请求提交到服务端，并在结算请求中携带具体被用户选中的多个商品对象的信息。

当然，在另一种情况下，也可能是第二用户针对之前已经生成但尚未支付的多个交易订单，发起合并支付请求时，由于多个交易订单中可能关联多个商品对象，且对应不同的第一货币种类，因此，而不同货币种类之间的汇率等信息可能是在实时变化的，因此，在合并支付时，也可以使用本申请实施例中的方案，将多个交易订单中关联的多个商品对象确定为待结算的商品对象，然后按照后续的步骤进行总应付金额的计算。

其中，具体的商品对象可以是卖家或者商家等第一用户发布的，相应的，价格属性也通常是由第一用户在发布商品对象时进行设定的价格属性。例如，某第一用户发布了某商品对象，并指定其价格为100美元，则该商品对象的原始价格属性的属性值就是100美元，等等。其中，在本申请实施例中，由于是对应跨境场景，卖家或者商家等第一用户可能来自多个国家，因此，具体发布的商品对象时，对商品对象的价格属性信息通常是用各自国家的货币种类(币种)来进行描述(也即，通过具体各自国家的币种对商品对象进行报价)。例如，美国的第一用户发布的商品对象，其价格属性信息以美元为单位进行描述，欧洲的第一用户发布的商品对象，其价格属性信息以欧元为单位进行描述，等等。

S202：确定执行支付操作时所需使用的第二货币种类；

在本申请实施例中，将商品对象关联的国家的币种称为第一货币种类，相应的，将第二用户用于支付的币种称为第二货币种类。可以理解的是，这里所述的第一货币种类并不是指具体某个货币种类，而是对第一用户发布的商品对象对应的报价币种的统称，对于不同国家的第一用户所发布的商品对象，具体用于描述价格属性信息的第一货币种类会有所不同，例如，包括美元，欧元，等等。第二货币种类也是类似，是对第二用户在支付时所采用的币种的统称，对于不同国家的第二用户，支付时采用的币种会不同，因此，也会对应不同的第二货币种类，例如，中国的第二用户在支付时通常以人民币为单位，美国的第二用户在支付时通常以美元为单位，等等。

其中，具体在确定第二用户关联的执行支付操作时所使用的第二货币种类时，可以有多种方式。例如，一种方式下，可以根据第二用户所关联的第二客户端所面向的国家等信息来确定。也就是说，在具体实现时，可以为不同国家的第二用户开发不同的第二客户端，这样，对于关联了具体国家对应的第二客户端的第二用户，可以默认其需要使用该国家对应的第二货币种类进行支付。例如，如果某第二用户安装了中国版的第二客户端，则可以默认该第二用户需要使用人民币为单位进行支付，等等。或者，另一种方式下，如果多个不同国家的用户关联相同的第二客户端，并且该第二客户端支持多种不同的国家及语言的选择，在用户选择某个具体的国家及语言之后，可以默认该用户使用该国家对应的币种作为支付币种。再或者，还可以根据用户预先配置的信息进行确定。例如，某用户虽然位于美国，但是希望使用人民币进行支付，则也可以预先进行配置，此时，可以优先根据用户的配置信息，确定具体第二用户对应的第二货币种类。

S203：根据所述多个商品对象创建至少两个交易订单，并确定所述至少两个交易订单分别对应的结算结果信息，所述结算结果信息通过所述第二货币种类进行描述。

由于待结算的多个商品对象对应了多个不同的第一用户，因此，接收到具体的结算请求后，可以以第一用户为单位，创建多个不同的交易订单。同时，还可以确定出具体交易订单对应的结算结果信息。在本申请实施例中，具体交易订单的结算结果可以通过第二货币种类进行描述。例如，多个商品对象对应了美国、欧洲、日本的多个第一用户，分别通过美元、欧元、日元等对原始价格属性进行描述，但是，第二用户是中国用户，需要采用人民币进行支付，因此，具体的交易订单的结算结果可以以人民币为单位进行描述，以便于执行支付操作，等等。

其中，具体在确定交易订单的结算结果时，由于通常需要考虑到逆向链路中的需求，而逆向链路中通常是以商品对象为单位进行操作，例如，某交易订单关联了两个商品对象，但是，在第二用户进行退款或者退货时，可以指定对其中一个商品对象进行退款或退货处理，等等。在这种情况下，通常需要在下单时，就以商品对象为单位确定出具体的结算金额信息，以便于在逆向链路中确定需要向第二用户退款的金额等信息。因此，在本申请实施例中，具体在确定各个交易订单的结算结果信息时，也可以首先以商品对象为单位，分别确定出商品对象的结算结果，然后再确定具体订单的结算结果。

其中，在确定具体的商品对象的结算结果时，一方面可以对所述价格属性信息进行从第一货币种类向第二货币种类的汇率转换，另一方面，在涉及到用户权益信息的情况下，还可以进行用户权益信息的计算，以确定所述多个商品对象分别对应的通过第二货币种类描述的应付金额信息。

具体的，在本申请实施例中，可以首先以商品对象为单位，分别对所述价格属性信息进行从第一货币种类向第二货币种类的汇率转换以及用户权益信息计算，以确定所述多个商品对象分别对应的通过第二货币种类描述的应付金额信息，然后再进行具体交易订单的结算结果的计算。

其中，具体在进行汇率转换以及用户权益信息(具体可以是由系统或者第一用户为第二用户提供的各种优惠策略的统称，例如，具体可以包括优惠券、“红包”、“满减”等多种不同形式)计算时，根据具体用户权益类型的不同，可以有多种不同的处理方式。具体的，用户权益通常可以分为第一用户为第二用户提供的第一用户权益，以及系统或者平台层面为第二用户提供的第二用户权益。对于前者，通常是以第一货币种类进行描述，后者则以第二货币种类进行描述。例如，某第一用户针对其发布的全部或者部分商品对象提供了“2件8折，3件7折”的第一用户权益，这种第一用户权益只能在该第一用户关联的具体店铺对象内部使用。另外，平台还为第二用户提供了“满200减40”的第二用户权益，这类用户权益通常是可以跨店铺使用的，在本申请实施例的跨境场景中，还可以在不同国家的店铺之间使用。也就是说，假设某用户购买了某商品对象A以及商品对象B，该商品对象A是美国用户发布的，商品对象B是欧洲用户发布的，只要这两个商品对象的总金额达到200元人民币，就可以享受减40元现金的优惠，等等。另外，在具体实现时，上述第一用户权益与第二用户权益可能是可以叠加使用的，例如，可以在通过第一用户提供的第一用户权益享受完打折优惠之后，再通过平台提供的第二用户权益享受满200减40的优惠，并且，在使用这种第二用户权益时，还可以进行跨店铺甚至跨国家的“凑单”。

可见，在涉及到具体的用户权益信息时，尤其是在存在多种不同类型的用户权益，以及各种不同的使用规则的情况下，具体商品对象的应付金额信息的计算是比较复杂的。为此，本申请实施例还提供了相应的处理方案。

具体的，首先，如果所述商品对象命中由关联的第一用户提供的第一用户权益，则可以首先根据商品对象的原始价格属性信息以及所述第一用户权益对应的优惠方式信息，确定通过所述第一货币种类描述的优惠后的价格属性信息，再根据优惠后的价格属性信息进行从第一货币种类向第二货币种类的汇率转换。例如，某商品对象对应的第一用户提供了“2件8折，3件7折”的第一用户权益，并且当前第二用户(例如，是中国的用户)恰好选择了该第一用户(例如，是美国的用户)关联的两件商品对象，则这两个商品对象可以享受“8折”优惠。此时，可以首先对这两个商品对象的原始价格属性信息(通过美元进行描述)进行8折计算，得到优惠后的价格属性信息。之后，再将优惠后的价格属性信息从美元转换为人民币，等等。

另外，如果存在命中同一第二用户权益的多个不同商品对象，则可以首先在将价格属性信息(可以是原始价格属性，也可以是通过第一用户权益进行优惠后的价格属性)从第一货币种类汇率转换到第二货币种类后，再基于汇率转换后的价格属性信息，以及所述第二用户权益的优惠方式信息，确定所述多个不同商品对象分别对应的第一分摊金额，所述第一分摊金额通过所述第二货币种类进行描述。然后，根据所述汇率转换后的价格属性信息以及对应的第一分摊金额，确定所述多个商品对象分别对应的通过第二货币种类描述的应付金额信息。

也就是说，由于多个商品对象命中了同一第二用户权益，则需要在这些商品对象之间对该用户权益进行分摊。例如，4件商品对象命中了“满200减40”的用户权益，则需要将优惠的“40元”分摊到这四件商品对象上，每件商品对象优惠一定的金额。其中，具体的分摊方式可以按照预先制定的规则进行，例如，按照商品对象的价格属性比例进行分摊，等等。

这里需要说明的是，这种第二用户权益属于平台层面的提供的优惠，因此，通常可以进行跨店铺甚至跨境的“凑单”，第二用户可以从多个店铺选择多件商品对象进行“凑单”，以满足优惠条件，从而获得相应的用户权益。但是，如果使用现有技术中的方案，由于需要按照报价币种的不同拆分成多个订单并分别支付，因此，就使得这种“凑单”操作也受到限制。例如，用户实际选择了4件商品对象，这4件商品对象的总价格属性值加在一起能够满足某项第二用户权益的条件。但是，由于这4件商品对象分属于两个不同的第一用户，对应不同的第一货币种类，因此，现有技术中需要拆分成两个订单，由第一用户分别进行支付，而这两个拆分后的订单的总价格属性可能都无法满足第二用户权益的条件，以至于该第二用户难以享受到该第二用户权益带来的优惠。而在本申请实施例中，虽然不同的第一货币种类也可以拆分成不同的订单，但是，由于可以进行合并支付，因此，可以将不同第一货币种类的多个不同商品对象合并到一起进行对第二用户权益条件的判断，这样可以更好的帮助用户完成“凑单”，提升用户体验。

由于具体的第二用户权益信息通常是通过第二用户关联的第二货币种类进行描述的，因此，可以是在将商品对象的价格属性转换到第二货币种类之后，再进行第二用户权益的分摊。其中，商品对象的价格属性可以包括原始价格属性，也可以包括通过第一用户权益进行优惠后的价格属性，对于后者，相当于是将第一用户权益与第二用户权益进行了叠加。具体实现时，可以根据实际需求而定。

在将商品对象的价格属性信息转换为第二货币种类，并确定出第二用户权益的分摊金额之后，可以计算出商品对象的应付金额信息。例如，某商品对象既命中了第一用户权益，又命中了第二用户权益，则商品对象的应付金额＝(商品对象的原始价格属性信息-第一用户权益信息)*汇率-第二用户权益信息分摊金额。其中，这里的汇率就可以是指具体商品对象对应的第一货币种类与第二用户对应的第二货币种类之间的汇率。例如，某商品对象的原始价格属性值是40美元，其命中的第一用户权益是8折优惠，则优惠后的价格属性值为40*0.8＝32USD(美元)。同时，该商品对象还命中了“满200减40CNY(人民币)”的第二用户权益，与其他商品对象进行分摊后，该商品对象获得的分摊金额是8CNY。另外假设美元兑换人民币的当前汇率为6.6837，则该商品对象的应付金额为32*6.6837-8＝205.8784CNY。

通过这种方式可以以商品对象为单位，分别确定出各商品对象的应付金额信息，这样，后续如果发生退款或者退货等售后需求，由于可以以商品对象为单位发起售后，因此，如果用户针对某商品对象发起了退款货退货等，则可以利用该应付金额信息，确定出所需退还的金额。

另外，在具体实现时，由于在后续第二用户完成支付后，平台方需要向具体的第一用户进行结算，此时，需要使用第一用户对应的第一货币种类进行结算。因此，确定出商品对象的权益分摊金额(为便于描述，将其称为第一分摊金额)之后，还可以分别将所述第一分摊金额进行从第二货币种类到各自对应的第一货币种类的反算，确定以所述第一货币种类进行描述的第二分摊金额。然后，可以根据所述商品对象的原始价格属性信息以及所述第二分摊金额，确定所述交易订单对应的通过第一货币种类描述的应收金额信息，以用于提供给所述交易订单对应的第一用户。例如，在前述例子中，某商品对象获得的第一分摊金额是8CNY，则反算之后，以美元为单位表达的第二分摊金额为8/6.6837＝1.1969USD。这样，后续第二用户完成支付后，具体由平台方向该商品对象对应的第一用户进行结算时，针对该商品对象需要支付给第一用户的金额为40*0.8-1.1969＝30.8031USD。

当然，具体实现时，第二用户可能会选购了同一第一用户的多件商品对象，因此，具体实现时，在所述第二用户完成支付后，可以将所支付的金额保存到公共账户，并将所述多个交易订单分别置为已支付状态。也即，一个第一用户可以对应一个交易订单，如果第二用户选择了同一第一用户发布的多个商品对象，则该第一用户对应的交易订单中关联多个商品对象。进而，可以根据商品对象的价格属性信息以及所述第二分摊金额，确定具体的交易订单对应的应收金额信息，以便在从公共账户向所述第一用户进行结算时，根据所述交易订单对应的应收金额信息向对应的第一用户进行结算，其中，所述应收金额通过所述第一货币种类进行描述。

当然，具体实现时，具体的商品对象还可能会关联有运费属性信息，该运费属性信息也可以通过所述第一货币种类进行描述。此时，还可以以商品对象为单位，分别对所述运费属性信息进行从第一货币种类向第二货币种类的汇率转换以及用户权益信息计算，以确定所述多个商品对象分别对应的通过第二货币种类描述的应付运费金额信息；然后，可以根据所述价格属性信息的货币种类汇率转换以及用户权益信息计算结果，以及所述应付运费金额信息，确定所述多个商品对象分别对应的通过第二货币种类描述的应付金额信息。

另外，由于涉及到跨境交易，因此，具体实现时，还可以根据所述通过所述多个商品对象的价格属性信息以及关联的国家信息，分别向计税系统发起计税请求，以获取计税结果。

总之，通过具体商品对象价格属性信息的汇率转换以及用户权益计算，运费的汇率转换以及用户权益计算，以及具体的计税计算，每个具体的商品对象可以对应多项中间数据的产生。在具体实现时，还可以分别对各项中间数据进行保存，以用于在各种不同阶段向不同的用户进行透出，或者提供给数据库使用，等等。例如，假设当前待结算的商品对象有4件，其中商品对象1、2对应同一第一用户A，对应的第一货币种类为USD；商品对象3、4对应同一第一用户B，对应的第一货币种类为EUR(欧元)。第二用户对应的第二货币种类为CNY。则具体保存的各项数据可以包括：

商品对象1：商品对象原始价格属性值(USD)，原始运费(USD)，商品对象在第一用户权益下的优惠额(USD)，商品对象在第二用户权益下的第一分摊金额(CNY)，商品对象在第二用户权益下的第二分摊金额(USD)，运费在第一用户权益下的优惠额(USD)，运费在第二用户权益下的第一分摊金额(CNY)，运费在第二用户权益下的第二分摊金额(USD)，商品对象税(USD)，运费税(USD)；

商品对象2与商品对象1类似；

商品对象3：商品对象原始价格属性值(EUR)，原始运费(USD)，商品对象在第一用户权益下的优惠额(EUR)，商品对象在第二用户权益下的第一分摊金额(CNY)，商品对象在第二用户权益下的第二分摊金额(EUR)，运费在第一用户权益下的优惠额(EUR)，运费在第二用户权益下的第一分摊金额(CNY)，运费在第二用户权益下的第二分摊金额(EUR)，商品对象税(EUR)，运费税(EUR)；

商品对象4与商品对象3类似。

S204：提供合并支付操作选项，以用于对所述至少两个交易订单进行合并支付。

通过上述步骤可以分别计算出每个交易订单的结算结果信息，之后，便可以根据所述至少两个交易订单分别对应的结算结果信息，计算总的结算结果信息。进而可以提供合并支付操作选项，以用于对所述至少两个交易订单进行合并支付。具体实现时，可以通过多种方式提供上述合并支付操作选项，例如，在一种方式下，可以在提供给第二用户的订单页面中，提供上述合并支付操作选项。另外，该订单页面中还可以提供总的应付金额信息(可以将多个交易订单各自对应的结算结果进行相加确定)，当然，具体实现时，还可以提供前述各项中间数据，例如，包括原始价格属性值，第一用户权益下的优惠额，第二用户权益下的分摊金额，运费情况，税费信息，等等。当然，这些信息都可以以第二货币种类进行描述。

具体实现时，通过所述用于合并支付的操作选项接收到操作请求后，还可以提供可选的支付渠道信息(例如，通过银行卡支付，通过关联的网络金融产品进行支付等)，以便通过所选择的目标支付渠道对所述多个商品对象进行合并支付。

另外，具体的支付渠道也可能会提供用户权益信息，例如，某银行提供的用户权益信息为，如果选择使用该银行的银行卡支付，则可以获得随机金额的“红包”奖励，并可用于抵扣支付款。在这种情况下，同样涉及到到用户权益的分摊问题。为此，在本申请实施例中，如果所选择的目标支付渠道关联有用户权益信息，则可以根据所述多个交易订单分别对应的应付金额信息，确定所述多个交易订单分别对应的支付权益分摊金额；然后，根据所述多个交易订单分别对应的应付金额信息以及所述支付权益分摊金额，确定所述多个交易订单的实付金额信息；再根据所述多个交易订单的实付金额信息确定总的实付金额信息，以便根据所述总的实付金额信息进行合并支付。

另外，针对这种支付相关的用户权益的分摊金额，也可以分别将所述支付权益分摊金额进行从第二货币种类到各自对应的第一货币种类的反算，确定所述交易订单分别对应的以所述第一货币种类进行描述的支付权益分摊金额。

如果所述目标支付渠道还关联有手续费用信息，则还可以根据所述多个交易订单分别对应的应付金额信息以及所述支付权益分摊金额，确定所述多个交易订单分别对应的手续费用分摊金额；然后，根据所述多个交易订单分别对应的应付金额信息、所述支付权益分摊金额以及所述手续费用分摊金额，确定所述多个交易订单分别对应的实付金额信息。

此外，如果对所述合并支付操作选项进行了操作但未完成支付，则可以根据所述多个商品对象关联的第一用户为单位生成多个交易订单，并根据根据每个交易订单对应的一个或多个商品对象，拆分成多个子订单。后续在待支付订单信息界面中，可以提供用于对所述多个交易订单进行合并支付的操作选项，以用于对所述多个交易订单进行合并支付。由于汇率具有实时变化的特点，因此，用户选择对合并支付之后，可以重新计算对各个商品对象的价格属性、运费等进行汇率转换以及用户权益计算，具体的转换以及用户权益计算过程可以与前文所述类似，这里不再详述。

需要说明的是，在本申请实施例中，涉及到将多个不同的第一货币种类转转到同一第二货币种类，并利用第二货币种类进行支付的情况。而在实际应用中，有些国家的第一货币种类可能不支持跨币种的支付，例如，以卢布为单位发布的商品对象，通常仅允许用卢布进行支付，无法用其他货币种类进行支付，等等。因此，具体实现时，还可以对具体商品对象对应的第一货币种类进行判断，如果其中包括不支持跨货币种类支付的第一货币种类，则可以将其对应的商品对象单独拆分出来，通过其他方式对其进行支付。例如，在具体进行支付时，可以要求用户使用具有对应第一货币种类账户的银行卡等支付渠道进行支付，等等。

另外需要说明的是，本申请实施例涉及到的具体商品对象，可以包括对应具体实体物品的商品对象，或者，还可以包括服务类商品对象，例如旅行线路服务，住宿服务，等等，本申请实施例对于具体商品对象的类别不进行限定。

总之，针对待结算的多个商品对象，如果其中至少两个商品对象的价格属性信息关联不同的第一货币种类，则可以根据所述多个商品对象创建至少两个交易订单，并确定所述至少两个交易订单分别对应的结算结果信息，所述结算结果信息通过所述第二货币种类进行描述。之后，可以提供用于对所述多个交易订单进行合并支付的操作选项，这样，使得用户可以对至少两个交易订单进行合并支付。这样，即使至少两个交易订单关联的商品对象对应不同的第一货币种类，第二用户也只需要执行一次支付操作，即可实现对至少两个交易订单的合并支付，因此，可以简化用户操作，提升用户体验。

实施例二

该实施例二是从第一客户端的角度，提供了一种订单信息处理方法，参见图3，该装置可以包括：

S301：接收服务端提供的交易订单信息，所述交易订单时根据第二用户对多个商品对象执行结算操作后生成的，其中至少两个商品对象的价格属性信息关联不同的第一货币种类；所述交易订单信息包括所述交易订单的应收金额信息以及在用户权益下的优惠额信息，所述应收金额信息以及所述优惠额信息通过对应的第一货币种类进行描述；

S302：对所述交易订单信息进行展示。

其中，如果所述交易订单关联多个商品对象，则还可以获得所述交易订单关联的多个子订单的信息并进行展示，所述多个子订单与所述多个商品对象相对应，所述子订单的信息包括对应的商品对象的应付金额信息，以及在用户权益下的优惠额信息。

需要说明的是，本申请实施例中可能会涉及到对用户数据的使用，在实际应用中，可以在符合所在国的适用法律法规要求的情况下(例如，用户明确同意，对用户切实通知，等)，在适用法律法规允许的范围内在本文描述的方案中使用用户特定的个人数据。

与实施例一相对应，本申请实施例还提供了一种商品对象结算处理装置，参见图4，该装置可以包括：

商品对象确定单元401，用于确定待结算的多个商品对象，其中至少两个商品对象的价格属性信息关联不同的第一货币种类；

货币种类确定单元402，用于确定执行支付操作时所需使用的第二货币种类；

订单创建单元403，用于根据所述多个商品对象创建至少两个交易订单，并确定所述至少两个交易订单分别对应的结算结果信息，所述结算结果信息通过所述第二货币种类进行描述；

合并支付单元404，用于提供合并支付操作选项，以用于对所述至少两个交易订单进行合并支付。

其中，所述订单创建单元具体可以包括：

应付金额信息确定子单元，用于以商品对象为单位，分别对所述价格属性信息进行从第一货币种类向第二货币种类的汇率转换以及用户权益信息计算，以确定所述多个商品对象分别对应的通过第二货币种类描述的应付金额信息；

结算结果确定子单元，用于根据所述至少两个交易订单分别关联的商品对象，以及所述多个商品对象的所述应付金额信息信息，确定所述至少两个交易订单分别对应的结算结果信息。

其中，所述应付金额信息确定子单元具体可以用于：

如果所述商品对象命中由关联的第一用户提供的第一用户权益信息，则根据商品对象的原始价格属性信息以及所述第一用户权益信息，确定通过所述第一货币种类描述的优惠后的价格属性信息；

根据所述优惠后的价格属性信息进行从第一货币种类向第二货币种类的汇率转换，确定所述商品对象的所述应付金额信息。

或者，所述应付金额信息确定子单元还可以用于：

如果存在命中同一第二用户权益信息的多个不同商品对象，则在将价格属性信息从第一货币种类汇率转换到第二货币种类后，基于汇率转换后的价格属性信息，以及所述第二用户权益的优惠方式信息，确定所述多个不同商品对象分别对应的第一分摊金额，所述第一分摊金额通过所述第二货币种类进行描述；

根据所述汇率转换后的价格属性信息以及对应的第一分摊金额，确定所述多个商品对象分别对应的通过第二货币种类描述的应付金额信息。

另外，该装置还可以包括：

第一反算单元，用于分别将所述第一分摊金额进行从第二货币种类到各自对应的第一货币种类的反算，确定以所述第一货币种类进行描述的第二分摊金额；

应收金额信息确定单元，用于根据所述商品对象的原始价格属性信息以及所述第二分摊金额，确定所述交易订单对应的通过第一货币种类描述的应收金额信息，以用于提供给所述交易订单对应的第一用户。

再者，该装置还可以包括：

支付完成单元，用于通过所述操作选项接收到合并支付请求并完成支付后，将所述总的结算结果信息计入公共账户，并将所述至少两个交易订单分别置为已支付状态；

清算单元，用于在从公共账户向所述第一用户进行结算时，根据所述交易订单对应的所述应收金额信息向对应的第一用户进行结算。

另外，所述商品对象还可以关联有运费属性信息，所述运费属性信息通过所述第一货币种类进行描述；

此时，该装置还可以包括：

运费信息计算单元，用于以商品对象为单位，分别对所述运费属性信息进行从第一货币种类向第二货币种类的汇率转换以及用户权益信息计算，以确定所述多个商品对象分别对应的通过第二货币种类描述的应付运费金额信息；

应付金额确定单元，用于根据所述价格属性信息的货币种类汇率转换以及用户权益信息计算结果，以及所述应付运费金额信息，确定所述多个商品对象分别对应的通过第二货币种类描述的应付金额信息。

另外，还可以包括：

计税结果获取单元，用于根据所述通过所述多个商品对象的价格属性信息以及关联的国家信息，分别向计税系统发起计税请求，以获取计税结果。

再者，该装置还可以包括：

判断单元，用于对所述多个商品对象分别对应的多种不同的第一货币种类进行判断，如果其中包括不支持跨货币种类支付的第一货币种类，则将其对应的商品对象单独提取出来，采用其他方式对其进行支付。

其中，所述合并支付单元具体可以用于：在订单页面中提供所述提供合并支付操作选项，所述订单页面还用于对所述至少两个交易订单的订单内容以及总的结算结果信息进行展示。

在具体进行支付时，该装置还可以包括：

可选支付渠道信息提供单元，用于通过所述用于合并支付的操作选项接收到操作请求后，提供可选的支付渠道信息，以便通过所选择的目标支付渠道对所述至少两个交易订单进行合并支付。

支付权益计算单元，用于如果所选择的目标支付渠道关联有用户权益信息，则根据所述至少两个交易订单分别对应的结算结果信息，确定所述至少两个交易订单分别对应的支付权益分摊金额；

实付金额确定单元，用于根据所述至少两个交易订单分别对应的结算结果信息以及所述支付权益分摊金额，确定所述至少两个交易订单的实付金额信息；

总实付金额确定单元，用于根据所述至少两个交易订单的实付金额信息确定总的实付金额信息，以便根据所述总的实付金额信息进行合并支付。

再者，该装置还可以包括：

第二反算单元，用于分别将所述支付权益分摊金额进行从第二货币种类到各自对应的第一货币种类的反算，确定所述交易订单分别对应的以所述第一货币种类进行描述的支付权益分摊金额。

另外，还可以包括：

手续费计算单元，用于如果所述目标支付渠道还关联有手续费用信息，则根据所述至少两个交易订单分别对应的结算结果信息以及所述支付权益分摊金额，确定所述至少两个交易订单分别对应的手续费用分摊金额；

实付金额确定单元，用于根据所述至少两个交易订单分别对应的应付金额信息、所述支付权益分摊金额以及所述手续费用分摊金额，确定所述至少两个交易订单分别对应的实付金额信息。

另外，所述合并支付单元还可以用于：

在所述订单界面中对所述多个商品对象分别对应的通过所述第一货币种类描述的价格属性信息进行展示。

另外，该装置还可以包括：

订单拆分单元，用于如果对所述合并支付操作选项进行了操作但未完成支付，则根据所述交易订单对应的一个或多个商品对象，拆分成多个子订单；

操作选项提供单元，用于在待支付订单信息界面中，提供用于对所述至少两个交易订单进行合并支付的操作选项，以用于对所述至少两个交易订单进行合并支付。

与实施例二相对应，本申请实施例还提供了一种订单信息处理装置，参见图5，该装置可以包括：

订单信息接收单元501，用于接收服务端提供的交易订单信息，所述交易订单时根据第二用户对多个商品对象执行结算操作后生成的，其中至少两个商品对象的价格属性信息关联不同的第一货币种类；所述交易订单信息包括所述交易订单的应收金额信息以及在用户权益下的优惠额信息，所述应收金额信息以及所述优惠额信息通过对应的第一货币种类进行描述；

订单展示单元502，用于对所述交易订单信息进行展示。

其中，该装置还可以包括：

子订单展示单元，用于如果所述交易订单关联多个商品对象，获得所述交易订单关联的多个子订单的信息并进行展示，所述多个子订单与所述多个商品对象相对应，所述子订单的信息包括对应的商品对象的应付金额信息，以及在用户权益下的优惠额信息。

另外，本申请实施例还提供了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现前述方法实施例中任一项所述的方法的步骤。

以及一种电子设备，包括：

一个或多个处理器；以及

与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令,所述程序指令在被所述一个或多个处理器读取执行时，执行前述方法实施例中任一项所述的方法的步骤。

其中，图6示例性的展示出了电子设备的架构，例如，设备600可以是移动电话，计算机，数字广播终端，消息收发设备，游戏控制台，平板设备，医疗设备，健身设备，个人数字助理，飞行器等。

参照图6，设备600可以包括以下一个或多个组件：处理组件602，存储器604，电源组件606，多媒体组件608，音频组件610，输入/输出(I/O)的接口612，传感器组件614，以及通信组件616。

处理组件602通常控制设备600的整体操作，诸如与显示，电话呼叫，数据通信，相机操作和记录操作相关联的操作。处理元件602可以包括一个或多个处理器620来执行指令，以完成本公开技术方案提供的方法的全部或部分步骤。此外，处理组件602可以包括一个或多个模块，便于处理组件602和其他组件之间的交互。例如，处理部件602可以包括多媒体模块，以方便多媒体组件608和处理组件602之间的交互。

存储器604被配置为存储各种类型的数据以支持在设备600的操作。这些数据的示例包括用于在设备600上操作的任何应用程序或方法的指令，联系人数据，电话簿数据，消息，图片，视频等。存储器604可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(SRAM)，电可擦除可编程只读存储器(EEPROM)，可擦除可编程只读存储器(EPROM)，可编程只读存储器(PROM)，只读存储器(ROM)，磁存储器，快闪存储器，磁盘或光盘。

电源组件606为设备600的各种组件提供电力。电源组件606可以包括电源管理系统，一个或多个电源，及其他与为设备600生成、管理和分配电力相关联的组件。

多媒体组件608包括在设备600和用户之间的提供一个输出接口的屏幕。在一些实施例中，屏幕可以包括液晶显示器(LCD)和触摸面板(TP)。如果屏幕包括触摸面板，屏幕可以被实现为触摸屏，以接收来自用户的输入信号。触摸面板包括一个或多个触摸传感器以感测触摸、滑动和触摸面板上的手势。触摸传感器可以不仅感测触摸或滑动动作的边界，而且还检测与触摸或滑动操作相关的持续时间和压力。在一些实施例中，多媒体组件608包括一个前置摄像头和/或后置摄像头。当设备600处于操作模式，如拍摄模式或视频模式时，前置摄像头和/或后置摄像头可以接收外部的多媒体数据。每个前置摄像头和后置摄像头可以是一个固定的光学透镜系统或具有焦距和光学变焦能力。

音频组件610被配置为输出和/或输入音频信号。例如，音频组件610包括一个麦克风(MIC)，当设备600处于操作模式，如呼叫模式、记录模式和语音识别模式时，麦克风被配置为接收外部音频信号。所接收的音频信号可以被进一步存储在存储器604或经由通信组件616发送。在一些实施例中，音频组件610还包括一个扬声器，用于输出音频信号。

I/O接口612为处理组件602和外围接口模块之间提供接口，上述外围接口模块可以是键盘，点击轮，按钮等。这些按钮可包括但不限于：主页按钮、音量按钮、启动按钮和锁定按钮。

传感器组件614包括一个或多个传感器，用于为设备600提供各个方面的状态评估。例如，传感器组件614可以检测到设备600的打开/关闭状态，组件的相对定位，例如所述组件为设备600的显示器和小键盘，传感器组件614还可以检测设备600或设备600一个组件的位置改变，用户与设备600接触的存在或不存在，设备600方位或加速/减速和设备600的温度变化。传感器组件614可以包括接近传感器，被配置用来在没有任何的物理接触时检测附近物体的存在。传感器组件614还可以包括光传感器，如CMOS或CCD图像传感器，用于在成像应用中使用。在一些实施例中，该传感器组件614还可以包括加速度传感器，陀螺仪传感器，磁传感器，压力传感器或温度传感器。

通信组件616被配置为便于设备600和其他设备之间有线或无线方式的通信。设备600可以接入基于通信标准的无线网络，如WiFi，或2G、3G、4G/LTE、5G等移动通信网络。在一个示例性实施例中，通信部件616经由广播信道接收来自外部广播管理系统的广播信号或广播相关信息。在一个示例性实施例中，所述通信部件616还包括近场通信(NFC)模块，以促进短程通信。例如，在NFC模块可基于射频识别(RFID)技术，红外数据协会(IrDA)技术，超宽带(UWB)技术，蓝牙(BT)技术和其他技术来实现。

在示例性实施例中，设备600可以被一个或多个应用专用集成电路(ASIC)、数字信号处理器(DSP)、数字信号处理设备(DSPD)、可编程逻辑器件(PLD)、现场可编程门阵列(FPGA)、控制器、微控制器、微处理器或其他电子元件实现，用于执行上述方法。

在示例性实施例中，还提供了一种包括指令的非临时性计算机可读存储介质，例如包括指令的存储器604，上述指令可由设备600的处理器620执行以完成本公开技术方案提供的方法。例如，所述非临时性计算机可读存储介质可以是ROM、随机存取存储器(RAM)、CD-ROM、磁带、软盘和光数据存储设备等。

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

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

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

Claims

1.一种商品对象结算处理方法，其特征在于，包括：

确定执行支付操作时所需使用的第二货币种类；

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

所述确定所述至少两个交易订单分别对应的结算结果信息，包括：

以商品对象为单位，分别对所述价格属性信息进行从第一货币种类向第二货币种类的汇率转换以及用户权益信息计算，以确定所述多个商品对象分别对应的通过第二货币种类描述的应付金额信息；

根据所述至少两个交易订单分别关联的商品对象，以及所述多个商品对象的所述应付金额信息信息，确定所述至少两个交易订单分别对应的结算结果信息。

3.根据权利要求2所述的方法，其特征在于，

所述分别对所述价格属性信息进行从第一货币种类向第二货币种类的汇率转换以及用户权益信息计算，包括：

4.根据权利要求2所述的方法，其特征在于，

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

分别将所述第一分摊金额进行从第二货币种类到各自对应的第一货币种类的反算，确定以所述第一货币种类进行描述的第二分摊金额；

根据所述商品对象的原始价格属性信息以及所述第二分摊金额，确定所述交易订单对应的通过第一货币种类描述的应收金额信息，以用于提供给所述交易订单对应的第一用户。

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

通过所述操作选项接收到合并支付请求并完成支付后，将所述总的结算结果信息计入公共账户，并将所述多个交易订单分别置为已支付状态；

在从公共账户向所述第一用户进行结算时，根据所述交易订单对应的所述应收金额信息向对应的第一用户进行结算。

7.根据权利要求2所述的方法，其特征在于，

所述商品对象还关联有运费属性信息，所述运费属性信息通过所述第一货币种类进行描述；

所述方法还包括：

以商品对象为单位，分别对所述运费属性信息进行从第一货币种类向第二货币种类的汇率转换以及用户权益信息计算，以确定所述多个商品对象分别对应的通过第二货币种类描述的应付运费金额信息；

根据所述价格属性信息的货币种类汇率转换以及用户权益信息计算结果，以及所述应付运费金额信息，确定所述多个商品对象分别对应的通过第二货币种类描述的应付金额信息。

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

根据所述通过所述多个商品对象的价格属性信息以及关联的国家信息，分别向计税系统发起计税请求，以获取计税结果。

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

对所述多个商品对象分别对应的第一货币种类进行判断，如果其中包括不支持跨货币种类支付的第一货币种类，则将其对应的商品对象单独提取出来，采用其他方式对其进行支付。

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

所述提供合并支付操作选项，包括：

在订单页面中提供所述提供合并支付操作选项，所述订单页面还用于对所述至少两个交易订单的订单内容以及总的结算结果信息进行展示。

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

通过所述用于合并支付的操作选项接收到操作请求后，提供可选的支付渠道信息，以便通过所选择的目标支付渠道对所述至少两个交易订单进行合并支付。

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

如果所选择的目标支付渠道关联有用户权益信息，则根据所述至少两个交易订单分别对应的结算结果信息，确定所述至少两个交易订单分别对应的支付权益分摊金额；

根据所述至少两个交易订单分别对应的结算结果信息以及所述支付权益分摊金额，确定所述至少两个交易订单的实付金额信息；

根据所述至少两个交易订单的实付金额信息确定总的实付金额信息，以便根据所述总的实付金额信息进行合并支付。

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

分别将所述支付权益分摊金额进行从第二货币种类到各自对应的第一货币种类的反算，确定所述交易订单分别对应的以所述第一货币种类进行描述的支付权益分摊金额。

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

如果所述目标支付渠道还关联有手续费用信息，则根据所述至少两个交易订单分别对应的结算结果信息以及所述支付权益分摊金额，确定所述至少两个交易订单分别对应的手续费用分摊金额；

根据所述至少两个交易订单分别对应的应付金额信息、所述支付权益分摊金额以及所述手续费用分摊金额，确定所述至少两个交易订单分别对应的实付金额信息。

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

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

如果对所述合并支付操作选项进行了操作但未完成支付，则根据所述交易订单对应的一个或多个商品对象，拆分成多个子订单；

在待支付订单信息界面中，提供用于对所述至少两个交易订单进行合并支付的操作选项，以用于对所述至少两个交易订单进行合并支付。

17.一种订单信息处理方法，其特征在于，包括：

对所述交易订单信息进行展示。

18.根据权利要求17所述的方法，其特征在于，

如果所述交易订单关联多个商品对象，则还包括：

获得所述交易订单关联的多个子订单的信息并进行展示，所述多个子订单与所述多个商品对象相对应，所述子订单的信息包括对应的商品对象的应付金额信息，以及在用户权益下的优惠额信息。

19.一种商品对象结算处理装置，其特征在于，包括：

20.一种订单信息处理装置，其特征在于，包括：

订单展示单元，用于对所述交易订单信息进行展示。

21.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，该程序被处理器执行时实现权利要求1至18任一项所述的方法的步骤。

22.一种电子设备，其特征在于，包括：

一个或多个处理器；以及

与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令,所述程序指令在被所述一个或多个处理器读取执行时，执行权利要求1至18任一项所述的方法的步骤。