遇到众筹和大额理财，产品订单该如何设计？

　　该篇文章通过剖析涉及金额高、募集周期长的订单业务需求，提出了这类订单的设计流程及原型方案。
　　在订单系统中，常见的类型有：付款到货的电商类、票务类订单，付款消费的团购类、外卖类O2O订单等等。
　　这些订单系统都具备完整的售前售中售后流程，其中售中的关键动作是支付，但大部分的订单系统都只有一次支付动作。
　　其实还有一些业务类型，在整个订单生命周期中是有两次支付动作的。本文主要就是列举一种在订单生命周期中涉及两次支付的订单系统的设计方案。
　　一、业务背景
　　有些业务涉及的金额高、募集周期长，如果让用户一开始就支付足额资金，那么这些大额资金就会出现站岗的现象：也就是说，资金支付并锁定了，但获得份额或收益还需要等待数周或更长。
　　由于这些资金动辄几十万、数百万、甚至上千万，在几周或一两个月的时间里站岗的话，利息的损失是可观的，对用户来说是一种实实在在的经济损失。
　　例如，金额较高的众筹类，包括酒店、民宿等空间众筹，募集周期常常达到1个月以上，甚至23个月，而不少投资金额是一万起、或数万、或一二十万，这些资金在几个月的时间里站岗，损失的利息最高可以达到数千元。更厉害的诸如信托、私募类的大额理财产品，起投金额一般是100万，募集周期短的12周，长的可能有一两个月，由于金额非常高，利息损失更高。
　　因此，类似这样的业务就出现一种需求场景：客户先支付少量预约金锁定额度，然后在预约期结束时，集中打款支付剩余的金额，从而既保证了募集结果的可控性，也保护了用户利益。
　　保证募集结果可控指的是：在长周期的募集过程中，由于用户支付了定金性质的预约金，后续反悔的可能性小，对顺利完成募集影响不大。
　　保护用户利益是指：用户只需支付小额预约金（一般为认购额度的1～5），就可以锁定额度，且大额资金也不用站岗损失利息。
　　描述到这里，核心流程就呼之欲出了：用户先支付预约金，到特定的时间点后再支付剩余金额。
　　二、两次支付为什么不是两个订单？
　　熟悉支付系统的人听到两次支付，一定会下意识认为应该是两笔订单，一笔是预约金支付订单，一笔是认购金支付订单。从支付系统的角度来说是正确的，因为对于支付系统来说，一个“支付订单”的生命周期包含了待支付、支付成功、支付失败或支付超时等状态，管理的一般是一笔支付的情况。
　　但上述所列举的场景，在业务角度上以及开发角度上，我们把它定义为一笔订单。原因如下：
　　从用户的角度：支付预约金目的是为了锁定额度，且后续支付的也是“剩余金额”，实际上在用户看来是一个事务的前后关系
　　从开发的角度：在业务系统层面（非支付系统层面）分开两个订单，然后再创建关联，复杂度反而会提高
　　因此，我们把它设计成在支付层是两笔订单，但在业务层则是一笔订单的两个阶段。
　　三、预约认购流程解析
　　下图是预约认购的核心流程，描述如下：
　　预约阶段：一般周期较长，用户可以支付少量预约金，锁定尚未被预约的份额。例如，欲认购某信托基金500万元，这个阶段只需要支付5万元预约金。需要注意的是，预约金是定金性质，支付后如果在认购阶段放弃认购资格的话，从法律角度来说平台是可以不退还的，但为了用户的体验，一般可以设计成可原路退还或可转为代金券在下次认购时使用的方式。
　　点击进入预约金支付页面后，订单即生成，这时候订单处于“预约金待支付”状态，支付成功则状态更新为“预约成功”。
　　认购阶段：一般周期较短，需要通过多种方式通知到客户及时打款支付剩余金额（例如余下99的金额），如上信托的例子，用户需要再支付495万元，支付成功则认购成功。如果在认购阶段没有完成支付，则在基金结束募集进入了封闭期后，用户支付的5万元按定金方式处理。
　　由于从预约到认购是同一个订单，用户在认购阶段触发认购支付流程时，会将订单更新为“认购待支付”状态，并显示待支付的剩余金额，支付成功后则状态更新为“认购成功”。
　　这个流程是抽取最核心的部分，在实际产品的设计中，还有诸多的细节需要处理好：
　　订单上要明显标明当前是处于预约阶段或认购阶段；
　　预约支付时，明确说明预约金用途及后续未认购的处理；
　　预约成功且到认购阶段时，应通过多种方式（APP消息、短信、人工电话通知）通知到客户，且在订单列表中可以便捷进行预约订单的认购操作，确保预约客户最大化转化为认购客户；
　　认购阶段，非预约用户点击认购时，需要做好提醒，例如提醒用户还有剩余额度，可联系客服直接认购等；也可以设置一个开放认购期，供未预约用户认购剩余份额。
　　四、订单管理原型设计
　　订单管理是该流程面向用户的重要界面，设计良好的功能流程可以保障用户使用顺畅、提高认购转化率。
　　订单流转和状态原型描述如下：
　　预约待支付：点击预约进入支付页面后，如果未支付，则是待支付状态，需要显示订单类型为“预约”、显示需要支付的金额、支付剩余时间，并可进行取消订单和付款的操作；
　　预约已支付：类型为“预约”，状态为“预约成功”；
　　认购引导：预约成功后，订单处于等待状态，在项目进入认购期后，订单出现“去认购”的提醒，注意此时订单的状态并未变化，只是多了一个开始认购的提醒和去认购的便捷按钮；
　　认购待支付：点击去认购并生成认购待支付订单后，订单状态更新为认购阶段的待支付状态，同样可以选择取消订单和付款两个操作。需要注意的是，如果业务模式限定必须先预约才有资格认购，则类型显示为“认购”即可，之所以显示为“预约转认购”是为了区别那种有开放认购并行存在的情况；
　　认购支付成功：认购订单支付完剩余款项后，订单状态更新为“认购成功”；
　　未认购：过了认购期仍然没有支付剩余款项的，订单类型保持为“预约”，订单状态保持为“预约成功”，但给予用户“预约金已转为代金券”的友好提示。
　　五、总结
　　对于涉及两次支付的订单系统的设计，需要整合好支付层的订单转化为方便用户使用的业务层的订单。
　　本文提出的方案是将一个事务中的两笔支付订单合成为有前后关系的一笔订单，从而方便用户在不同阶段对订单进行管理。