假设一种情况，你现在进入了一家创业公司，需要搭建一套电商支付系统，产品经理没有到位。没有需求，现在只有一个要求，满足任何情况下的支付系统的搭建。怎么做？刚开始的时候，依据之前的经验，你可能会画出类似下面的E-R图：

这种情况很简单，支持一个订单全流程下去，每个商户订单号只能使用一次。一笔支付订单支持多次退款，每个退款单号也是唯一的。当然这只是交易流水方面的关联关系，还有支付通道和商户路由，状态变化及交易流程，这一段网上好多人有过分享，不再赘述。产品经理没有到位，几位技术人员分析过后没有问题，就开始动工写代码了。大概半个月之后代码写完，测试基本OK。开始和订单系统进行联调测试，订单系统那边提出要求，每个商户订单号只能使用一次，不能接受。现实情况是，用户先下订单，然后可以合并多个订单去支付。后来又多问了一句，用户能不能用多种方式支付？没人回答，产品没到位，技术经理不敢做主，那我们只能按照多种支付方式来设计。现在问题来了，在现有情况下，如何调整？

经过最后讨论，大致的ER图应该是这个样子：

先说收单，订单系统提交过来的多个订单先入“合并订单明细表”，合并生成唯一交易号记录在“交易总表”中，如果可以付多次，那么需要一个详细的“支付交易明细表”这样整个流程就能串通下来。退款的时候很简单，订单系统那边要求一个订单本次一共退款金额，剩下的支付系统去计算。如上图所示，具体逻辑就是按照先进先出原则，计算出需要退款的流水（入商户退款明细表），然后向第三方通道发起退款（入通道退款明细表）请求即可。

好了，我这次分享暂时先到这里，有问题大家随时提问，谢谢！

本文档来自“支付产品架构交流群”的聊天记录整理，由志愿者整理并发布到本网站。如需要及时收到来自“支付产品架构交流群”的最新消息，请扫码关注“凤凰牌老熊”的微信公众号。