RuoYi-Vue-Pro 架构总览
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