之前的一篇文章回顾了「走取购」应对订单拆单的解决方案，但还有一点没有说完，那就是支付的问题。因为我们不免出现以下的情况：

1.多条订单创建完成之后， 不可能需要用户分开支付多次，一定是唤起一次支付宝/微信就支付完成；
2.用户可能放弃这次支付，然后又选择了支付其中某一笔订单，或其中订单列表里面待支付的另外两笔；

所以在这样的场景下，订单与支付不可能再像没有合并支付功能那样，属于同一条数据或者一对一关系了。

当时我还天真的以为第三方支付会不会提供这样的支付接口，下订单时候，允许同时传递两个不同的订单号，以此表示合并支付，后面是觉得我想多了。

而对于我们系统现有的支付模块，它其实不应该关心订单号怎么生成，订单怎么合并，它所提供的支付接口跟微信/支付宝一样，都只有1个订单号，至于这背后的关系对应，1对1，还是1对多，应该是订单模块所要考虑的。

基于以上场景，我给出了如下的解决方案，大致流程如下：

1.跟当当一样，在提交订单页中，前端需要做一次渠道商品的分类显示，即预拆单；
2.前端向后台提交的预拆单数据后，后台做数据wrap，检查等一些列动作，直至将商品按渠道建立平级订单；
3.后台将创建的订单集合（有可能集合里只有1笔单子）返回给前端；
4.最关键的一步：前端将这些订单集合再次向后台请求，让其生成1个支付单号并返回
5.拿到最新的支付单号后，前端再据此请求后台的支付接口
6.唤起支付界面，用户正常支付，流程结束
7.如果此时用户取消支付，则返回到订单页，查看待支付的订单
8.在待支付订单界面，你可以重复步骤4的流程，发起订单支付

以上的流程，同样还可以复用单笔支付跟多笔订单合并支付。可能的问题：调用上面的步骤4会每次生成新的支付单号，所以一旦该单号用户没有完成支付，就会处于闲置状态。解决办法，可以开启定时任务，一段时间内删除没有支付的支付单号。