本文主要是介绍大厂交易系统从0到1(01)-一笔交易到底涉及多少张表？，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
退款逻辑，1个业务单号--关联多个支付单号--也关联多个退款单号？退款单号，关联优惠券返还的，也可在退款单列表关联吗？返还比例多少，是在优惠券系统设置？
整个交易、支付、清结算、账务体系杂糅，会产生很多单据、单号。再考虑正向、逆向，他们的关系更复杂。
本文就来搞定订单、账单、支付记录、支付单、支付请求、卡消费记录、券核销记录等单据，他们在交易正、逆向中是如何联系的，又有怎么样的数据关系。
0 场景
在某平台购买一次家政阿姨上门保洁服务，总价120元，分2次支付，“先预付80元，再后付40元”，预付时用一张20元优惠券，微信支付60元。
1 3个核心，6大单据及关系
以上场景发生并非依赖一个系统实现，而是通过3个核心实现：交易核心、支付核心、卡券营销核心，每个核心内会产生相应的单据。
1.1 交易核心
交易核心安排交易流程，包含：
- 订单子系统
- 账单子系统
① 订单
订单子系统内会生成订单，订单记录了平台跟用户的本次交易信息：
- 买了啥
- 总价多少
- 用户用啥支付的
- ...
| 订单号 | 商品 | 金额 | 优惠金额 | 预付 | 后付 | 订单状态 |
|---|---|---|---|---|---|---|
| 666 | 家政阿姨 | ￥120.00 | ￥20.00 | ￥80.00 | ￥40.00 | 支付成功 |
② 账单
账单子系统产生账单，账单记录订单要如何结算的信息，为后续的支付、卡券核销做准备，该 case产生2笔账单：
- 预付账单
- 后付账单
| 订单号 | 账单ID | 金额 | 优惠金额 | 应付 | 支付状态 | 账单类型 |
|---|---|---|---|---|---|---|
| 666 | 666-1 | ￥80.00 | ￥20.00 | ￥60.00 | 成功 | 预付 |
| 666 | 666-2 | ￥40.00 | ￥0.00 | ￥40.00 | 成功 | 后付 |
③ 账单支付记录
一笔账单需要被用户支付（结算），账单中的支付方式是广义支付方式，包括卡、券、满减、积分及渠道支付，如case的预付账单优惠20元，渠道支付60，假设用户选择微信支付：
| 账单ID | 支付方式 | 金额 | 支付状态 | 外部流水号 |
|---|---|---|---|---|
| 666-1 | 优惠券 | ￥20.00 | 成功 | |
| 666-2 | 微信支付 | ￥60.00 | 成功 | 3435566 |
交易核心的3类单据，一对多对多关系。
1.2 卡券营销核心
① 券核销记录
券系统内记录的用户的券绑定信息、冻结及核销记录；卡系统记录了用户卡余额的消耗记录、卡余额退回记录。
卡券的变动记录依赖交易核心的推动，交易核心如何推动卡券建立联系？靠账单支付记录单据。案例中因为用了一张20元的券，所以券系统核销了该券，假设有一笔核销记录：
| 券编号 | 券类型 | 金额 | 券状态 | 订单号 | 账单流水号 |
|---|---|---|---|---|---|
| Q001 | 代金券 | ￥20.00 | 已使用 | 666 | 666-1-1 |
这条记录与账单支付记录之间建立了关联：
1.3 支付核心
60元走微信支付，即请求外部支付渠道完成支付，这部分支付走的就是支付核心。
① 支付单
支付核心是处理走外部支付通道的支付处理业务。支付核心会产生2类单据：
- 正向支付的支付单和支付请求明细
- 退款单和退款请求明细
| 账单ID | 支付单号 | 支付方式 | 金额 | 支付状态 | 外部流水号 |
|---|---|---|---|---|---|
| 666-1 | pay001 | 微信支付 | ￥60.00 | 成功 | 324345 |
② 支付请求
一笔支付可能请求渠道多次，因此还要建立一个支付请求的明细：
| 支付单号 | 支付请求号 | 支付方式 | 金额 | 支付状态 | 外部流水号 |
|---|---|---|---|---|---|
| pay001 | pay001-1 | 微信支付 | ￥60.00 | 失败 | |
| pay001 | pay001-2 | 微信支付 | ￥60.00 | 成功 |
支付单和支付请求是1对多：
该case支付在3个核心内产生的全部单据形成的关系：
至此，正向形成的单据及单据之间的关系讲解完毕。
2 逆向单据的产生和关系
这时再看逆向订单退款就容易。逆向只是正向的反向，依然3个核心和单据维度，只是单据变成逆向单：
- 订单变成退单
- 账单变成退款账单
- 账单支付记录变成账单退款记录
- 支付单变成退款单
- ...
2.1 逆向都是基于正向
没有正向单据，就没逆向单据，如用户没下单，就不会取消订单、也不会操作订单退回，支付也是如此，没有原支付成功，就不会有退款。
2.2 支付退款基于原支付单
支付核心的退款，是支付单，不能脱离原支付单，退款可：
- 全退
- 部分退
- 多次退
但绝不会超过原支付金额。
2.3 逆向由订单发起
订单是逆向的起点，就是只有业务产生逆向处理，如退了部分商品或订单差评产生部分退回等，才会产生支付的逆向。
因此，退款不一定有订单逆向，也可能是订单产生的差评罚款或其他原因，但都是基于订单，即退款基于订单发起。
2.4 交易需控制逆向的顺序
订单产生了逆向，因为订单用了卡、券、积分、微信支付等多种支付方式。逆向发生后，先处理谁，先退券还是先退积分，还是先退微信支付的金额？
若是全额退还好说，毕竟最终都会逆向处理，但部分退呢？
支付了80，用了20元券，微信支付60，现在要退40，咋退？是退20的券微信退20，还是微信退40？因此需要一个逆向顺序的控制，case中设置这样的顺序及设置了券不返还的策略：
这样的规则下，若预付单只退50元，那么看预付单的情况：
按“券>卡>渠道”的退款顺序逆向：
- 先处理20元券，因为券不返还，所以就只是将券变成已取消，这样就会从营销中台的成本中核销掉
- 而30元从微信支付退
- 所以，用户部分退50元，在这样的逆向策略下，只能拿回30元
关注我，紧跟本系列专栏文章，咱们下篇再续！
作者简介：魔都国企技术专家兼架构，多家大厂后台研发和架构经验，负责复杂度极高业务系统的模块化、服务化、平台化研发工作。具有丰富带团队经验，深厚人才识别和培养的积累。
参考：
- 编程严选网
本文由博客一文多发平台 OpenWrite 发布！
这篇关于大厂交易系统从0到1(01)-一笔交易到底涉及多少张表？的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
