支付业务的数据库表的设计
一、数据表
数据库中的数据表是整个核心逻辑的载体说在，所有的记账逻辑、以及与支付前台交互的数据都是在这里 进行记录。现就主要的表进行简要说明。不同的第三方支付其数据表名称肯定也不同，这里的表名称仅作参考
- 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：这个表为付款信息收集表，也是内部对账后的结果表。与之相对的是收款信息收集表。
