单车版订单服务/支付中心[笑]

/ 0评 / 0

单车版支付中心[笑]

没错。又是我在写支付和退款。
一想到支付就不得不想起那次记忆深刻的打款,真的千金散尽不回来。当我进行了一次加倍慈善之后,没想到的是我还能再写支付。
怎么说我也是练习时长一年半的代码练习生了,但的确没有信心和想法去搭建一个支付中心。因为不管是我的思路还是我的经验:都是零。抛开打款API的直接调用,我有点侥幸的认为支付也是差不多的事情,但是我清楚地知道,不同渠道的不同尿性是支付对接的一个很恶心的点,因为各种限制,付款流程和方式也不尽相同,而要做好这件事我觉得最重要的是能够抽象出业务和支付本身的关系。

明确需求和目标

支付,大型业务系统中或许都被划分到了中台(我没去过我不知道我猜的),而在交易系统里,支付其实是一个很庞大的体系:收银台、交易核心、支付核心、渠道网关、账务系统、会计系统、清算系统、合规系统等。显然一己之力是很难构建完美的支付系统,不管是账务管理还是清算,都能拉出来写个十几期,其本身资金流转和交易味道重,复杂的资金流转和账务使得业务本身就很复杂,显然虽然我们虽然搭建支付中心,但是只有一月不到时间,而支撑交易本身发生的其实只有支付核心和网关。作为一个会产生商业行为的小型企业,并没有能力自己去做金融相关的,往往借助第三方平台来促使资金流动发生交易,而和第三方系统的对接是创建交易的基本,所以本期涉及的第一个核心就是:渠道网关
而有了和第三方系统的交互,但得跑通自己的业务流程,所以另外一部分的重要组成便是支付核心交易核心作为和业务强关联的系统也必不可少。而不同业务往往有着不同的支付场景和交易类型,所以收银台是作为本系统的最后一个内容。
为什么不做账务系统、会计系统、清算系统?答案很简单:资源不够,量力而行。因为账务系统在原来的产品帮助下是有一定成长,但是会计、清算(结算)由于拆解的问题,并不是不存在,而是很分散的耦合在业务线的系统当中,这部分并不是研发能够凭借自己的能力推动,需要优秀的财务/产品团队一起定制属于公司业务线的交易核心和规则。而此处涉及大量财务的专业知识,我只能看到很少的一部分,但是我明白强劲的会计/清算研发只能解决40%的问题,是落地的问题。
关于合规系统,原因更简单了:交易频次。首先从我们的业务出发我们其实是一个单用户交易频次不高的公司,合规系统涉及到风控、反诈骗、反黑产等设计复杂、甄别困难的设计难点,并不是当前我们公司体量能够做的事情,而当我们的交易量上升,达到合规系统底线的时候,或许就会有人推动该系统的落地(我想我是看不到了)
从上面一段分析当中得出了三个结论:
我们需要 收银台 来发起/提交支付,交易核心确保支付数额/支付内容是业务可靠的,支付核心去发起交易,通过渠道网关呼起支付内容,用户完成支付,再由渠道网关通知支付核心完成交易动作,由支付核心向下通知各业务线支付成功消息。后面就成了业务系统自己的事情了。

基本玩法

从上面的目标来看,我们的流程大致是这样的:
UTOOLS1577721420884.jpg
而通过上面的情况来看若要用户完成最简单的支付,上图已经是青春版最佳实现了。这样一来系统的划分就很明显:
UTOOLS1577723401789.jpg
以服务的维度划分完成了,剩下的就是落地的细节了,有关这块的设计其实我的老大给了我一些很不错的思路:通过策略者模式来设计收银台支付模板/渠道的选择,通过实现不同渠道的获取支付方式来组成。
呼起支付的大概思路如下:

// 获取支付渠道
PayGateWay payGateWay = PayGateWay.get(request);
// 获取支付模板
PayModel payModel = PayModel.get(request);
// 交易核心检查
tradeCilent.checkPayInfo(request);
// 生成支付流水
Pay pay = payMapper.save(request,payModel,payGateWay);
// 调用渠道获取支付信息
return gateWayClient.getPayUrl(request,pay);

而其他的细节大都是在处理报文、校验状态、核对签名。具体的网关还得看第三方的尿性。更具体的表设计以及其他思路其实更倾向于不和业务系统重耦合。而退款的思路与之类似。

不足和改进

因为消息队列和Http的不可靠,为了保证分布式系统的数据一致性,我们使用了一些土办法:
UTOOLS1577724197477.jpg
上图的勾兑检测程序和Raincat的确解决了一些问题,但是虚线部分依旧是存在问题的,但是这里往往处于业务扯皮阶段,我想应该短时间内不会有改变吧。
更多的问题其实在于解决第三方系统和我方系统订单状态不一致,这里的办法就更多了,看第三方的接口,可以像上面一样一起勾兑,也可以主动查询,但是前提是业务方有对应的处理流程(我司反感自动退款,所以一般都是客诉处理....)

总结

萌新第一次写这种系统,对于很多地方的确一开始考虑的不是很好。好在组内大佬一直给了一些很贴合的指导,虽然最后被我实现的很烂,但是有一说一,上线一月千万流水还是有的,感谢教导(真的很感谢帮助哈哈哈哈)但是交易系统是很庞大的,我身处在一个小型的公司,面对复杂度并不是很高的业务系统就已经有点迷了,很难想象巨型的交易系统到底长什么样子(许个愿,说不定有生之年就能看到了...)支付总体来讲和业务关联关系不大,但却是一个很讲究处理流程和事件驱动的事儿,继续加油~

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注