在第一期中，用户先填写信息生成订单，然后再查询用户是否开通免密支付，开通后直接发起扣款。这样做的好处是将开通流程整合进投保流程，开通后自动完成扣款，符合正常的投保逻辑。
在扣款处理上，第一期的做法是当跳转进入开通流程的地址中存在订单号时，开通后就自动发起首期款扣费，因此代扣功能与百万医疗产品关联起来了，这限制了后期业务线拓展，因此在2期中，我们的主要工作就是将代扣服务与下单分离开，方法就是在用户进行投保之前就引导用户开通代扣服务。
因此在流程上进行了如下调整：
微信框架下流程调整
微信下在加载专题页时就判断用户（根据openID判断）是否开通代扣服务，没有开通则隐藏投保模块，引导去完成开通，开通后跳转回专题页，再进行投保下单和扣款。
APP框架下流程调整
APP框架下因涉及到登录态的判断，流程上要稍微复杂一些，但是逻辑与微信框架下基本一致。在完成登录态判断后，再进行是否开通免密支付判断，未登录/已登录未开通的则不展示投保模块。
值得一提的是，对于未开通免密支付的用户，在未登录状态下，需要3次跳转（一次跳转到登录态，一次跳转到专题页，一次跳转到开通免密支付页，见流程图右半部分），该情况下登录成功后跳转回专题页的过程中，不满足开通免密支付条件时就直接进行再次跳转，与流程图中的左侧情况不同，因此需要做区分。采取的方法是由登录页跳转回专题页的地址上加个识别参数，地址中带这个参数的专题页加载时，不符合开通条件就跳转到开通页面。
开通免密支付引导
调整后的流程是用户投保之前需要先开通免密支付，这与用户的预期不太一致，因此上线后订单量出现明显下降，后来在页面上进行了提示，转化才提升1期水平。
总结
自己埋的坑跪着也要填完啊o(╯□╰)o，所以设计流程时要充分考虑后期的拓展性，当然更要兼顾用户惯有认知，高转化才是最终的目的。
