支付系统架构：从零到一搭建一家支付公司

文章	评论	标签
180	0	297

写在前面

很多人以为支付系统就是"调个收单接口 + 记录一下订单"。

直到他们第一次遇到：凌晨三点的重复扣款告警、季度对账差了几百万找不到原因、监管来函要求提供完整的资金流水审计链……

支付公司的架构，是在合规压力、资金安全、高并发、极低容错四座大山之间走钢丝。少一块，轻则业务异常，重则牌照被吊。

这篇文章画出一家支付公司必须有的核心系统全景，每个系统讲清楚"它解决什么问题、为什么不能没有它"。

一、全景架构图

先看整体，再看细节。

graph TD subgraph 外部接入层 MERCHANT[商户系统] USER[C端用户] CHANNEL[外部支付渠道 Visa Mastercard Aani 等] REGULATOR[监管机构 CBUAE SAMA 等] end subgraph 网关层 API Gateway GW[统一支付网关 API Gateway] AUTH[认证鉴权 OAuth2 + HMAC] RATE[限流熔断 Rate Limiter] end subgraph 核心业务层 PAY[支付核心 Payment Engine] RISK[风控系统 Risk Engine] ROUTE[智能路由 Smart Router] WALLET[账户钱包 Wallet Service] LEDGER[会计账本 Ledger Engine] end subgraph 渠道接入层 CHANNEL_GW[渠道网关 Channel Gateway] RECONCILE[对账系统 Reconciliation] SETTLE[清结算系统 Settlement] end subgraph 合规风控层 AML[反洗钱 AML Engine] KYC[身份核验 KYC Service] SANCTION[制裁筛查 Sanction Screening] REPORT[监管报送 Regulatory Reporting] end subgraph 基础设施层 MQ[消息队列 Kafka] CACHE[缓存集群 Redis] DB[数据库集群 MySQL + TiDB] VAULT[密钥管理 HSM + Vault] end MERCHANT & USER --> GW GW --> AUTH --> RATE --> PAY PAY --> RISK PAY --> ROUTE PAY --> WALLET PAY --> LEDGER ROUTE --> CHANNEL_GW CHANNEL_GW --> CHANNEL CHANNEL_GW --> RECONCILE RECONCILE --> SETTLE PAY --> AML AML --> SANCTION WALLET --> KYC SETTLE --> REPORT REPORT --> REGULATOR PAY & WALLET & LEDGER --> MQ & CACHE & DB GW & PAY --> VAULT

二、核心系统逐一拆解

2.1 支付核心引擎（Payment Engine）⭐ 最重要

支付引擎是整个系统的心脏，所有支付指令在这里被创建、调度、执行和终结。

它解决的问题： 如何在分布式系统中保证一笔钱只被处理一次、状态不丢失、出错可回滚。

stateDiagram-v2 [*] --> CREATED : 商户发起支付 CREATED --> RISK_CHECK : 提交风控 RISK_CHECK --> REJECTED : 风控拦截 RISK_CHECK --> ROUTING : 风控通过 ROUTING --> PROCESSING : 路由选渠道，调用渠道API PROCESSING --> SUCCESS : 渠道返回成功 PROCESSING --> FAILED : 渠道返回失败 PROCESSING --> PENDING : 渠道超时，状态未知 PENDING --> SUCCESS : 主动轮询确认成功 PENDING --> FAILED : 轮询确认失败 PENDING --> REVERSED : 触发隐式撤销 SUCCESS --> REFUNDING : 发起退款 REFUNDING --> REFUNDED : 退款成功 REFUNDING --> REFUND_FAILED : 退款失败 REVERSED --> [*] REJECTED --> [*] REFUNDED --> [*] note right of PENDING PENDING 是最危险的状态钱可能已扣，也可能未扣必须有主动探查机制超时后触发 Implicit Reversal end note

支付引擎的三个核心设计原则：

幂等性是底线。每一笔支付请求必须携带唯一的幂等键（idempotency key），无论因网络重试被调用多少次，只处理一次，只产生一笔资金变动。

最终一致性是目标。支付涉及多个系统（风控、路由、账务、渠道），不追求强一致，但每笔交易必须在有限时间内达到确定状态，不允许永久 PENDING。

可补偿事务是保底。任何一步失败，都必须有对应的补偿动作——渠道已扣款但业务系统异常，则触发撤销；撤销失败则人工介入，但流程不能断。

2.2 会计账本（Ledger Engine）⭐ 最容易被忽视

账本不是数据库里几张表，它是整个公司的财务真相。

它解决的问题： 在任意时刻，系统内每一分钱在哪里、从哪来、到哪去，必须可以完整追溯。

graph LR subgraph 复式记账模型 TX[每笔交易] --> DR[借方 Debit 资金流出方] TX --> CR[贷方 Credit 资金流入方] DR -.->|金额相等| CR end subgraph 账户体系 A1[用户钱包账户] A2[商户结算账户] A3[手续费收入账户] A4[渠道待结算账户] A5[备付金账户] A6[风险准备金账户] end subgraph 一笔用户付款的账务流 E1["用户钱包 -100 AED 借：用户账户 100"] E2["渠道待结算 +100 AED 贷：待结算账户 97"] E3["手续费收入 +3 AED 贷：手续费账户 3"] end TX --> E1 & E2 & E3

账本的黄金法则：

永远不要直接 UPDATE 余额，只能 INSERT 流水记录，余额通过 SUM 计算得出。这听起来性能差，但它换来了完整的审计链——任何余额异常，都能追溯到每一笔流水的来源。

2.3 风控引擎（Risk Engine）⭐ 最复杂

风控是支付公司的免疫系统，它必须在毫秒级完成对每笔交易的判断。

flowchart LR TXN[交易请求] --> PRE[前置规则同步毫秒级] PRE --> R1[设备指纹是否异常设备] PRE --> R2[IP黑名单代理/VPN检测] PRE --> R3[账户状态是否冻结/限额] PRE --> R4[基础限额单笔/日累计] R1 & R2 & R3 & R4 --> SCORE[实时评分引擎规则+模型混合] SCORE --> S1[行为序列分析近30分钟交易模式] SCORE --> S2[设备关联图谱同设备多账户] SCORE --> S3[收款方风险历史拒付率] SCORE --> S4[ML模型打分异常概率0-100] S1 & S2 & S3 & S4 --> DECISION{综合决策} DECISION -->|低风险| PASS[放行] DECISION -->|中风险| REVIEW[人工审核队列] DECISION -->|高风险| BLOCK[直接拦截] PASS & REVIEW & BLOCK --> POST[异步后置分析特征回流模型更新]

风控引擎有一个永恒的矛盾：拦截率和误伤率。拦截太松，欺诈穿越；拦截太严，好用户被误杀，客诉飙升，GMV下跌。这个平衡点需要通过持续的数据反馈来调整，没有一劳永逸的策略。

2.4 智能路由（Smart Router）

路由决定的是：这笔钱走哪条路，才能以最低成本、最高成功率送达目的地。

graph TD REQ[支付请求] --> FILTER[硬过滤剔除不可用渠道] FILTER --> F1{渠道支持该支付方式?} FILTER --> F2{渠道当前是否熔断?} FILTER --> F3{渠道单日限额是否已满?} FILTER --> F4{渠道支持该币种?} F1 & F2 & F3 & F4 -->|全部通过| POOL[候选渠道池] POOL --> SCORE2[软评分排序] SCORE2 --> W1[成功率权重35% 近7日成功率] SCORE2 --> W2[成本权重40% 综合MDR费率] SCORE2 --> W3[延迟权重15% 平均响应时间] SCORE2 --> W4[容量权重10% 剩余配额比例] W1 & W2 & W3 & W4 --> SELECT[选取最优渠道] SELECT --> EXECUTE[发起支付] EXECUTE -->|失败| FALLBACK[降级到次优渠道] FALLBACK --> EXECUTE

2.5 账户钱包系统（Wallet Service）

钱包是用户资金的数字容器，它比普通余额表复杂得多。

钱包最怕的两件事： 超扣（余额变负）和重复入账（余额凭空多出来）。前者靠数据库乐观锁/悲观锁，后者靠幂等键。两者都靠严格的流水记录和定期余额校验。

2.6 对账系统（Reconciliation）⭐ 最容易被低估

对账是支付公司的体检报告。它每天回答一个问题：我们账本上的数字，和渠道实际结算的数字，是否一致？

flowchart TD subgraph 数据源 INTERNAL[内部账本流水每笔交易记录] CHANNEL_BILL[渠道账单文件 T+1 CSV/SFTP] end subgraph 对账流程 DOWNLOAD[自动下载渠道账单] --> PARSE[解析标准化统一字段映射] PARSE --> MATCH[逐笔撮合按渠道订单号匹配] MATCH --> CHECK{对账结果} end subgraph 差异分类 CHECK -->|金额一致| OK[平账正常] CHECK -->|内部有渠道无| TYPE1[长款可能是渠道漏记] CHECK -->|渠道有内部无| TYPE2[短款可能是回调丢失] CHECK -->|金额不一致| TYPE3[金额差异需人工核查] CHECK -->|手续费差异| TYPE4[费率差异合同Review] end subgraph 差异处理 TYPE1 --> ACTION1[向渠道确认追溯补记] TYPE2 --> ACTION2[查回调日志触发补单] TYPE3 --> ACTION3[人工审核上报财务] TYPE4 --> ACTION4[对比合同计入损益] end INTERNAL --> MATCH CHANNEL_BILL --> DOWNLOAD

对账的黄金指标： 对账平账率。一家成熟支付公司，日对账平账率应在 99.99% 以上。剩下的 0.01% 才是人工介入的部分。如果平账率低于 99.9%，说明系统有严重的稳定性或数据一致性问题。

2.7 清结算系统（Settlement）

清结算解决的是：钱在什么时候、按什么规则、打到谁的账户里。

sequenceDiagram participant RECON as 对账系统 participant SETTLE as 清结算系统 participant FEE as 手续费计算 participant BANK as 出款银行 participant MERCHANT as 商户账户 RECON->>SETTLE: 对账完成，触发结算 SETTLE->>SETTLE: 按结算周期汇总
T+1 或 T+3 或周结 SETTLE->>FEE: 计算应扣手续费 FEE-->>SETTLE: 返回净结算金额 SETTLE->>SETTLE: 生成结算指令 SETTLE->>BANK: 发起银行出款 BANK-->>SETTLE: 出款确认 SETTLE->>MERCHANT: 更新商户结算账户 SETTLE->>SETTLE: 生成结算报告 Note over SETTLE: 结算记录不可修改 Note over SETTLE: 每笔出款必须可追溯

2.8 合规四件套（AML + KYC + 制裁筛查 + 监管报送）

合规不是可选项，是牌照的生命线。

graph TD subgraph KYC["KYC 身份核验"] K1["文件核验护照 ID 驾照"] --> K2["活体检测 Liveness"] K2 --> K3["地址证明水电账单"] K3 --> K4["风险定级 Low Medium High"] end subgraph SANCTION["制裁筛查实时"] S1[OFAC SDN List] S2[UN Sanctions] S3[EU Consolidated] S4["本地监管黑名单如CBUAE名单"] S1 & S2 & S3 & S4 --> SCREEN{命中?} SCREEN -->|命中| FREEZE["冻结账户上报监管"] SCREEN -->|未命中| CLEAR[放行] end subgraph AML["AML 反洗钱监控"] T1["交易行为监控金额频率对手方"] T2["结构性交易识别化整为零 smurfing"] T3["跨境资金流向高风险国家预警"] T4["PEP识别政治敏感人士"] T1 & T2 & T3 & T4 --> SAR["可疑交易报告 SAR Filing"] end subgraph REPORT["监管报送"] R1["日报大额交易报告 CTR"] R2["月报业务数据统计"] R3["即时报可疑交易 SAR"] R4["年报审计财务报告"] end K4 --> T1 CLEAR --> T1 SAR --> R3

三、关键横切关注点

3.1 幂等性设计

幂等是支付系统的第一公民，任何对资金有影响的操作都必须幂等。

3.2 分布式事务策略

支付涉及多个服务，强一致分布式事务代价太高，生产中常用的是以下模式：

graph LR subgraph Saga 模式推荐 SA1[支付服务扣减余额] -->|成功| SA2[渠道服务发起扣款] SA2 -->|成功| SA3[账本服务记录流水] SA3 -->|失败| COMP3[补偿：冲销流水] SA2 -->|失败| COMP2[补偿：恢复余额] end subgraph 本地消息表兜底 LM1[业务操作 + 写消息表同一DB事务] --> LM2[消息轮询投递至少一次] LM2 --> LM3[消费方幂等处理] end

3.3 资金安全四道防线

graph TD LINE1[第一道：接入层防护防重放防篡改签名验证 TLS加密] LINE2[第二道：业务层防护幂等控制余额乐观锁限额校验] LINE3[第三道：账务层防护复式记账余额双向校验流水不可删改] LINE4[第四道：审计层防护操作日志全留存异常告警定期对账] LINE1 --> LINE2 --> LINE3 --> LINE4 style LINE1 fill:#3498db,color:#fff style LINE2 fill:#27ae60,color:#fff style LINE3 fill:#e67e22,color:#fff style LINE4 fill:#8e44ad,color:#fff

四、系统重要性总览

quadrantChart title "支付系统核心模块重要性与复杂度" x-axis "实现复杂度低" --> "实现复杂度高" y-axis "业务重要性低" --> "业务重要性高" quadrant-1 "优先投入核心壁垒" quadrant-2 "重要逐步完善" quadrant-3 "基础配套" quadrant-4 "技术挑战按需建设" "支付核心引擎": [0.75, 0.98] "会计账本": [0.60, 0.95] "对账系统": [0.65, 0.92] "合规体系": [0.80, 0.90] "风控引擎": [0.85, 0.88] "清结算系统": [0.70, 0.85] "账户钱包": [0.55, 0.80] "智能路由": [0.60, 0.70] "API网关": [0.40, 0.75] "监控告警": [0.35, 0.72] "消息队列": [0.30, 0.60] "密钥管理": [0.50, 0.82]

五、建设顺序建议

不是所有系统都要在 Day 1 建好，但有些东西拖不得：

timeline title 支付公司系统建设路线图 MVP 第1-3月 : 支付核心引擎（状态机+幂等） : 基础账本（流水记录+余额） : 单渠道接入 : 基础KYC接入 : API网关+签名验证合规就绪第4-6月 : AML引擎上线 : 制裁筛查实时化 : 监管报送系统 : 对账系统T+1自动化 : 密钥管理HSM 规模化第7-12月 : 智能路由多渠道 : 风控引擎规则+模型 : 清结算自动化 : 钱包账户体系 : 完整监控告警成熟期第2年起 : 实时对账 : ML风控模型迭代 : 多币种多市场扩张 : 自动化监管报送

六、写在最后：支付架构的本质

画了这么多图，最后说一句大白话：

支付系统架构的本质，是在"钱不能丢、钱不能多、钱不能慢、钱不能乱"这四个约束下，构建一套可以持续演进的工程体系。

graph LR A[钱不能丢幂等+账本+对账] --- B[钱不能多乐观锁+余额校验] B --- C[钱不能慢路由+缓存+异步] C --- D[钱不能乱状态机+事务+审计] D --- A A & B & C & D --> CENTER[用户信任] style CENTER fill:#e74c3c,color:#fff

技术可以迭代，架构可以演进，唯独用户信任，一旦丢失极难找回。

这是支付和其他软件系统最本质的区别：其他系统出 bug 是用户体验问题，支付系统出 bug 是真实的钱消失了。

本文为《从入门到放弃》系列技术架构篇，适合作为支付系统建设的 High-Level 路线图参考。