1. 概述
聚合支付，也称为“融合支付”或“统一支付”，是一种第三方支付服务。它通过集成多种支付渠道（如微信支付、支付宝、银联、各大银行网银等），为商户提供一个统一的、简化的支付接口。商户只需一次对接，即可支持所有主流的支付方式，从而降低开发成本、简化财务对账、提升用户支付体验。
核心价值:
简化接入: 商户无需单独对接多个支付渠道。
统一管理: 在一个平台上管理所有渠道的交易和账单。
降低成本: 减少接口开发和后期维护的成本。
提升体验: 为消费者提供多样化的支付选择。
2. 系统架构
一个典型的聚合支付系统可以采用微服务架构，以保证系统的可伸缩性、高可用性和可维护性。
2.1. 架构图
+---------------------------------------------------------------------------------+
| 商户应用 (Merchant App/Website) |
+---------------------------------------------------------------------------------+
| ^
| (1. 创建订单) (6. 支付结果通知)
v |
+---------------------------------------------------------------------------------+
| 聚合支付网关 (Gateway API) |
| (API鉴权、参数校验、路由分发、签名、统一返回格式) |
+---------------------------------------------------------------------------------+
| ^
| (2. 请求支付) (5. 异步回调)
v |
+---------------------------------------------------------------------------------+
| 核心服务层 (Core Services) |
| |
| +-----------------+ +-----------------+ +-----------------+ +-----------------+
| | 交易服务 | | 路由服务 | | 渠道服务 | | 账务服务 |
| | (订单管理、 | | (智能选择最优 | | (对接不同支付 | | (记账、对账、 |
| | 支付、退款) | | 支付渠道) | | 渠道) | | 结算) |
| +-----------------+ +-----------------+ +-----------------+ +-----------------+
+---------------------------------------------------------------------------------+
| ^
| (3. 发起支付请求) (4. 支付结果通知)
v |
+---------------------------------------------------------------------------------+
| 第三方支付渠道 (e.g., 支付宝, 微信支付, 银联) |
+---------------------------------------------------------------------------------+
架构说明:
接入层 (Gateway): 作为系统的统一入口，负责处理来自商户的所有API请求。主要功能包括身份认证、权限校验、请求参数校验、协议转换、请求路由等。
核心服务层 (Core Services):
交易服务: 系统的核心，处理所有交易相关的逻辑，包括创建支付订单、处理退款请求、记录交易流水等。
路由服务: 根据预设的规则（如费率最低、成功率最高、渠道稳定性等）动态选择最合适的支付渠道。
渠道服务: 负责封装与各个第三方支付渠道的交互。每个支付渠道（如微信、支付宝）都对应一个独立的子模块，隔离不同渠道的接口差异。
账务服务: 处理所有与资金相关的业务，包括记账、与渠道进行对账、生成结算单、为商户提供清晰的财务报表等。
基础支撑: 包括数据库（MySQL/PostgreSQL）、缓存（Redis）、消息队列（RabbitMQ/Kafka）等。
3. 核心业务流程
3.1. 支付流程 (主扫)
用户下单: 用户在商户APP或网站选择商品，点击支付。
商户创建订单: 商户后端系统生成自己的业务订单，并调用聚合支付平台的“统一下单”API。
聚合平台处理:
网关进行验签和参数校验。
交易服务创建聚合支付订单，状态为“待支付”。
路由服务根据规则选择一个支付渠道（例如微信支付）。
渠道服务调用微信支付的“统一下单”接口。
返回支付凭证:
微信支付返回一个二维码URL。
聚合平台将此URL包装后返回给商户。
商户展示二维码: 商户前端展示二维码，等待用户扫码。
用户扫码支付: 用户使用微信扫码并输入密码完成支付。
异步回调:
微信支付服务器将支付成功的结果异步通知到聚合平台预设的回调地址。
聚合平台的渠道服务接收通知，验签后更新支付订单状态为“支付成功”。
账务服务进行记账。
聚合平台通过消息队列或HTTP请求，将最终支付结果异步通知给商户。
商户处理: 商户接收到通知，验签后更新自己的业务订单状态，并向用户展示支付成功页面。
3.2. 退款流程
商户发起退款: 商户通过后台或API调用聚合平台的“申请退款”接口，并提供原支付订单号和退款金额。
聚合平台处理:
交易服务校验该订单是否可退款（如状态为“支付成功”，且未超过退款期限）。
创建退款订单，状态为“退款中”。
渠道服务根据原支付订单号，找到对应的支付渠道，调用其退款接口。
异步回调:
第三方支付渠道处理退款后，将结果异步通知给聚合平台。
聚合平台更新退款订单状态（“退款成功”或“退款失败”），并通知商户。
4. 功能模块设计
商户管理:
商户信息录入与审核。
商户应用管理（AppID, AppSecret生成）。
支付渠道配置与费率设置。
交易管理:
支付订单查询与管理。
退款订单查询与管理。
交易流水明细。
渠道管理:
配置和管理所有对接的第三方支付渠道。
监控各渠道的健康状况和交易成功率。
路由管理:
配置路由规则（如按金额、按时间、按商户类型等）。
提供手动切换和自动切换策略。
账务中心:
自动对账: 定时（如每日凌晨）下载渠道的交易账单，与系统内的交易流水进行逐条比对，生成对账差异报告。
结算管理: 根据与商户约定的结算周期（T+1, D+0等），生成结算单，并将款项划拨给商户。
报表统计: 提供多维度的交易数据统计报表，如日/月交易额、渠道分布、成功率等。
API与开发者中心:
提供清晰的API文档和SDK。
提供API调试工具。
管理回调通知和密钥。
5. 数据库设计 (核心表)
5.1. pay_order (支付订单表)
字段名
类型
注释
id
BIGINT
主键
mch_id
VARCHAR(32)
商户ID
app_id
VARCHAR(32)
应用ID
pay_order_id
VARCHAR(64)
支付订单号（系统内唯一）
mch_order_no
VARCHAR(64)
商户订单号
channel_id
VARCHAR(16)
支付渠道ID (e.g., WX_NATIVE, ALIPAY_PC)
channel_order_no
VARCHAR(64)
渠道侧订单号
amount
INT
支付金额（分）
currency
VARCHAR(8)
币种 (e.g., CNY)
status
TINYINT
状态 (0-待支付, 1-支付成功, 2-支付失败)
notify_url
VARCHAR(255)
支付结果异步通知地址
created_at
DATETIME
创建时间
updated_at
DATETIME
更新时间
5.2. refund_order (退款订单表)
字段名
类型
注释
id
BIGINT
主键
pay_order_id
VARCHAR(64)
关联的原支付订单号
refund_order_id
VARCHAR(64)
退款订单号（系统内唯一）
mch_refund_no
VARCHAR(64)
商户退款单号
channel_refund_no
VARCHAR(64)
渠道侧退款单号
refund_amount
INT
退款金额（分）
status
TINYINT
状态 (0-退款中, 1-退款成功, 2-退款失败)
notify_url
VARCHAR(255)
退款结果异步通知地址
created_at
DATETIME
创建时间
updated_at
DATETIME
更新时间
5.3. mch_info (商户信息表)
字段名
类型
注释
mch_id
VARCHAR(32)
商户ID (主键)
mch_name
VARCHAR(128)
商户名称
status
TINYINT
状态 (0-禁用, 1-启用)
private_key
TEXT
商户API私钥（用于签名）
platform_public_key
TEXT
平台公钥（用于验签）
6. API 设计 (示例)
6.1. 统一下单API
Request (POST /api/payment/unifiedorder)
{
"app_id": "appid_123456",
"mch_order_no": "MCH202406110001",
"amount": 1, // 金额，单位分
"currency": "CNY",
"channel_id": "WX_NATIVE", // 指定支付渠道
"subject": "测试商品",
"body": "iPhone 15 Pro Max",
"notify_url": "https://your.domain/api/notify",
"sign": "ABCDEFG..." // 签名
}
Response (Success)
{
"code": 0,
"msg": "Success",
"data": {
"pay_order_id": "PO202406110001",
"pay_data": "weixin://wxpay/bizpayurl?pr=xxxxxxxx" // 支付凭证 (二维码URL)
},
"sign": "HIJKLMNOP..." // 平台返回的签名
}
6.2. 签名机制
目的: 防止请求被篡改，并验证请求方身份。
机制: 采用非对称加密（如RSA256）。
请求签名: 商户使用自己的私钥对请求参数（除sign字段外，按ASCII码排序拼接）进行签名，生成sign值。
平台验签: 聚合支付平台使用预存的商户公钥对收到的请求进行验签。
响应签名: 平台使用自己的私钥对返回给商户的数据进行签名。
商户验签: 商户使用平台的公钥对收到的响应进行验签。
7. 安全与合规
数据安全:
敏感信息（如密钥、证书）必须加密存储。
数据库密码、配置文件等需要进行严格的权限管理。
所有对外接口强制使用HTTPS。
支付安全:
严格的签名和验签机制，防止中间人攻击。
设置IP白名单，只允许指定的商户服务器IP访问API。
对交易金额、频率等进行风控监控。
合规性:
如果系统涉及资金的“二清”（即平台先收款再结算给商户），则必须持有中国人民银行颁发的《支付业务许可证》，否则属于违规行为。
合规的做法是作为“技术服务提供商”，不直接触碰资金。资金流由第三方支付渠道直接清算给商户。系统只处理信息流。
对于处理银行卡信息的系统，需要遵循PCI DSS (支付卡行业数据安全标准)。
8. 技术选型建议
后端框架: Spring Boot / Spring Cloud (Java), Django / Flask (Python), Express / Nest.js (Node.js)
数据库: MySQL 8.0+ 或 PostgreSQL
缓存: Redis (用于缓存商户信息、路由规则等)
消息队列: RabbitMQ 或 Kafka (用于服务间的异步通信和任务解耦，如支付回调通知)
网关: Spring Cloud Gateway / Nginx + Lua
容器化: Docker & Kubernetes (用于快速部署和弹性伸缩)
这个设计方案提供了一个全面的蓝图。在实际开发中，还需要根据具体的业务需求和团队技术栈进行调整和细化。