多订单混合支付系统的搭建
凤凰牌老熊移动支付网2018/8/21 15:31:06

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

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

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

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

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

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

本文为作者授权发布,不代表移动支付网立场,转载请注明作者及来源,未按照规范转载者,移动支付网保留追究相应责任的权利。

展开全文
相关阅读
资讯查询取消