RuoYi-Vue-Pro 架构总览
Pay 支付中心

Pay 支付中心

核心定位

Pay 支付中心是平台的「统一收银台」。商城卖东西要收款、ERP 采购要付款、会员充值要收款——所有这些收付款场景都通过支付中心统一完成，业务模块不需要关心底层是微信支付还是支付宝。

一句话：对接一次支付中心，所有业务模块都能收付款。

解决什么问题

痛点 支付中心如何解决
每个业务单独对接微信/支付宝 统一对接一次，所有业务复用
支付渠道切换需要改业务代码 渠道变更对业务透明
支付回调处理分散 统一回调 → 分发到各业务模块
支付流水无处可查 支付中心记录所有流水，统一对账

用户角色

graph LR subgraph 角色 DEV["开发者
对接支付 API
处理支付回调"] ADMIN2["运营/财务
查看支付流水
处理退款
对账"] ENDUSER["终端用户
发起支付
查看支付结果"] end

架构设计

graph TB subgraph 业务层["业务模块（支付调用方）"] MALL["商城
订单支付"] ERP2["ERP
采购付款"] OTHER["其他模块
充值/转账"] end subgraph 支付中心["支付中心 yudao-module-pay"] API_LAYER["API 层
PayOrderApi / PayRefundApi"] CHANNEL["渠道适配层
PayClient 统一客户端"] CALLBACK["回调处理层
统一回调 → 分发业务"] end subgraph 渠道层["支付渠道"] WXPAY["微信支付
公众号/小程序/扫码"] ALIPAY["支付宝
PC/Wap/转账"] MOCK["模拟支付
开发调试用"] end 业务层 --> API_LAYER API_LAYER --> CHANNEL CHANNEL --> 渠道层 渠道层 --> CALLBACK CALLBACK --> 业务层

支付应用设计

graph TB subgraph 应用隔离 APP1["支付应用：商城订单
回调地址：/mall/order/callback
订单前缀：MALL-"] APP2["支付应用：ERP 采购
回调地址：/erp/purchase/callback
订单前缀：ERP-"] APP3["支付应用：会员充值
回调地址：/member/recharge/callback
订单前缀：MBR-"] end

每个业务模块对应一个「支付应用」，拥有独立的回调地址和订单编号前缀，确保支付回调能准确路由到正确的业务处理逻辑。

支付全流程

sequenceDiagram participant U as 用户 participant BIZ as 业务系统（商城） participant PAY as 支付中心 participant CH as 支付渠道（微信/支付宝） U->>BIZ: 提交订单，点击支付 BIZ->>PAY: 创建支付单 PayOrderApi PAY->>CH: 发起支付请求 CH-->>U: 弹出支付页面 U->>CH: 完成支付（扫码/密码） CH-->>PAY: 异步回调：支付成功 PAY->>PAY: 更新支付单状态 PAY->>BIZ: 回调通知：订单已支付 BIZ->>BIZ: 更新订单状态 BIZ-->>U: 显示支付成功

支持的支付方式

渠道 支付方式 适用场景
微信支付 公众号支付 微信公众号内 H5 商城
微信支付 小程序支付 微信小程序商城
微信支付 转账 佣金提现、退款
支付宝 PC 支付 PC 端商城
支付宝 Wap 支付 移动端 H5 商城
支付宝 转账 佣金提现、退款
模拟支付 模拟 开发调试，无需真实账号

依赖关系

Mall 商城 → Pay 支付中心 ← ERP 进销存
                ↑
        系统管理模块（权限）

商城和 ERP 都依赖支付中心，支付中心依赖系统管理模块提供权限和配置管理。

docs