引言
本篇是本次支付系列的一个终篇，是博主就目前的支付经验一个总结，如果后期博主能有幸接触到大型支付公司的架构和有更深层次的理解，可能会继续更新本系列。
1、银行卡签约
1.1、支付通道优先级
第三方支付平台稳定性参差不齐，稳定点的价格会贵点，便宜的可能会有各种意想不到的坑等着你，傲娇点的支付通道会要求最低交易量。设置支付通道的优先级，就是在支付通道关闭后，系统自动的切换备选支付通道。
1.2、银行卡签约次数
第三方支付平台的收费标准是签约成功一次就收费一次，同一张银行卡同一个支付通道的也要收费。因此，系统必须判断客户一张银行卡只需签约一次。
1.3、银行卡签约日志
客户什么样的人都有，有的客户银行卡签约的时候用的建行的卡，确认的时候换成了交行的卡，然后投诉说银行卡签约始终有问题，这时候日志的作用就体现出来了。
2、支付
2.1、请求接口
支付接口需要预防客户表单重复提交，保证接口的幂等性，并发加锁处理，同时支付的参数需要进行安全校验。
2.2、请求超时
支付请求提交给第三方支付后，可能由于网络原因，对方没有接收到，请求超时；可能是对方收到了，响应的时候，网络异常了。此时，不应该随便的选择重试机制，应该采取保守的策略，因为无法知道订单的处理状态，可以将订单置为处理中，后面利用同步查询接口，对该笔订单进行查询。
2.3、返回状态码
支付成功的结果是比较好判断的，支付失败的结果原因很多，遇到不确定的状态码，一定要多向第三方支付多求证，系统业务层面对状态码只能一一比对，禁止使用else。
2.4、异步通知
异步通知接口需要校验通知的IP是否是对应第三方支付、通知金额是否是订单的金额，报文的安全性，避免以及接口的幂等性。
2.5、同步查询
支付的结果一般是以异步回调通知为准，但是由于网络原因或者其它异常原因，导致异步通知失败，此时需要进行同步查询，同步查询一般以定时任务方式，请求的间隔时间需要询问第三方支付，每个支付通道的时间会有差异，不能过早的查询，避免对方还没来得及处理，返回“交易不存在”，导致我们将系统订单的支付状态错误的处理，造成金额的损失。同时，对于“交易不存在”的状态，我们一定要谨慎的处理，最好的方法是预警，通知人工处理。
2.6、支付日志
支付日志很重要！ 支付日志一定要记录原始的报文、请求的参数、相应的结果、耗时等信息，因为这是排查错误的有效方式、与第三方支付交流的凭证。
3、对账
对账一般是第二日对前一个交易日资金的结算，包括各个支付通道之间的应收和应付的汇总，对账最好细分到具体的订单 ，如果账有差异的时候，方便排查问题。
4、监控
监控常见的是运维层面的，支付交易的要求更为严格，需要业务层面的监控，比如：远程资金是否充足。更为严格的应该对支付通道的稳定性、用户的交易是否异常进行监控，发现异常邮件通知相关人员。
5、测试
测试是重要的一个环节，所有的场景必须在测试环境下进行模拟一遍，不同的银行卡、资金等都要走一遍流程；线上的环境中，必须至少要走一笔完整的流程，遇到项目更新内容比较多时，一定要限制用户流量，待确定支付稳定可用后，再分批放开所有的用户，防止灾难性的后果。
结束语
支付的坑不限于文中描述的这些内容，上面是需要十分注意的坑，在支付系统开发中，一定要保持谨慎的态度，保持保守的操作，要保证要异常回滚，补偿等机制，支付的总结就到这了，希望本文能够对大家有所帮助。
微信扫码，关注一位有故事的程序员。关注后（回复：1024），领取海量Java架构进阶资料。