前言
做支付一年多了，公司的支付平台刚搭建好进的公司，经历了从一开始的各处漏洞，到代码重构后系统稳定运行，再到功能的逐渐完善和易用性提升，最后到现在追求系统效率的提升，我也从当初对支付一脸懵逼的实习生到成为了解支付的各个方面能顺利解决各种问题的开发工程师，感触颇多。
在做的是一个典型的聚合支付平台，主要跟第三方支付公司（也有银行）交互。 开发语言是 PHP。可能大家印象中，支付作为一个重型业务，应该用 java 这种重型语言来开发。但在小型公司初期业务迅速扩展时期，跟得上业务的发展至关重要，PHP 作为敏捷开发的代表，自然在技术选型上有着很大的优势。可能跟业务量相关，平台目前在一个阿里云小机器上暂时没有效率压力，日处理二三百万交易没有问题。
本系列准备分三篇来介绍，支付相关的基本概念、支付系统的设计和我做支付时遇到的一些坑，可能会偏业务一些，也不往首页上放了，留给有缘人。
支付概念
支付是个概念性很强的领域，其业务方面有许多专业词汇，技术上也比其他业务要求要严格，毕竟牵涉到钱，这里先简单地介绍几个概念，便于后面文章理解。
聚合支付
聚合支付，聚合的是第三方支付公司（如支付宝、网银在线、快钱等，下简称三方公司）。
我们支付最终处理方都是银行，但银行并不是谁都有资质接入的，这就需要第三方支付公司。第三方支付公司对接多个银行通道，但业务参差不齐，商户若直接对接多个第三方支付公司成本也会很高。这时便需要聚合支付平台了，聚合支付平台对接多个商户，作为中间人角色，本身并无业务。但商户只需要对接到一个聚合支付平台便能方便地接入支付功能，目前市场上比较成功的聚合支付平台有 ping++、付钱拉等。
幂等性
幂等更多的是一个计算机概念，在计算机领域也有多种应用，如 HTTP 的 PUT 方法（也被应用于 RESTFUL API 的概念中）。特点是其任意多次执行所产生的影响均与一次执行的影响相同，也就是说一个动作，做多少次都不会影响到最终的结果，保持交易处理的幂等性在支付系统中特别重要。
支付通道
对支付平台来说，支付通道是指 一个三方支付公司分配的一个商户号，当然它也可以更细地划分，如添加卡类型、银行等维度，具体要考虑到支付路由系统的设计。
终态
终态，顾名思义，是最终的不会再改变的状态。相较于其他业务，支付系统对终态的定义要更清晰一些，它代表着一笔交易的最终状态，要么成功，要么失败，不会有其他状态。
异步
异步与同步对应，是指一个请求发出后，结果由回调或通知来处理。由于支付处理的复杂性和严密性，一笔交易往往无法在很短的时间内确认终态，而长时间的阻塞等待也是不可接受的，所以支付系统对异步特别依赖。
风控
风险控制，是识别异常交易并加以额外验证的模块，一般牵涉重要些的系统都会有。风控并不能完全避免资金损失，只能尽量减少损失。简单的包括频繁相同请求控制，时间段内交易金额限制等，复杂的会包括惯性分析，用户画像等。
风控的严密性和交易的安全性成正向相关，但同时也会影响系统流程的复杂性，越严密的风控必然会导致更长的流程，更差的用户体验，甚至会需要运营人员介入。
对账
对账严格来说并不是支付流程中不可缺少的步骤，它是一种确认和补救机制，它通过对比交易双方的记录汇总来发现支付问题。
虚拟账户
虚拟账户是一个很巧妙的设计，它是远程账户金额在本地的映射，只要保证在远程所有的支出和收入在本地有同样的记录，就能通过本地金额来确认远程账户的金额，这样就避免了频繁的账户金额查询操作。此设计一般被用在代付和退款业务中，这两种业务通常需要在支付发起方在支付受理方设立一个账户并充值维持其金额可用。
支付网关
支付网关是支付发起方与支付受理方的接口，通常有复杂的报文处理，如参数映射、参数强验证、加密、签名等。 支付网关中将三方公司的状态码映射为自己系统的状态码这一步骤是重中之重。
支付要素
指支持中起决定性的信息，一般为人信息或交易主体银行卡的信息。
- 二要素：姓名、身份证号；
- 三要素：姓名、身份证号、卡号；
- 四要素：姓名、身份证号、卡号、手机号；
- 六要素（信用卡）：姓名、身份证号、卡号、手机号、cvv2、expire_date；
数据设计
交易表的设计
交易表需要考虑多通道，在一条业务记录在一条支付通道交易时可能会失败，如果有重试机制的话，那么一条业务记录会对应多条三方公司的请求记录。另外一定要考虑扩展字段，后续会以此字段来缓冲字段的扩充。
用户和绑卡表
很多时候支付系统需要对支付要素进行验证，每次都去请求支付通道验证显然会造成浪费，那么我们需要对数据进行缓存。
为什么是缓存呢，因为这些支付要素都是有有效期限的，一个人会改名，卡会换绑定手机号，如果无脑使用以前的数据会造成一部分信息判断错误。设置合适的过期机制或重试机制才能使降低成本和提高准确率之间达成平衡。
日志数据库
日志在支付系统内有着非比寻常系统的重要性，它除了肩负着问题定位和分析，交易跟踪的重任，在与外部的接口处更有着请求凭证的作用，良好的日志管理系统可以帮助技术人员快速定位和解决问题，也能在与三方公司扯皮时准确扔出凭证，完善的日志系统也可以直接给运营使用，以此减轻开发人员的工作压力。
小结
之前曾多次想过总结一下，可总因为觉得沉淀不够而搁置下来，如今大胆写下来吧，有时间和机会的话，再慢慢修订。
可能一时考虑的并不全，也可能由于见识原因，所介绍的东西难免有遗漏，慢慢进步吧~
初稿：2017-03-20