第三方支付相关知识结构

 

1、综述

作者：梁川
链接：https://www.zhihu.com/question/54247561/answer/138579226

技术内容：
1、事务处理：包括关系数据库的ACID、分布式事务（2阶段、3阶段、TCC、补偿性事务、可靠事件、Sagas长事务等）。先结合Spring AOP之类框架，把数据库事务处理机制深入研究一下。
2、服务化及服务化治理：交易导向系统一般都较为复杂，一般主流平台构建都采用SoA或类SoA架构，服务化及服务化治理成为关键，由此引申出消息中间件、zookeeper、redis、dubbo、spring boot、spring cloud等之类框架及技术
3、差错处理机制：由于偏互联网化的第三方支付、交易系统，系统间接口调用存在诸多的不稳定因素，例如支付结果通知时候，或者网络中断、或者对端服务器down掉等，导致结果通知未收到，最终影响对账、支付确认。因此整个系统的异常处理机制、补偿机制极为重要（例如异步通知、补单、主动查询）
4、安全：包括安全编码规范及习惯，避免SQL注入、各种Web安全漏洞攻击等常见攻击手段；各种数据加密算法及安全体系，例如PKI体系、TLS/SSL；
5、网络通讯及可靠接口调用设计
6、数据库性能及扩展性：交易系统一些关键表可能很难通过常用的NOSQL缓存、分库、分表、分库等机制来扩展，可能成为整个系统的性能瓶颈，例如账户表。良好的数据库表设计能力、SQL调优常识至关重要
以上内容，并非说偏内容导向的程序员不需要关注，交易导向的系统更需要强调这些，作为程序员，第一步先夯实以上技术基础。

与偏内容导向的程序员不同，第三方支付等交易系统一般还涉及较多的业务常识，包括：
1、会计学基础知识：账户系统是第三方支付的核心，而账户系统的原理来源于会计学原理
2、金融基础知识：包括银行、基金、保险、信托等的知识
3、电子商务知识
4、第三方支付的知识

以上业务常识，涉及面很广，不可能一下全了解，可以根据公司业务及个人方向来重点了解相关领域的业务常识。
可以说，只有真正了解业务，才可能设计、开发出好的系统。程序员一定要技术能力+业务能力并重，由此延展开还包括产品能力。虽然是技术，但一定要有意识培养自己的产品规划、产品设计、产品管理、产品运营的意识和能力，产品能力本身与技术设计和架构能力是相通的。

市面上关于第三方支付的图书较少，有几类偏技术的文档值得推荐：
1、强烈建议可以仔细研读一下一些第三方支付公司的商户接入接口规范文档，一方面了解业务，更重要的是学习好的接口设计及差错处理机制；
2、第三方支付申请牌照的认证规范，基本上涵盖了一个支付系统的技术规范、业务规范，很值得好好研读
3、银联相关的规范文档、接口文档，基本上涵盖了POS收单、清结算等的相关知识，比较成体系

 

资源：

支付大讲堂  http://wenku.baidu.com/link?url=f3B2CcmgR_piOfqKKDUGTI43L7CHzPsUcJC2vW71tFA53udM-xX3uWVeShMoST0wZ49vO_7Cu8T-E_Qohu5CPzBqkWcdppkw9HUZje0f1Ta

支付大讲堂---中国支付清算协会培训课程精选系列  中国金融出版社出版

人人都是产品经理  http://www.woshipm.com/

 

2、如何设计一个完整的订单系统

转：https://www.zhihu.com/question/54662446

 

作者：梁川
链接：https://www.zhihu.com/question/54662446/answer/140793441
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

说一下一些关键设计点供参考。
以下设计点，可以归为 "幂等设计"、"CQRS/Event Sourcing"、补偿机制等一些设计原则的体现。
1、请求/响应方都要维护自己平台的请求号/响应号，并保证请求号/响应号的唯一性。
设计上不能假定对方能够保证唯一性，应当保证请求方的序号+响应方的序号是唯一的。

2、原始请求/响应报文的所有内容都要本地持久化存储，便于请求/响应的过程回溯，有助于审计、排查、定位问题。

3、对订单状态定义要遵循MECE(Mutually Exclusive Collectively Exhaustive)原则，同时对状态机的迁移要做完整记录

4、消息同步返回+异步通知+主动查询结合 的补偿机制
由于互联网通信的不可靠性，例如双方网络、服务器、应用等因素的影响，不管是同步返回、异步通知、主动查询报文都可能出现超时无响应、报文丢失等情况，所以像支付业务，对结果的通知一般采用几种方案结合的补偿机制，不能完全依赖某一种机制。
例如一个支付结果的通知，一方面会在支付页面跳转时候返回支付结果（一般只用作前端展示使用，非最终状态），同时会采用后台异步通知机制（有前台、后台通知的，以后台异步通知结果为准），但由于前台跳转、后台结果通知都可能失效，因此还以定时补单+请求方主动查询接口作为辅助手段。
常见的补单操作，任务调度策略一般设定30秒、60秒、3分钟、6分钟、10分钟调度多次（以自己业务需要），如果调度接收到响应确认报文，补单成功，则中止对应订单的调度任务；如果超过补单上限次数，则停止补单，避免无谓的资源浪费。请求端随时可以发起请求报文查询对应订单的状态。

5、对重复报文的判重机制，这对诸如支付、代付等场景至关重要，避免出现重复支付、重复付款。

6、采用不同的事务处理机制（按照支付宝的说法叫柔性事务）来满足不同的业务场景需求。例如对支付账户余额更新，采用标准的ACID事务（两阶段、三阶段）；对虚拟账户账户的会计分录采用补偿型事务（异步确保型）；对支付结果通知，采用补偿型事务机制（最大努力通知）；

 

3、总结

技术方面主要可以借鉴淘宝相关的分享，包括SOA、事务方面。业务方面可以银行、电信、淘宝相关的业务，大体上流程类同