项目背景
为了更好的被业务端调用，满足业务方的需求，我接到了优化统一支付的任务。刚接手时，我也是比较茫然，不知该从何下手。看到的只是那几个页面的流程，不知道背后的业务，所以我决定着手开始了解系统构成，以及后端流程。
系统构成
想做支付业务，先得了解支付系统的构成，交互如果不了解业务，就没有办法展开工作，如果不了解业务，我们的工作难道就是画几个页面而已吗？
前期工作
阅读后端时序图，PRD，接口文档，进行了大量的竞品分析，发现现有流程中的问题当前问题，基于体验的角度提出进一步优化，主要由原因有以下几点：
1.如何定义支付失败，用户的操作失败为何会被定义成支付失败，给出失败结果
（根据竞品分析，如：用户的银行卡内余额不足，第三方支付密码验证错误等情况都不应被定义成支付失败）
2.根据业务需求，以下几点需要重新梳理
订单类型A：上送付款方式给支付系统，发起支付后，付款方式不可更改。
订单类型B：在确认订单页已经选好了优惠信息，发起支付请求，传参支付金额＝订单金额－优惠信息，优惠券不显示
订单类型C：是否展示付款详情页，如何定义，不该统一都展示，因为有些业务，需要快速的完成支付，并且在订单层面已经确认了所有的该确认的信息，付款方式，优惠信息等等）
分析得出，线上支付时，外部订单都理应展示付款详情页，因为需要向用户展示，用户标识，告知用户你在使用快钱账户下的付款方式进行消费。
内部订单的话，根据业务需求（如在确认订单页已选择好），根据业务需求做成参数，可通过传参不显示付款详情
订单类型D：支付完成之后需要直接回到发起支付的地方，或者支付完成之后需要直接进入到订单详情，（而不是现有的，统一给出一个支付结果页，再跳转至业务要求的URL），（参考支付宝）支付结果在统一支付模块中暂时，后续更新交易状态－因为用户并不关心支付状态
订单类型E：外部客户端订单调起快钱的支付系统，完成支付之后，需要直接回到外部客户端的指定URL（同上）
3.关于银行返回的开户行信息、CVV2码等错误代码该如何处理
首先需要知道，这些是怎么来的，根据路由系统选择的支付渠道，有些会用到大额、小额支付系统，需要验证开户行信息等，而目前大多数绑卡流程中是不会验证开户行信息
返回这些错误码即代表支付失败，用户验证完成之后，需重新发起支付请求，是否还需要完成风控要求的验证条件，待与风控沟通。
场景分析以及影响因素
线下场景：C扫B、付款码
线上内部终端
这个通常来说用户会是看到一件商品，对确认购买中间，中间省略很多。最后发起支付，所有前面的工作都是为了完成交易，所以先上支付的时候，你会发现遇到一些错误操作，你决定放弃的时候，会反复和用户确认，真的要放弃支付吗？
1.用户发起支付即代表有支付意愿，响应速度需要快速，并需要给出发起支付到调起支付服务的过程－增加lording
2.明确支付信息，订单信息、支付金额、账户、优惠信息、付款方式，避免然用户重复的选择，选择及以为着需要用户思考，思考即意味着降低那部分冲动消费的用户转化率－明确付款方式、优惠券的规则及各种状态
3.增加在用户遇到问题的时候对应的解决方法，主要归类为风控验证报错、支付渠道报错、支付系统问题，网络问题
风控验证报错如：支付密码验证失败，给予用户重新输入的机会，找回密码的入口
支付渠道报错如：银行返回CVV2码验证失败，让用户进行CVV2验证并重新发起支付再或者，银行卡余额不足，给予用户明确的指示，需要更换其它付款方式
系统问题：如XXX系统出现问题，请稍候再试
网络问题：如弱网情况下，停留在当前页给用户，再次操作的机会
4.一些用户的操作失误导致用户想放弃支付，增加用户的放弃支付的操作以及思考
例如：用户指纹支付验证失败3次，给出用户选择，输入密码，或者取消，用户点击取消之后，再次与用户确认，是否真的要退出支付。
线上外部终端
当外部终端调用支付服务时，增加用户标识
例如：需提示用户他使用的是本公司账户进行支付，试想一下，用户沉浸在XX的购物体验中，发起支付的时候，不知道我的钱是从哪里付出去的，会然用户产生疑问。
另一点，支付完成之后，告知外部终端结果，然外部定义后续的交易状态如何展示，这里涉及到通讯问题。
用户任务梳理
发起支付请求：
1.发起支付请求状态
2.正在发起支付请求状态
3.支付请求失败状态
4.弱网状态
5.无网状态
选择付款方式：
1.添加新的银行卡
2.选择其它可用付款方式
3.支付渠道返回报错后，引导用户更换付款方式，需排除掉已错误的付款方式
4.不可用状态包括
－余额不足（支付账户、理财账户、信用账户）
－银行卡限额问题（单笔银行限额与风控单笔限额取低值）
－订单不支持的付款方式（由于订单的限制，如信用账户还款，不可用信用卡）
－账户状态异常
优惠信息：
1.选择其它优惠券（默认选择最优惠的券，可更改）
2.将该业务无法满足优惠券限制的优惠券灰色显示，不可选择
风控要求验证信息：
－验证支付密码
1.输入支付密码
2.忘记支付密码
3.重新输入支付密码
4.支付账户被锁定
－验证指纹
1.验证指纹
2.三次验证失败，引导用支付密码替代
－第三方支付短信验证码
1.获取短信验证码
2.输入短信验证码
3.验证短信验证码
－人脸识别验证（暂时未上线）
－当前交易涉及到高风险交易
提交支付状态：
1.完成验证条件即提交支付
2.正在提交支付
3.返回结果
4.弱网状态下提交返回
5.无网状态下无法提交
支付渠道返回结果给出指示：
1.银行卡余额不足－更换付款方式，或放弃支付
2.预留手机号有误－更换付款方式，或放弃支付
3.银行卡超过当日限额－更换付款方式，或放弃支付
4.银行返回CVV2码有误－验证CVV2码，验证完成，重新发起支付，回退可更换付款方式
5.银行返回银行卡有效期有误－验证银行卡有效期，验证完成，重新发起支付，回退可更换付款方式
6.银行返回开户行信息有误－验证开户行信息，验证完成，重新发起支付，回退可更换付款方式
支付结果：
1.未完成支付（包含用户主动放弃支付－前往业务传参URL
2.支付成功－前往业务传参URL／显示内置交易状态页
支付成功记录账单
关键因素
关注商品>用户理解商品>接受商品>保持对产品关注>确定购买
在用户发起支付之前，用户大致会有这几个步骤，每一步转化都会有衰减，所以整个支付的体验，关键就在于：（不要让用户有太多的思考，快速且高效的完成支付，给用户一条明确路，整个设计围绕着让用户完成支付任务，甚至给用户做出放弃支付操作时候，增加障碍，参考了支付宝）
在支付过程中，对于用户操作失误的情况，给于用户明确的其它路径，提高统一支付的转化率，遇到的关键点有（银行卡余额不足、指纹支付有误、支付密码有误、银行卡预留手机号有误、CVV2码验证、信用卡有效期）
增加提交支付－支付返回结果的过场动画，提交支付之后，会有1～2秒的时间，等到结果，从这一点而言，微信没有支付做的好。所以参考支付宝，另外结合产品定位，公司产品就是一个支付工具，将支付结果包在支付服务中，是为了更好的被业务端调用。
统一支付流程图
根据以下增加交易接入方请求时带入参数
（1）付款方式
情况A：交易接入方带入支付方式，发起支付之后不可更改
情况B：交易接入方不带入支付方式，发起支付之后，（排除业务不支持支付方式、账户异常、银行卡限额不支持、余额不足仅针对支付账户、信用账户、理财账户）
（2）优惠券信息
情况A：交易接入方不支持优惠信息，发起支付后不显示优惠券
情况B：交易接入方已选择优惠券，发起支付后上送优惠券，支付金额＝订单金额－优惠券，优惠券信息不显示
情况C：交易接入方不上送优惠券，发起支付后，查询优惠券信息，默认选择最匹配的优惠券，可更改
情况D：如无可用优惠券，显示字段“暂无可有优惠券”
（3）付款详情
有些业务确认订单已经选好相关支付信息，且场景需要用户快速完成支付，付款详情可不显示，（AB测试，根据数据后续再优化）
（4）是否为外部订单
情况A：外部订单需传入外部订单号、商户号，显示用户标识
情况B：内部订单，不显示用户标识，因为本身都是在钱包内
（5）支付完成／未完成的回调URL
情况A：该交易本身有业务订单待支付状态，回调未支付URL应该是订单详情，因为已创建了业务订单
情况B：该交易本身无业务订单待支付状态，回调已支付URL展示交易后续状态
情况C：该交易本身无业务订单待支付状态，有些业务不需要展示后续交易状态，回调已支付URL可直接前往发起支付的地方，因为支付本身已告知用户支付结果
（6）内置交易状态页
情况A：发起支付时候传参调用内部交易状态页，包含基础字段，1：支付方式 2：支付金额 3：支付状态 4：订单信息 ，建议业务定制，不要调用
情况B：支付完成之后，交易接入方无响应，调用内置交易状态页
情况C：发起支付时候传参不需要调用内部交易状态页，支付完成／未完成，回调业务传入的URL
