Arch Day 45: 支付架构全景 — 支付系统不只是"转钱"，是连接商业的基础设施

日期: 2026-05-14 (Day 45) 阶段: 第二阶段 - 金融域深度 标签: #支付系统 #四方模型 #支付全链路 #PCI-DSS #BIAN #资金流

---

核心概念

一句话定义

支付系统是连接资金供给方与需求方的基础设施，其本质不是"转钱"，而是通过信息流驱动资金流，在多方参与者之间完成价值转移、确认和记录的完整生命周期管理。

为什么资深架构师仍需关注

常见误区与反模式

---

知识点详解

知识点1：四方模型（Four-Party Model）深度解析

四方模型是银行卡支付的基础架构，理解它是理解整个支付体系的起点。

┌─────────────┐                         ┌─────────────┐
│   持卡人      │   ①刷卡/扫码/在线支付    │    商户      │
│ (Cardholder) │ ──────────────────────→ │  (Merchant)  │
│             │                         │             │
│  消费者/付款方 │                         │  收款方/卖家  │
└──────┬──────┘                         └──────┬──────┘
       │                                       │
       │ ③账单/还款                       ② 结算资金
       │                                       │
┌──────▼──────┐      ④清算/结算          ┌──────▼──────┐
│   发卡行      │ ◄──────────────────── │   收单行      │
│  (Issuer)    │                        │  (Acquirer)  │
│             │                         │             │
│ 持卡人的银行  │ ────────────────────→  │  商户的银行   │
└──────┬──────┘      ⑤资金划转          └──────┬──────┘
       │                                       │
       └────────────┐  ┌──────────────────────┘
                    │  │
              ┌─────▼──▼─────┐
              │   卡组织       │
              │(Card Network) │
              │  Visa/MC/银联  │
              │              │
              │ 制定规则/路由   │
              │ 清算/品牌管理   │
              └──────────────┘

各方角色与职责

三流分析：资金流、信息流、费用流

信息流（毫秒级）
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
持卡人 → POS/网关 → 收单行 → 卡组织 → 发卡行
                                        │
                        授权响应 ◄────────┘
                        (批准/拒绝/转介)

资金流（T+1 ~ T+3）
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
发卡行 → (扣持卡人账户)
       → 卡组织清算中心
       → 收单行
       → 商户结算账户

费用流
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
商户支付: 手续费 2.5%（举例）
  ├── 交换费(Interchange): 1.8% → 发卡行
  ├── 网络费(Scheme Fee):  0.2% → 卡组织
  └── 收单服务费:          0.5% → 收单行

知识点2：支付全链路生命周期

一笔完整的支付从发起到最终完成，经历收单→清算→结算→对账四个核心阶段。

graph LR
    A[收单<br/>Acquiring] --> B[清算<br/>Clearing]
    B --> C[结算<br/>Settlement]
    C --> D[对账<br/>Reconciliation]

    A1[交易发起<br/>授权请求<br/>风控拦截] --> A
    B1[交易汇总<br/>轧差计算<br/>手续费分配] --> B
    C1[资金划转<br/>账户入账<br/>到账通知] --> C
    D1[数据比对<br/>差异识别<br/>差错处理] --> D

各阶段详细说明

知识点3：支付类型全景分类

支付类型分类树
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
按时效性分
├── 即时支付 (Real-time): 扫码支付、NFC支付
├── 准实时 (Near real-time): 快捷支付、网银转账
├── 批量支付 (Batch): 工资代发、批量代扣
└── 定时支付 (Scheduled): 预约转账、自动还款

按方向分
├── 收款 (Collection/Pay-in): 商户收款、充值
├── 付款 (Payout/Pay-out): 提现、退款、分账出款
├── 转账 (Transfer): P2P转账、内部调拨
└── 代扣 (Direct Debit): 保险扣费、订阅服务

按场景分
├── 线上支付: 电商、App内支付
├── 线下支付: POS刷卡、扫码
├── 跨境支付: 外币交易、跨境汇款
├── B2B支付: 企业间结算、供应链金融
└── 政府支付: 社保、税收

按介质分
├── 银行卡: 借记卡、信用卡
├── 账户: 余额支付、钱包支付
├── 二维码: 主扫、被扫
├── NFC: Apple Pay、云闪付
└── 数字货币: DCEP、稳定币

知识点4：支付系统的核心质量属性

支付系统的质量属性优先级与普通互联网系统截然不同：

支付系统质量属性优先级
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

  正确性 >>>>>> 可用性 >>> 性能 >> 安全 > 可扩展
  (Correctness) (Availability) (Performance) (Security) (Scalability)

  "一笔扣错"的后果 > "系统宕机1小时"的后果

知识点5：支付牌照对架构的约束

支付不是纯技术问题，牌照和合规要求直接约束架构设计：

PCI-DSS对架构的具体约束
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

网络层:
├── 持卡人数据环境(CDE)必须独立网段
├── 防火墙规则严格管控进出流量
└── DMZ隔离外部接入

应用层:
├── 卡号(PAN)存储必须加密(AES-256)
├── CVV禁止存储（即用即丢）
├── 日志中不得出现完整卡号
└── 传输全链路TLS 1.2+

运营层:
├── 季度漏洞扫描
├── 年度渗透测试
├── 访问控制需要最小权限+MFA
└── 完整的审计日志保留1年+

知识点6：BIAN支付相关Service Domain映射

BIAN (Banking Industry Architecture Network) 定义了银行业标准服务域，支付相关的核心服务域如下：

BIAN 支付相关 Service Domain
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Payment Execution Domain
├── Payment Initiation (支付发起)
│   └── 接收、验证支付请求
├── Payment Order (支付指令)
│   └── 支付指令的创建和管理
├── Payment Execution (支付执行)
│   └── 资金划转的实际执行
└── Payment Clearing (支付清算)
    └── 机构间的清算处理

Supporting Domains
├── Card Transaction Switch (卡交易转接)
│   └── POS/ATM交易的路由和处理
├── ACH Fulfillment (ACH处理)
│   └── 批量支付的处理
├── Correspondent Banking (代理行)
│   └── 跨境支付的代理行管理
├── Currency Exchange (外汇)
│   └── 汇率管理和外币兑换
└── Fraud Evaluation (欺诈评估)
    └── 交易风险评估

---

对比分析

全球主要支付体系对比

支付系统 vs 普通交易系统

---

架构设计实操

设计目标

绘制支付全链路C4 Context图和Container图，清晰展示资金流和信息流的流转路径。

C4 Context图（系统上下文）

                    ┌─────────────────────────────────────────┐
                    │            外部参与方                      │
                    │                                         │
  ┌──────────┐     │  ┌──────────┐    ┌──────────┐          │
  │  商户     │────│─→│ 收单行    │    │  发卡行   │          │
  │(Merchant)│     │  │(Acquirer)│    │ (Issuer) │          │
  └──────────┘     │  └─────┬────┘    └────┬─────┘          │
       ↑            │        │              │                │
       │            │  ┌─────▼──────────────▼─────┐         │
  ┌────┴─────┐     │  │      卡组织/清算网络        │         │
  │ 消费者    │     │  │   (Card Network/银联)      │         │
  │(Consumer)│     │  └──────────────────────────┘         │
  └──────────┘     └─────────────────────────────────────────┘
                              ↕
           ┌──────────────────────────────────────┐
           │         支付平台 (Our System)          │
           │                                      │
           │  ┌────────┐  ┌────────┐  ┌────────┐ │
           │  │支付网关  │→│清结算   │→│ 对账    │ │
           │  │Gateway │  │Engine  │  │ Recon  │ │
           │  └────────┘  └────────┘  └────────┘ │
           │  ┌────────┐  ┌────────┐  ┌────────┐ │
           │  │风控引擎  │  │商户管理 │  │ 账务   │ │
           │  │RiskCtrl │  │MerchMgr│  │Account │ │
           │  └────────┘  └────────┘  └────────┘ │
           └──────────────────────────────────────┘

C4 Container图（支付平台内部）

┌─────────────────────────────────────────────────────────────────┐
│                      支付平台 Container 视图                      │
│                                                                 │
│  ┌───────────────────────────────────────────────────────────┐  │
│  │                    API Gateway Layer                       │  │
│  │  ┌──────────┐  ┌──────────┐  ┌──────────┐               │  │
│  │  │商户API   │  │ 内部API   │  │回调通知   │               │  │
│  │  │(REST)    │  │(gRPC)    │  │(Webhook) │               │  │
│  │  └─────┬────┘  └─────┬────┘  └──────────┘               │  │
│  └────────┼──────────────┼──────────────────────────────────┘  │
│           │              │                                      │
│  ┌────────▼──────────────▼──────────────────────────────────┐  │
│  │                  Business Layer                            │  │
│  │                                                           │  │
│  │  ┌──────────┐  ┌──────────┐  ┌──────────┐  ┌──────────┐│  │
│  │  │支付核心   │  │退款服务   │  │结算服务   │  │对账服务   ││  │
│  │  │PayCore   │  │Refund    │  │Settle    │  │Recon     ││  │
│  │  └─────┬────┘  └──────────┘  └──────────┘  └──────────┘│  │
│  │        │                                                  │  │
│  │  ┌─────▼────┐  ┌──────────┐  ┌──────────┐  ┌──────────┐│  │
│  │  │路由引擎   │  │风控引擎   │  │商户管理   │  │账务引擎   ││  │
│  │  │Router    │  │RiskCtrl  │  │MerchMgr  │  │Ledger    ││  │
│  │  └─────┬────┘  └──────────┘  └──────────┘  └──────────┘│  │
│  └────────┼─────────────────────────────────────────────────┘  │
│           │                                                      │
│  ┌────────▼─────────────────────────────────────────────────┐  │
│  │                  Channel Layer                             │  │
│  │  ┌──────────┐  ┌──────────┐  ┌──────────┐  ┌──────────┐│  │
│  │  │银联通道   │  │微信通道   │  │支付宝通道  │  │银行直连   ││  │
│  │  │UnionPay  │  │WeChat    │  │Alipay    │  │BankDirect││  │
│  │  └──────────┘  └──────────┘  └──────────┘  └──────────┘│  │
│  └──────────────────────────────────────────────────────────┘  │
│                                                                 │
│  ┌──────────────────────────────────────────────────────────┐  │
│  │                  Infrastructure Layer                      │  │
│  │  ┌──────────┐  ┌──────────┐  ┌──────────┐  ┌──────────┐│  │
│  │  │MySQL集群  │  │Redis集群  │  │MQ        │  │ES日志     ││  │
│  │  └──────────┘  └──────────┘  └──────────┘  └──────────┘│  │
│  └──────────────────────────────────────────────────────────┘  │
└─────────────────────────────────────────────────────────────────┘

ADR-045：支付系统分层架构决策

---

AI增强实践

AI在支付架构中的应用场景

AI增强的支付架构
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

1. 智能路由 (AI-Powered Routing)
   ├── 基于历史成功率的ML预测模型
   ├── 实时调整通道权重
   └── 考虑因素：通道成功率、费率、响应时间、限额剩余

2. 实时反欺诈 (Real-time Fraud Detection)
   ├── 行为特征提取：设备指纹、地理位置、交易模式
   ├── 在线推理：<50ms内完成风险评分
   └── 模型类型：XGBoost(线上) + 深度学习(离线分析)

3. 异常交易监控 (Anomaly Detection)
   ├── 时序异常检测：交易量突增/骤降
   ├── 自动告警和降级触发
   └── 根因分析辅助

4. 智能对账 (Intelligent Reconciliation)
   ├── 模糊匹配：处理通道字段差异
   ├── 自动分类差异原因
   └── 推荐平账方案

5. 商户风险评估 (Merchant Risk Scoring)
   ├── 进件审核自动化（OCR + NLP）
   ├── 交易行为风险评分
   └── 动态费率调整建议

AI辅助架构设计Prompt示例

Prompt: 我正在设计一个聚合支付系统的架构，需要支持以下场景：
1. 同时对接银联、微信、支付宝、银行直连4类通道
2. 支持扫码支付、快捷支付、网银支付3种方式
3. 峰值TPS 5000，日均交易100万笔
4. 要求PCI-DSS Level 2合规

请帮我：
- 识别核心架构决策点
- 推荐技术栈选型
- 画出C4 Container图
- 列出关键的质量属性场景(QAS)

---

与Web3/DeFi的关联

传统支付 vs DeFi支付的本质差异

Stripe → Web3的演进趋势

传统支付架构:
  商户 → 支付网关 → 收单行 → 卡组织 → 发卡行
  (每个环节都是一个独立公司，各收手续费)

Web3支付架构:
  用户 → DApp前端 → 智能合约 → 链上结算
  (中间环节被智能合约替代)

混合趋势(现在正在发生):
  商户 → Stripe/Circle → USDC → 链上结算 → 法币出金
  (稳定币作为桥梁，连接传统支付和链上结算)

对Web3 PM的启示

1. 支付的核心问题在DeFi中仍然存在：幂等性（链上nonce）、最终性（区块确认）、对账（链上vs链下数据一致）
2. 四方模型被压缩但不消失：DEX聚合器≈收单行、跨链桥≈卡组织、钱包≈发卡行
3. 合规是最大变量：MiCA/TFR等法规正在将KYC/AML要求引入DeFi

---

今日思考

深度问题1：支付系统为什么"正确性"比"可用性"更重要？

在互联网系统中，我们常说"可用性优先"——宁可返回部分结果也不要完全不可用。但支付系统反过来：宁可拒绝一笔交易（系统暂时不可用），也不能扣错一分钱（正确性出错）。

这背后的逻辑是：可用性问题是"用户现在不能用"，重试即可修复；正确性问题是"钱扣错了"，修复代价是差错处理+客户投诉+监管审查+声誉损失。

深度问题2：四方模型在移动支付时代还成立吗？

在中国的微信/支付宝生态中，四方模型已经被"改造"。微信支付同时扮演了收单行（接入商户）、发卡行（管理用户余额/绑卡）、卡组织（制定规则）三重角色，形成了事实上的"两方模型"。这种高度集中带来了效率但也带来了垄断风险，这也是网联被强制成立的原因——央行需要重建多方制衡。

深度问题3：如果让你从零设计一个支付系统，第一个建的模块是什么？

不是支付网关，不是风控引擎，而是账务系统(Ledger)。因为支付的本质是"记账"——不管通过什么通道、什么方式支付，最终都是在账本上做借贷记录。账务系统是支付的"真相之源"(Source of Truth)，所有其他模块都依赖它来确认"钱到底在哪里"。

---

面试题准备

题目1：支付系统最核心的设计原则是什么？

30秒回答

支付系统最核心的原则是**"不多扣、不少扣、不重扣"**，即资金正确性。这要求系统在任何异常情况下（网络超时、系统重启、并发冲突）都能保证每笔交易的金额准确、不重复执行。

2分钟回答

支付系统有四个核心设计原则，按优先级排序：

第一，正确性（不多扣不少扣不重扣）。这是支付的生命线。实现手段包括：幂等键保证不重扣、状态机保证流转正确、对账保证最终一致。

第二，可审计（全链路可追溯）。每笔交易从发起到完成的每个环节都必须有日志记录，支持事后追查和监管审计。

第三，高可用（故障不停付）。通道故障时自动切换，系统故障时快速恢复。但可用性不能以牺牲正确性为代价——宁可"交易暂停"也不能"扣错钱"。

第四，安全合规（数据不泄露）。PCI-DSS合规、数据加密、最小权限访问。

在架构实现上，我会用三层保障：

• 预防层：幂等设计+状态机
• 检测层：实时对账+异常监控
• 恢复层：自动补偿+人工介入

追问准备

• 追问1：如何保证幂等性？→ 幂等键+Redis原子操作+数据库唯一索引三层保障
• 追问2：正确性和可用性冲突时怎么选？→ 用具体场景回答：如果不确定是否扣款成功，宁可查询确认再重试，不能直接重试（可能双扣）

题目2：四方模型中各方的角色和利益关系？

30秒回答

四方模型包括持卡人、商户、发卡行、收单行，加上卡组织作为网络中枢。核心利益链是：商户付手续费(约2-3%)，其中60-70%作为交换费给发卡行（激励发卡），10%给卡组织（维护网络），20-30%给收单行（服务商户）。

2分钟回答

四方模型是理解支付体系的基础框架，各方角色如下：

发卡行(Issuer)：面向消费者，发行银行卡、提供授信、承担信用风险。收入主要来自交换费(Interchange Fee)，这也是为什么银行积极发卡——每笔交易都能分润。

收单行(Acquirer)：面向商户，提供接入、交易处理、资金结算。收入来自商户扣率(MDR)减去交换费和网络费的差额。

卡组织(Card Network)：Visa/MC/银联，制定规则、提供清算网络、管理品牌。收入来自每笔交易的网络使用费。

关键博弈：发卡行希望交换费高（更多分润），商户希望交换费低（减少成本），收单行夹在中间两头受气，卡组织需要平衡各方利益维持网络效应。

在中国市场，微信/支付宝打破了四方模型，同时扮演多个角色，这带来了效率但也引发了垄断担忧，促使央行成立网联进行清算监管。

---

学习资源

---

明日预告

Day 46: 收单系统设计 — 从商户发起支付到通道返回结果，聚合支付网关的完整架构。核心话题：通道路由策略（成本最优/成功率最优/限额均衡）、商户管理系统、通道管理与熔断降级。这是支付链路的"入口"，也是用户感知最直接的环节。