支付系统搭建怎么做平台和支付系统搭建详解？ _生活百科

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

文章插图
你所规划的流程图基本类型如下所示：
1. 平台统一收款
平台上入驻的商户均以平台的进件资质发起交易，平台与商户的结算账期，由平台与商户协商决定，订单信息也由平台方业务系统自行记录，聚合支付服务提供方记录支付单信息。
2.订单分账设置
消费者收到后商品之后，平台调用聚合支付服务提供方的分账接口，分账指令按照平台给商户设置的账期，转至合作银行进行分账处理。
3. 退款操作流程
退款全额退款退手续费，资金原路退回。（看支付通道，银行退给聚合方，就退给平台）
4. 平台收款角色
消费者、平台、商户、分销商。消费者通过推广员支付的订单，会按照一定比例给推广员发放奖金。
在没有产品经理的情况下，几位技术人员分析过后没有问题，敲定了一个ER图(实体联系图）之后就会开始动工写代码了。
初步的ER图

文章插图
支持一个订单全流程下去，每个商户订单号只能使用一次。一笔支付订单支持多次退款，每个退款单号也是唯一的。
大概半个月之后代码写完，测试基本完成后，就会开始和前端业务系统系统进行联调测试，这时候业务系统那边提出要求，每个商户订单号只能使用一次，不能接受。
现实情况是，用户先下订单，然后可以合并多个订单去支付。
技术经理面对这种情况也不知所措了，现在问题是：在现有情况下，如何调整？经过最后讨论，大致的ER图应该是这个样子：
修改后的大致的ER图

文章插图
先说收单，业务系统提交过来的多个订单先入“合并订单明细表”，合并生成唯一交易号记录在“交易总表”中，如果可以付多次，那么需要一个详细的“支付交易明细表”这样整个流程就能串通下来。
退款的时候，订单系统那边要求一个订单本次一共退款金额，剩下的支付系统去计算。
如上图所示，具体逻辑就是按照先进先出原则，计算出需要退款的流水（入商户退款明细表），然后向第三方通道发起退款（入通道退款明细表）请求即可。
需要注意的是：是否全额退款、是否退手续费、是否资金原路退回。这个看支付通道，会根据通道，有不同的要求。比如说，可能要求必须是商户当日有未结算的金额才可以，结算给商户的，就不支持退款了。有些第三方通道可以不区分支付渠道，只要商户有收款即可。
说完订单系统的拆单合单之后，业务系统的下单逻辑基本能跑通了。
但与此同时又出现一个新的问题：用户能不能用多种方式支付？我们同一种支付方式后端对应了多个支付通道，当消费者使用多种支付方式之后这一笔支付订单该往那个通道去送呢？
如何解决支付系统的关键性问题？
用户在前端选择一种支付方式，比如使用招行借记卡来支付后，系统不一定就是调用招行的接口来执行支付。支付宝、微信等第三方支付平台以及银联等，都支持招行借记卡支付。
这种将支付方式落地到具体的支付接口的模块，就是支付路由，如何打造一个好的支付路由呢？首先要从设计目标和软件架构入手。
设计目标
支付路由在支付系统中的核心作用，除了本职工作路由外，还承担如下职责：
省钱—这是支付路由选择支付通道的最主要的规则。哪个通道省钱，基本会优先考虑这个通道。
提升支付产品的QOS—这体现在系统的可靠性、稳定性、性能和可用性上，通过屏蔽掉无法连接、不稳定、性能低的通道来提升这些指标。
支持营销—通过优先选择有优惠活动的通道，可以帮助业务提升付费客户量，降低运营成本。一个设计良好的支付路由，可以大大降低运营投入。
【支付系统搭建怎么做平台和支付系统搭建详解？】软件架构
上述流程，在实现上，可参考的架构设计：