1. 应用管理: 同时支持公司多个业务系统对接。
2. 商户管理: 支持商户入驻，商户需要向平台方提供相关的资料备案。
3. 渠道管理: 支持微信、支付宝、银联、京东支付等多种渠道。
4. 账户管理: 渠道账户管理，支持共享账户（个人商户）及自有账户。
5. 支付交易: 生成预支付订单、提供退款服务。
6. 对账管理: 实现支付系统的交易数据与第三方支付渠道交易明细的自动核对（通常T+1），确保交易数据的准确性和一致性。
7. 清算管理: 计算收款交易中商户的应收与支付系统收益。
8. 结算管理: 根据清算结果，将资金划拨至商户对应的资金帐户中。

1. 用户在商城选购商品并发起支付请求；
2. 商城将支付订单通过B2C网关收款接口传送至支付网关；
3. 用户选择网银支付及银行，支付平台将订单转送至指定银行网关界面；
4. 用户支付完成，银行处理结果并向平台返回处理结果；
5. 支付平台接收处理结果，落地处理并向商户返回结果；
6. 商城接收到支付公司返回结果，落地处理（更改订单状态）并通知用户。

1. 用户在商户平台发起退款申请，商户核实退款信息及申请；
2. 商户登录支付平台账户/或者通过支付公司提供的退款接口向支付平台发起退款；
3. 支付系统会对退款信息校验（退款订单对应的原订单是否支付成功？退款金额是否少于等于原订单金额？），校验商户账户余额是否充足等；校验不通过，则无法退款；
4. 支付系统在商户可用余额账户扣除金额，并将退款订单发送至银行，银行完成退款操作。注意：对于网关收款的订单退款，各银行要求不一，有些银行提供的退款接口要求原订单有效期在90或180天，有些银行不提供退款接口；针对超期或者不支持接口退款的订单，支付公司通过代付通道完成退款操作。

1. 支付系统内部间的对账，支付系统一般是分布式的，整个支付系统被拆分成了多个子系统，如交易系统、账户系统、会计系统、账户系统，每个子系统在处理各自的业务，系统间的对账，就是以上系统的核对，用于修正内部系统的数据不一致。
2. 支付系统与渠道的对账，这里的渠道泛指所有为支付系统提供代收付业务的渠道，如：第三方支付公司、银行、清算中心、网联、银联等。

1. 信息流勾对：即业务对账／交易对账，主要是就收单交易的支付信息与银行提供的信息流文件进行勾兑。信息流的勾地能发现支付系统与银行系统间的掉单、两边由于系统间的原因导致的同一笔交易支付金额不一致（可能性很小）或者支付状态不一致。信息流勾兑一般用来恢复掉单数据，可通过补单或者具体系统问题排查解决。
2. 资金流勾对：即资金对账，主要就收单交易的支付信息与银行提供的资金流信息进行勾兑。资金流的勾兑能发现支付系统在银行的帐户资金实际发生的变动与应该发生的变动的差异，比如长款（银行多结算给支付系统）和短款（银行少结算给支付系统）。

说了这么多，就出现来4个对账文件，支付系统信息流文件、支付系统资金流文件、银行信息流文件、银行资金流文件。业务对账（勾兑）就是支付系统的信息流文件与银行的信息流文件勾兑，资金对账即支付系统的资金流文件与银行的资金流文件勾兑。

• 支付系统信息流没有，而银行有的差异，可能是因为支付系统交易数据的丢失、银行的掉单，如果是银行的掉单，由支付公司的运营登录银行网银确认后，做补单处理，并将差异表中该记录核销。
• 支付系统信息流有，而银行没有的差异，此种情况一般不会发生，因为支付系统所有的交易数据都是取银行返回状态的数据。

2、资金流勾对对差异处理

• 支付系统资金流没有，而银行有的差异。可能原因如下：1、银行日切晚与支付系统核心账务系统；2、支付系统账务核心系统与其他系统间的掉单。一旦出现，则会出现长款（即银行不应该结算而实际结算）的现象，对于因日切导致的差异，在第二天的对账中系统会对平，其他原因的，需要技术排查。
• 支付系统资金流有，而银行没有的差异，可能是因为银行日切早于支付系统的核心账务系统，一旦出现，会出现短款（银行应结算而实际未结算）的现象，银行日切导致段差异，会在下一天与银行的勾对中，将此笔差异勾对上，如果是非日切导致的原因，就需要找银行追款了。

总结就是，业务对账，即信息流对账，支付系统的交易流水与银行的交易流水间核对，保障支付交易完整入账。资金对账，即资金流对账，支付系统的入账流水与银行的结算流水间核对，保障银行入账流水与实际入账资金的匹配。

• 所有的支付操作，都需要对输入执行参数校验，避免接口受到攻击。
• 验证输入参数中各字段的有效性验证，比如用户ID,商户ID,价格，返回地址等参数。
• 验证账户状态。交易主体、交易对手等账户的状态是处于可交易的状态。
• 验证订单：如果涉及到预单，还需要验证订单号的有效性，订单状态是未支付。为了避免用户缓存某个URL地址，还需要校验下单时间和支付时间是否超过预定的间隔。
• 验证签名。签名也是为了防止支付接口被伪造。 一般签名是使用分发给商户的key来对输入参数拼接成的字符串做MD5 Hash或者RSA加密，然后作为一个参数随其他参数一起提交到服务器端。

• 阻断交易，说明该交易是高风险的，需要终止，不执行第5个步骤；
• 增强验证，说明该交易有一定的风险，需要确认下是不是用户本人在操作。这可以通过发送短信验证码或者其他可以验证用户身份的方式来做校验，验证通过后，可以继续执行该交易。
• 放行交易，即本次交易是安全的，可以继续往下走。

• 在支付网关前置的主流程中，仅记录交易流水，即将当前的请求保存到数据库中。
• 完成数据记录后，发送MQ出来，记账、统计、分析，都是接收MQ来完成数据处理。
• 涉及到本地资金支付，比如钱包支付，会需要分布式事务处理，扣减账号余额，记账，扣减库存等，每个操作失败，都要回滚。阿里有很不错的分享，这里不详细描述。
• 当交易量上来后，需要考虑交易表的分表分库的事情。分表分库有两个策略，按照流水号或者交易主体id来走。后者可以支持按用户来获取交易记录。我们用的是前者。后者可以走elastic，确保数据库专用。风控，信用和统计所需要的数据，通过MQ同步到历史库里面。作为支付系统最有价值的数据，在存储上做到专库专用，无可厚非，毕竟存储成本还是廉价的。

1-5-10. 10 支付路由

支付路由是一个复杂的话题。对支付系统来说，能支持的支付方式越多越好，不能由于支付方式的不支持断了财路。现实中的支付方式多得难以置信。用户随时甩出一张你听都没听说过的卡。如果一个银行卡只有几个用户在用，那针对这个卡开发个对接有点得不尝失。现在第三方支付的爆发，确实给开发支付系统省了不少事。但是公司不可能只对接一个第三方支付，如果这个渠道出问题了，或者闹矛盾了，把链接给掐了，老板还不欲哭无泪。总之，得对接多个渠道。对于交易量大的银行，还得考虑直联。

1-5-11. 11 渠道接入

对于支付渠道，首先考虑的是接入哪些渠道。要对接的渠道按优先级有：

• 第三方支付，对大部分应用来说，支付宝和微信支付都是必须的，一般来说，这两者可以占到90%以上的交易量。用户不需要绑卡，授权后直接支付就行。各种平台都支持，性能和稳定性都不错。对于一些特殊业务，比如游戏，企业支付，可以查看一些专用的第三方支付平台。
• 银联，它的存在，极大方便了和银行的对接。和第三方支付主要不同在两个地方一是需要绑卡，也就是用户先把卡号，手机，身份证号提供出来。这一步会折损不少用户。绑卡后，以后的支付操作就简单了，用户只需要输入密码就行。手机客户端不需要像第三方支付那样安装SDK，都在服务器端完成。当然，这是针对快捷支付。网银支付还是挺麻烦的。银联接入也需要ADSS认证。
• 银行：2018年2月9日银监会公布了最新权威数字：一共【4549家】开发性金融机构1家：国家开发银行；政策性银行2家：进出口银行、农业发展银行；5大国有银行：工、建、农、中、交；邮储银行1家；全国性股份制商业银行12家：招行、中信、兴业、民生、浦发、光大、广发、华夏、平安、浙商、渤海、恒丰；金融资产管理公司4家：信达、华融、长城、东方四大AMC；城商行134家；住房储蓄银行1家；民营银行17家，如网商银行；农商行1262家；农村合作银行33家；农村信用社965家；村镇银行1562家；贷款公司13家；农村资金互助社48家；外资法人银行39家；信托公司68家；金融租赁公司69家；企业集团财务公司247家；汽车金融公司25家；消费金融公司22家；货币经纪公司5家；其他金融机构14家。一般对接一个银行预计有3周左右的工作量，大部分银行需要专线接入，费用和带宽有关，一年也得几万费用。不同银行对接入环境有不同要求，这也是成本。
• 手机支付：比如苹果的In-App支付， 三星支付、华为支付等， 这些支付仅针对特定的手机型号， 支持NFC等，根据业务需要也可以接入。

2. 总结

支付系统是一个繁杂的系统，其中涉及了各种错综复杂的业务流程，以上只是简单介绍了支付系统我们能看见的一些问题和设计，还有后续的系统保障没有写出来，没写出来的才是关键部分，比如：支付系统监控（业务监控分类、渠道监控、商户监控、账户监控）文章只是引子， 架构不是静态的，而是动态演化的。只有能够不断应对环境变化的系统，才是有生命力的系统。所以即使你掌握了以上所有的业务细节，仍然需要演化式思维，在设计的同时，借助反馈和进化的力量推动架构的持续演进。

[source]支付系统