首先排除第三方支付服务能否支撑等其他外在影响因素，单独就需求功能来说：

1、需求是否为伪需求？

在实际使用过程中，一般用户要么选择金额支付，要么选择分期/预支付。那么一个多商品一部分金额支付，一部分分期/预支付的场景需求程度好像并不是很多。对于用户来说，是可有可无的需求还是令人兴奋的需求？

2、需求的功能设计

订单拆分支付一般是组合下单，订单中可能包含不同店铺的多个商品的不同购买数量。这里面涉及3个数级参数：店铺数量、商品种类、单一商品的数量。订单的拆解支付会涉及到以上3个数级参数的拆解或合并，数级操作越多，操作过程越复杂，流程被回退的概率就越大，会大大增加用户操作难、操作流程长度和复杂体验感。

3、功能的交互场景

原有订单支付模块，购物车商品列表，一般包含2级，一级店铺和二级商品列表。用户选择店铺或商品，系统计算最后的订单总金额，用户选择支付方式，确认下单，完成支付，操作闭环。

新的订单支付模块，

方案一：购物车商品列表，一般包含2级，一级店铺和二级商品列表（相同）。用户选择店铺或商品，将选择的数据拉入一个新的操作界面，系统计算最后的订单总金额。然后选择金额支付的商品范围或分期/预支付商品范围，确认下单，完成支付，操作闭环。

方案二：在商品列表栏中， 每一个商品单独进行支付方式的选择，最终订单金额的展现不仅仅包含总金额，还包含金额支付和分期/预支付的分别总金额。

也就是说，方案一在需求的订单支付模块，会多出一个按不同支付方式归拢商品数据的操作，根据用户选择的随机性，在少量商品订单的情况下，操作次数较少，交互直观。当商品订单数量巨大，商品种类繁多，列表list较长时，操作次数增加，交互变得不在直观，需要用户记忆和反复调整。方案二需要单独的某一个商品选择支付方式，同样在少量商品时，还能接收，当商品种类数量较多时，需要大量的选择操作和反复调整。但是方案二优于方案一。