支付宝手机充值
有同学会问，手机充值功能不就这么简单吗，一个手机号码输入框，再选择面额，完成支付，不就完事了么。
且不考虑支付环节，那么问题来了，用户完成支付，然后呢？你该如何帮用户进行充值？后台记录下用户手机号码然后跑去营业厅帮用户充值？呵呵~跑死你。这里就涉及到手机充值供应商，我们与供应商对接，供应商再与运营商对接，当然也可直接与供应商对接，前提是你的用户体量够大，数据可观人家才肯跟你玩。
业务
大体流程：当用户发起充值后，我们将数据请求发给供应商，供应商再向运营商发起充值请求。运营商再将充值结果返回给供应商，供应商返回给我们。
项目初期需与供应商确定好对接流程，如下图，即泳道图：
该图已包含用户简单的流程，主要还是体现我们与供应商系统对接方案，当技术拿到这套流程后，会出相应的时序图，这属于技术方案范畴，你无需精通，但作为产品需大致了解下时序图，以后出现问题，在哪个环节出问题了，你就能知道是在哪里出问题，便于做决策。
后台流程定下后我们终于可以定前端的流程了，输入号码-选择面额-支付，再考虑号码错误怎么办，如果用户修改号码会怎样等等异常流程，流程定下来，这里前端信息元素相对较少，我直接跳过信息框架梳理开始玩界面原型设计了，其实设计过程脑子里已经定好框架。下图以充流量为例：
原型图+交互细节，各种交互细节可根据具体需求而定，这里就不展开。关于原型要做出带交互效果还是这样每个页面每种情况展开说明，具体还是得看开发同事的喜好，曾经做成带炫酷拽交互效果的，结果不太理想，UI，开发对于页面间的层级结构理解不够清晰，这样也会忽略很多异常细节情况，所以现在是每个页面每种情况展开说明，技术这边是流水线生产，这样的图便于开发的同事“流水作业”。
资金
支付，涉及到支付就涉及到资金流，有资金流就有清结算/对账，对账主要与供应商核对订单状态，双方应在市场层面合作初期约定好合作方式(预存款/后结算）、对账周期、对账以谁为准等等，一般都是D+1对账（不是T+1），即第二个自然日确定前一天订单的状态，前一天订单有成功/失败还有处理中这种不确定的状态，确定的状态核对正不正确，不确定的状态勾对确定状态，通过这种方式确定是否应该退款/赔付，当然设计对账流程/差异处理时是要杜绝赔付这种情况发生的。
对账后再月结打款给供应商，或者先预存款款项在供应商那里，用户充值一笔就从供应商那边相应的账户里扣款。至于供应商与运营商怎么玩就不管啦。如果与运营商对接的玩法也基本一样。
到这里，业务流/资金流都完成了闭环。这是一个手机充值功能从无到有过程。
但对于一个坑爹的产品经理，工作还没完，还要安排运营人员配置相应的打款信息，配置各种参数，安排人员编写产品手册给客服人员等等，确保业务上线后能正常运转。
关于你看到的只是冰山一角。
