支付业务的数据库表的设计

一、数据表

数据库中的数据表是整个核心逻辑的载体说在,所有的记账逻辑、以及与支付前台交互的数据都是在这里 进行记录。现就主要的表进行简要说明。不同的第三方支付其数据表名称肯定也不同,这里的表名称仅作参考

  • gTransLog表: 支付网关交易流水表,所有通过网关的交易全部都会在此表中写入数据。
  • tAccounts表: 用户的账户数据记录表,在第三方系统中其记录着用户的账上资金。
  • tAccountLog表: 用于记录账户的自己流水情况,所有对tAccounts表的资金变动都会在流水表中进行记录
  • tBankPaymentInfo表: 上传对账文件后,解析对账文件生成的表
  • tBankcardInfo表: 用于存储用户或者商户所绑定银行卡的信息,包括银行名称、卡号等
  • tChannelConfig表: 渠道配置表,用于配置商户与不同渠道的对应关系,比如接入支付宝或者招商银行
  • tFreeze表: 冻结表,当tAccounts表中的资金有事先冻结的情况下,比如说基金赎回等会向tFreezes表中插入数据
  • tPayments表: 付款表,记录账户付款相关信息
  • tReceivables表: 收款表,记录收款信息
  • tPaymentChannel表: 商户付款渠道的相关信息
  • tRefundChannel表: 商户退款屠刀的相关信息
  • tRollLog表: 业务流水表
  • tTrans表: 交易表,只要是交易,资金有变化,是商户与用户交互的过程
  • tTransLog表: 交易流水表,记录交易流水的相关信息
  • tTransCashBack: 记录银行账号退款的相关信息
  • tBankPayReconFile表:上传对账文件后,解析对账文件生成的表
  • tReconcilationPaySucc表:对账成功后写入的表
  • tReconcilationPayFail表:对账失败后写入的表
  • tAccountSystemayPaymentInfo表:付款内部数据收集表

二、数据表分析

在第一部分对其中后台记账系统的数据表中大致进行了一下说明,但是其中也会有一些需要注意的点, 这才测试中分出关键。现在就每一个表进行详细的分析一下。

1、gTransLog表:该表是所有网关交易都要登记的表,从支付前台传入的数据首先经过gTransLog表进行 网关登记和注册,然后再进行其他记账。在表中有内部交易单号,用于查取交易数据;有returnCode用户存放银行返回 的数据;有状态标志用于查询交易的最终状态。很多时候,支付前端的请求都是直接查取网关表来进行某些交易逻辑判断。

2、tAccounts表:该表是账户数据记录表,记录着用户账上的资金。可以联系一下支付宝,就相当于个人的支付宝账户 里面的余额。不同的记账系统对账户的区分也不一样,可能有的账户系统中只用商户账户存在,有的则允许个人和商户都存在。该 表中的账户除了较为重要的Balance Amount外,还有几点需要注意:

  • 账户的冻结金额
  • 账户的子类型,有些时候需要关注是主账户还是次级账户
  • 账户的科目类型,是资产账户还是负债账户,这在记录账户流水的时候很有用
  • 账户的状态,可用还是失效

3、tAccountLog表: 该表是用来记录资金账户流水变化,并记录相关交易单号以及金额。在表中会有标志记录这次的资金流动情况 是借记还是贷记,这在核对账户的资金流动上很重要,难免出错。

4、tBankPaymentInfo表:这个表在对账的时候使用,关于对账相关逻辑在下一章情景支付中进行讲述。这个表是付款对账表,当然与之 相对的是收款对账表,在此仅以付款对账表进行讲述。将对账文件进行解析,获取文件中数据,来成生成此表。将在外部对账时使用。

5、tChannelConfig表:该表是渠道配置表,主要是商户使用。该表中配置了商户以及此商户所接入的渠道,比如支付宝或者某银行。可以 从现实生活中去理解此逻辑,在某商户进行购物时并不是每一个商户都对某家银行支持,说的也是这个道理。

6、tFreezes表:该表为冻结表,当有交易发生资金冻结的情况时,都会向这个表中写入数据;而当这个某些资金解冻后,也将该冻结表中的 状态改为解冻。并不是所有的交易在金额变动之前都会去事先冻结金额,对于实时性交易来说,账户的钱是会被实时扣除。账户资金出现冻结的情况 出现在基金申购、优惠券消费等为数不多的场景中。

7、tPayments表: 该表为付款表,这里的付款是从商户的角度来说的,对于用户来说就是收款。初次涉及账户逻辑时很容易将这逻辑搞混,这个表使用 再向用户打钱的时候才会被用到。比如在基金赎回的场景中,就会向这个表中插入数据,通过表中的状态,就可以判断其向用户打钱有没有成功,对于没有成功、 的情形又会涉及到退票的情形,这在下一章讨论。

8、tReceivables表: 该表为收款表。这里的收款也是对商户而言,对用户而言则是付款。比如用户在进行购物的时候,用户是付款,商户是收款,那么此时 就会向此表中插入数据,其表中也存有state字段用来表示用户付款有没有成功。只要是涉及用户的资金进入第三方系统,此表都会有收款数据写入。

9、tPaymentChannel表:此表为付款渠道表,如果从字面意思进行理解便可知道,这个是付款时的渠道。不管是商户还是用户其相关的付款渠道信息都是在此 配置,如果在这个表中将渠道置为无效,则在支付前端看不到此渠道。

10、tRefundChannel表:此表是退款渠道配置表,可以类比付款渠道配置表进行理解。

11、tTrans表:该表是交易表,核心点在与交易,交易必须有买和卖,只有这样才能完成交易。此时就涉及一个易被忽视的问题,比如向用户向自己钱包充值, 这个阶段只是收钱,并没有存在交易,所以在这个场景下并不会向该表中写入数据。在一般的交易中,可查看表中的状态来判断此交易的状态,是等待付款、付款完成 、付款失败、已清算。支付前端也时刻通过这个表来进行其他联接查询操作。

12、tTransLog表:该表为交易流水表,对tTans表的变化都会在tTransLog中进行记录,这在后续查询交易异常情况下,比较有帮助作用

13、tTransCashBack表:该表为现金退款表,当用户通过银行卡支付并成功扣款后,这个时候如果发起退款那么要这个表中插入数据。有一个情况要注意,这个表中的 数据只涉及银行退款,比如在组合消费的时候,可能有优惠券的金额。那么由于优惠券过期而发生退款时,银行卡退款部分写入tTransCashBack表中。

14、tBankPayReconFile表:这个表中的数据为解析银行付款对账文件而来,其数据来源于银行。这个数据表为付款文件对账表,与之相对的是收款银行文件对账表,虽然 在这里没有将其列出,但是其业务逻辑思想是相通的。

15、tReconcilationPaySucc表:对账数据的结果存放处,对账的结果又对平和对差的区别。具体在这里不做讲解,对平的数据放入此表中,而对差的数据放入Fail表中。

16、tAccountSystemayPaymentInfo:这个表为付款信息收集表,也是内部对账后的结果表。与之相对的是收款信息收集表。

原文地址:https://www.cnblogs.com/jpfss/p/9019876.html

时间: 2024-11-08 03:16:05

支付业务的数据库表的设计的相关文章

树形结构的数据库表Schema设计-基于左右值编码

树形结构的数据库表Schema设计 程序设计过程中,我们常常用树形结构来表征某些数据的关联关系,如企业上下级部门.栏目结构.商品分类等等,通常而言,这些树状结构需要借助于数据库完 成持久化.然而目前的各种基于关系的数据库,都是以二维表的形式记录存储数据信息,因此是不能直接将Tree存入DBMS,设计合适的Schema及其对 应的CRUD算法是实现关系型数据库中存储树形结构的关键. 理想中树形结构应该具备如下特征:数据存储冗余度小.直观性强:检索遍历过程简单高效:节点增删改查CRUD操作高效.无意

树形结构的数据库表Schema设计

今天又有幸遇到一个不知道的东西,那就是树型结构在数据库表中设计的问题.由于只是阅读了人家的东西,就直接给连接吧. 第一个:http://blog.csdn.net/monkey_d_meng/article/details/6647488 第二个:http://my.oschina.net/XYleung/blog/99604 两个讲的都是一个道理,不同的人合适不同的版本吧.都给大家吧.

数据库 表关系设计参考

表关系设计 出版社表关系 # 出版社表 class Publisher(models.Model): name = models.CharField(max_length=32) addr = models.CharField(max_length=128) phone = models.IntegerField() def __str__(self): return self.name # 作者表 class Author(models.Model): name = models.CharFi

MySQL数据库优化技术之数据库表的设计

三范式介绍表的范式:只有符合的第一范式,才能满足第二范式,进一步才能满足第三范式. 1. 第一范式:表的列具有原子性,不可再分解.只要是关系型数据库都自动满足第一范式.数据库的分类:关系型数据库:MySQL/ORACLE/Sql Server/DB2等非关系型数据库:特点是面向对象或者集合nosql数据库:MongoDB(特点是面向文档) 2. 第二范式:表中的记录是唯一的,就满足第二范式.通常我们设计一个主键来实现.主键一般不含业务逻辑,一般是自增的: 3. 第三范式:表中不要有冗余数据,即如

数据库表的设计 注意点

注意点: 如果是代码表基本不会变化的我们可以只设计  dm字段而不加pkid字段  代码表还会不断变化的话我们再加一个pkid自增长,如果涉及到外键我们要引用的是dm而不是pkid,因为这样我在导入数据的时候可以避免数据对不上.  业务表的话我们还是也加一个dm(可以guid)字段好了,Pkid自增长或者我们只要一个Id(guid)这样都是防止自增长的特性导致导入数据混乱,那么我们guid还是在前台生成好再插进去,不然同样会导致和自增长一样的导入数据混乱.

数据库表的设计

首先建立sell.sql文件,在里面输入: create table 'product_info' ( 'product_id' varchar(32) not null, #因为是企业级项目,防止不够用,所以用varchar字符类型. 'product_name' varchar(64) not null comment '商品名称', 'product_price' decimal(8,2) not null comment '单价', 'product_stock' int not nul

粉丝关注数据库表的设计

CREATE TABLE relation ( id PRIMARY KEY AUTO_INCREMENT, //主键,自增 from_user_id big integer, // 用户 A 的 id to_user_id big integer,// 用户 B 的 Id rel_type enum(1,2) //关注数据 ); 拉黑/粉丝/关注,在数据库里,存的都是一个映射关系的数字.比如,拉黑是 1,粉丝/关注是一个东西,是 2.那么,一条记录里的关键数据是: from_user_id /

数据库表的设计(怎么设计)

1,字段的类型 除了id(主键)为int外,能够用varchar2类型的都用(方便) 2,设计字段要预留两个字段(如果一开始怕自己设计不周到,最好多预留字段) 3,字段长度适当设计长一些 原文地址:https://www.cnblogs.com/wskb/p/12085078.html

数据库表设计的随笔(分库分表)

笔者目前就职的是一家创业型的互联网公司,既然算是互联网公司,那么就会设计到无论是应用系统还是数据库的分布式.下面简单介绍下有关数据库方面的一些设计. 数据库表的设计,根据自己的业务所需可以拆分成多库.有订单库.产品库.账户库.底层支付库等等,这也就是传说中的垂直分库.那么数据库架构和数据库优化有哪些解决思路: 1.垂直分表.垂直分表也就是“一张表拆分成多张表”,比如订单表里面,有不同类型的订单,拿普通订单和一元夺宝订单来说,一元夺宝订单会有抽奖码中奖吗等等,这些是一元夺宝订单独有的,就可以单独拿