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