支付系统架构

 

• 支付前：在商品下单时，构建订单模型，根据拆单规则校验库存、商品状态等，然后进行账户资金冻结，生成交易流水，此时的状态都是待支付；

• 支付对接：支付前业务模型初始化成功之后，构建第三方支付对接请求，发起付款流程，并记录相应的请求动作和参数，等待支付结果的通知；

• 支付后：根据支付结果的成功与否，执行相应的业务模型状态更新，如果支付成功则交易记录、冻结的资金、订单结构与库存等都需要做一系列更新；

数据结构

 

• 账面管理：三个核心维度，账户金额，可用余额，冻结金额；

• 交易记录：存储用户的交易动作，但是可能会产生多个交易明细，典型的场景就是购物车下单；

• 交易明细：通常因为订单拆分，从而导致交易被拆分多条明细，进而将资金支付给不同商家；

• 支付对接：请求第三方支付平台时，需要记录请求时参数，以及第三方回调通知的报文；

• 订单记录：在一笔订单中可能存在多个拆分的子单，拆分策略也很多，比如仓库，商家，品类等；

• 订单明细：管理每笔子订单的信息，下单的商品、规格、买卖双方、单价、数量、金额等；

关联业务：

上面单从支付的主逻辑去分析流程，实际上涉及到的业务远不止流程中提到的这些，以常见的电商场景为例，交易中还存在商品管理、库存管理、物流管理，支付对接还会涉及优惠规则嵌入等等；

• 商品主体：维护商品各个维度的信息，并提供各种规格选项，以及基础的定价阶梯，构建商品详情描述；

• 仓储管理：订单拆单之后，需要根据商品编号去校验仓储信息，进行相应的库存冻结以及支付后的仓库发货；

 优惠券规则

 

• 优惠券主体：为了适配更多的业务场景，需要对优惠规则有诸多的设计，比如满减或折扣比例、按价格阶梯优惠、有效期限制等；

• 发放规则：支撑日常的运营活动，用户生命周期的维护，以及渠道流量的转化，提供用户群营销的基础能力；

这里简述的商品和优惠券业务，都是与支付流程有紧密的联系，比如拆单后库存不足，需要移除该商品；优惠券在支付中的使用策略，以及退款时的处理方式等；

最后从技术实现的角度，总结一下支付流程中的一些关键问题：

• 业务模型：对业务有清晰的理解，并能拆分出核心的节点，设计出相应的流程时序和数据结构；

• 事务管理：交易流程中常用TCC事务机制，即Try(预处理)、Confirm(确认)、Cancel(取消)模式；

• 加锁与重试：支付完成后发出支付成功的消息，而后进行业务更新，通常需要对处理的订单号加锁，避免消息重试机制引发数据问题；

• 资金结算：涉及金额的计算，自然要求不能出现精度损失的问题，在一次交易中必须保证每笔资金可以通过对账核验；

• 流程维护：流程本身是很难保证不出现错误的，需要在开发的时候，提供流程的可视化界面，并且支持手动维护的机制；

很多复杂的业务场景管理，都需要一个长期的迭代过程，但是前提需要牢牢把握住核心的逻辑；对业务的认知是一个由繁入简的过程，而业务的实现是一个由浅到深的过程，即分析与理解，到落地实现，再到探索与创新。