5

聊聊支付流程的设计与实现逻辑 - 知了一笑

 1 year ago
source link: https://www.cnblogs.com/cicada-smile/p/16440287.html
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

新手打怵老手头疼的业务;

一、业务背景

通常在业务体系中,都会或多或少的涉及到支付相关的功能;对于一些经验欠缺同学来说,最紧张的就是面对这类支付结算的逻辑,因为流程中的任何细节问题,都可能引发对账异常的情况;

错误发生之后,再想去修复流程,花费的时间成本又是高昂的,还牵扯错误数据的调平问题,最终很可能引发乱账算不清的结果,然后需要人工介入手动处理;

1691717-20220703165756589-1201982993.png

在支付场景中,不但涉及诸多的复杂业务,结算规则,超长的流程,第三方对接,其中更是涉及到诸多技术细节,比如:事务管理、异步处理、重试机制、加锁等;下面来分析具体的细节逻辑。

二、支付业务

1、流程拆解

面对复杂业务的时候,最基本的能力就是要懂得把流程拆成模块,做好各个模块管理,再考虑如何衔接起整个流程,从而形成解决问题的思路和经验;

1691717-20220703165803444-1994064315.png

如图是对交易场景常见的分解,大致可以分为四个模块:

  • 账面管理:对于开通支付功能的用户,必须清晰的管理资金信息;比如可用,冻结,账单等;
  • 交易流水:整个资金管理的流水记录,不局限于交易场景,还有充值,提现,退款等;
  • 支付对接:通常流程中的支付功能都是对接第三方支付平台来实现的,所以要做好请求和报文的记录;
  • 订单结构:比如在电商交易中,订单模型的管理,拆单策略等,支付的商品规格等;

这里只是从一个常规的交易流程中去分析,实际的细节描述会远比图例复杂,虽然业务细节各不相同,但是处理思路是大体相通的;再根据各个模块设计流程时序图,规划好节点之间的衔接和协作;

2、流程时序

通过时序图的设计,来分析各个节点在衔接协作时应该如何处理,在支付业务中,通常分为支付前、支付对接、支付后三个核心阶段:

1691717-20220703165810077-660897301.png
  • 支付前:在商品下单时,构建订单模型,根据拆单规则校验库存、商品状态等,然后进行账户资金冻结,生成交易流水,此时的状态都是待支付;
  • 支付对接:支付前业务模型初始化成功之后,构建第三方支付对接请求,发起付款流程,并记录相应的请求动作和参数,等待支付结果的通知;
  • 支付后:根据支付结果的成功与否,执行相应的业务模型状态更新,如果支付成功则交易记录、冻结的资金、订单结构与库存等都需要做一系列更新;

实际上对业务有清晰的理解和拆分之后,再做好时序流程的设计,这样就已经让一个复杂的场景看起来简单许多了,之后就是设计各个节点的数据结构;

3、结构设计

基于上面的业务场景分析和拆解,以及流程时序图的呈现,可以很容易输出一份基础维度的结构设计,下图可以作为参考:

1691717-20220703165816830-2123250587.png
  • 账面管理:三个核心维度,账户金额,可用余额,冻结金额;
  • 交易记录:存储用户的交易动作,但是可能会产生多个交易明细,典型的场景就是购物车下单;
  • 交易明细:通常因为订单拆分,从而导致交易被拆分多条明细,进而将资金支付给不同商家;
  • 支付对接:请求第三方支付平台时,需要记录请求时参数,以及第三方回调通知的报文;
  • 订单记录:在一笔订单中可能存在多个拆分的子单,拆分策略也很多,比如仓库,商家,品类等;
  • 订单明细:管理每笔子订单的信息,下单的商品、规格、买卖双方、单价、数量、金额等;

即使单看上面的简单设计,都能感觉到支付业务的复杂性,更何况还会叠加红包或满减等优惠规则之后,其复杂程度可想而知;

当然如果有明确的开发规范,在复杂版本中,所有开发必须输出业务的分解拆分思路,时序和结构设计,在统一评审之后再落地编码,这样即便是复杂的业务也会有极大的质量保证。

三、关联业务

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

商品管理

1691717-20220703165822239-309850996.png
  • 商品主体:维护商品各个维度的信息,并提供各种规格选项,以及基础的定价阶梯,构建商品详情描述;
  • 仓储管理:订单拆单之后,需要根据商品编号去校验仓储信息,进行相应的库存冻结以及支付后的仓库发货;

优惠券规则

1691717-20220703165828496-1332518002.png
  • 优惠券主体:为了适配更多的业务场景,需要对优惠规则有诸多的设计,比如满减或折扣比例、按价格阶梯优惠、有效期限制等;
  • 发放规则:支撑日常的运营活动,用户生命周期的维护,以及渠道流量的转化,提供用户群营销的基础能力;

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

四、实践总结

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

  • 业务模型:对业务有清晰的理解,并能拆分出核心的节点,设计出相应的流程时序和数据结构;
  • 事务管理:交易流程中常用TCC事务机制,即Try(预处理)、Confirm(确认)、Cancel(取消)模式;
  • 加锁与重试:支付完成后发出支付成功的消息,而后进行业务更新,通常需要对处理的订单号加锁,避免消息重试机制引发数据问题;
  • 资金结算:涉及金额的计算,自然要求不能出现精度损失的问题,在一次交易中必须保证每笔资金可以通过对账核验;
  • 流程维护:流程本身是很难保证不出现错误的,需要在开发的时候,提供流程的可视化界面,并且支持手动维护的机制;

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

五、参考源码

编程文档:
https://gitee.com/cicadasmile/butte-java-note

应用仓库:
https://gitee.com/cicadasmile/butte-flyer-parent

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK