交易模块，关于重复支付的交易表设计的几点疑问

[ZeroMing]

1. transaction_code VARCHAR(64) NOT NULL COMMENT '真实给第三方的交易code，异步通知的时候更新',这个字段具体是怎么处理呢，一般来说，在发起支付的时候，不是就已经传递了第三方的订单编号了么，这个在异步通知的时候，怎么再给第三方呢？
2. 重复支付的情况：
   1. 针对一笔订单的相同渠道的支付。第一笔订单已经发起了支付，会在pay_transaction表中记录一条支付订单。假设，第一条支付订单还在等待异步回调过程中，且没有超时。用户在这个情况下再次发起支付，那这笔订单是直接进pay_repeat_transaction表，还是说先进pay_transaction表，额外在pay_repeat_transaction表中记录重复数据
   2. 针对一笔订单的不同渠道的支付。情况类似，也有相同的疑问？

[ZeroMing]

1. 抱歉！上面第2个点是我的理解的问题，仔细看了下文档，是说异步回调的时候，判断是不是重复支付的订单（也就是查一下是不是已经有支付订单被支付了，如果已经有，那么该订单会被记录为重复订单），重复支付的订单会写入到pay_repeat_transaction中。意味着重复支付的订单，如果是支付成功的，那么就需要业务人员去操作后台退款接口或者线下退款了
2. 其实这种处理方式，算是一个兜底的方案吧。本身我们业务去处理的时候，是可以在接口层面就限制住不让用户去重复支付的。但是这是为了避免因为网络延迟导致的重复支付的问题

[chunpat]

• 其实这种处理方式，算是一个兜底的方案吧。本身我们业务去处理的时候，是可以在接口层面就限制住不让用户去重复支付的。但是这是为了避免因为网络延迟导致的重复支付的问题

其中一场景是一个微信码给两个人扫，都支付成功了。(一次结清)出现一支付单两次支付，不同第三方交易id异步通知

[ZeroMing]

• 其实这种处理方式，算是一个兜底的方案吧。本身我们业务去处理的时候，是可以在接口层面就限制住不让用户去重复支付的。但是这是为了避免因为网络延迟导致的重复支付的问题

其中一场景是一个微信码给两个人扫，都支付成功了。(一次结清)出现一支付单两次支付，不同第三方交易id异步通知

哦哦。这种情况是我没考虑到的。这种情况下，难道微信那边没做限制么，总有一个先支付成功的吧。如果出现了这种情况。那就得入pay_repeat_transaction表了，走退款处理了

[ZeroMing]

1. 如果单独设计一个支付系统的设计中，一个业务订单，应该是对应N笔支付订单的，比如说，对于一笔业务订单，我可以使用支付宝支付，然后取消；然后继续再使用微信的app支付，取消；然后再继续使用微信的网页扫码支付；在这种的情况下，应该都是对应的不同的渠道支付订单吧。也就是业务支付订单和渠道支付订单是1对N

[chunpat]

• 其实这种处理方式，算是一个兜底的方案吧。本身我们业务去处理的时候，是可以在接口层面就限制住不让用户去重复支付的。但是这是为了避免因为网络延迟导致的重复支付的问题

其中一场景是一个微信码给两个人扫，都支付成功了。(一次结清)出现一支付单两次支付，不同第三方交易id异步通知

哦哦。这种情况是我没考虑到的。这种情况下，难道微信那边没做限制么，总有一个先支付成功的吧。如果出现了这种情况。那就得入pay_repeat_transaction表了，走退款处理了

微信的话，生成微信支付订单的时候，自定义订单号唯一，微信那边就会验证重复支付。