支付单、业务单、退款单一次订场退款里的三表对齐背景「快约球」订场链路里用户支付成功后会同时存在概念表 / 字段职责业务订场单venue_bookingspay_status/booking_status场次是否确认、是否取消支付单payment_ordersstatus与微信商户单号、金额、用户绑定退款流水payment_refundsout_refund_no、金额、微信退款号、来源早期取消订场只改业务表并返回mock_refunded/wechat_pending占位——资金侧没有真实退款后台也没有按会员聚合的订单视图。这在演示可以在对账不行。目标用户取消与后台退款走同一条PaymentService.refundPaidOrder。已支付订场退款后支付单refunded业务单取消并释放slot_offer。Admin 能按userId列出该会员全部支付单并对paid发起退款。微信未就绪且开启 mock 时明确记mock不假装已打到微信。状态机支付单pending → paid → refunding → refunded ↘ closed / failed下单失败或关单说明refunding已向微信发起或本地进入退款流程。微信返回SUCCESS落payment_refunds.statussuccess订单refunded再执行业务冲正。微信返回PROCESSING退款流水记processing业务上仍可先释放场地避免档期继续被占资金到账靠微信侧异步完成产品文案不要写「秒到账」。关键实现要点1. 退款入口统一Admin: POST /api/v1/admin/orders/{id}/refund User cancel (已支付订场): refundVenueBookingIfPaid(bookingId) ↓ PaymentService.refundPaidOrder(outTradeNo, reason, source) ↓ WeChatPayV3Client.createRefund(...) 或 mock ↓ applyBizAfterRefund → venueDirectBookingService.applyRefundCancel(bookingId)source区分admin/user_cancel方便以后审计。2. 三表写入顺序建议顺序插入payment_refundspending支付单paid → refunding调微信或 mock更新退款流水 支付单refunded业务冲正订场取消 释放时段微信调用失败时退款流水failed支付单回退到paid避免卡在refunding无法重试。3. 按会员查单Admin 列表增加userId条件并对users.username / nickname做关键词检索。业务类型包含player_membership、team_vip、venue_booking。这比单独再做一张「会员订单宽表」更便宜支付域本来就有user_id。4. 会员 / VIP 退款的产品选择订场退款会冲正业务会员与 VIP只退支付单不自动撤销权益。原因权益回收涉及到期日、叠加开通、人工赠送自动扣回容易误伤。钱和权分离交给运营。接口与表便于对照FlywayV60__payment_refunds.sql另有启动兜底PaymentRefundsTableMigration微信POST /v3/refund/domestic/refunds支付单扩展状态refunding/refunded小结坑建议只改业务表、资金占位用户取消与后台退款必须共用履约退款失败卡在 refunding失败回退paid允许重试PROCESSING 当失败可先释放库存文案写清「处理中」会员退款自动降级先退款权益回收单独策略远程库 微信退款的系统里状态对齐比多做一个按钮重要。先让三张表能互相解释再谈分账与对账报表。
