某个第三方支付平台数据库的分析、学习与总结
之前一直从事一般的WEB系统的开发，做过很多的项目了，现在主要做的一项工作就是与客户沟通需求后，设计出数据模型出来，并设计出主要的功能页面。
从来没做过金融方面的业务，于是从百度文库中找来一个第三方支付平台的数据库结构，进行分析，用通俗的语言总结出来，以掌握金融系统的业务设计。
百度文库的地址是：http://wenku.baidu.com/view/48f79722964bcf84b9d57bf1
一、基础平台核心库
1.账户：首先无论个人、企业在你平台上都有一个账户表，必须的。记录账记的基本信息，想想你的银行活期存折上的信息吧。当然5个金额要注意到，总的，可提现的，冻结的....但是有几个字段我不懂，计算积数，上期总金额等等。是的，我从来没注意过银行的活期是怎么计息的，利率在变，金额在变，怎么计？查了一下
银行按季结息，每季度末月的20日为结息日。
每次变动以头计算*持续天数=计算积数，当然从上期总金额开始算。
当季利息就是积数*计息日的日利率（年利/360，不是365是因为银行规定）
表上还有一个安全控制值，是MD5+BASE64，这个就是散列值，防止重要数据发生变化，摘要信息嘛。BASE64就是字符都变成基本的，这都可以理解。
这个，这张表就理解清楚了！！！
2.冻结、注销流水表：没啥好讲的，就是对某个账户的这种操作的日志一样的信息。
3.账户资金变动流水与冻结流水表：类似于每一次存钱，取钱的记录一样，当然实现上变动类型比较多。记录下每笔变动前后的总金额之类的。特别要注意有一个关联流水ID。比如我们充值，总金额发生了变化，但到底是怎么充的，哪个银行卡充的，成功没有，等等详细的信息这个表里都没有，却是记录在后面的充值交易流水表中。
似乎这样会有很多冗余，但这么设计是正确的，记录的角度不同，具体的每一笔变动的情况当然非常重要，但账户角度关注总金额变化。
4.交易流水相关表：这里的9张表就是9种交易的详细信息，每一笔交易都会在相关的表中记录下来。里面的详细情况如果有需要分析的后面再补了。
5.会计账务：说到会计，可能我们做软件的就不太清楚了，感觉有点专业。我也没学过，但我们分析下这几张表，同样也可以掌握基本的业务。
先说说后面两张表：科目明细与凭证明细，这个名字就知道是具体的一项业务的信息了。
（后面有备注：每种具体的业务，只操作凭证表，并设置业务关联。然后自动登记2个科目，2个金额到科目明细表。日终，汇总科目明细表到到科目日记账表。）
说的比较明确了，业务中只操作凭证，凭证会关联交易流水的ID的。比如一笔资金的变化，对于交易双方一增一减，必然产业两个科目的变化记录，记录在科目明细表中。
另外的科目类型、凭证类型、科目凭证对应关系都可以认为是维护的字典项目。科目从名称上理解就是一种分类方式。凭证理解为凭据、证件之类的单据吧。正好我手头上有前几天取钱的单据：中国邮储银行的通用凭证，一般是打印出来给客户签字的，可能有几联，大家都留一份，为啥要有纸质的东西？因为要有人工签名的纸头证据啊，全都电子化还不现实。
至于科目日记账：就是每天的产生的科目的统计啊，为什么每天？这个是要求吧。
至于试算平衡表：就是账户变化与科目两个不同维度变动的对比，两个角度的数据应该是一致的，应该是同一个事务产生的不同的记录方式数据的平衡。有对比才能及时发现问题，所以也应该是标准的做法。金融平台容不得半点马虎。
6.系统参数：这里就是记录各流水表的流水号的，当天不断累加的纯数字。因为当天从头开始，不能用Oracle的seq，不多讲了。
7.渠道：这个渠道从名称上来说就是一个个交易的通道，具体指啥呢，要搞搞清楚？我发现后面3.11有渠道类型与渠道管理，比如有 网银、同城、银企等5个类型。更重要的表是：渠道管理表，里面重要的字段是“支付渠道为本平台分配的商户号”，还有URL,IP,队列,类名等信息。
后面还有一个渠道账户对应表，渠道与交易类型共同PK，而且还有一个帐号，那么渠道就是本平台在其它银行之类的平台上的商户号，我平台是人家某银行的一个商户。而且还可以开几个帐号。类似于我个人是某银行一个客户，我名下有几个银行账号，有借记卡，有信用卡等，以前还可以开几个信用卡。而对平台来说，开的帐号与交易类型是相关的。
继续在网上【知乎】查了些资料：
“银行接口指的是银行等提供的技术接口。
银行通道是对银行接口的封装，并包含了诸如具体合作银行及通道的详细信息。例如同为某家商业银行的某个支付接口，非总对总的情况，支付公司可能同时在北京分行、上海分行接入。
支付渠道是对银行通道的业务封装，包含了诸如通道成本、最低商户费率等信息。
支付产品是第三方支付对外提供的产品，例如快捷支付。
支付渠道路由的设计，一般采用规则引擎或类似方案（例如基于groovy），如果单纯只是满足企业当前的业务需要，用最丑陋的If-Else方式也能搞定。”
再找到一些资料：
备付金又称为沉淀资金或准备金，第三方支付备付金是指存在第三方支付平台，为即将产生的支付交易，在银行储备的准备金。买家付款到确认收货、卖家收款总隔着几个交易日，那些“沉淀”在第三方支付机构账户上的资金就是“备付金”。后来又查到备付金只能有一个监管银行，多个合作银行，貌似政策还在微调，因为为了备付金的安全。备付金分存管（跨行）、收付（同行内收付）、汇缴（汇总一下，每日清0，转到收付账户）账户，银行渠道路由系统是所有第三方支付核心的系统之一。
（这里有https://www.zhihu.com/question/34352468，灰色细胞的解释清楚）
比如小明在网上看中了一款产品，使用了支付宝进行付款，在使用支付宝付款的时候，选择的是小明的招商银行卡，付款成功后，小明的招行账户会扣除资金，同时支付宝会将支付成功的信息告诉卖家，卖家发货。在第二天，招商银行会将小明被扣除的资金结算给支付宝，这个时候这笔钱是由银行结算给支付宝在招商银行开设的对公账户。而小明由于还没有确认收货，或者可能一周之后才会确认收货，那么在这段时间，这笔钱会一直停留在支付宝的对公账户中。（后面本人发挥：）等确认收货了，收货的方如果只到其支付宝账号，那只要记账就行了，都是在备付金中，但如果收货方要现金，就从最做优的路由方案结果中，转给对方银行账号上，一般是与对方相同的同行内的收付账号转收货方账号，支付宝此行的收付账号有头寸的话。）
好了，到这里渠道概念差不多了。有些交易的过程也非常清楚了。另外一些概念，如清分clearing,清算settlement,结算Settlement of Accounts轧差neting,头寸position也简单知道一下，英文也许更好理解。
上面写那很多，下面真正来分析表的设计：
252，253的渠道参数、返回码就是一些配置项，不多说了。251是清算指令，就是发起一个渠道的清算任务，就是一个渠道的某业务的支付场次基本情况记录，一个命令的执行情况，不涉及金额。254是渠道交易流水，既然是流水，就是具体的一个个渠道的交易信息了，一般是与支付交易流水密切相关的，只要不是平台内部的交易，就要和渠道打交道，反正信息是非常全，字段也非常的多。255是批量交易的渠道的批次表，批量交易时是很多笔的情况。里面有个settleDate居然叫轧差日期，我反正很注重命名问题，名字准确可减少了大脑中的运算，可以更好的考虑更复杂的事情。257，258渠道对账表与不平明细表，是指渠道双方对账，借贷是不是正确，从字段看不出是不是天天对账的，不过是通过文件来对账的。明细就是发现不平，要记录是哪一个交易，如果是批量的，记录下批次，可能要人工处理。我在实际中知道有人报名马拉松，出现支付成功，却网站说不成功，是系统没做好，这个可以看成是事务，不过要人工回滚或者人工补正确。
2.5.（12.13.14）分别是同城对账指令、对账表与对账明细。指令中PK是流水，那就是每一次对账都是有一个指令的。对账表与明细中都有笔数与金额数，差别从PK中可以看出。对账表对应每一个对账报文，一天内可以多个报文。明细中多了业务编号，就是按业务产生成明细，并不是细到每一个业务。15/16的下载回应与回应明细，貌似是给企业查看一天内的情况的，总的和明细的情况。应该不复杂，没有数据与页面说明也就不细究了。
（写到这里，家里网络崩溃，已经在写基金了，ITEYE页面刷新了，居然不是后台提交，也没恢复自动保存的内容，晕死....另外保存后会回到查看页面，一般应该是继续编辑吧，或者用不同的按钮...）
二、系统管理数据库
这里的系统维护、权限等与其它平台的设计差别不大，就不多研究了。
重点是账户：
结算账户余额表，就是我平台的结算账户在各个合作银行的账户上的钱数情况。
子账户类型，前面有提到平台客户可以有多个子账户，有类型就有可能互转，另外子账户会与客户的银行卡绑定，那么客户银行卡的信息有一个表，绑定有一个表；绑定变化也有一个流水表。客户的银行账号也要进行验证，验证就有一个记录，还可能一天多次验证，都记录在一个表中。
3.4.8是代付绑定收款账户，某个平台的客户根据与平台的协议，由平台代付水电煤，付到公用事业公司的相关银行账户上去。就要有一个记录。当然具体的一笔业务是另外记录的。
客户信息：这个就是平台上的客户的情况，当然客户有个人，还有企业。文章中说是不是考虑两个分开的表，因为字段差别比较大，也是有可能的。
商户信息也是要记录的。
其它的客户级别，开通的业务，相关的协议等、手续费、限额啥的就不说了，比较简单。
看一下3.11.7（记录快付通结算户之间的资金调拨指令）与3.12.3/4这三个表，结算户就是前面提到的平台在各合作银行开的收付账号，监管户就是备付金分存管账号。头寸不足时就要调拨。
三、基金相关数据库
先看一个概念：赎回是从理财产品或者基金转入你的帐户余额 提现是从帐户余额转到你的银行卡。
开户信息：在基金业务平台开立的只能是基金子账户。
业务表：申购、撤销与赎回是三个核心的业务，所以有三个相关交易的表，都与基金定单有关，说明是真正的基金购买行为了。
还有一个充提交易表，是有关子账户与银行账户之间的关系，应该只是指基金业务子账户吧。这个与基金本身操作关系不大。
基金交易一般有个T+*的问题，当日15点交易所下班的问题。
【基金赎回资金过户是T+2，也就是说，今天（T日）你申请赎回，今天收市后（就是今天晚上）基金管理公司把所有的赎回申请进行统计计算，再经过托管人的复核之后，上报至[中登公司]；在明天白天（T+1日），中登公司那帮犊子们上班之后，就会把头一天（T日）接收到的申购赎回申请统计，然后进行资金过帐，说白了就钱该给谁就给谁，基金份额该给谁给谁；然后等后天（T+2日），如果你是赎回，那这天钱都到你帐户了；如果你是申购，那基金份额就到你帐户了。】
其实基金这边也比较简单的，客户有一个基金子账户。基金管理公司能支取的是自有资金，不能支取客户受托的资金用于其他用途。客户受托的资金存放于专户，只能用于股票、债券买卖。这个与第三方支付公司的备付金一样被严格监管的。
另外指指令表，显示是与监管银行之间的交易指令、包括成功笔数，成功金额等信息，莫非基金的申购就是直接由平台打到监管银行中的基金公司的专用托管账户上？这个也不难，有人告诉一下就知道了。刚才顺便查了一下：监管、托管、存管银行的关系。有一个说监管是监督机构，存管保证的客户的信息与监管的账户之前的资金流动，而不会被基金公司挪用。
四、总结：
从网上的一个数据库设计，基本上可以学习到上面相当多的金融相关业务及其关系，配合网上的其它一些文章，差不多理解了支付业务。不过一些文章看的出政策变化是很多的，必然影响业务系统。
因为以前从没了解过相关的系统，所以分析难免有出错与不足的地方，欢迎指正！！
从来没做过金融方面的业务，于是从百度文库中找来一个第三方支付平台的数据库结构，进行分析，用通俗的语言总结出来，以掌握金融系统的业务设计。
百度文库的地址是：http://wenku.baidu.com/view/48f79722964bcf84b9d57bf1
一、基础平台核心库
1.账户：首先无论个人、企业在你平台上都有一个账户表，必须的。记录账记的基本信息，想想你的银行活期存折上的信息吧。当然5个金额要注意到，总的，可提现的，冻结的....但是有几个字段我不懂，计算积数，上期总金额等等。是的，我从来没注意过银行的活期是怎么计息的，利率在变，金额在变，怎么计？查了一下
银行按季结息，每季度末月的20日为结息日。
每次变动以头计算*持续天数=计算积数，当然从上期总金额开始算。
当季利息就是积数*计息日的日利率（年利/360，不是365是因为银行规定）
表上还有一个安全控制值，是MD5+BASE64，这个就是散列值，防止重要数据发生变化，摘要信息嘛。BASE64就是字符都变成基本的，这都可以理解。
这个，这张表就理解清楚了！！！
2.冻结、注销流水表：没啥好讲的，就是对某个账户的这种操作的日志一样的信息。
3.账户资金变动流水与冻结流水表：类似于每一次存钱，取钱的记录一样，当然实现上变动类型比较多。记录下每笔变动前后的总金额之类的。特别要注意有一个关联流水ID。比如我们充值，总金额发生了变化，但到底是怎么充的，哪个银行卡充的，成功没有，等等详细的信息这个表里都没有，却是记录在后面的充值交易流水表中。
似乎这样会有很多冗余，但这么设计是正确的，记录的角度不同，具体的每一笔变动的情况当然非常重要，但账户角度关注总金额变化。
4.交易流水相关表：这里的9张表就是9种交易的详细信息，每一笔交易都会在相关的表中记录下来。里面的详细情况如果有需要分析的后面再补了。
5.会计账务：说到会计，可能我们做软件的就不太清楚了，感觉有点专业。我也没学过，但我们分析下这几张表，同样也可以掌握基本的业务。
先说说后面两张表：科目明细与凭证明细，这个名字就知道是具体的一项业务的信息了。
（后面有备注：每种具体的业务，只操作凭证表，并设置业务关联。然后自动登记2个科目，2个金额到科目明细表。日终，汇总科目明细表到到科目日记账表。）
说的比较明确了，业务中只操作凭证，凭证会关联交易流水的ID的。比如一笔资金的变化，对于交易双方一增一减，必然产业两个科目的变化记录，记录在科目明细表中。
另外的科目类型、凭证类型、科目凭证对应关系都可以认为是维护的字典项目。科目从名称上理解就是一种分类方式。凭证理解为凭据、证件之类的单据吧。正好我手头上有前几天取钱的单据：中国邮储银行的通用凭证，一般是打印出来给客户签字的，可能有几联，大家都留一份，为啥要有纸质的东西？因为要有人工签名的纸头证据啊，全都电子化还不现实。
至于科目日记账：就是每天的产生的科目的统计啊，为什么每天？这个是要求吧。
至于试算平衡表：就是账户变化与科目两个不同维度变动的对比，两个角度的数据应该是一致的，应该是同一个事务产生的不同的记录方式数据的平衡。有对比才能及时发现问题，所以也应该是标准的做法。金融平台容不得半点马虎。
6.系统参数：这里就是记录各流水表的流水号的，当天不断累加的纯数字。因为当天从头开始，不能用Oracle的seq，不多讲了。
7.渠道：这个渠道从名称上来说就是一个个交易的通道，具体指啥呢，要搞搞清楚？我发现后面3.11有渠道类型与渠道管理，比如有 网银、同城、银企等5个类型。更重要的表是：渠道管理表，里面重要的字段是“支付渠道为本平台分配的商户号”，还有URL,IP,队列,类名等信息。
后面还有一个渠道账户对应表，渠道与交易类型共同PK，而且还有一个帐号，那么渠道就是本平台在其它银行之类的平台上的商户号，我平台是人家某银行的一个商户。而且还可以开几个帐号。类似于我个人是某银行一个客户，我名下有几个银行账号，有借记卡，有信用卡等，以前还可以开几个信用卡。而对平台来说，开的帐号与交易类型是相关的。
继续在网上【知乎】查了些资料：
“银行接口指的是银行等提供的技术接口。
银行通道是对银行接口的封装，并包含了诸如具体合作银行及通道的详细信息。例如同为某家商业银行的某个支付接口，非总对总的情况，支付公司可能同时在北京分行、上海分行接入。
支付渠道是对银行通道的业务封装，包含了诸如通道成本、最低商户费率等信息。
支付产品是第三方支付对外提供的产品，例如快捷支付。
支付渠道路由的设计，一般采用规则引擎或类似方案（例如基于groovy），如果单纯只是满足企业当前的业务需要，用最丑陋的If-Else方式也能搞定。”
再找到一些资料：
备付金又称为沉淀资金或准备金，第三方支付备付金是指存在第三方支付平台，为即将产生的支付交易，在银行储备的准备金。买家付款到确认收货、卖家收款总隔着几个交易日，那些“沉淀”在第三方支付机构账户上的资金就是“备付金”。后来又查到备付金只能有一个监管银行，多个合作银行，貌似政策还在微调，因为为了备付金的安全。备付金分存管（跨行）、收付（同行内收付）、汇缴（汇总一下，每日清0，转到收付账户）账户，银行渠道路由系统是所有第三方支付核心的系统之一。
（这里有https://www.zhihu.com/question/34352468，灰色细胞的解释清楚）
比如小明在网上看中了一款产品，使用了支付宝进行付款，在使用支付宝付款的时候，选择的是小明的招商银行卡，付款成功后，小明的招行账户会扣除资金，同时支付宝会将支付成功的信息告诉卖家，卖家发货。在第二天，招商银行会将小明被扣除的资金结算给支付宝，这个时候这笔钱是由银行结算给支付宝在招商银行开设的对公账户。而小明由于还没有确认收货，或者可能一周之后才会确认收货，那么在这段时间，这笔钱会一直停留在支付宝的对公账户中。（后面本人发挥：）等确认收货了，收货的方如果只到其支付宝账号，那只要记账就行了，都是在备付金中，但如果收货方要现金，就从最做优的路由方案结果中，转给对方银行账号上，一般是与对方相同的同行内的收付账号转收货方账号，支付宝此行的收付账号有头寸的话。）
好了，到这里渠道概念差不多了。有些交易的过程也非常清楚了。另外一些概念，如清分clearing,清算settlement,结算Settlement of Accounts轧差neting,头寸position也简单知道一下，英文也许更好理解。
上面写那很多，下面真正来分析表的设计：
252，253的渠道参数、返回码就是一些配置项，不多说了。251是清算指令，就是发起一个渠道的清算任务，就是一个渠道的某业务的支付场次基本情况记录，一个命令的执行情况，不涉及金额。254是渠道交易流水，既然是流水，就是具体的一个个渠道的交易信息了，一般是与支付交易流水密切相关的，只要不是平台内部的交易，就要和渠道打交道，反正信息是非常全，字段也非常的多。255是批量交易的渠道的批次表，批量交易时是很多笔的情况。里面有个settleDate居然叫轧差日期，我反正很注重命名问题，名字准确可减少了大脑中的运算，可以更好的考虑更复杂的事情。257，258渠道对账表与不平明细表，是指渠道双方对账，借贷是不是正确，从字段看不出是不是天天对账的，不过是通过文件来对账的。明细就是发现不平，要记录是哪一个交易，如果是批量的，记录下批次，可能要人工处理。我在实际中知道有人报名马拉松，出现支付成功，却网站说不成功，是系统没做好，这个可以看成是事务，不过要人工回滚或者人工补正确。
2.5.（12.13.14）分别是同城对账指令、对账表与对账明细。指令中PK是流水，那就是每一次对账都是有一个指令的。对账表与明细中都有笔数与金额数，差别从PK中可以看出。对账表对应每一个对账报文，一天内可以多个报文。明细中多了业务编号，就是按业务产生成明细，并不是细到每一个业务。15/16的下载回应与回应明细，貌似是给企业查看一天内的情况的，总的和明细的情况。应该不复杂，没有数据与页面说明也就不细究了。
（写到这里，家里网络崩溃，已经在写基金了，ITEYE页面刷新了，居然不是后台提交，也没恢复自动保存的内容，晕死....另外保存后会回到查看页面，一般应该是继续编辑吧，或者用不同的按钮...）
二、系统管理数据库
这里的系统维护、权限等与其它平台的设计差别不大，就不多研究了。
重点是账户：
结算账户余额表，就是我平台的结算账户在各个合作银行的账户上的钱数情况。
子账户类型，前面有提到平台客户可以有多个子账户，有类型就有可能互转，另外子账户会与客户的银行卡绑定，那么客户银行卡的信息有一个表，绑定有一个表；绑定变化也有一个流水表。客户的银行账号也要进行验证，验证就有一个记录，还可能一天多次验证，都记录在一个表中。
3.4.8是代付绑定收款账户，某个平台的客户根据与平台的协议，由平台代付水电煤，付到公用事业公司的相关银行账户上去。就要有一个记录。当然具体的一笔业务是另外记录的。
客户信息：这个就是平台上的客户的情况，当然客户有个人，还有企业。文章中说是不是考虑两个分开的表，因为字段差别比较大，也是有可能的。
商户信息也是要记录的。
其它的客户级别，开通的业务，相关的协议等、手续费、限额啥的就不说了，比较简单。
看一下3.11.7（记录快付通结算户之间的资金调拨指令）与3.12.3/4这三个表，结算户就是前面提到的平台在各合作银行开的收付账号，监管户就是备付金分存管账号。头寸不足时就要调拨。
三、基金相关数据库
先看一个概念：赎回是从理财产品或者基金转入你的帐户余额 提现是从帐户余额转到你的银行卡。
开户信息：在基金业务平台开立的只能是基金子账户。
业务表：申购、撤销与赎回是三个核心的业务，所以有三个相关交易的表，都与基金定单有关，说明是真正的基金购买行为了。
还有一个充提交易表，是有关子账户与银行账户之间的关系，应该只是指基金业务子账户吧。这个与基金本身操作关系不大。
基金交易一般有个T+*的问题，当日15点交易所下班的问题。
【基金赎回资金过户是T+2，也就是说，今天（T日）你申请赎回，今天收市后（就是今天晚上）基金管理公司把所有的赎回申请进行统计计算，再经过托管人的复核之后，上报至[中登公司]；在明天白天（T+1日），中登公司那帮犊子们上班之后，就会把头一天（T日）接收到的申购赎回申请统计，然后进行资金过帐，说白了就钱该给谁就给谁，基金份额该给谁给谁；然后等后天（T+2日），如果你是赎回，那这天钱都到你帐户了；如果你是申购，那基金份额就到你帐户了。】
其实基金这边也比较简单的，客户有一个基金子账户。基金管理公司能支取的是自有资金，不能支取客户受托的资金用于其他用途。客户受托的资金存放于专户，只能用于股票、债券买卖。这个与第三方支付公司的备付金一样被严格监管的。
另外指指令表，显示是与监管银行之间的交易指令、包括成功笔数，成功金额等信息，莫非基金的申购就是直接由平台打到监管银行中的基金公司的专用托管账户上？这个也不难，有人告诉一下就知道了。刚才顺便查了一下：监管、托管、存管银行的关系。有一个说监管是监督机构，存管保证的客户的信息与监管的账户之前的资金流动，而不会被基金公司挪用。
四、总结：
从网上的一个数据库设计，基本上可以学习到上面相当多的金融相关业务及其关系，配合网上的其它一些文章，差不多理解了支付业务。不过一些文章看的出政策变化是很多的，必然影响业务系统。
因为以前从没了解过相关的系统，所以分析难免有出错与不足的地方，欢迎指正！！