等等
首先,有个概念:
点融逻辑架构:
这张是非常常见、典型的逻辑架构:
点融component架构:
这张非常设计具体业务了,但金融部分仍非常值得参考,如一些component:
对账,也可以成为清算。一般为了保证系统的数据的准确性,尤其是金额数据。
金额的走向如下:
用户银行账户--支付--》银行(第三方支付平台)--通知--》内部系统。
所以银行会有流水,我们根据内部系统的支付记录与银行(第三方支付平台)的后台支付记录按流水进行一一核对。
另外,内部系统产生出的流水(transaction),我们通常有后续的步骤,譬如产生现金流cashflow。现金流同样要与内部的流水进行一一核对。
正常运作的时候,应该是有每日清算(不一定是EOD--end of day),保证用户的资产的正确性。有的公司会有更严格的清算处理:每个几个小时进行清算。
由于某些特殊情况,如用户基于不知情、或账户安全原因(被盗卡),不承认某笔交易是正常交易。--那么就需要系统取消某一笔交易。取消交易时,资金一般可以按资金来路原路返回。
系统因此需要提供取消交易的功能,但不能简单的删除订单,要留下证据,一般可以更新为取消状态。(同时要保留操作记录)
注意内部的逻辑关系,一笔已经达成的交易被取消,对应需要emit 一些event进行统计关联的计算数据。--有时类似牵一发动全身的感觉。
所谓掉单:用户A在第三方(银行/支付公司)支付了,然后在自身系统没有得到更新到用户的资产。
可能原因:第三方一般会一次同步回调或者多次异步回调不成功导致。要么网络有延时或者丢包导致第三方与自身系统网络通讯不成功,要么通知到了,但没处理好,或者没及时处理。
解决方案:
改单,一个典型情况是,金额或者状态错了,需要进行对交易流水进行更新。但不能直接更新数据库,而应系统提供功能出来,以防直接改动数据,没触发其他关联数据的更新。这一点与退款类似。
该系统之所以称为复式簿记,是因为每笔交易都至少记录在两个不同的账户当中。每笔交易的结果至少被记录在一个借方和一个贷方的账户,且该笔交易的借贷双方总额相等。该方法发生的每一笔经济业务都要以相等的金额,同时在两个或两个以上相互联系的账户中进行登记。
类似于能量守恒定律,把来龙去脉都记下来.
系统设计:
账户子系统存储要素应该包含2类表:
一个是账户表(账户余额/状态表)account,主要记录账户基本信息:ID,名称,类目,可用余额,冻结余额等;
另一个是账户流水表(又叫流水明细表)cashflow,记录这些账户所有相关变化的流水记录。
日结表:EOD 日结,应与账户体系隔离,属于清算日结,不要影响主业务。日结做了后,数据不会因为对以往进行修改(也不应该这样处理)而产生偏差。
连连支付文档
PayPalm支付文档
支付宝文档
支付宝架构
点融网架构
原文:https://www.cnblogs.com/no7dw/p/13628873.html