京东搞出的一个产品 bug？
昨天星球里有个同学向我提了一个问题，我还跟她讨论了几个回合，是关于电商产品中「好友代付」场景下的设计逻辑问题。
她在做产品的过程中为了对标同类产品的实现逻辑，专门测试了京东和淘宝的「代付」功能。在使用京东 App 的好友代付功能时发现，针对同一个订单竟然可以支付两次。
我先说下什么叫「好友代付」。
简单说，就是你在京东或淘宝上买东西的时候，在支付环节可以选择让他人帮你付款。
在淘宝上，是选择支付宝好友代付。京东里，是选择微信好友代付。
以京东为例，选择代付功能后会跳转到微信，选择某个好友发送后，对方会收到一个付款链接。
点击这个链接进去，看到的是一个付款页面。
场景明确了，接下来我跟你们说下她是怎么发现同一个订单能同时支付两次的。
首先，还原下业务经过。
她使用的是京东旗下的「京喜」小程序下单购买的非自营商品，活动单价 1 元。
然后，她提交订单并选择了找人代付功能。注意，在好友代付成功之前，作为下单人的她还是可以继续支付订单的。
接下来，将两台手机放到一起同时点击支付，此时调起了支付窗口，同时输入支付密码后支付成功。
也就是说，针对同一笔订单完成了两次付款。
显然，这不是一个正常现象，同一笔订单不应该能被重复支付。
随后，她使用下单人的账号发起了订单退款，代付方退款成功了，可下单人没有退款。
通过截图可以看到，两笔订单都是支付成功的，而且对应的商品订单号是一样的，支付时间也是一样的。
这就奇怪了，为什么同一笔订单能支付两次呢？为什么发起退款后，只有代付方成功退款了呢？
我先说结论吧。
这可能不是一个技术层面的 bug，但肯定是一个产品层面的 bug。
第一，之所以能实现好友代付，是因为订单模块和支付模块是解耦的，二者通过订单号和交易流水号关联。
在技术上，两个模块可以实现独立。在组织上，订单团队和收银台支付团队也可以独立。
第二，作为特殊场景下的极端测试场景，当同一个订单被下单方和代付方同时发起支付时，理论上是需要做并发判断的，要有一个锁死机制，不能让同一笔订单被支付两次。如果发生，那就是个业务 bug。
第三，既然是个业务流程中不允许存在的 bug，在产品设计环节就应该从逻辑上避免。
所以，在发起支付时需要对订单状态进行判断，只允许一笔支付订单产生。既然出现了这个问题，显然是个产品 bug。
之所以说不是技术层面的 bug，是因为这笔异常订单最终都完成了系统退款。
回到前面说的退款问题。
在一段时间后，下单人的退款也完成了，只不过比代付方的退款延迟很久。
针对这个现象，可能的情况也有多种。比如商家审核延迟、系统异常延迟、固定脚本检测退款订单或者是运营人员发现后的手工处理。
总之，从用户体验的角度看，这肯定是一个 bad case，也是一个产品 bug。
那么，导致这个问题出现的原因是什么呢？
这里，我斗胆猜测一下。
前面提到了，这是京东旗下「京喜」业务下的订单。按照京东的特点，不同的垂直业务可能有自己的产品研发体系，他们的业务系统会在京东订单中台的基础上做二次逻辑开发。
举个例子，京东健康也是京东的垂直业务，因为属于医药场景下的特殊订单，业务流程和普通商品交易有些区别。所以，他们的订单流程实际上也是基于京东主交易流程系统上的二次开发，逻辑底层调用的也是京东的交易中台系统。
因此，这个订单可能也是垂直业务的产研团队进行的二次处理。而他们在调用中台支付接口时没有对订单状态进行判断和检测。
另外一种可能，就是好友代付功能下的订单状态判断缺失。
因为在这个场景下，极小概率会出现下单方和代付方同时支付的情况，只有极端测试的时候会出现。
既然概率足够小，那很可能在设计和开发阶段就忽略了。或者没有被忽略，只是因为优先级不高而暂时没有加上。
当然，在真实的用户使用场景下，这个问题出现的概率并不高。但不管怎么说，既然能出现，那就说明确实是系统的漏洞。
作为一个大体量的产品，再下的问题也可能被放大。哪怕是 0.001% 的出现概率，放在一个日单量如此巨大的产品上，也不是一个小数。
以上，只是我的猜测，并不构成结论。
订单编号也在图里了，京东订单中台的产品同学如果看到了可以去查下这一单的具体交易情况。
如果确实是问题，就赶紧 fix 一下吧。
如果你也在设计类似的交易系统产品，同类的问题也可以思考下如何避免。
做产品之所以好玩，其中一点就是透过现象找逻辑。
················· 唐韧出品 ·················
同样的问题，在美团的产品上就没存在。
可能很多人对交易系统产品不是很了解，因为我做过，所以我知道其中的复杂性。
说实话，平台类电商的交易系统可能是所有产品中复杂程度最高的一类，如果有机会做一次，锻炼意义还是挺大的。