0到1只是告诫自己才刚开始上路呢
今年的开发重心放在商城支付上。参与需求与表结构设计，独立负责支付服务接口的开发。之前没有支付相关开发经验。历史原因，公司的开发同事无一有相关经验。现在回想当时真胆大，主动提出做相关开发。
胆大可以，盲目胆大不可以，闭门造车不可取。因此在网上参考了很多支付开发的相关资料，推荐一个我比较中意的博客
凤凰牌老熊 http://blog.lixf.cn/
下面分享下在开发中攒的一些微小的经验
设计要点
支付网关：对外提供支付服务的统一接口，安全校验、接口安全比如熔断、限流与隔离等
支付渠道：通过网关分发到对应的支付渠道模块
花生壳 OR ngrok
支付回调需要提供外网可访问地址，为了在调试时不影响复杂的部署成本，一般会通过工具实现外网能访问本机。
比较常用的工具有花生壳和ngrok
我用的是开源的改良版ngrok
Github地址 minlia-cross https://github.com/minlia-projects/minlia-cross
依赖下maven 启动就能使用 简单方便 还可以设置二级域名
感谢作者提供这么好的东东
扫码支付流程设计
特别提一下扫码支付，对接到支付宝支付时才发现扫码支付不返回前端的同步通知
这就比较尴尬了，前端开发人员就不能判别用户何时支付。一种方法就是在一定时间内的不停的请求后端服务器获取支付状态信息。显而易见，性能是个隐患。
我们采用的方法类似于12306的支付操作，通过用户点击操作告之前端向服务器获取支付状态。
风控
要不要做？要！
怎么做？
随着业务的发展与产品的成熟风控安全不断加强。单打独斗能力有限，还需要与其他部门的配合，如基于大数据的风险控制。更专业的会成立风控团队。
对接支付遇到的坑
不提名字的话这个坑就白说了 O(∩_∩)O
我只提下我比较不能容忍的
先提一下 要有一个懂相关业务的产品经理啊 至少是负责的，不然还得跟他一起沟通需求，对接中突然出现各种资料缺失很影响开发效率的！！ 血的经验！
通联支付（第三方综合支付） 只回调支付成功信息，支付失败不返回。。查单也只能查询支付成功的信息（大坑啊）还有在支付提交时间要按他的时间规则保存好，是退款接口重要请求参数
支付宝支付
- 沙箱环境回调不起作用，生产环境就没问题（原因未知。可能人品不好，无奈）
- 支付宝的蚂蚁金服开发平台提供的文档一般都很详细，足够使用了。如果你确实遇见不能解决的对接问题会有个机器答疑 当然只能回答比较小白的问题。如果确实需要人工帮助，可以持续”骚扰“窗口 后面会弹出专门的技术人员提供帮助（嘚瑟.jpg）get小技能
微信支付
- 对比支付宝提供的开发文档，微信的无力吐槽。准备对接微信支付的开发人员做好心理准备
- 因为业务原因，一个订单可以支持多次支付。出现微信回调支付成功信息延迟返回（延迟达到7分钟之久）导致用户继续支付多笔，导致溢额。目前就微信出现这一种情况。
解决方法，只能后期人工对账干预
建行电子支付
- 不提供测试环境（能一把过的大神可以无视我了）对于直连银行支付，技术不是难点，关键就是沟通，对于你懂得的规整制度。。。选择性搭理你。所以建议预留好充足的时间直连对接各大行
- 支付的服务器回调地址是在商户管理后台设置的，没有测试环境就意味着上完正式后就不能改了不然影响线上支付。。
- 建行的退款。。。
招商分期支付
…后面在慢慢补坑
填坑
每笔支付的请求参数报文与返回参数报文都要记录下来，很有用处的！！
- 本文标题： 支付服务开发从0到1
- 文章作者： sherryriver（木木三可）
- 发布时间： 2017.10.23
- 本文链接： https://sherryriver.github.io/2017/10/23/支付开发从0到1/
- 许可协议： "署名-非商用-相同方式共享 4.0" 转载请保留原文链接及作者。