一、主题分享

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

20180805_194111

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

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

20180805_195741

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

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


本文档来自支付产品技术交流群的聊天记录整理,由志愿者整理并发布到本网站。如需要及时收到来自支付产品技术交流群的最新消息,请扫码关注“凤凰牌老熊”的微信公众号。新建的支付产品技术群还有不少空位, 本群面向支付行业的有经验(2年以上)的产品经理、软件工程师、架构师等,提供交流平台。如想加入本群,请在本文评论中留言(不公开),说明所在的公司、负责的工作、入群分享的主题和时间。