本文主要是从支付架构、支付流程分析、支付核心逻辑、支付基础服务、支付安全五个方面来详细讲述支付系统架构
（1）、架构的定义：架构一定是基于业务功能来展开的，主要是制定技术规范、框架，指导系统落地；好的架构是需要不断演变和进化而来的。
（2）、架构需要关注的基础核心点主要是：安全、稳定、可扩展。
（3）、构建架构时需要关注的点：目标客户是谁、主要场景有哪些、流程是怎样的、模型、职责有哪些、边界在哪里以及设计。其中比较难以理解的点是困难及模型这两块。
（4）、架构与业务需求的关系：架构的产生来自于业务需求，业务需求进一步抽象形成架构，架构指导后续研发，研发最终成果解决业务需求的问题。整体是一个正向循环的关系。
一、支付架构
二、支付流程分析
第一步：用户选择支付渠道，进入商户客户端；
第二步：商户客户端发送支付要素，到商户服务端；
第三步：商户服务端发起支付请求到渠道（个别渠道如支付宝是不需要此步骤）；
第四步：渠道返回支付凭证到商户服务端；
第五步：商户服务端返回支付凭证到商户客户端；
第六步：用户调用支付宝控件完成支付。
第七步：一般渠道是采用异步通知方法来通知商户，但是有些企业是在第六步支付完成之后，在C端会同步通知支付成功。如果以此结果来判断支付是否成功，其实是不严谨会出问题的，应当调用渠道的支付接口来进行核查，然后以渠道返回的结果为准。
在日常工作中，许多企业在选择第四方服务商或者渠道的时候，会着重关注「并发」这个点，认为并发量需要达到上万级才可以满足日常需求，但实际上这个量级非常大，其实并没有必要的。
若直接对接渠道可能会遇到的问题：
（1）、接口文档升级、变更能及时得到通知；
（2）、有些业务没有异步通知；
（3）、同一业务在不同渠道表现不一样；
（4）、各种渠道的各自异常。
商户的要求：
（1）、清晰的 API 、SDK 文档；
（2）、安全；
（3）、所有应用接口统一标准的异步通知；
（4）、保证出口 IP 稳定（安全）。
在系统架构设计时需要注意的一些要点：
（1）、提供规范的 API、SDK；
（2）、安全（通讯安全、数据安全）；
（3）、稳定；
（4）、异步通知统一；
（5）、各渠道的异常；
（6）、及时了解渠道接口调整。
三、支付核心逻辑
这里讲一下，支付成功之后，我们会把订单信息同步到财务系统，在账务系统里我们设计了诸如转账、汇款等功能，在前期设计时会设计好账务的生成规则，例如；一笔支付的请求会生成多笔账务，对其字段进行区分，这样方便管理和维护。
3.1、支付网关
此处特指API网关，支付网关的功能：
限流最好不要放到业务流程中做，会影响用户的体验。
支付网关的内容：
（1）、唯一的请求入口；
（2）、统一的身份认证、签名、加解密、流控；
（3）、API 调用计费；
（4）、API 的监控、报警分析；
（5）、API 发布管理；
（6）、熔断；
（7）、API 聚合；
（8）、协议转换；
上述内容除了必要意外，其他不放在业务层做，也是为了更好的用户体验。
3.2、支付逻辑
主要是根据请求的参数进行静态检验和业务逻辑校验，避免系统异常。
（1）、适配渠道的参数校验：长度、类型、格式；
（2）、订单的支付状态：是否支付；
（3）、订单的有效期等等。
要点：
一般商户是不需要做支付路由，大部分都是指定了最终的某个支付渠道。
但也有些没有指定了某个最终的渠道，比如银行卡的支付可以选择哪个第三方支付来完成支付，还有微信线上线下的封装，这个时候就涉及到支付路由规则配置。
支付路由规则配置：
（1）、费率：单笔费率、总额费率、阶梯费率；
（2）、营销活动：固定时间单笔优惠、单笔满减、单笔这款、直接补贴；
（3）、额度限制：单笔额度、时间范围内总额度；
（4）、服务指标：失败率、平均响应时间、异常率、TPS；
（5）、特殊配置：特殊要求（比如某渠道能快速结算）。
3.3、支付风控
要点：梳理清楚业务风险，分析风险原因，制定风险防范规则。
（1）数据来源
内部数据：
（1）、用（商）户信息
（2）、交易数据
（3）、账户数据
（4）、黑名单
（5）、设备、位置信息
（6）、日志数据
外部数据：
（1）、第三方购买
（2）、央行征信
（3）、芝麻信用
（4）、合作数据
（2）风控流程
事前：
（1）、入网审核
（2）、风险评估
（3）、单笔限额设置
（4）、单日限额设置
（5）、频次设置
事中：
（1）、实时分析
（2）、多维度判断
（3）、拒绝
（4）、拦截 – 进一步验证– 人工介入
（5）、延迟操作（例如用户大额提现，需要时间段进行复核）
事后：
（1）、数据分析
（2）、巡查、警告
（3）、降低评级
（4）、升级防范措施
（5）、逻辑完善
（6）、反馈至事前、事中规则中
3.4、账务系统
（1）、账务生成
（2）、内部对账
（3）、原始账单下载
（4）、生成标准账单
（5）、对账
（6）、差错处理
账务生成后首先进行内部对账，后进行原始账单下载，再生成标准账单，进行对账之后进行差错处理。
内部流程如图：
订阅交易信息；
根据交易事件查询生成账务的规则。
交易事件：支付、退款、转账等等。
（1）、根据规则生成账务明细；
（2）、将账务明细落地。
对账流程：
内部对账：
（1）、保证账务和交易信息配对
（2）、一条交易信息有多条账务信息
渠道账单下载：
（1）、下载；
（2）、账单标准化（对账字段统一）；
（3）、落地标准化账单。
对账：
（1）、账务和标准账单对账双向对账；
（2）、差错处理。
对账部分：
（1）、获取核对文件；
（2）、以账务系统为准来逐笔比对（以某个字段为准进行比对）；
（3）、数据一致标记成功，数据不一致标记差错。
反向操作：
（1）、以渠道账单为准来逐笔比对；
（2）、数据一致标记成功，数据不一致标记差错。
账单下载：
这里提一句，在做异常处理这部分工作时，有的研发朋友写代码时遇到过类似的问题，例如：订单在周末下单，但账单周一才能查询；等到周一时发现查询不到，选择立即重试 + X 分钟后重试就结束了。
这样是不行的，因为银行有的是 8 点之后可以查询到，有的是 9 点之后，所以要选择递增时间重试，然后标记人工处理。
3.5、差错处理
（1）、本地丢失：渠道账单的数据未在账务中查找到。
（2）、渠道丢失：账务中的数据未在渠道账单中查找到。
（3）、数据差错：账务与渠道某些对账字段未能对上。
此处需要注意的是，针对差错都需要向渠道查询每笔订单信息再次确认，同时，有些渠道的交易成功时间本来就是有错误的。一般来说是件不会差错很大，一般出现在跨日交易中，例如：当天交易无账单，先标记为差错，第二天再改正。
四、支付基础服务
（1）、Webhook
（2）、公共推送服务
（3）、主动查询
（4）、补偿
（5）、链路监控
4.1、Webhook
4.2、公共推送服务
异步延时调用
场景：
（1）、订单创建成功的时候会向服务推送主动查询信息，如果订单支付成功会通知服务取消后续的主动查询，否则在过期时间点向渠道主动查询订单是否支付目的是避免渠道异步通知服务的异常。
（2）、退款创建成功的时候会向服务推送主动查询信息，该服务会在一定的时间范围内多次查询渠道直到有明确的结果返回（有些渠道没有异步通知）。
（3）、转账也是类似的逻辑，但某些渠道只提供重试的功能，要注意幂等性。
补偿：
（1）、协调保证各模块间数据的一致性；
（2）、一般会跟重试、回滚、兜底来协调使用；
（3）、使用条件：系统异常、业务异常；
（4）、补偿失败报警人工干预。
4.3、链路监控
展示信息：应用、URL、调用方、调用时间、调用次数、调用失败次数、本地平均耗时、总平均耗时、调用失败平均耗时 、错误率、依赖度。
关注：Cache、SQL、HTTP、TCP
基本信息：
依赖度：
五、支付安全
5.1、数据安全
（1）、防窃听、防越权防抵赖、防破坏、防篡改、防重放、防泄漏。
（2）、使用范围：网络、系统、应用、业务等。
5.2、数据安全要点
（1）、加密通讯（防窃听）
（2）、双向签名（防抵赖、防篡改）
（3）、敏感数据加密存储（防泄漏）
（4）、密钥管理（通过认证接口获取，只允许加载到内存，不允许直接写入配置文件）
（5）、权限控制（防越权-非法访问）
（6）、数据的完整性（放篡改- 数据被恶意修改、非法篡改）
5.3、其他
（1）、内部接口认证。
（2）、避免内部代码未经审核发布到托管平台！！！
（3）、数据异常分析。
（4）、安全机构合作。
5.4、注意点
（1）、使用 HTTPS 加密传输；
（2）、传输的数据使用签名；
（3）、提交的数据是符合规则并且是不存在或者是未支付的；
（4）、支付成功以服务端异步通知为准。
