WEB端的支付流程相较于APP端更为复杂，需要更多的交互细节考虑。从商品选择到订单确认，再到选择支付币种，选择支付渠道，如何给用户比较友好的用户体验尤为重要。
在产品设计阶段，我将不同等级的会员及所能提供的不同服务差异放在了一个页面，用户可以很清晰的看到每一等级的会员所能享受到的服务差别。这里建议不要设置过多的会员等级，增加用户的学习成本（我们设置了3个级别：免费会员、高级会员、专业会员，同时留下了联系方式可以直接联系我们提供定制化的服务）。
不同层级的会员一定要有足够吸引用户选购的功能点，或者说你要明确自己的客户分层。比如中小企业客户需要哪些功能？大企业用户需要哪些功能等。关于用户分级的问题，这里先不做赘述。
线上支付流程当用户选择了适合的服务后，进入到确认订单页面。这里我省去了购物车的环节，转而将“选择时长、选择支付币种”等购物车流程，与订单详情合并。让用户做到所选即所得，缩短支付路径。同时可以非常直观的看到自己选择的服务，以及需要支付的金额。
线上支付下单流程当用户下单后，我们在后台自动生成1笔“待支付”状态的订单，同时第三方接口会回传给我们一个URL。通过二维码生成工具，我们会在新弹出来的页面上将URL转成该笔订单所需要的二维码。（期间涉及到我们需要用第三方支付平台的公钥解密文件，当时开发就出现了密钥格式出错导致解密失败的问题，排查了半天原因最后大家也很尴尬😅）
与此同时，后端数据库会执行一个策略是线上支付的订单如果在30分钟内仍旧没有完成支付，我们会将订单强制关闭。前端页面也会通过计时器的方式，告知用户“您的支付已经超时，请重新发起”这类文案提示。这样避免的大量堆积无效的待支付订单，一定要对订单自动处理。
原支付页面会出现一个手动同步订单状态的弹窗，一旦出现用户完成了支付但是页面状态没有刷新的情况，可以允许用户手动刷新。当然，如果未完成支付的话点击，出现提示“支付尚未完成，请在新弹出的页面完成支付”。
当用户完成支付后，二维码页面会出现支付成功的弹窗，同时倒计时提醒用户将自动关闭。原有的会员页面刷新，提醒用户“会员已经开通啦，ENJOY！”后端订单状态变更为“支付成功”此时一次线上支付流程结束。
TO B产品同样面临着线下支付的环节，此时的业务逻辑是，我们会给用户展示出来需要转账的银行信息，当用户完成转账后，在平台上提交“转账流水单号（或者转账编号）”，同时转账时备注所需要开通的服务及账号信息。我们收到相关业务通知邮件后，运营同学会与财务进行查账核实。如果收到款项则第一时间在后台为此用户开通账号，同时邮件提醒。如果未查收到款项，则会手动关闭此订单（线下订单也会自动关闭，时限设置在72小时）。
比较理想的方式是可以和财务系统对接，这块会在后续迭代继续优化。
管理后台管理后台我们提供了一系列字段直观的展示给运营同学：例如下单时间、支付渠道、支付金额、支付状态查看，基本的查询功能等。同时允许运营铜同学进行订单状态的修改。后续会考虑加入Dashboard，批量操作等功能。
数据打点对于支付这种重要流程，数据打点必不可少。需要监控到用户跳入“服务选择”页面前的来源页（也就是说哪个功能能触及到用户需求，他有强烈欲望想看看到底如何开通会员），页面访问量，每个按钮点击量，用户再哪个环节跳出率比较高等等，为后续支付环节优化提供数据支撑。
复盘及后续需要处理的问题1. 支付宝/微信官方渠道说支付相关的二维码失效时间为2小时，第三方支付渠道建议在2分钟内完成支付。如果真存在订单有效期内，二维码过期的问题。那么后续需要加入页面轮询，及时请求新的支付URL，替换掉失效的二维码；
2. 会员续费：后续会加入此功能；
3. 会员升级：需要制定升级策略，如何补差价，如何计算有效期，是否某些情况下不允许升级等等；
4. 折扣价：这块我们在后台设计时已经预留了字段，可以满足定额折扣、比例折扣、选择某些套餐时折扣、达到某个值后折扣等需求；
5. 页面交互：需要优化现有页面交互，让支付流程更加流畅；
6. 风控环节：因为目前订单量不大，因此采用人工审核的方式。后续会加入机器自动风控的策略，对于一些操作违规的账号第一时间作出限制；
7. 支付是业务逻辑比较复杂的模块，需要在需求评审前想清楚各个环节的逻辑及可能出现的问题，这样可以一定程度避免因为需求没有考虑清楚导致开发延期的问题。
欢迎互撩～～
联系客服
